On Wed, 8 Mar 2006, Andrew Morton wrote: > Alan Stern <[EMAIL PROTECTED]> wrote: > > > > What about those scheduler changes you found through the bisection search? > > Any word on that? > > Ingo's gone over them pretty closely. The current theory is that the CPU > scheduler change alters timing sufficiently for the bug to bite. > > The machine passes memtest86. > > Ingo's suspecting stack corruption. Do you know whether USB anywhere does > DMA into automatically-allocated storage (ie: kernel stacks)?
We try to avoid doing that, but such things have been known to creep into the sources from time to time. We fix them whenever they surface. I'm pretty sure that usbcore and usb-storage are clean in this respect, and probably usbhid is also (I haven't gone through it to check personally; presumably others have). The only drivers listed in your /proc/bus/usb/devices were hub and usbhid, and the ALPS UGX device didn't have any drivers bound. Have you tried running your test with the USB devices unplugged? That won't prevent usb_choose_configuration from getting called (since it's used for the virtual root hubs exported by the host controller drivers) but it should make everything more deterministic. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
