2.6.16-rc1-mm3
in [Kernel]
|
Next: Grant
From: Nick Piggin on 1 Feb 2006 03:40 Michal Piotrowski wrote: > Hi, > > On 26/01/06, Nick Piggin <nickpiggin(a)yahoo.com.au> wrote: > >>Nick Piggin wrote: >>Sorry, wrong patch. >> >>Note the warnings you are seeing should not result in memory >>corruption, but will result in the given hugepage leaking. >> >>-- >>SUSE Labs, Novell Inc. >> >> >>Index: linux-2.6/include/linux/mm.h >>=================================================================== >>--- linux-2.6.orig/include/linux/mm.h >>+++ linux-2.6/include/linux/mm.h >>@@ -294,6 +294,8 @@ struct page { >> */ >> static inline int put_page_testzero(struct page *page) >> { >>+ if (unlikely(PageCompound(page))) >>+ page = (struct page *)page_private(page); >> BUG_ON(atomic_read(&page->_count) == 0); >> return atomic_dec_and_test(&page->_count); >> } >> >> >> > > > Now I have got this: > > BUG: unable to handle kernel paging request at virtual address eaa34b3c > printing eip: > b0161cdd > *pde = 0048a067 > *pte = 3aa34000 > Oops: 0000 [#1] > PREEMPT SMP DEBUG_PAGEALLOC > last sysfs file: /devices/pci0000:00/0000:00:1d.1/usb3/idVendor > Modules linked in: snd_intel8x0 snd_ac97_codec snd_ac97_bus > snd_pcm_oss snd_mixer_oss snd_pcm snd_timer ide_cd cdrom intel_agp > agpgart snd i2c_i801 hw_random soundcore snd_page_alloc unix > CPU: 0 > EIP: 0060:[<b0161cdd>] Not tainted VLI > EFLAGS: 00010282 (2.6.16-rc1-mm3 #4) > EIP is at do_path_lookup+0x22b/0x259 > eax: eaa34b20 ebx: eb328000 ecx: 00000000 edx: eb328f4c > esi: ffffff9c edi: fffffffe ebp: eb328f24 esp: eb328f0c > ds: 007b es: 007b ss: 0068 > Process udevd (pid: 731, threadinfo=eb328000 task=eb30ca80) > Stack: <0>00000000 eb5cb000 b015fab1 eb5cb000 eb5cb000 00000000 > eb328f40 b01621f3 > eb328f4c ffffff9c afbf6dec afbf6dec 00000100 eb328f9c b015bf69 eb328f4c > eaa34b20 b23d5f28 00000000 eb329003 b015f8ce 00000000 00000001 00000000 > Call Trace: > [<b0103917>] show_stack_log_lvl+0xaa/0xb5 > [<b0103a54>] show_registers+0x132/0x19d > [<b0103d91>] die+0x171/0x1fb > [<b02ab110>] do_page_fault+0x3be/0x568 > [<b010343f>] error_code+0x4f/0x54 > [<b01621f3>] __user_walk_fd+0x2d/0x41 > [<b015bf69>] sys_readlinkat+0x26/0x93 > [<b015bfe9>] sys_readlink+0x13/0x15 > [<b01028bf>] sysenter_past_esp+0x54/0x75 > Code: 00 83 c0 04 e8 9a 82 14 00 8b 03 c7 80 e4 01 00 00 00 00 00 00 > 8b 55 08 8b 45 ec e8 55 fa ff ff 89 c7 8b 55 08 8b 02 85 c0 74 24 <8b> > 50 1c 85 d2 74 1d b8 00 f0 ff ff 21 e0 8b 00 83 b8 d4 04 00 > <6>ACPI: PCI Interrupt 0000:02:05.0[A] -> GSI 22 (level, low) -> IRQ 21 > > Here is dmesg: > http://www.stardust.webpages.pl/files/mm/2.6.16-rc1-mm3/mm-dmesg2 > > Here is config > http://www.stardust.webpages.pl/files/mm/2.6.16-rc1-mm3/mm-config > > Regards, > Michal Piotrowski > Thanks for testing Michal. Andrew this one looks unrelated - have you seen anything similar? Any ideas? Nick -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andrew Morton on 1 Feb 2006 04:00 Nick Piggin <nickpiggin(a)yahoo.com.au> wrote: > > > Now I have got this: > > > > BUG: unable to handle kernel paging request at virtual address eaa34b3c > > printing eip: > > b0161cdd > > *pde = 0048a067 > > *pte = 3aa34000 > > Oops: 0000 [#1] > > PREEMPT SMP DEBUG_PAGEALLOC > > last sysfs file: /devices/pci0000:00/0000:00:1d.1/usb3/idVendor > > Modules linked in: snd_intel8x0 snd_ac97_codec snd_ac97_bus > > snd_pcm_oss snd_mixer_oss snd_pcm snd_timer ide_cd cdrom intel_agp > > agpgart snd i2c_i801 hw_random soundcore snd_page_alloc unix > > CPU: 0 > > EIP: 0060:[<b0161cdd>] Not tainted VLI > > EFLAGS: 00010282 (2.6.16-rc1-mm3 #4) > > EIP is at do_path_lookup+0x22b/0x259 > > eax: eaa34b20 ebx: eb328000 ecx: 00000000 edx: eb328f4c > > esi: ffffff9c edi: fffffffe ebp: eb328f24 esp: eb328f0c > > ds: 007b es: 007b ss: 0068 > > Process udevd (pid: 731, threadinfo=eb328000 task=eb30ca80) > > Stack: <0>00000000 eb5cb000 b015fab1 eb5cb000 eb5cb000 00000000 > > eb328f40 b01621f3 > > eb328f4c ffffff9c afbf6dec afbf6dec 00000100 eb328f9c b015bf69 eb328f4c > > eaa34b20 b23d5f28 00000000 eb329003 b015f8ce 00000000 00000001 00000000 > > Call Trace: > > [<b0103917>] show_stack_log_lvl+0xaa/0xb5 > > [<b0103a54>] show_registers+0x132/0x19d > > [<b0103d91>] die+0x171/0x1fb > > [<b02ab110>] do_page_fault+0x3be/0x568 > > [<b010343f>] error_code+0x4f/0x54 > > [<b01621f3>] __user_walk_fd+0x2d/0x41 > > [<b015bf69>] sys_readlinkat+0x26/0x93 > > [<b015bfe9>] sys_readlink+0x13/0x15 > > [<b01028bf>] sysenter_past_esp+0x54/0x75 > > Code: 00 83 c0 04 e8 9a 82 14 00 8b 03 c7 80 e4 01 00 00 00 00 00 00 > > 8b 55 08 8b 45 ec e8 55 fa ff ff 89 c7 8b 55 08 8b 02 85 c0 74 24 <8b> > > 50 1c 85 d2 74 1d b8 00 f0 ff ff 21 e0 8b 00 83 b8 d4 04 00 > > <6>ACPI: PCI Interrupt 0000:02:05.0[A] -> GSI 22 (level, low) -> IRQ 21 > > > > Here is dmesg: > > http://www.stardust.webpages.pl/files/mm/2.6.16-rc1-mm3/mm-dmesg2 > > > > Here is config > > http://www.stardust.webpages.pl/files/mm/2.6.16-rc1-mm3/mm-config > > > > Regards, > > Michal Piotrowski > > > > Thanks for testing Michal. Andrew this one looks unrelated - > have you seen anything similar? No, I don't think I have. > Any ideas? This has a greggy feel to it. udev is trying to read a symlink in sysfs, probably USB-related, but it hit a bad address. It might boot OK without CONFIG_DEBUG_PAGEALLOC. Michal, it'd be useful to look up 0xb0161cdd in gdb, see what line it died at. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Michal Piotrowski on 2 Feb 2006 16:10 Hi, On 01/02/06, Andrew Morton <akpm(a)osdl.org> wrote: > Nick Piggin <nickpiggin(a)yahoo.com.au> wrote: [snip] > > Andrew this one looks unrelated - > > have you seen anything similar? > > No, I don't think I have. > > > Any ideas? > > This has a greggy feel to it. udev is trying to read a symlink in sysfs, > probably USB-related, but it hit a bad address. It might boot OK without > CONFIG_DEBUG_PAGEALLOC. > > Michal, it'd be useful to look up 0xb0161cdd in gdb, see what line it died > at. > Here is output form gdb: http://www.stardust.webpages.pl/files/mm/2.6.16-rc1-mm3/mm-do_path_lookup Regards, Michal Piotrowski PS. Sorry for late answer, but I have some exams and I don't have many free time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andrew Morton on 2 Feb 2006 17:20 Michal Piotrowski <michal.k.k.piotrowski(a)gmail.com> wrote: > > On 01/02/06, Andrew Morton <akpm(a)osdl.org> wrote: > > Nick Piggin <nickpiggin(a)yahoo.com.au> wrote: > [snip] > > > Andrew this one looks unrelated - > > > have you seen anything similar? > > > > No, I don't think I have. > > > > > Any ideas? > > > > This has a greggy feel to it. udev is trying to read a symlink in sysfs, > > probably USB-related, but it hit a bad address. It might boot OK without > > CONFIG_DEBUG_PAGEALLOC. > > > > Michal, it'd be useful to look up 0xb0161cdd in gdb, see what line it died > > at. > > > > Here is output form gdb: > http://www.stardust.webpages.pl/files/mm/2.6.16-rc1-mm3/mm-do_path_lookup I actually meant `l *0xb0161cdd' so we get file-n-line. But from that, it appears that we won't get very interesting info anyway. Oh well, let's see if this still happens in next -mm. Bugs like this have a habit of simply vanishing as people fix stuff up. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Michal Piotrowski on 2 Feb 2006 18:51
On 02/02/06, Andrew Morton <akpm(a)osdl.org> wrote: > > I actually meant `l *0xb0161cdd' so we get file-n-line. But from that, it > appears that we won't get very interesting info anyway. > > Oh well, let's see if this still happens in next -mm. Bugs like this have > a habit of simply vanishing as people fix stuff up. > I have been using -mm4 for five days (with Nick's patch) and I didn't notice this bug. Regards, Michal Piotrowski - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |