Re: bluetooth memory corruption (was Re: ext3-related crash in 2.6.20-rc1)
Hi! > > > > Okay, I spoke too soon. bluetooth & suspend memory corruption was > > > > _way_ harder to reproduce than expected. Took me 5-or-so-suspend > > > > cycles... so it is probably unrelated to the previous crash. > > > > > > can you try to reproduce this with 2.6.20-rc2 as well. > > > > Yep, here it is, reproduced on 6-th-or-so suspend. > > > > bluetooth may need to be actively used in order for this to trigger; > > connecting to the net over my cellphone seems to work okay. > > > > (Full logs in attachment). > > Is this issue also present in 2.6.19 or is it a regression? Not sure... but I know there were some bluetooth & suspend problems before. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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: bluetooth memory corruption (was Re: ext3-related crash in 2.6.20-rc1)
On Mon, Dec 25, 2006 at 12:36:47AM +0100, Pavel Machek wrote: > On Sun 2006-12-24 15:39:23, Marcel Holtmann wrote: > > Hi Pavel, > > > > > > I got this nasty oops while playing with debugger. Not sure if that is > > > > related; it also might be something with bluetooth; I already know it > > > > corrupts memory during suspend, perhaps it corrupts memory in some > > > > error path? > > > > > > Okay, I spoke too soon. bluetooth & suspend memory corruption was > > > _way_ harder to reproduce than expected. Took me 5-or-so-suspend > > > cycles... so it is probably unrelated to the previous crash. > > > > can you try to reproduce this with 2.6.20-rc2 as well. > > Yep, here it is, reproduced on 6-th-or-so suspend. > > bluetooth may need to be actively used in order for this to trigger; > connecting to the net over my cellphone seems to work okay. > > (Full logs in attachment). Is this issue also present in 2.6.19 or is it a regression? > Pavel cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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: bluetooth memory corruption (was Re: ext3-related crash in 2.6.20-rc1)
Hi Pavel, > > > > > I got this nasty oops while playing with debugger. Not sure if that is > > > > > related; it also might be something with bluetooth; I already know it > > > > > corrupts memory during suspend, perhaps it corrupts memory in some > > > > > error path? > > > > > > > > Okay, I spoke too soon. bluetooth & suspend memory corruption was > > > > _way_ harder to reproduce than expected. Took me 5-or-so-suspend > > > > cycles... so it is probably unrelated to the previous crash. > > > > > > can you try to reproduce this with 2.6.20-rc2 as well. > > > > (reproduced in another mail). > > > > _urb_queue_tail(__pending_q(husb, _urb->type), _urb); > > err = usb_submit_urb(urb, GFP_ATOMIC); > > if (err) { > > BT_ERR("%s tx submit failed urb %p type %d err %d", > > husb->hdev->name, urb, _urb->type, err); > > _urb_unlink(_urb); > > > > ~~ > > Do we need to remove urb from pending_q here? > > > > _urb_queue_tail(__completed_q(husb, _urb->type), _urb); > > } else > > atomic_inc(__pending_tx(husb, _urb->type)); > > > > Any news? Should I convert above idea to a patch? Or should I make > bluetooth suspend() routine return error so corruption is impossible > to hit? to be honest, I have no idea. This code is way to ugly anyway. Regards 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: bluetooth memory corruption (was Re: ext3-related crash in 2.6.20-rc1)
Hi! > > > > I got this nasty oops while playing with debugger. Not sure if that is > > > > related; it also might be something with bluetooth; I already know it > > > > corrupts memory during suspend, perhaps it corrupts memory in some > > > > error path? > > > > > > Okay, I spoke too soon. bluetooth & suspend memory corruption was > > > _way_ harder to reproduce than expected. Took me 5-or-so-suspend > > > cycles... so it is probably unrelated to the previous crash. > > > > can you try to reproduce this with 2.6.20-rc2 as well. > > (reproduced in another mail). > > _urb_queue_tail(__pending_q(husb, _urb->type), _urb); > err = usb_submit_urb(urb, GFP_ATOMIC); > if (err) { > BT_ERR("%s tx submit failed urb %p type %d err %d", > husb->hdev->name, urb, _urb->type, err); > _urb_unlink(_urb); > > ~~ >Do we need to remove urb from pending_q here? > > _urb_queue_tail(__completed_q(husb, _urb->type), _urb); > } else > atomic_inc(__pending_tx(husb, _urb->type)); > Any news? Should I convert above idea to a patch? Or should I make bluetooth suspend() routine return error so corruption is impossible to hit? Pavel -- Thanks for all the (sleeping) penguins. - 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: bluetooth memory corruption (was Re: ext3-related crash in 2.6.20-rc1)
Hi! > > > I got this nasty oops while playing with debugger. Not sure if that is > > > related; it also might be something with bluetooth; I already know it > > > corrupts memory during suspend, perhaps it corrupts memory in some > > > error path? > > > > Okay, I spoke too soon. bluetooth & suspend memory corruption was > > _way_ harder to reproduce than expected. Took me 5-or-so-suspend > > cycles... so it is probably unrelated to the previous crash. > > can you try to reproduce this with 2.6.20-rc2 as well. (reproduced in another mail). _urb_queue_tail(__pending_q(husb, _urb->type), _urb); err = usb_submit_urb(urb, GFP_ATOMIC); if (err) { BT_ERR("%s tx submit failed urb %p type %d err %d", husb->hdev->name, urb, _urb->type, err); _urb_unlink(_urb); ~~ Do we need to remove urb from pending_q here? _urb_queue_tail(__completed_q(husb, _urb->type), _urb); } else atomic_inc(__pending_tx(husb, _urb->type)); Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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: bluetooth memory corruption (was Re: ext3-related crash in 2.6.20-rc1)
On Sun 2006-12-24 15:39:23, Marcel Holtmann wrote: > Hi Pavel, > > > > I got this nasty oops while playing with debugger. Not sure if that is > > > related; it also might be something with bluetooth; I already know it > > > corrupts memory during suspend, perhaps it corrupts memory in some > > > error path? > > > > Okay, I spoke too soon. bluetooth & suspend memory corruption was > > _way_ harder to reproduce than expected. Took me 5-or-so-suspend > > cycles... so it is probably unrelated to the previous crash. > > can you try to reproduce this with 2.6.20-rc2 as well. Yep, here it is, reproduced on 6-th-or-so suspend. bluetooth may need to be actively used in order for this to trigger; connecting to the net over my cellphone seems to work okay. (Full logs in attachment). Pavel Linux version 2.6.20-rc2 ([EMAIL PROTECTED]) (gcc version 4.0.4 20060507 (prerelease) (Debian 4.0.3-3)) #383 SMP Fri Dec 22 11:30:05 CET 2006 ... system 00:00: resuming pnp 00:01: resuming system 00:02: resuming pnp 00:03: resuming pnp 00:04: resuming pnp 00:05: resuming pnp 00:06: resuming pnp 00:07: resuming i8042 kbd 00:08: resuming pnp: Device 00:08 does not support activation. i8042 aux 00:09: resuming pnp: Device 00:09 does not support activation. pnp 00:0a: resuming pnp 00:0b: resuming platform bluetooth: resuming pcspkr pcspkr: resuming vesafb vesafb.0: resuming serial8250 serial8250: resuming usb usb1: resuming usb usb3: resuming ata2: SATA link down (SStatus 0 SControl 0) ata3: SATA link down (SStatus 0 SControl 0) ata4: SATA link down (SStatus 0 SControl 0) hub 1-0:1.0: resuming hub 3-0:1.0: resuming i8042 i8042: resuming atkbd serio0: resuming psmouse serio1: resuming usb usb4: resuming usb usb5: resuming hub 4-0:1.0: resuming hub 5-0:1.0: resuming usb usb2: resuming hub 2-0:1.0: resuming mmcblk mmc0:cc53: resuming sd 0:0:0:0: resuming usb 3-2: resuming usbdev3.8_ep00: PM: resume from 0, parent 3-2 still 2 usb 3-2:1.0: PM: resume from 2, parent 3-2 still 2 usb 3-2:1.0: resuming usbdev3.8_ep81: PM: resume from 0, parent 3-2:1.0 still 2 usbdev3.8_ep02: PM: resume from 0, parent 3-2:1.0 still 2 usbdev3.8_ep83: PM: resume from 0, parent 3-2:1.0 still 2 usb 3-1: resuming usbdev3.9_ep00: PM: resume from 0, parent 3-1 still 2 hci_usb 3-1:1.0: PM: resume from 2, parent 3-1 still 2 hci_usb 3-1:1.0: resuming hci0: PM: resume from 0, parent 3-1:1.0 still 2 usbdev3.9_ep81: PM: resume from 0, parent 3-1:1.0 still 2 usbdev3.9_ep82: PM: resume from 0, parent 3-1:1.0 still 2 usbdev3.9_ep02: PM: resume from 0, parent 3-1:1.0 still 2 hci_usb 3-1:1.1: PM: resume from 2, parent 3-1 still 2 hci_usb 3-1:1.1: resuming usbdev3.9_ep83: PM: resume from 0, parent 3-1:1.1 still 2 usbdev3.9_ep03: PM: resume from 0, parent 3-1:1.1 still 2 usb 3-1:1.2: PM: resume from 2, parent 3-1 still 2 usb 3-1:1.2: resuming usbdev3.9_ep84: PM: resume from 0, parent 3-1:1.2 still 2 usbdev3.9_ep04: PM: resume from 0, parent 3-1:1.2 still 2 usb 3-1:1.3: PM: resume from 2, parent 3-1 still 2 usb 3-1:1.3: resuming Restarting tasks ... <3>__tx_submit: hci0 tx submit failed urb f765d1bc type 2 err -19 usb 3-1: USB disconnect, address 9 PM: Removing info for No Bus:usbdev3.9_ep81 PM: Removing info for No Bus:usbdev3.9_ep82 PM: Removing info for No Bus:usbdev3.9_ep02 slab error in verify_redzone_free(): cache `size-512': memory outside object was overwritten [] cache_free_debugcheck+0x128/0x1d0 [] hci_usb_close+0xf3/0x160 [] kfree+0x50/0xa0 [] hci_usb_close+0xf3/0x160 [] hci_usb_disconnect+0x2e/0x90 [] usb_disable_interface+0x53/0x70 [] usb_unbind_interface+0x38/0x80 [] __device_release_driver+0x68/0xb0 [] device_release_driver+0x1e/0x40 [] bus_remove_device+0x8b/0xa0 [] device_del+0x159/0x1c0 [] usb_disable_device+0x4d/0x100 [] usb_disconnect+0x9a/0x110 [] hub_thread+0x355/0xbd0 [] schedule+0x2de/0x8f0 [] autoremove_wake_function+0x0/0x50 [] hub_thread+0x0/0xbd0 [] kthread+0xec/0xf0 [] kthread+0x0/0xf0 [] kernel_thread_helper+0x7/0x10 === f70a2720: redzone 1:0x5a5a5a5a, redzone 2:0xc0545e9e. [ cut here ] kernel BUG at mm/slab.c:2878! invalid opcode: [#1] SMP Modules linked in: CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010012 (2.6.20-rc2 #383) EIP is at cache_free_debugcheck+0x1b2/0x1d0 eax: f70a271c ebx: f70a20f8 ecx: 00052c00 edx: 020c esi: c20df680 edi: f70a2720 ebp: 5a5a5a5a esp: c2313e30 ds: 007b es: 007b ss: 0068 Process khubd (pid: 304, ti=c2312000 task=c2257030 task.ti=c2312000) Stack: c06aedf0 f70a2720 5a5a5a5a c0545e9e c04b08d3 f70a20c0 c20df680 c20d9164 f70a2724 0286 c016b610 f653e8d8 f653e8c4 c2134ba0 000c c04b08d3 c2134b5c c2134b8c f62e0a54 c2134ad0 0001 c2134ad0 f62e0a54 c07dbee0 Call Trace: [] sock_alloc_send_skb+0x16e/0x1c0 [] hci_usb_close+0xf3/0x160 [] kfree+0x50/0xa0 [] hci_usb_close+0xf3/0x160 [] hci_usb_disconnect+0x2e/0x90 [] u
Re: bluetooth memory corruption (was Re: ext3-related crash in 2.6.20-rc1)
Hi! > > PM: Removing info for No Bus:usbdev3.15_ep81 > > PM: Removing info for No Bus:usbdev3.15_ep82 > > PM: Removing info for No Bus:usbdev3.15_ep02 > > slab error in verify_redzone_free(): cache `size-512': memory outside > > object was overwritten > > [] cache_free_debugcheck+0x128/0x1d0 > > [] hci_usb_close+0xf3/0x160 > > [] kfree+0x50/0xa0 > > [] hci_usb_close+0xf3/0x160 > > [] hci_usb_disconnect+0x2e/0x90 > > [] usb_disable_interface+0x53/0x70 > > [] usb_unbind_interface+0x38/0x80 > > [] __device_release_driver+0x68/0xb0 > > [] device_release_driver+0x1e/0x40 > > [] bus_remove_device+0x8b/0xa0 > > [] device_del+0x159/0x1c0 > > [] usb_disable_device+0x4d/0x100 > > [] usb_disconnect+0x9a/0x110 > > [] hub_thread+0x355/0xbd0 > > [] schedule+0x2de/0x8f0 > > [] autoremove_wake_function+0x0/0x50 > > [] hub_thread+0x0/0xbd0 > > [] kthread+0xec/0xf0 > > [] kthread+0x0/0xf0 > > [] kernel_thread_helper+0x7/0x10 > > === > > yes, this one looks like memory scribblage in bluetooth. The > buffer.c assertion failure should now be fixed, please verify. I can confirm buffer.c assertion to be fixed (yes, I was using gdb at that time). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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: bluetooth memory corruption (was Re: ext3-related crash in 2.6.20-rc1)
Hi Pavel, > > I got this nasty oops while playing with debugger. Not sure if that is > > related; it also might be something with bluetooth; I already know it > > corrupts memory during suspend, perhaps it corrupts memory in some > > error path? > > Okay, I spoke too soon. bluetooth & suspend memory corruption was > _way_ harder to reproduce than expected. Took me 5-or-so-suspend > cycles... so it is probably unrelated to the previous crash. can you try to reproduce this with 2.6.20-rc2 as well. Regards 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: bluetooth memory corruption (was Re: ext3-related crash in 2.6.20-rc1)
On Sun, 24 Dec 2006 00:55:01 +0100 Pavel Machek <[EMAIL PROTECTED]> wrote: > PM: Removing info for No Bus:usbdev3.15_ep81 > PM: Removing info for No Bus:usbdev3.15_ep82 > PM: Removing info for No Bus:usbdev3.15_ep02 > slab error in verify_redzone_free(): cache `size-512': memory outside object > was overwritten > [] cache_free_debugcheck+0x128/0x1d0 > [] hci_usb_close+0xf3/0x160 > [] kfree+0x50/0xa0 > [] hci_usb_close+0xf3/0x160 > [] hci_usb_disconnect+0x2e/0x90 > [] usb_disable_interface+0x53/0x70 > [] usb_unbind_interface+0x38/0x80 > [] __device_release_driver+0x68/0xb0 > [] device_release_driver+0x1e/0x40 > [] bus_remove_device+0x8b/0xa0 > [] device_del+0x159/0x1c0 > [] usb_disable_device+0x4d/0x100 > [] usb_disconnect+0x9a/0x110 > [] hub_thread+0x355/0xbd0 > [] schedule+0x2de/0x8f0 > [] autoremove_wake_function+0x0/0x50 > [] hub_thread+0x0/0xbd0 > [] kthread+0xec/0xf0 > [] kthread+0x0/0xf0 > [] kernel_thread_helper+0x7/0x10 > === yes, this one looks like memory scribblage in bluetooth. The buffer.c assertion failure should now be fixed, please verify. - 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: bluetooth memory corruption (was Re: ext3-related crash in 2.6.20-rc1)
Hi! > > I got this nasty oops while playing with debugger. Not sure if that is > > related; it also might be something with bluetooth; I already know it > > corrupts memory during suspend, perhaps it corrupts memory in some > > error path? > > Okay, I spoke too soon. bluetooth & suspend memory corruption was > _way_ harder to reproduce than expected. Took me 5-or-so-suspend > cycles... so it is probably unrelated to the previous crash. > > I was getting pretty regular crashes with bluetooth & gdb, but I was > not using bluetooth at the time of ext3-related crash. And for completeness, here's bluetooth + gdb oops. Ok, I'm not _sure_ it is bluetooth related. I'll try it without bluetooth in a while. Pavel PM: Adding info for No Bus:vcsa8 coda_read_super: Bad mount data coda_read_super: device index: 0 coda_read_super: rootfid is (01234567..080519b0.) PM: Removing info for No Bus:vcs10 PM: Removing info for No Bus:vcsa10 coda_upcall: Venus dead on (op,un) (7.2) flags 10 Failure of coda_cnode_make for root: error -19 hci_cmd_task: hci0 command tx timeout PM: Adding info for No Bus:rfcomm1 PM: Adding info for bluetooth:acl00803715A329 hci_acldata_packet: hci0 ACL packet for unknown connection handle 12 hci_acldata_packet: hci0 ACL packet for unknown connection handle 12 hci_acldata_packet: hci0 ACL packet for unknown connection handle 12 hci_acldata_packet: hci0 ACL packet for unknown connection handle 12 hci_acldata_packet: hci0 ACL packet for unknown connection handle 12 hci_acldata_packet: hci0 ACL packet for unknown connection handle 12 hci_acldata_packet: hci0 ACL packet for unknown connection handle 12 hci_acldata_packet: hci0 ACL packet for unknown connection handle 12 hci_acldata_packet: hci0 ACL packet for unknown connection handle 12 hci_acldata_packet: hci0 ACL packet for unknown connection handle 12 hci_acldata_packet: hci0 ACL packet for unknown connection handle 12 hci_acldata_packet: hci0 ACL packet for unknown connection handle 12 hci_acldata_packet: hci0 ACL packet for unknown connection handle 12 l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpected continuation frame (len 0) l2cap_recv_acldata: Unexpe
bluetooth memory corruption (was Re: ext3-related crash in 2.6.20-rc1)
Hi! > I got this nasty oops while playing with debugger. Not sure if that is > related; it also might be something with bluetooth; I already know it > corrupts memory during suspend, perhaps it corrupts memory in some > error path? Okay, I spoke too soon. bluetooth & suspend memory corruption was _way_ harder to reproduce than expected. Took me 5-or-so-suspend cycles... so it is probably unrelated to the previous crash. I was getting pretty regular crashes with bluetooth & gdb, but I was not using bluetooth at the time of ext3-related crash. Pavel acpi acpi: resuming __tx_submit: hci0 tx submit failed urb c20efb08 type 2 err -113 agpgart-intel :00:00.0: resuming pci :00:02.0: resuming pci :00:02.1: resuming PM: Writing back config space on device :00:02.1 at offset 1 (was 90, writing 93) HDA Intel :00:1b.0: resuming PM: Writing back config space on device :00:1b.0 at offset 1 (was 100106, writing 100102) PCI: Setting latency timer of device :00:1b.0 to 64 pci :00:1c.0: resuming PCI: Setting latency timer of device :00:1c.0 to 64 pci :00:1c.1: resuming PCI: Setting latency timer of device :00:1c.1 to 64 pci :00:1c.2: resuming PCI: Setting latency timer of device :00:1c.2 to 64 pci :00:1c.3: resuming PM: Writing back config space on device :00:1c.3 at offset f (was 40400, writing 4040b) PM: Writing back config space on device :00:1c.3 at offset 9 (was 10001, writing e421e421) PM: Writing back config space on device :00:1c.3 at offset 8 (was 0, writing ebf0ea00) PM: Writing back config space on device :00:1c.3 at offset 7 (was 2000, writing 8070) PM: Writing back config space on device :00:1c.3 at offset 3 (was 81, writing 810010) PM: Writing back config space on device :00:1c.3 at offset 1 (was 10, writing 100107) PCI: Setting latency timer of device :00:1c.3 to 64 uhci_hcd :00:1d.0: resuming PCI: Setting latency timer of device :00:1d.0 to 64 usb usb4: root hub lost power or was reset uhci_hcd :00:1d.1: resuming PCI: Setting latency timer of device :00:1d.1 to 64 usb usb2: root hub lost power or was reset uhci_hcd :00:1d.2: resuming PCI: Setting latency timer of device :00:1d.2 to 64 usb usb5: root hub lost power or was reset uhci_hcd :00:1d.3: resuming PCI: Setting latency timer of device :00:1d.3 to 64 usb usb3: root hub lost power or was reset ehci_hcd :00:1d.7: resuming PCI: Setting latency timer of device :00:1d.7 to 64 pci :00:1e.0: resuming PM: Writing back config space on device :00:1e.0 at offset 1 (was 15, writing 17) PCI: Setting latency timer of device :00:1e.0 to 64 pci :00:1f.0: resuming PIIX_IDE :00:1f.1: resuming ahci :00:1f.2: resuming PCI: Setting latency timer of device :00:1f.2 to 64 pci :00:1f.3: resuming pci :02:00.0: resuming PM: Writing back config space on device :02:00.0 at offset 1 (was 100107, writing 100103) pci :03:00.0: resuming yenta_cardbus :15:00.0: resuming ohci1394 :15:00.1: resuming PM: Writing back config space on device :15:00.1 at offset 4 (was 0, writing e4301000) PM: Writing back config space on device :15:00.1 at offset 3 (was 80, writing 804000) PM: Writing back config space on device :15:00.1 at offset 1 (was 210, writing 216) ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[21] MMIO=[e4301000-e43017ff] Max Packet=[2048] IR/IT contexts=[4/4] sdhci :15:00.2: resuming PM: Writing back config space on device :15:00.2 at offset 4 (was 0, writing e4301800) PM: Writing back config space on device :15:00.2 at offset 3 (was 80, writing 804000) PM: Writing back config space on device :15:00.2 at offset 1 (was 210, writing 216) system 00:00: resuming pnp 00:01: resuming system 00:02: resuming pnp 00:03: resuming pnp 00:04: resuming pnp 00:05: resuming pnp 00:06: resuming pnp 00:07: resuming i8042 kbd 00:08: resuming pnp: Device 00:08 does not support activation. i8042 aux 00:09: resuming pnp: Device 00:09 does not support activation. pnp 00:0a: resuming pnp 00:0b: resuming platform bluetooth: resuming pcspkr pcspkr: resuming vesafb vesafb.0: resuming serial8250 serial8250: resuming usb usb1: resuming hub 1-0:1.0: resuming usb usb2: resuming hub 2-0:1.0: resuming usb usb4: resuming ata2: SATA link down (SStatus 0 SControl 0) ata3: SATA link down (SStatus 0 SControl 0) ata4: SATA link down (SStatus 0 SControl 0) usb usb5: resuming hub 4-0:1.0: resuming hub 5-0:1.0: resuming usb usb3: resuming hub 3-0:1.0: resuming i8042 i8042: resuming atkbd serio0: resuming psmouse serio1: resuming mmcblk mmc0:cc53: resuming sd 0:0:0:0: resuming usb 3-2: resuming usbdev3.14_ep00: PM: resume from 0, parent 3-2 still 2 usb 3-2:1.0: PM: resume from 2, parent 3-2 still 2 usb 3-2:1.0: resuming usbdev3.14_ep81: PM: resume from 0, parent 3-2:1.0 still 2 usbde