Interesting ... towards the end your kernel messages had lots of messages among which were periodic:
Oct 15 03:42:32 hal9 kernel: drivers/usb/host/ohci-q.c: 00:02.0 bad entry fcac7c1 Oct 15 03:42:35 hal9 kernel: drivers/usb/host/ohci-q.c: 00:02.0 bad entry fcac7c1 Oct 15 03:42:41 hal9 kernel: drivers/usb/host/ohci-q.c: 00:02.0 bad entry fcac7c1 Oct 15 03:42:44 hal9 kernel: drivers/usb/host/ohci-q.c: 00:02.0 bad entry fcac7c1 Oct 15 03:43:02 hal9 kernel: drivers/usb/host/ohci-q.c: 00:02.0 bad entry fcac7c1 Oct 15 03:43:05 hal9 kernel: drivers/usb/host/ohci-q.c: 00:02.0 bad entry fcac7c1 Oct 15 03:43:08 hal9 kernel: drivers/usb/host/ohci-q.c: 00:02.0 bad entry fcac7c1 Oct 15 03:43:11 hal9 kernel: drivers/usb/host/ohci-q.c: 00:02.0 bad entry fcac7c1 Many/all related to failures when it was trying to get the device descriptor (I guess) for device #7. What was that device, do you know? That's interesting because it's much the same as Martin reported, but with two key differences. One, that your controller didn't give itself the kiss of death. Two, that it was always the same pointer! Three (sorry, I can't count on mondays) the pointer is reasonable. Four, that they're likely all happening after some control request error. Something that might be useful here: at the very end of ohci-q.c there is a line calling ed_deschedule(). Make it call start_urb_unlink() instead, same signature, and see if anything changes. - Dave ------------------------------------------------------- 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
