hi, while testing more corrupted images with hfsplus, i came across one which triggered the following bug: [15840.675016] BUG: unable to handle kernel paging request at fffffffb [15840.675016] IP: [<c0116a4f>] kmap+0x15/0x56 [15840.675016] *pde = 00008067 *pte = 00000000 [15840.675016] Oops: 0000 [#1] PREEMPT DEBUG_PAGEALLOC [15840.675016] Modules linked in: [15840.675016] [15840.675016] Pid: 11575, comm: ln Not tainted (2.6.27-rc4-00123-gd3ee1b4-dirty #29) [15840.675016] EIP: 0060:[<...

I haven't seen this one before. Bad page state in process 'firefox-bin' page:ffffe20001011f00 flags:0x0100000000000000 mapping:ffffe20001011f18 mapcount:0 count:0 Trying to fix it up, but a reboot is needed Backtrace: Pid: 4180, comm: firefox-bin Tainted: G W 2.6.26.3-rt3 #3 Call Trace: [<ffffffff80287a72>] bad_page+0x6f/0x9d [<ffffffff8029184c>] ? inc_zone_page_state+0x5f/0x6b [<ffffffff80289046>] free_hot_cold_page+0x88/0x1e6 [<ffffffff8028920b>] free_hot_...

may need user to have new kexec tools that could create e820 table from /sys/firmware/memmap instead of /proc/iomem for second kernel Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Cc: Bernhard Walle <bwalle@suse.de> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Index: linux-2.6/arch/x86/kernel/e820.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/e820.c +++ linux-2.6/arch/x8...

So, with newest kernel I should just leave 'iommu' out from boot options. I could try to upgrade even to 2.6.26, which Debian has in unstable repository. What, if after booting to 2.6.26 and without any 'iommu' boot parameters, there still appears "Out of Iommu space" messages? What kind of logs should I post? I'm a bit nervous due to past experience of complete hardd disk corruption. But if that was problem with the old kernel and more later versions are safer in this repect, I could once mor...

The documentation of mmiotrace describes an unimplemented feature which allows the user to write any comments on his trace by writing on a tracing/marker file. Here is an implementation of this idea. It applies on last version of tip tree. Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> --- kernel/trace/trace.c | 264 ++++++++++++++++++++++++++++++++++++-------------- kernel/trace/trace.h | 5 + 2 files changed, 198 insertions(+), 71 deletions(-) diff --git a/kernel/trace/t...

Hi, When using UML with a UML block device, and issuing a reboot, I was getting a kernel panic on the next kernel startup because UML was unable to open the file mapped to the UBD. I think this is because the file is not closed when the UBD is released, and the following patch appears to resolve this issue. I'm not sure if it's the right fix, as I may have missed something, but it works for me. -- Tom diff --git a/arch/um/drivers/ubd_kern.c b/arch/um/drivers/ubd_kern.c index b58fb89..946a17...

Compile your kernel with CONFIG_USB_DEBUG and autosuspend will be logged. Post a log. Regards Oliver --

I am experiencing a problem with PCI device on local PCI bus governed by the MV64662 chip in our board. The board runs Gentoo with kernel 2.6.9. The PCI device is trying to master PCI bus and access the SDRAM behind the MV64662 chip. The general description of the problem is that the driver at initialization writes a pattern "0xfeedface" to specific allocated memory locations in SDRAM behind the MV64662 chip and upon an interrupt, the interrupt handler checks these memory locations to see whether...

Hello, When trying to install Debian Lenny today on my new PC it booted the installation, but failed to recognise the dvd drive, and I could not continue the installer. After asking for a solution on #debian at irc.debian.org (irc.oftc.net), some users have tried to help me with this. One of them tracked down some information, and suggested me to post to this mailing list (his name was enouf). This is the information that I got: Motherboard: ASUS M3N78 Pro (according to enouf the sata control...

zap_pid_ns_processes() sets pid_ns->child_reaper = NULL, this is wrong. Yes, we have already killed all tasks in this namespace, and sys_wait4() doesn't see any child. But this doesn't mean ->children list is empty, we may have EXIT_DEAD tasks which are not visible to do_wait(). In that case the subsequent forget_original_parent() will crash the kernel because it will try to re-parent these tasks to the NULL reaper. Even if there are no childs, it is not good that forget_original_parent() u...

task_child_reaper() has no callers anymore, kill it. Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru> --- 2.6.27-rc4/include/linux/pid_namespace.h~4_KILL_HELPER 2008-07-30 13:12:48.000000000 +0400 +++ 2.6.27-rc4/include/linux/pid_namespace.h 2008-08-24 19:33:12.000000000 +0400 @@ -84,12 +84,6 @@ static inline struct pid_namespace *task return tsk->nsproxy->pid_ns; } -static inline struct task_struct *task_child_reaper(struct task_struct *tsk) -{ - BUG_ON(tsk != current); - retu...

UmUtc2VuZGluZywgYmVjYXVzZSBHbWFpbCBzZW50IHRoZSBvcmlnaW5hbCBhcyBIVE1MIGFuZCB0 aGUgbGlzdCByZWplY3RlZCBpdAoKeG0tZGViaWFuLmNmZyBmcm9tIGh0dHA6Ly9wZW9wbGUuZGVi aWFuLm9yZy9+am9leWgvZC1pL2ltYWdlcy9kYWlseQooMjQvMDgvMDgpLCBvcHRpb25zIHNlbGVj dGVkIChpZ25vcmluZyB0aGUgY29tbWVudHMgYW5kIHRoZSBjb2RlIGF0CnRoZSBib3R0b20pOgoK bWVtb3J5ID0gMjU2Cm5hbWUgPSAiZGVidGVzdDEiCnZpZiA9IFsnYnJpZGdlPWV0aDAnXQpkaXNr ID0gWydwaHk6L2Rldi9tYXBwZXIvVm9sR3JvdXAwMC1kZWJ0ZXN0MSx4dmRhLHcnXQoKZG9tVSBz dGFydGVkIGxpa2UgdGhpczoKCnhtIGNyZWF0ZSAtYyB4...

Hi Eric, So, where does this 127 come from? I can only find reference to a maximum length of 255 unicode characters (16 bits per character) in the following technical note for HFS+ (see sections "HFS Plus Names" and "Catalog Thread Records"): http://developer.apple.com/technotes/tn/tn1150.html Hmm? Pekka --

Looks good to me. Reviewed-by: Pekka Enberg <penberg@cs.helsinki.fi> --

after discussing with Ingo, we have one more generic way to detect the same situation. please help to verify the attached patch. ( don't apply previous patch) YH

After disabling CD-ROM polling the next top-100 winner is "extra timer=20 interrupt": Cn Avg residency P-states (frequencies) C0 (cpu running) ( 4.2%) 750 Mhz 0.0% polling 0.0ms ( 0.0%) 500 Mhz 100.0% C1 0.0ms ( 0.0%) C2 0.9ms (95.8%) Wakeups-from-idle per second : 1101.2 interval: 5.0s Power usage (ACPI estimate): 11.7W (2.2 hours) Top causes for wakeups: 31.6% ( 8.4) <interrupt> :...

Hi, I found this old thread /lkml/2001/10/30/256 which uncovered some mmap problems with 2.4.x kernels. I ran the test program on a 2.6.21 x86_64 with 2GB and the test program doesn't make the system unusable but it fails when it runs out of free memory and has to start recycling. This is almost the same to the original problem and I wonder whether there is a missing patch somewhere or any reason why this was not fixed in newer versions. thanks --

calibrated_APIC_clock still have two copies. it seems we should use 32 bit, because some system may not has tsc but it is some long than 64 bits... Thanks Yinghai Lu --

correct, the 32-bit calibration code looks more mature, so we should pick that. (after making sure it's properly 64-bit clean) Ingo --

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/apic_32.c | 188 +++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 188 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/apic_32.c b/arch/x86/kernel/apic_32.c index b21b772..6e99af5 100644 --- a/arch/x86/kernel/apic_32.c +++ b/arch/x86/kernel/apic_32.c @@ -90,6 +90,24 @@ static __init int setup_apicpmtimer(char *s) __setup("apicpmtimer", setup_apicpmtimer); #endif +#ifdef CONFIG_X86_64 +#de...

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/apic_32.c | 24 +++++++++++++++++++++--- arch/x86/kernel/apic_64.c | 24 ++++++++++++++++++++++-- 2 files changed, 43 insertions(+), 5 deletions(-) diff --git a/arch/x86/kernel/apic_32.c b/arch/x86/kernel/apic_32.c index 749adb5..d357038 100644 --- a/arch/x86/kernel/apic_32.c +++ b/arch/x86/kernel/apic_32.c @@ -1474,10 +1474,17 @@ int __init APIC_init_uniprocessor(void) /* * This interrupt should _never_ happen ...

Signed-off-by: Yinghai Lu <yhlu.kernel@mgail.com> --- arch/x86/kernel/apic_32.c | 20 +++++++++++ arch/x86/kernel/apic_64.c | 82 ++++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 101 insertions(+), 1 deletions(-) diff --git a/arch/x86/kernel/apic_32.c b/arch/x86/kernel/apic_32.c index 0d9c000..87566a3 100644 --- a/arch/x86/kernel/apic_32.c +++ b/arch/x86/kernel/apic_32.c @@ -1214,6 +1214,25 @@ void __cpuinit end_local_APIC_setup(void) apic_pm_activate(); } +#ifde...

except x2apic, detec_init_APIC, and calibrating_APIC_clock Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/apic_32.c | 125 ++++++++++++++++++++++++++++++++++++++++---- arch/x86/kernel/apic_64.c | 10 +++- 2 files changed, 122 insertions(+), 13 deletions(-) diff --git a/arch/x86/kernel/apic_32.c b/arch/x86/kernel/apic_32.c index 6fb2b45..294256f 100644 --- a/arch/x86/kernel/apic_32.c +++ b/arch/x86/kernel/apic_32.c @@ -66,6 +66,9 @@ static int __init parse_lapic...

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/apic_64.c | 35 +++++++++++++++++++++++------------ 1 files changed, 23 insertions(+), 12 deletions(-) diff --git a/arch/x86/kernel/apic_64.c b/arch/x86/kernel/apic_64.c index c40a900..d3ec746 100644 --- a/arch/x86/kernel/apic_64.c +++ b/arch/x86/kernel/apic_64.c @@ -82,10 +82,23 @@ static __init int setup_apicpmtimer(char *s) __setup("apicpmtimer", setup_apicpmtimer); #endif -int disable_x2apic; +#ifdef CONFIG...

From: Cyrill Gorcunov <gorcunov@gmail.com> Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/apic_32.c | 3 +++ arch/x86/kernel/apic_64.c | 2 ++ 2 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/apic_32.c b/arch/x86/kernel/apic_32.c index 63bebb3..0f52bdd 100644 --- a/arch/x86/kernel/apic_32.c +++ b/arch/x86/kernel/apic_32.c @@ -718,6 +718,9 @@ void smp_apic_timer_inte...