Re: Warnings and Oops on 2.6.23-rc6 while activily using rfcomm links (mm/slab.c)
On 10/1/07, Cornelia Huck <[EMAIL PROTECTED]> wrote: > On Fri, 28 Sep 2007 18:32:32 +0200, > Pierre-Yves Paulus <[EMAIL PROTECTED]> wrote: > > This looks more informational, thanks. > > > DEV: Unregistering device. ID = 'rfcomm0' > > PM: Removing info for No Bus:rfcomm0 > > kobject_uevent_env > > fill_kobj_path: path = '/class/tty/rfcomm0' > > fill_kobj_path: path = > > '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/hci2/acl00126253F906' > > kobject rfcomm0: cleaning up > > device_create_release called for rfcomm0 > > Here rfcomm0 was unregistered and released. > > > bus bluetooth: remove device acl00126253F906 > > PM: Removing info for bluetooth:acl00126253F906 > > kobject_uevent_env > > fill_kobj_path: path = > > '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/hci2/acl00126253F906' > > kobject acl00126253F906: cleaning up > > And here the corresponding physdev. > > > BUG: unable to handle kernel NULL pointer dereference at virtual address > > > > printing eip: > > c0249e29 > > *pde = > > Oops: [#1] > > Modules linked in: rfcomm l2cap battery ipv6 dm_snapshot dm_mirror > > dm_mod softdog loop parport_pc parport floppy rtc pcspkr ac button > > psmouse serio_raw snd_cs5535audio snd_ac97_codec ac97_bus snd_pcm > > snd_timer snd soundcore snd_page_alloc geode_rng cs5535_gpio hci_usb > > bluetooth geode_aes blkcipher tsdev evdev usbhid hid reiserfs ide_disk > > generic amd74xx ide_core ohci_hcd sata_via ata_generic 8139cp libata > > 8139too usbcore mii scsi_mod thermal processor fan > > CPU:0 > > EIP:0060:[]Not tainted VLI > > EFLAGS: 00010017 (2.6.23-rc8 #1) > > EIP is at skb_dequeue+0x23/0x4a > > eax: 0282 ebx: 0282 ecx: edx: caf8ab8c > > esi: c8428d48 edi: c8428c00 ebp: c8428c0c esp: c124ff60 > > ds: 007b es: 007b fs: gs: ss: 0068 > > Process events/0 (pid: 5, ti=c124e000 task=c1243500 task.ti=c124e000) > > Stack: caf8ab8c c024b0a1 c8428c00 d02f4075 c8428d60 c020eb8d c08978a8 > > > > cf7ab680 c8428d48 c020eac4 c01279a9 > > c124ffb4 > > 0046 c1243500 cf7ab680 cf7ab680 c0127ffe c124ffd0 c01280b0 > > > > Call Trace: > > [] skb_queue_purge+0x11/0x17 > > [] rfcomm_tty_flush_buffer+0x1c/0x33 [rfcomm] > > [] do_tty_hangup+0xc9/0x2d0 > > [] do_tty_hangup+0x0/0x2d0 > > [] run_workqueue+0x7d/0x103 > > [] worker_thread+0x0/0xbe > > [] worker_thread+0xb2/0xbe > > [] autoremove_wake_function+0x0/0x35 > > [] kthread+0x36/0x5b > > [] kthread+0x0/0x5b > > [] kernel_thread_helper+0x7/0x10 > > === > > rfcomm0 is already freed, maybe this code is still trying to access it? > > > Code: 89 42 0a 5b 5e 5f 5d c3 53 89 c2 9c 58 90 8d b4 26 00 00 00 00 89 > > c3 fa 90 8d b4 26 00 00 00 00 90 8b 0a 39 d1 75 04 31 c9 eb 17 <8b> 01 > > ff 4a 08 89 02 89 50 04 c7 01 00 00 00 00 c7 41 04 00 00 > > EIP: [] skb_dequeue+0x23/0x4a SS:ESP 0068:c124ff60 > > WARNING: at lib/kref.c:33 kref_get() > > [] kref_get+0x34/0x3d > > [] kobject_get+0xf/0x13 > > [] get_device+0xe/0x14 > > [] device_move+0x13/0x114 > > [] rfcomm_tty_close+0x23/0x61 [rfcomm] > > [] release_dev+0x1c0/0x54e > > [] rfcomm_dev_destruct+0x59/0x65 [rfcomm] > > [] rfcomm_dev_ioctl+0x329/0x4d0 [rfcomm] > > [] tick_program_event+0x2a/0x49 > > [] release_sock+0xc/0x74 > > [] tty_release+0x7/0xa > > [] __fput+0x93/0x147 > > [] filp_close+0x51/0x58 > > [] __sched_text_start+0x1d6/0x245 > > [] sys_close+0x54/0x83 > > [] syscall_call+0x7/0xb > > === > > DEVICE: moving 'rfcomm0' to '' > > kobject : cleaning up > > device_create_release called for rfcomm0 > > But here someone still tries to move rfcomm0 around? It already is gone > and released... The code path has no reference on rfcomm0. (Well, > device_move() tries to get a reference on the device to be moved, but > that doesn't help since the device is already gone.) > > This looks like a race inside rfcomm. The device_unregister() either > needs to be delayed until after device_move() has finished, or the > thread calling device_move() needs to have a reference. (device_move() > on an unregistered device should just fail but not oops.) Marcel? > - Hi, please try the attached patch. or the one by marcel in http://lkml.org/lkml/2007/11/5/111 Please tell me the result, thanks. Regards dave diff.rfcomm Description: Binary data
Re: Warnings and Oops on 2.6.23-rc6 while activily using rfcomm links (mm/slab.c)
On 10/1/07, Cornelia Huck [EMAIL PROTECTED] wrote:
On Fri, 28 Sep 2007 18:32:32 +0200,
Pierre-Yves Paulus [EMAIL PROTECTED] wrote:
This looks more informational, thanks.
DEV: Unregistering device. ID = 'rfcomm0'
PM: Removing info for No Bus:rfcomm0
kobject_uevent_env
fill_kobj_path: path = '/class/tty/rfcomm0'
fill_kobj_path: path =
'/devices/pci:00/:00:0f.4/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/hci2/acl00126253F906'
kobject rfcomm0: cleaning up
device_create_release called for rfcomm0
Here rfcomm0 was unregistered and released.
bus bluetooth: remove device acl00126253F906
PM: Removing info for bluetooth:acl00126253F906
kobject_uevent_env
fill_kobj_path: path =
'/devices/pci:00/:00:0f.4/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/hci2/acl00126253F906'
kobject acl00126253F906: cleaning up
And here the corresponding physdev.
BUG: unable to handle kernel NULL pointer dereference at virtual address
printing eip:
c0249e29
*pde =
Oops: [#1]
Modules linked in: rfcomm l2cap battery ipv6 dm_snapshot dm_mirror
dm_mod softdog loop parport_pc parport floppy rtc pcspkr ac button
psmouse serio_raw snd_cs5535audio snd_ac97_codec ac97_bus snd_pcm
snd_timer snd soundcore snd_page_alloc geode_rng cs5535_gpio hci_usb
bluetooth geode_aes blkcipher tsdev evdev usbhid hid reiserfs ide_disk
generic amd74xx ide_core ohci_hcd sata_via ata_generic 8139cp libata
8139too usbcore mii scsi_mod thermal processor fan
CPU:0
EIP:0060:[c0249e29]Not tainted VLI
EFLAGS: 00010017 (2.6.23-rc8 #1)
EIP is at skb_dequeue+0x23/0x4a
eax: 0282 ebx: 0282 ecx: edx: caf8ab8c
esi: c8428d48 edi: c8428c00 ebp: c8428c0c esp: c124ff60
ds: 007b es: 007b fs: gs: ss: 0068
Process events/0 (pid: 5, ti=c124e000 task=c1243500 task.ti=c124e000)
Stack: caf8ab8c c024b0a1 c8428c00 d02f4075 c8428d60 c020eb8d c08978a8
cf7ab680 c8428d48 c020eac4 c01279a9
c124ffb4
0046 c1243500 cf7ab680 cf7ab680 c0127ffe c124ffd0 c01280b0
Call Trace:
[c024b0a1] skb_queue_purge+0x11/0x17
[d02f4075] rfcomm_tty_flush_buffer+0x1c/0x33 [rfcomm]
[c020eb8d] do_tty_hangup+0xc9/0x2d0
[c020eac4] do_tty_hangup+0x0/0x2d0
[c01279a9] run_workqueue+0x7d/0x103
[c0127ffe] worker_thread+0x0/0xbe
[c01280b0] worker_thread+0xb2/0xbe
[c012a510] autoremove_wake_function+0x0/0x35
[c012a363] kthread+0x36/0x5b
[c012a32d] kthread+0x0/0x5b
[c0104e17] kernel_thread_helper+0x7/0x10
===
rfcomm0 is already freed, maybe this code is still trying to access it?
Code: 89 42 0a 5b 5e 5f 5d c3 53 89 c2 9c 58 90 8d b4 26 00 00 00 00 89
c3 fa 90 8d b4 26 00 00 00 00 90 8b 0a 39 d1 75 04 31 c9 eb 17 8b 01
ff 4a 08 89 02 89 50 04 c7 01 00 00 00 00 c7 41 04 00 00
EIP: [c0249e29] skb_dequeue+0x23/0x4a SS:ESP 0068:c124ff60
WARNING: at lib/kref.c:33 kref_get()
[c01c6db7] kref_get+0x34/0x3d
[c01c61a9] kobject_get+0xf/0x13
[c022578d] get_device+0xe/0x14
[c02257a6] device_move+0x13/0x114
[d02f4b7c] rfcomm_tty_close+0x23/0x61 [rfcomm]
[c020f88d] release_dev+0x1c0/0x54e
[d02f40e5] rfcomm_dev_destruct+0x59/0x65 [rfcomm]
[d02f4725] rfcomm_dev_ioctl+0x329/0x4d0 [rfcomm]
[c0130c96] tick_program_event+0x2a/0x49
[c0248124] release_sock+0xc/0x74
[c020fc22] tty_release+0x7/0xa
[c015dabd] __fput+0x93/0x147
[c015b66a] filp_close+0x51/0x58
[c02a8b0e] __sched_text_start+0x1d6/0x245
[c015c70b] sys_close+0x54/0x83
[c0103c72] syscall_call+0x7/0xb
===
DEVICE: moving 'rfcomm0' to 'NULL'
kobject NULL: cleaning up
device_create_release called for rfcomm0
But here someone still tries to move rfcomm0 around? It already is gone
and released... The code path has no reference on rfcomm0. (Well,
device_move() tries to get a reference on the device to be moved, but
that doesn't help since the device is already gone.)
This looks like a race inside rfcomm. The device_unregister() either
needs to be delayed until after device_move() has finished, or the
thread calling device_move() needs to have a reference. (device_move()
on an unregistered device should just fail but not oops.) Marcel?
-
Hi,
please try the attached patch.
or the one by marcel in http://lkml.org/lkml/2007/11/5/111
Please tell me the result, thanks.
Regards
dave
diff.rfcomm
Description: Binary data
Re: Warnings and Oops on 2.6.23-rc6 while activily using rfcomm links (mm/slab.c)
On Fri, 28 Sep 2007 18:32:32 +0200, Pierre-Yves Paulus <[EMAIL PROTECTED]> wrote: This looks more informational, thanks. > DEV: Unregistering device. ID = 'rfcomm0' > PM: Removing info for No Bus:rfcomm0 > kobject_uevent_env > fill_kobj_path: path = '/class/tty/rfcomm0' > fill_kobj_path: path = > '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/hci2/acl00126253F906' > kobject rfcomm0: cleaning up > device_create_release called for rfcomm0 Here rfcomm0 was unregistered and released. > bus bluetooth: remove device acl00126253F906 > PM: Removing info for bluetooth:acl00126253F906 > kobject_uevent_env > fill_kobj_path: path = > '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/hci2/acl00126253F906' > kobject acl00126253F906: cleaning up And here the corresponding physdev. > BUG: unable to handle kernel NULL pointer dereference at virtual address > > printing eip: > c0249e29 > *pde = > Oops: [#1] > Modules linked in: rfcomm l2cap battery ipv6 dm_snapshot dm_mirror > dm_mod softdog loop parport_pc parport floppy rtc pcspkr ac button > psmouse serio_raw snd_cs5535audio snd_ac97_codec ac97_bus snd_pcm > snd_timer snd soundcore snd_page_alloc geode_rng cs5535_gpio hci_usb > bluetooth geode_aes blkcipher tsdev evdev usbhid hid reiserfs ide_disk > generic amd74xx ide_core ohci_hcd sata_via ata_generic 8139cp libata > 8139too usbcore mii scsi_mod thermal processor fan > CPU:0 > EIP:0060:[]Not tainted VLI > EFLAGS: 00010017 (2.6.23-rc8 #1) > EIP is at skb_dequeue+0x23/0x4a > eax: 0282 ebx: 0282 ecx: edx: caf8ab8c > esi: c8428d48 edi: c8428c00 ebp: c8428c0c esp: c124ff60 > ds: 007b es: 007b fs: gs: ss: 0068 > Process events/0 (pid: 5, ti=c124e000 task=c1243500 task.ti=c124e000) > Stack: caf8ab8c c024b0a1 c8428c00 d02f4075 c8428d60 c020eb8d c08978a8 > > cf7ab680 c8428d48 c020eac4 c01279a9 > c124ffb4 > 0046 c1243500 cf7ab680 cf7ab680 c0127ffe c124ffd0 c01280b0 > > Call Trace: > [] skb_queue_purge+0x11/0x17 > [] rfcomm_tty_flush_buffer+0x1c/0x33 [rfcomm] > [] do_tty_hangup+0xc9/0x2d0 > [] do_tty_hangup+0x0/0x2d0 > [] run_workqueue+0x7d/0x103 > [] worker_thread+0x0/0xbe > [] worker_thread+0xb2/0xbe > [] autoremove_wake_function+0x0/0x35 > [] kthread+0x36/0x5b > [] kthread+0x0/0x5b > [] kernel_thread_helper+0x7/0x10 > === rfcomm0 is already freed, maybe this code is still trying to access it? > Code: 89 42 0a 5b 5e 5f 5d c3 53 89 c2 9c 58 90 8d b4 26 00 00 00 00 89 > c3 fa 90 8d b4 26 00 00 00 00 90 8b 0a 39 d1 75 04 31 c9 eb 17 <8b> 01 > ff 4a 08 89 02 89 50 04 c7 01 00 00 00 00 c7 41 04 00 00 > EIP: [] skb_dequeue+0x23/0x4a SS:ESP 0068:c124ff60 > WARNING: at lib/kref.c:33 kref_get() > [] kref_get+0x34/0x3d > [] kobject_get+0xf/0x13 > [] get_device+0xe/0x14 > [] device_move+0x13/0x114 > [] rfcomm_tty_close+0x23/0x61 [rfcomm] > [] release_dev+0x1c0/0x54e > [] rfcomm_dev_destruct+0x59/0x65 [rfcomm] > [] rfcomm_dev_ioctl+0x329/0x4d0 [rfcomm] > [] tick_program_event+0x2a/0x49 > [] release_sock+0xc/0x74 > [] tty_release+0x7/0xa > [] __fput+0x93/0x147 > [] filp_close+0x51/0x58 > [] __sched_text_start+0x1d6/0x245 > [] sys_close+0x54/0x83 > [] syscall_call+0x7/0xb > === > DEVICE: moving 'rfcomm0' to '' > kobject : cleaning up > device_create_release called for rfcomm0 But here someone still tries to move rfcomm0 around? It already is gone and released... The code path has no reference on rfcomm0. (Well, device_move() tries to get a reference on the device to be moved, but that doesn't help since the device is already gone.) This looks like a race inside rfcomm. The device_unregister() either needs to be delayed until after device_move() has finished, or the thread calling device_move() needs to have a reference. (device_move() on an unregistered device should just fail but not oops.) Marcel? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Warnings and Oops on 2.6.23-rc6 while activily using rfcomm links (mm/slab.c)
On Fri, 28 Sep 2007 18:32:32 +0200, Pierre-Yves Paulus [EMAIL PROTECTED] wrote: This looks more informational, thanks. DEV: Unregistering device. ID = 'rfcomm0' PM: Removing info for No Bus:rfcomm0 kobject_uevent_env fill_kobj_path: path = '/class/tty/rfcomm0' fill_kobj_path: path = '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/hci2/acl00126253F906' kobject rfcomm0: cleaning up device_create_release called for rfcomm0 Here rfcomm0 was unregistered and released. bus bluetooth: remove device acl00126253F906 PM: Removing info for bluetooth:acl00126253F906 kobject_uevent_env fill_kobj_path: path = '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/hci2/acl00126253F906' kobject acl00126253F906: cleaning up And here the corresponding physdev. BUG: unable to handle kernel NULL pointer dereference at virtual address printing eip: c0249e29 *pde = Oops: [#1] Modules linked in: rfcomm l2cap battery ipv6 dm_snapshot dm_mirror dm_mod softdog loop parport_pc parport floppy rtc pcspkr ac button psmouse serio_raw snd_cs5535audio snd_ac97_codec ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc geode_rng cs5535_gpio hci_usb bluetooth geode_aes blkcipher tsdev evdev usbhid hid reiserfs ide_disk generic amd74xx ide_core ohci_hcd sata_via ata_generic 8139cp libata 8139too usbcore mii scsi_mod thermal processor fan CPU:0 EIP:0060:[c0249e29]Not tainted VLI EFLAGS: 00010017 (2.6.23-rc8 #1) EIP is at skb_dequeue+0x23/0x4a eax: 0282 ebx: 0282 ecx: edx: caf8ab8c esi: c8428d48 edi: c8428c00 ebp: c8428c0c esp: c124ff60 ds: 007b es: 007b fs: gs: ss: 0068 Process events/0 (pid: 5, ti=c124e000 task=c1243500 task.ti=c124e000) Stack: caf8ab8c c024b0a1 c8428c00 d02f4075 c8428d60 c020eb8d c08978a8 cf7ab680 c8428d48 c020eac4 c01279a9 c124ffb4 0046 c1243500 cf7ab680 cf7ab680 c0127ffe c124ffd0 c01280b0 Call Trace: [c024b0a1] skb_queue_purge+0x11/0x17 [d02f4075] rfcomm_tty_flush_buffer+0x1c/0x33 [rfcomm] [c020eb8d] do_tty_hangup+0xc9/0x2d0 [c020eac4] do_tty_hangup+0x0/0x2d0 [c01279a9] run_workqueue+0x7d/0x103 [c0127ffe] worker_thread+0x0/0xbe [c01280b0] worker_thread+0xb2/0xbe [c012a510] autoremove_wake_function+0x0/0x35 [c012a363] kthread+0x36/0x5b [c012a32d] kthread+0x0/0x5b [c0104e17] kernel_thread_helper+0x7/0x10 === rfcomm0 is already freed, maybe this code is still trying to access it? Code: 89 42 0a 5b 5e 5f 5d c3 53 89 c2 9c 58 90 8d b4 26 00 00 00 00 89 c3 fa 90 8d b4 26 00 00 00 00 90 8b 0a 39 d1 75 04 31 c9 eb 17 8b 01 ff 4a 08 89 02 89 50 04 c7 01 00 00 00 00 c7 41 04 00 00 EIP: [c0249e29] skb_dequeue+0x23/0x4a SS:ESP 0068:c124ff60 WARNING: at lib/kref.c:33 kref_get() [c01c6db7] kref_get+0x34/0x3d [c01c61a9] kobject_get+0xf/0x13 [c022578d] get_device+0xe/0x14 [c02257a6] device_move+0x13/0x114 [d02f4b7c] rfcomm_tty_close+0x23/0x61 [rfcomm] [c020f88d] release_dev+0x1c0/0x54e [d02f40e5] rfcomm_dev_destruct+0x59/0x65 [rfcomm] [d02f4725] rfcomm_dev_ioctl+0x329/0x4d0 [rfcomm] [c0130c96] tick_program_event+0x2a/0x49 [c0248124] release_sock+0xc/0x74 [c020fc22] tty_release+0x7/0xa [c015dabd] __fput+0x93/0x147 [c015b66a] filp_close+0x51/0x58 [c02a8b0e] __sched_text_start+0x1d6/0x245 [c015c70b] sys_close+0x54/0x83 [c0103c72] syscall_call+0x7/0xb === DEVICE: moving 'rfcomm0' to 'NULL' kobject NULL: cleaning up device_create_release called for rfcomm0 But here someone still tries to move rfcomm0 around? It already is gone and released... The code path has no reference on rfcomm0. (Well, device_move() tries to get a reference on the device to be moved, but that doesn't help since the device is already gone.) This looks like a race inside rfcomm. The device_unregister() either needs to be delayed until after device_move() has finished, or the thread calling device_move() needs to have a reference. (device_move() on an unregistered device should just fail but not oops.) Marcel? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Warnings and Oops on 2.6.23-rc6 while activily using rfcomm links (mm/slab.c)
Hello, I applied it, and re-tested without enabling slub debugging this time. I got one Oops so far, but it seems it didn't hit your patch's log statement. Testing is going on... Another one, still not hitting it. After the first Oops happened, I issued a reboot command, but it hung with a second Oops (see the very bottom). At that point I had to hard-reset the box. Linux version 2.6.23-rc8 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 Fri Sep 28 17:12:14 CEST 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009e800 (usable) BIOS-e820: 0009e800 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 0f7b (usable) BIOS-e820: 0f7b - 0f7b3000 (ACPI NVS) BIOS-e820: 0f7b3000 - 0f7c (ACPI data) BIOS-e820: - 0001 (reserved) 247MB LOWMEM available. Zone PFN ranges: DMA 0 -> 4096 Normal 4096 ->63408 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 ->63408 DMI 2.2 present. ACPI: RSDP 000F63C0, 0014 (r0 AMDGX3) ACPI: RSDT 0F7B3040, 0028 (r1 AMDGX3 AWRDACPI 42302E31 AWRD0) ACPI: FACP 0F7B30C0, 0074 (r1 AMDGX3 AWRDACPI 42302E31 AWRD0) ACPI: DSDT 0F7B3180, 35BD (r1 AMDGX3 AWRDACPI 1000 MSFT 10E) ACPI: FACS 0F7B, 0040 ACPI: PM-Timer IO Port: 0x9c10 Allocating PCI resources starting at 1000 (gap: 0f7c:f083) swsusp: Registered nosave memory region: 0009e000 - 0009f000 swsusp: Registered nosave memory region: 0009f000 - 000a swsusp: Registered nosave memory region: 000a - 000f swsusp: Registered nosave memory region: 000f - 0010 Built 1 zonelists in Zone order. Total pages: 62913 Kernel command line: root=UUID=c925de24-972b-437c-860f-8109d900aa4b ro panic=60 console=ttyS1,38400 console=tty0 No local APIC present or hardware disabled Initializing CPU#0 PID hash table entries: 1024 (order: 10, 4096 bytes) Detected 498.063 MHz processor. Console: colour VGA+ 80x25 console [tty0] enabled console [ttyS1] enabled Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 243152k/253632k available (1707k kernel code, 9908k reserved, 679k data, 312k init, 0k highmem) virtual kernel memory layout: fixmap : 0xfffb3000 - 0xf000 ( 304 kB) vmalloc : 0xd000 - 0xfffb1000 ( 767 MB) lowmem : 0xc000 - 0xcf7b ( 247 MB) .init : 0xc0358000 - 0xc03a6000 ( 312 kB) .data : 0xc02aac35 - 0xc0354aa4 ( 679 kB) .text : 0xc010 - 0xc02aac35 (1707 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. SLUB: Genslabs=22, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1 Calibrating delay using timer specific routine.. 997.66 BogoMIPS (lpj=1995333) Security Framework v1.0.0 initialized SELinux: Disabled at boot. Capability LSM initialized Mount-cache hash table entries: 512 CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line) CPU: L2 Cache: 128K (32 bytes/line) Compat vDSO mapped to e000. CPU: AMD Geode(TM) Integrated Processor by AMD PCS stepping 02 Checking 'hlt' instruction... OK. ACPI: Core revision 20070126 ACPI: setting ELCR to 0200 (from 0c00) Booting paravirtualized kernel on bare hardware NET: Registered protocol family 16 EISA bus registered ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xfa740, last bus=0 PCI: Using configuration type 1 Setting up standard PCI resources ACPI: Interpreter enabled ACPI: (supports S0 S1 S5) ACPI: Using PIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11) ACPI: PCI Interrupt Link [LNKB] (IRQs 5 10 *11) ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 11) *0 ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 11) *0 Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init ACPI: bus type pnp registered pnp: PnP ACPI: found 13 devices ACPI: ACPI bus type pnp unregistered PnPBIOS: Disabled by ACPI PNP PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report NET: Registered protocol family 8 NET: Registered protocol family 20 ACPI: RTC can wake from S4 Time: tsc clocksource has been installed. pnp: 00:00: iomem range 0xf-0xf3fff could not be reserved pnp: 00:00: iomem range 0xf4000-0xf7fff could not be reserved pnp: 00:00: iomem range 0xf8000-0xfbfff could not be reserved pnp: 00:00: iomem range 0xfc000-0xf could not be reserved NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 3, 32768 bytes) TCP: Hash tables
Re: Warnings and Oops on 2.6.23-rc6 while activily using rfcomm links (mm/slab.c)
Hello,
This looks suspiciously like someone tried to decrease a refcount on a
freed kobject. Unfortunately, we only see this after the fact with slub
debugging turned on :( So could you please turn it off again (but leave
kobject debugging on) and try with the following silly debug patch:
---
lib/kobject.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
--- linux-2.6.orig/lib/kobject.c
+++ linux-2.6/lib/kobject.c
@@ -502,8 +502,12 @@ static void kobject_release(struct kref
*/
void kobject_put(struct kobject * kobj)
{
- if (kobj)
+ if (kobj) {
+ if (!atomic_read(>kref.refcount))
+ pr_debug("%s: kobject [EMAIL PROTECTED] already has zero
refcount!\n",
+__FUNCTION__, kobj->name, kobj);
kref_put(>kref, kobject_release);
+ }
}
I applied it, and re-tested without enabling slub debugging this time. I
got one Oops so far, but it seems it didn't hit your patch's log
statement. Testing is going on...
Linux version 2.6.23-rc8 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115
(prerelease) (Debian 4.1.1-21)) #1 Fri Sep 28 17:12:14 CEST 2007
BIOS-provided physical RAM map:
BIOS-e820: - 0009e800 (usable)
BIOS-e820: 0009e800 - 000a (reserved)
BIOS-e820: 000f - 0010 (reserved)
BIOS-e820: 0010 - 0f7b (usable)
BIOS-e820: 0f7b - 0f7b3000 (ACPI NVS)
BIOS-e820: 0f7b3000 - 0f7c (ACPI data)
BIOS-e820: - 0001 (reserved)
247MB LOWMEM available.
Zone PFN ranges:
DMA 0 -> 4096
Normal 4096 ->63408
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0:0 ->63408
DMI 2.2 present.
ACPI: RSDP 000F63C0, 0014 (r0 AMDGX3)
ACPI: RSDT 0F7B3040, 0028 (r1 AMDGX3 AWRDACPI 42302E31 AWRD0)
ACPI: FACP 0F7B30C0, 0074 (r1 AMDGX3 AWRDACPI 42302E31 AWRD0)
ACPI: DSDT 0F7B3180, 35BD (r1 AMDGX3 AWRDACPI 1000 MSFT 10E)
ACPI: FACS 0F7B, 0040
ACPI: PM-Timer IO Port: 0x9c10
Allocating PCI resources starting at 1000 (gap: 0f7c:f083)
swsusp: Registered nosave memory region: 0009e000 - 0009f000
swsusp: Registered nosave memory region: 0009f000 - 000a
swsusp: Registered nosave memory region: 000a - 000f
swsusp: Registered nosave memory region: 000f - 0010
Built 1 zonelists in Zone order. Total pages: 62913
Kernel command line: root=UUID=c925de24-972b-437c-860f-8109d900aa4b ro
panic=60 console=ttyS1,38400 console=tty0
No local APIC present or hardware disabled
Initializing CPU#0
PID hash table entries: 1024 (order: 10, 4096 bytes)
Detected 498.060 MHz processor.
Console: colour VGA+ 80x25
console [tty0] enabled
console [ttyS1] enabled
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 243152k/253632k available (1707k kernel code, 9908k reserved,
679k data, 312k init, 0k highmem)
virtual kernel memory layout:
fixmap : 0xfffb3000 - 0xf000 ( 304 kB)
vmalloc : 0xd000 - 0xfffb1000 ( 767 MB)
lowmem : 0xc000 - 0xcf7b ( 247 MB)
.init : 0xc0358000 - 0xc03a6000 ( 312 kB)
.data : 0xc02aac35 - 0xc0354aa4 ( 679 kB)
.text : 0xc010 - 0xc02aac35 (1707 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
SLUB: Genslabs=22, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1
Calibrating delay using timer specific routine.. 997.66 BogoMIPS
(lpj=1995326)
Security Framework v1.0.0 initialized
SELinux: Disabled at boot.
Capability LSM initialized
Mount-cache hash table entries: 512
CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line)
CPU: L2 Cache: 128K (32 bytes/line)
Compat vDSO mapped to e000.
CPU: AMD Geode(TM) Integrated Processor by AMD PCS stepping 02
Checking 'hlt' instruction... OK.
ACPI: Core revision 20070126
ACPI: setting ELCR to 0200 (from 0c00)
Booting paravirtualized kernel on bare hardware
NET: Registered protocol family 16
EISA bus registered
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfa740, last bus=0
PCI: Using configuration type 1
Setting up standard PCI resources
ACPI: Interpreter enabled
ACPI: (supports S0 S1 S5)
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (:00)
ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 5 10 *11)
ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 11) *0
ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 11) *0
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 13 devices
ACPI: ACPI bus type pnp unregistered
PnPBIOS: Disabled by ACPI PNP
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try
Re: Warnings and Oops on 2.6.23-rc6 while activily using rfcomm links (mm/slab.c)
On Thu, 27 Sep 2007 20:07:54 +0200,
Pierre-Yves Paulus <[EMAIL PROTECTED]> wrote:
> Another one below, complete log from power-up to reboot, with some bugs
> and one Oops. I only trimmed the numerous "l2cap_recv_acldata" and "ACL
> packet for unknown connection handle" lines which always fill up the log.
Hmm, looked at it, but currently I can't see what's wrong from a driver
core perspective...
> =
> BUG kmalloc-128: Poison overwritten
> -
>
> INFO: 0xc5734f28-0xc5734f40. First byte 0x6a instead of 0x6b
> INFO: Allocated in rfcomm_dev_ioctl+0xbd/0x4e6 [rfcomm] age=6110 cpu=0
> pid=3677
> INFO: Freed in rfcomm_dev_destruct+0x59/0x65 [rfcomm] age=3157 cpu=0
> pid=3927
> INFO: Slab 0xc10ae680 used=21 fp=0xc5734f20 flags=0x40c2
> INFO: Object 0xc5734f20 @offset=3872 fp=0xc57342c0
>
> Bytes b4 0xc5734f10: 05 00 00 00 f8 23 0f 00 5a 5a 5a 5a 5a 5a 5a 5a
> ø#..
>Object 0xc5734f20: 6b 6b 6b 6b 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b
^^
This looks suspiciously like someone tried to decrease a refcount on a
freed kobject. Unfortunately, we only see this after the fact with slub
debugging turned on :( So could you please turn it off again (but leave
kobject debugging on) and try with the following silly debug patch:
---
lib/kobject.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
--- linux-2.6.orig/lib/kobject.c
+++ linux-2.6/lib/kobject.c
@@ -502,8 +502,12 @@ static void kobject_release(struct kref
*/
void kobject_put(struct kobject * kobj)
{
- if (kobj)
+ if (kobj) {
+ if (!atomic_read(>kref.refcount))
+ pr_debug("%s: kobject [EMAIL PROTECTED] already has
zero refcount!\n",
+__FUNCTION__, kobj->name, kobj);
kref_put(>kref, kobject_release);
+ }
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Warnings and Oops on 2.6.23-rc6 while activily using rfcomm links (mm/slab.c)
On Thu, 27 Sep 2007 20:07:54 +0200,
Pierre-Yves Paulus [EMAIL PROTECTED] wrote:
Another one below, complete log from power-up to reboot, with some bugs
and one Oops. I only trimmed the numerous l2cap_recv_acldata and ACL
packet for unknown connection handle lines which always fill up the log.
Hmm, looked at it, but currently I can't see what's wrong from a driver
core perspective...
=
BUG kmalloc-128: Poison overwritten
-
INFO: 0xc5734f28-0xc5734f40. First byte 0x6a instead of 0x6b
INFO: Allocated in rfcomm_dev_ioctl+0xbd/0x4e6 [rfcomm] age=6110 cpu=0
pid=3677
INFO: Freed in rfcomm_dev_destruct+0x59/0x65 [rfcomm] age=3157 cpu=0
pid=3927
INFO: Slab 0xc10ae680 used=21 fp=0xc5734f20 flags=0x40c2
INFO: Object 0xc5734f20 @offset=3872 fp=0xc57342c0
Bytes b4 0xc5734f10: 05 00 00 00 f8 23 0f 00 5a 5a 5a 5a 5a 5a 5a 5a
ø#..
Object 0xc5734f20: 6b 6b 6b 6b 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b
^^
This looks suspiciously like someone tried to decrease a refcount on a
freed kobject. Unfortunately, we only see this after the fact with slub
debugging turned on :( So could you please turn it off again (but leave
kobject debugging on) and try with the following silly debug patch:
---
lib/kobject.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
--- linux-2.6.orig/lib/kobject.c
+++ linux-2.6/lib/kobject.c
@@ -502,8 +502,12 @@ static void kobject_release(struct kref
*/
void kobject_put(struct kobject * kobj)
{
- if (kobj)
+ if (kobj) {
+ if (!atomic_read(kobj-kref.refcount))
+ pr_debug(%s: kobject [EMAIL PROTECTED] already has
zero refcount!\n,
+__FUNCTION__, kobj-name, kobj);
kref_put(kobj-kref, kobject_release);
+ }
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Warnings and Oops on 2.6.23-rc6 while activily using rfcomm links (mm/slab.c)
Hello,
This looks suspiciously like someone tried to decrease a refcount on a
freed kobject. Unfortunately, we only see this after the fact with slub
debugging turned on :( So could you please turn it off again (but leave
kobject debugging on) and try with the following silly debug patch:
---
lib/kobject.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
--- linux-2.6.orig/lib/kobject.c
+++ linux-2.6/lib/kobject.c
@@ -502,8 +502,12 @@ static void kobject_release(struct kref
*/
void kobject_put(struct kobject * kobj)
{
- if (kobj)
+ if (kobj) {
+ if (!atomic_read(kobj-kref.refcount))
+ pr_debug(%s: kobject [EMAIL PROTECTED] already has zero
refcount!\n,
+__FUNCTION__, kobj-name, kobj);
kref_put(kobj-kref, kobject_release);
+ }
}
I applied it, and re-tested without enabling slub debugging this time. I
got one Oops so far, but it seems it didn't hit your patch's log
statement. Testing is going on...
Linux version 2.6.23-rc8 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115
(prerelease) (Debian 4.1.1-21)) #1 Fri Sep 28 17:12:14 CEST 2007
BIOS-provided physical RAM map:
BIOS-e820: - 0009e800 (usable)
BIOS-e820: 0009e800 - 000a (reserved)
BIOS-e820: 000f - 0010 (reserved)
BIOS-e820: 0010 - 0f7b (usable)
BIOS-e820: 0f7b - 0f7b3000 (ACPI NVS)
BIOS-e820: 0f7b3000 - 0f7c (ACPI data)
BIOS-e820: - 0001 (reserved)
247MB LOWMEM available.
Zone PFN ranges:
DMA 0 - 4096
Normal 4096 -63408
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0:0 -63408
DMI 2.2 present.
ACPI: RSDP 000F63C0, 0014 (r0 AMDGX3)
ACPI: RSDT 0F7B3040, 0028 (r1 AMDGX3 AWRDACPI 42302E31 AWRD0)
ACPI: FACP 0F7B30C0, 0074 (r1 AMDGX3 AWRDACPI 42302E31 AWRD0)
ACPI: DSDT 0F7B3180, 35BD (r1 AMDGX3 AWRDACPI 1000 MSFT 10E)
ACPI: FACS 0F7B, 0040
ACPI: PM-Timer IO Port: 0x9c10
Allocating PCI resources starting at 1000 (gap: 0f7c:f083)
swsusp: Registered nosave memory region: 0009e000 - 0009f000
swsusp: Registered nosave memory region: 0009f000 - 000a
swsusp: Registered nosave memory region: 000a - 000f
swsusp: Registered nosave memory region: 000f - 0010
Built 1 zonelists in Zone order. Total pages: 62913
Kernel command line: root=UUID=c925de24-972b-437c-860f-8109d900aa4b ro
panic=60 console=ttyS1,38400 console=tty0
No local APIC present or hardware disabled
Initializing CPU#0
PID hash table entries: 1024 (order: 10, 4096 bytes)
Detected 498.060 MHz processor.
Console: colour VGA+ 80x25
console [tty0] enabled
console [ttyS1] enabled
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 243152k/253632k available (1707k kernel code, 9908k reserved,
679k data, 312k init, 0k highmem)
virtual kernel memory layout:
fixmap : 0xfffb3000 - 0xf000 ( 304 kB)
vmalloc : 0xd000 - 0xfffb1000 ( 767 MB)
lowmem : 0xc000 - 0xcf7b ( 247 MB)
.init : 0xc0358000 - 0xc03a6000 ( 312 kB)
.data : 0xc02aac35 - 0xc0354aa4 ( 679 kB)
.text : 0xc010 - 0xc02aac35 (1707 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
SLUB: Genslabs=22, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1
Calibrating delay using timer specific routine.. 997.66 BogoMIPS
(lpj=1995326)
Security Framework v1.0.0 initialized
SELinux: Disabled at boot.
Capability LSM initialized
Mount-cache hash table entries: 512
CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line)
CPU: L2 Cache: 128K (32 bytes/line)
Compat vDSO mapped to e000.
CPU: AMD Geode(TM) Integrated Processor by AMD PCS stepping 02
Checking 'hlt' instruction... OK.
ACPI: Core revision 20070126
ACPI: setting ELCR to 0200 (from 0c00)
Booting paravirtualized kernel on bare hardware
NET: Registered protocol family 16
EISA bus registered
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfa740, last bus=0
PCI: Using configuration type 1
Setting up standard PCI resources
ACPI: Interpreter enabled
ACPI: (supports S0 S1 S5)
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (:00)
ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 5 10 *11)
ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 11) *0
ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 11) *0
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 13 devices
ACPI: ACPI bus type pnp unregistered
PnPBIOS: Disabled by ACPI PNP
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try
Re: Warnings and Oops on 2.6.23-rc6 while activily using rfcomm links (mm/slab.c)
Hello, I applied it, and re-tested without enabling slub debugging this time. I got one Oops so far, but it seems it didn't hit your patch's log statement. Testing is going on... Another one, still not hitting it. After the first Oops happened, I issued a reboot command, but it hung with a second Oops (see the very bottom). At that point I had to hard-reset the box. Linux version 2.6.23-rc8 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 Fri Sep 28 17:12:14 CEST 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009e800 (usable) BIOS-e820: 0009e800 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 0f7b (usable) BIOS-e820: 0f7b - 0f7b3000 (ACPI NVS) BIOS-e820: 0f7b3000 - 0f7c (ACPI data) BIOS-e820: - 0001 (reserved) 247MB LOWMEM available. Zone PFN ranges: DMA 0 - 4096 Normal 4096 -63408 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -63408 DMI 2.2 present. ACPI: RSDP 000F63C0, 0014 (r0 AMDGX3) ACPI: RSDT 0F7B3040, 0028 (r1 AMDGX3 AWRDACPI 42302E31 AWRD0) ACPI: FACP 0F7B30C0, 0074 (r1 AMDGX3 AWRDACPI 42302E31 AWRD0) ACPI: DSDT 0F7B3180, 35BD (r1 AMDGX3 AWRDACPI 1000 MSFT 10E) ACPI: FACS 0F7B, 0040 ACPI: PM-Timer IO Port: 0x9c10 Allocating PCI resources starting at 1000 (gap: 0f7c:f083) swsusp: Registered nosave memory region: 0009e000 - 0009f000 swsusp: Registered nosave memory region: 0009f000 - 000a swsusp: Registered nosave memory region: 000a - 000f swsusp: Registered nosave memory region: 000f - 0010 Built 1 zonelists in Zone order. Total pages: 62913 Kernel command line: root=UUID=c925de24-972b-437c-860f-8109d900aa4b ro panic=60 console=ttyS1,38400 console=tty0 No local APIC present or hardware disabled Initializing CPU#0 PID hash table entries: 1024 (order: 10, 4096 bytes) Detected 498.063 MHz processor. Console: colour VGA+ 80x25 console [tty0] enabled console [ttyS1] enabled Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 243152k/253632k available (1707k kernel code, 9908k reserved, 679k data, 312k init, 0k highmem) virtual kernel memory layout: fixmap : 0xfffb3000 - 0xf000 ( 304 kB) vmalloc : 0xd000 - 0xfffb1000 ( 767 MB) lowmem : 0xc000 - 0xcf7b ( 247 MB) .init : 0xc0358000 - 0xc03a6000 ( 312 kB) .data : 0xc02aac35 - 0xc0354aa4 ( 679 kB) .text : 0xc010 - 0xc02aac35 (1707 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. SLUB: Genslabs=22, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1 Calibrating delay using timer specific routine.. 997.66 BogoMIPS (lpj=1995333) Security Framework v1.0.0 initialized SELinux: Disabled at boot. Capability LSM initialized Mount-cache hash table entries: 512 CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line) CPU: L2 Cache: 128K (32 bytes/line) Compat vDSO mapped to e000. CPU: AMD Geode(TM) Integrated Processor by AMD PCS stepping 02 Checking 'hlt' instruction... OK. ACPI: Core revision 20070126 ACPI: setting ELCR to 0200 (from 0c00) Booting paravirtualized kernel on bare hardware NET: Registered protocol family 16 EISA bus registered ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xfa740, last bus=0 PCI: Using configuration type 1 Setting up standard PCI resources ACPI: Interpreter enabled ACPI: (supports S0 S1 S5) ACPI: Using PIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11) ACPI: PCI Interrupt Link [LNKB] (IRQs 5 10 *11) ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 11) *0 ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 11) *0 Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init ACPI: bus type pnp registered pnp: PnP ACPI: found 13 devices ACPI: ACPI bus type pnp unregistered PnPBIOS: Disabled by ACPI PNP PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try pci=routeirq. If it helps, post a report NET: Registered protocol family 8 NET: Registered protocol family 20 ACPI: RTC can wake from S4 Time: tsc clocksource has been installed. pnp: 00:00: iomem range 0xf-0xf3fff could not be reserved pnp: 00:00: iomem range 0xf4000-0xf7fff could not be reserved pnp: 00:00: iomem range 0xf8000-0xfbfff could not be reserved pnp: 00:00: iomem range 0xfc000-0xf could not be reserved NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 3, 32768 bytes) TCP: Hash tables configured
Re: Warnings and Oops on 2.6.23-rc6 while activily using rfcomm links (mm/slab.c)
Hello, Please use CONFIG_SLUB and turn on SLUB debugging. Something is very wrong somewhere... I did so, on 2.6.23-rc8. I also did include CONFIG_DEBUG_DRIVER and CONFIG_DEBUG_KOBJECT, following Cornelia Huck's advice. Did you see any messages (from the driver core) surrounding kobject_move() usage or the kref badness messages? I'm asking because refcounting/lifetime issues may be the reason for your problems... I just figured out how to get KERN_DEBUG to the serial console for capture... Here is what I got (same kernel config as before) so far: Bluetooth: L2CAP ver 2.8 Bluetooth: L2CAP socket layer initialized Bluetooth: RFCOMM socket layer initialized Bluetooth: RFCOMM TTY layer initialized Bluetooth: RFCOMM ver 1.8 DEV: registering device: ID = 'acl00E0033364E5' kobject acl00E0033364E5: registering. parent: hci1, set: devices PM: Adding info for bluetooth:acl00E0033364E5 bus bluetooth: add device acl00E0033364E5 kobject_uevent_env fill_kobj_path: path = '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.4/1-1.4.1/1-1.4.1:1.0/hci1/acl00E0033364E5' DEV: registering device: ID = 'acl0060574FEB37' kobject acl0060574FEB37: registering. parent: hci2, set: devices PM: Adding info for bluetooth:acl0060574FEB37 bus bluetooth: add device acl0060574FEB37 kobject_uevent_env fill_kobj_path: path = '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/hci2/acl0060574FEB37' DEV: registering device: ID = 'acl0017B066F14B' kobject acl0017B066F14B: registering. parent: hci1, set: devices PM: Adding info for bluetooth:acl0017B066F14B bus bluetooth: add device acl0017B066F14B kobject_uevent_env fill_kobj_path: path = '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.4/1-1.4.1/1-1.4.1:1.0/hci1/acl0017B066F14B' DEV: registering device: ID = 'acl000AD9D7A99A' kobject acl000AD9D7A99A: registering. parent: hci2, set: devices PM: Adding info for bluetooth:acl000AD9D7A99A bus bluetooth: add device acl000AD9D7A99A kobject_uevent_env fill_kobj_path: path = '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/hci2/acl000AD9D7A99A' bus bluetooth: remove device acl0060574FEB37 PM: Removing info for bluetooth:acl0060574FEB37 kobject_uevent_env fill_kobj_path: path = '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/hci2/acl0060574FEB37' kobject acl0060574FEB37: cleaning up bus bluetooth: remove device acl0017B066F14B PM: Removing info for bluetooth:acl0017B066F14B kobject_uevent_env fill_kobj_path: path = '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.4/1-1.4.1/1-1.4.1:1.0/hci1/acl0017B066F14B' kobject acl0017B066F14B: cleaning up bus bluetooth: remove device acl000AD9D7A99A PM: Removing info for bluetooth:acl000AD9D7A99A kobject_uevent_env fill_kobj_path: path = '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/hci2/acl000AD9D7A99A' kobject acl000AD9D7A99A: cleaning up bus bluetooth: remove device acl00E0033364E5 PM: Removing info for bluetooth:acl00E0033364E5 kobject_uevent_env fill_kobj_path: path = '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.4/1-1.4.1/1-1.4.1:1.0/hci1/acl00E0033364E5' kobject acl00E0033364E5: cleaning up DEV: registering device: ID = 'acl00126253F906' kobject acl00126253F906: registering. parent: hci2, set: devices PM: Adding info for bluetooth:acl00126253F906 bus bluetooth: add device acl00126253F906 kobject_uevent_env fill_kobj_path: path = '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/hci2/acl00126253F906' bus bluetooth: remove device acl00126253F906 PM: Removing info for bluetooth:acl00126253F906 kobject_uevent_env fill_kobj_path: path = '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/hci2/acl00126253F906' kobject acl00126253F906: cleaning up DEV: registering device: ID = 'acl00E0033364E5' kobject acl00E0033364E5: registering. parent: hci1, set: devices PM: Adding info for bluetooth:acl00E0033364E5 bus bluetooth: add device acl00E0033364E5 kobject_uevent_env fill_kobj_path: path = '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.4/1-1.4.1/1-1.4.1:1.0/hci1/acl00E0033364E5' bus bluetooth: remove device acl00E0033364E5 PM: Removing info for bluetooth:acl00E0033364E5 kobject_uevent_env fill_kobj_path: path = '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.4/1-1.4.1/1-1.4.1:1.0/hci1/acl00E0033364E5' kobject acl00E0033364E5: cleaning up DEV: registering device: ID = 'acl006057BB4D92' kobject acl006057BB4D92: registering. parent: hci2, set: devices PM: Adding info for bluetooth:acl006057BB4D92 bus bluetooth: add device acl006057BB4D92 kobject_uevent_env fill_kobj_path: path = '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/hci2/acl006057BB4D92' bus bluetooth: remove device acl006057BB4D92 PM: Removing info for bluetooth:acl006057BB4D92 kobject_uevent_env fill_kobj_path: path = '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/hci2/acl006057BB4D92' kobject acl006057BB4D92: cleaning up DEV: registering device: ID = 'acl000AD9D7A99A'
Re: Warnings and Oops on 2.6.23-rc6 while activily using rfcomm links (mm/slab.c)
On Wed, 26 Sep 2007 15:27:10 +0200, Pierre-Yves Paulus <[EMAIL PROTECTED]> wrote: > > Please use CONFIG_SLUB and turn on SLUB debugging. Something is very wrong > > somewhere... > > I did so, on 2.6.23-rc8. I also did include CONFIG_DEBUG_DRIVER and > CONFIG_DEBUG_KOBJECT, following Cornelia Huck's advice. Did you see any messages (from the driver core) surrounding kobject_move() usage or the kref badness messages? I'm asking because refcounting/lifetime issues may be the reason for your problems... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Warnings and Oops on 2.6.23-rc6 while activily using rfcomm links (mm/slab.c)
On Wed, 26 Sep 2007 15:27:10 +0200, Pierre-Yves Paulus [EMAIL PROTECTED] wrote: Please use CONFIG_SLUB and turn on SLUB debugging. Something is very wrong somewhere... I did so, on 2.6.23-rc8. I also did include CONFIG_DEBUG_DRIVER and CONFIG_DEBUG_KOBJECT, following Cornelia Huck's advice. Did you see any messages (from the driver core) surrounding kobject_move() usage or the kref badness messages? I'm asking because refcounting/lifetime issues may be the reason for your problems... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Warnings and Oops on 2.6.23-rc6 while activily using rfcomm links (mm/slab.c)
Hello, Please use CONFIG_SLUB and turn on SLUB debugging. Something is very wrong somewhere... I did so, on 2.6.23-rc8. I also did include CONFIG_DEBUG_DRIVER and CONFIG_DEBUG_KOBJECT, following Cornelia Huck's advice. Did you see any messages (from the driver core) surrounding kobject_move() usage or the kref badness messages? I'm asking because refcounting/lifetime issues may be the reason for your problems... I just figured out how to get KERN_DEBUG to the serial console for capture... Here is what I got (same kernel config as before) so far: Bluetooth: L2CAP ver 2.8 Bluetooth: L2CAP socket layer initialized Bluetooth: RFCOMM socket layer initialized Bluetooth: RFCOMM TTY layer initialized Bluetooth: RFCOMM ver 1.8 DEV: registering device: ID = 'acl00E0033364E5' kobject acl00E0033364E5: registering. parent: hci1, set: devices PM: Adding info for bluetooth:acl00E0033364E5 bus bluetooth: add device acl00E0033364E5 kobject_uevent_env fill_kobj_path: path = '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.4/1-1.4.1/1-1.4.1:1.0/hci1/acl00E0033364E5' DEV: registering device: ID = 'acl0060574FEB37' kobject acl0060574FEB37: registering. parent: hci2, set: devices PM: Adding info for bluetooth:acl0060574FEB37 bus bluetooth: add device acl0060574FEB37 kobject_uevent_env fill_kobj_path: path = '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/hci2/acl0060574FEB37' DEV: registering device: ID = 'acl0017B066F14B' kobject acl0017B066F14B: registering. parent: hci1, set: devices PM: Adding info for bluetooth:acl0017B066F14B bus bluetooth: add device acl0017B066F14B kobject_uevent_env fill_kobj_path: path = '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.4/1-1.4.1/1-1.4.1:1.0/hci1/acl0017B066F14B' DEV: registering device: ID = 'acl000AD9D7A99A' kobject acl000AD9D7A99A: registering. parent: hci2, set: devices PM: Adding info for bluetooth:acl000AD9D7A99A bus bluetooth: add device acl000AD9D7A99A kobject_uevent_env fill_kobj_path: path = '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/hci2/acl000AD9D7A99A' bus bluetooth: remove device acl0060574FEB37 PM: Removing info for bluetooth:acl0060574FEB37 kobject_uevent_env fill_kobj_path: path = '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/hci2/acl0060574FEB37' kobject acl0060574FEB37: cleaning up bus bluetooth: remove device acl0017B066F14B PM: Removing info for bluetooth:acl0017B066F14B kobject_uevent_env fill_kobj_path: path = '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.4/1-1.4.1/1-1.4.1:1.0/hci1/acl0017B066F14B' kobject acl0017B066F14B: cleaning up bus bluetooth: remove device acl000AD9D7A99A PM: Removing info for bluetooth:acl000AD9D7A99A kobject_uevent_env fill_kobj_path: path = '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/hci2/acl000AD9D7A99A' kobject acl000AD9D7A99A: cleaning up bus bluetooth: remove device acl00E0033364E5 PM: Removing info for bluetooth:acl00E0033364E5 kobject_uevent_env fill_kobj_path: path = '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.4/1-1.4.1/1-1.4.1:1.0/hci1/acl00E0033364E5' kobject acl00E0033364E5: cleaning up DEV: registering device: ID = 'acl00126253F906' kobject acl00126253F906: registering. parent: hci2, set: devices PM: Adding info for bluetooth:acl00126253F906 bus bluetooth: add device acl00126253F906 kobject_uevent_env fill_kobj_path: path = '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/hci2/acl00126253F906' bus bluetooth: remove device acl00126253F906 PM: Removing info for bluetooth:acl00126253F906 kobject_uevent_env fill_kobj_path: path = '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/hci2/acl00126253F906' kobject acl00126253F906: cleaning up DEV: registering device: ID = 'acl00E0033364E5' kobject acl00E0033364E5: registering. parent: hci1, set: devices PM: Adding info for bluetooth:acl00E0033364E5 bus bluetooth: add device acl00E0033364E5 kobject_uevent_env fill_kobj_path: path = '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.4/1-1.4.1/1-1.4.1:1.0/hci1/acl00E0033364E5' bus bluetooth: remove device acl00E0033364E5 PM: Removing info for bluetooth:acl00E0033364E5 kobject_uevent_env fill_kobj_path: path = '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.4/1-1.4.1/1-1.4.1:1.0/hci1/acl00E0033364E5' kobject acl00E0033364E5: cleaning up DEV: registering device: ID = 'acl006057BB4D92' kobject acl006057BB4D92: registering. parent: hci2, set: devices PM: Adding info for bluetooth:acl006057BB4D92 bus bluetooth: add device acl006057BB4D92 kobject_uevent_env fill_kobj_path: path = '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/hci2/acl006057BB4D92' bus bluetooth: remove device acl006057BB4D92 PM: Removing info for bluetooth:acl006057BB4D92 kobject_uevent_env fill_kobj_path: path = '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/hci2/acl006057BB4D92' kobject acl006057BB4D92: cleaning up DEV: registering device: ID = 'acl000AD9D7A99A'
Re: Warnings and Oops on 2.6.23-rc6 while activily using rfcomm links (mm/slab.c)
On 09/25/2007 11:04 AM, Pierre-Yves Paulus wrote: > Hello, > > Putting the bluetooth system under load (opening and closing several > rfcomm links off several USB adapters, and transmitting data over them), > I got the Oops below. The computer hung completely, as you can see. Just > before, I also got those warnings. > > I'm not sure if I'm providing the right and useful informations to allow > fixing of those problems, as I'm definitely no expert. Please tell me if > I do something the wrong way. > > Please use CONFIG_SLUB and turn on SLUB debugging. Something is very wrong somewhere... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Warnings and Oops on 2.6.23-rc6 while activily using rfcomm links (mm/slab.c)
On Tue, 25 Sep 2007 17:04:04 +0200, Pierre-Yves Paulus <[EMAIL PROTECTED]> wrote: > Hello, > > Putting the bluetooth system under load (opening and closing several > rfcomm links off several USB adapters, and transmitting data over them), > I got the Oops below. The computer hung completely, as you can see. Just > before, I also got those warnings. > > I'm not sure if I'm providing the right and useful informations to allow > fixing of those problems, as I'm definitely no expert. Please tell me if > I do something the wrong way. > > > WARNING: at lib/kref.c:33 kref_get() > [] kref_get+0x34/0x3d > [] kobject_get+0xf/0x13 > [] get_device+0xe/0x14 > [] device_move+0x13/0xe2 > [] rfcomm_tty_close+0x23/0x61 [rfcomm] > [] release_dev+0x1c0/0x54a > [] rfcomm_dev_destruct+0x59/0x65 [rfcomm] > [] rfcomm_dev_ioctl+0x328/0x4e6 [rfcomm] > [] autoremove_wake_function+0x0/0x35 > [] release_sock+0xc/0x74 > [] sock_ioctl+0x19f/0x1be > [] tty_release+0x7/0xa > [] __fput+0x93/0x147 > [] filp_close+0x51/0x58 > [] sys_close+0x54/0x83 > [] syscall_call+0x7/0xb > === This looks like some refcounting is messed up... > # CONFIG_DEBUG_DRIVER is not set > # CONFIG_DEBUG_KOBJECT is not set Switching these two on may provide helpful information. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Warnings and Oops on 2.6.23-rc6 while activily using rfcomm links (mm/slab.c)
On Tue, 25 Sep 2007 17:04:04 +0200, Pierre-Yves Paulus [EMAIL PROTECTED] wrote: Hello, Putting the bluetooth system under load (opening and closing several rfcomm links off several USB adapters, and transmitting data over them), I got the Oops below. The computer hung completely, as you can see. Just before, I also got those warnings. I'm not sure if I'm providing the right and useful informations to allow fixing of those problems, as I'm definitely no expert. Please tell me if I do something the wrong way. WARNING: at lib/kref.c:33 kref_get() [c01c537b] kref_get+0x34/0x3d [c01c484b] kobject_get+0xf/0x13 [c0223b2f] get_device+0xe/0x14 [c0223b48] device_move+0x13/0xe2 [d02f4b78] rfcomm_tty_close+0x23/0x61 [rfcomm] [c020e0a4] release_dev+0x1c0/0x54a [d02f40c9] rfcomm_dev_destruct+0x59/0x65 [rfcomm] [d02f470c] rfcomm_dev_ioctl+0x328/0x4e6 [rfcomm] [c012a3a8] autoremove_wake_function+0x0/0x35 [c02460bc] release_sock+0xc/0x74 [c0243f4e] sock_ioctl+0x19f/0x1be [c020e435] tty_release+0x7/0xa [c015be91] __fput+0x93/0x147 [c0159a39] filp_close+0x51/0x58 [c015aad1] sys_close+0x54/0x83 [c0103c72] syscall_call+0x7/0xb === This looks like some refcounting is messed up... # CONFIG_DEBUG_DRIVER is not set # CONFIG_DEBUG_KOBJECT is not set Switching these two on may provide helpful information. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Warnings and Oops on 2.6.23-rc6 while activily using rfcomm links (mm/slab.c)
On 09/25/2007 11:04 AM, Pierre-Yves Paulus wrote: Hello, Putting the bluetooth system under load (opening and closing several rfcomm links off several USB adapters, and transmitting data over them), I got the Oops below. The computer hung completely, as you can see. Just before, I also got those warnings. I'm not sure if I'm providing the right and useful informations to allow fixing of those problems, as I'm definitely no expert. Please tell me if I do something the wrong way. Please use CONFIG_SLUB and turn on SLUB debugging. Something is very wrong somewhere... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
