On Thu, 18 Sep 2003, Martin Schwenke wrote: > >>>>> "Alan" == Alan Stern <[EMAIL PROTECTED]> writes: > > Alan> Martin, please try again after applying this one-liner on > Alan> top of all those other patches. > > Hmmm... Would you believe no improvement? Logs follow... they look > a bit different... :-)
Progress, anyway. > 11:13 suspend > 11:16 resume > 11:17 /etc/init.d/hotplug restart > > peace & happiness, > martin > --------8<---------8<-------- CUT HERE --------8<---------8<-------- > [...] > Sep 18 11:13:46 localhost kernel: uhci-hcd 0000:00:07.2: suspend to state 3 > Sep 18 11:13:46 localhost kernel: drivers/usb/host/uhci-hcd.c: 1860: suspend_hc > [...] > Sep 18 11:16:04 localhost kernel: uhci-hcd 0000:00:07.2: suspend D4 --> D3 > Sep 18 11:16:04 localhost kernel: drivers/usb/host/uhci-hcd.c: 1860: wakeup_hc That much looks like it's working just right. > [...] > Sep 18 11:16:04 localhost kernel: uhci-hcd 0000:00:07.2: can't resume, not suspended! That's odd. Looks like the resume routine is being called a second time. But it shouldn't hurt anything. > Sep 18 11:16:04 localhost kernel: hub 1-0:0: port 1, status 301, change 1, 1.5 Mb/s That "change 1" indicates a connection change. The UHCI driver is saying that the port the mouse was plugged into got disconnected and then connected again. You didn't unplug your mouse while the system was asleep, did you? > Sep 18 11:16:04 localhost kernel: usb 1-1: USB disconnect, address 2 > Sep 18 11:16:04 localhost kernel: drivers/usb/core/message.c: nuking URBs for device > 1-1 > Sep 18 11:16:04 localhost kernel: usb 1-1: unregistering interfaces > Sep 18 11:16:04 localhost kernel: usb 1-1: hcd_unlink_urb ded3b260 fail -22 > Sep 18 11:16:04 localhost kernel: usb 1-1: hcd_unlink_urb ded3b140 fail -22 > Sep 18 11:16:04 localhost kernel: drivers/usb/core/usb.c: usb_hotplug > Sep 18 11:16:04 localhost kernel: usb 1-1: unregistering device So it goes through all this disconnect processing. > Sep 18 11:16:04 localhost kernel: drivers/usb/core/usb.c: usb_hotplug > Sep 18 11:16:04 localhost kernel: hub 1-0:0: debounce: port 1: delay 100ms stable 4 > status 0x301 > Sep 18 11:16:05 localhost kernel: hub 1-0:0: new USB device on port 1, assigned > address 3 > [...] > Sep 18 11:16:11 localhost kernel: usb 1-1: new device strings: Mfr=1, Product=2, > SerialNumber=0 > Sep 18 11:16:15 localhost kernel: drivers/usb/core/message.c: USB device number 3 > default language ID 0x409 > Sep 18 11:16:20 localhost kernel: usb 1-1: Product: USB Mouse > Sep 18 11:16:22 localhost kernel: usb 1-1: Manufacturer: Logitech > Sep 18 11:16:22 localhost kernel: drivers/usb/core/usb.c: usb_hotplug > Sep 18 11:16:22 localhost kernel: usb 1-1: usb_new_device - registering interface > 1-1:0 > Sep 18 11:16:22 localhost kernel: drivers/usb/core/usb.c: usb_hotplug > Sep 18 11:16:22 localhost kernel: hid 1-1:0: usb_probe_interface > Sep 18 11:16:22 localhost kernel: hid 1-1:0: usb_probe_interface - got id > Sep 18 11:16:28 localhost kernel: usb 1-1: control timeout on ep0in > Sep 18 11:16:36 localhost kernel: usb 1-1: control timeout on ep0in > Sep 18 11:16:47 localhost kernel: input: USB HID v1.10 Mouse [046d:c00c] on > usb-0000:00:07.2-1 And then this connect processing. That may be the cause of your trouble: the old data structures for the mouse device are gone and these new ones are here. I don't know about those control timeout messages, though. They indicate some deeper problem. I'll try doing the same sort of test on my own system and let you know how it comes out. Alan Stern ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
