The usb-uhci driver doesn't work in 2.4.1-0.1.8 - when inserting a USB mouse (or just let it be there, the kernel on the installation disk works), this happens: hub.c: USB new device connect on bus1/2, assigned device number 2 usb_control/bulk_msg: timeout usb.c: USB device not accepting new address=2 (error=-110) hub.c: USB new device connect on bus1/2, assigned device number 3 usb_control/bulk_msg: timeout usb.c: USB device not accepting new address=3 (error=-110) Switching to the uhci driver works around the problem, but we need to decide which one to stick with.
This defect is considered MUST-FIX for Florence Release-Candidate #1
FYI, I upgraded Dell Latitude LS500 from fisher kernel to 2.4.1-0.1.8. As soon as usb-uhci initializes, I get constant errors: "usb-uhci.c: interrupt, status x, frame# 0" where x = {10,20,30}
New info from the LS500... I only seem to get this error when eth0, the inbuilt 3Com Ethernet, is _up_.... I will attach /proc entries and my lsmod output... DS..
Created attachment 10221 [details] /proc contents and lsmod output
Try 0.1.9
0.1.9 looks good, i.e. error messages have gone. I haven't actually tried using USB.
The problem is that slab poisoning appears to be catching a bug in USB. We turned slab poisoning off in 0.1.9. I am not marking this bug as fixed because we don't know why turning off slab poisoning works around the bug.
*** Bug 27656 has been marked as a duplicate of this bug. ***
The problem is identified as a violation of alignment restrictions for the UHCI controller. If kmalloc or non-poisoned slab are used, the 16 bytes alignment occurs naturally due to L1 cache alignment. This is NOT guaranteed if slab is poisoned. IMHO, the proper fix for this problem is to split decriptors into hardware accessible, aligned, perhaps uncached, DMA-able part, and regular software part. It comes out pretty big, so it needs some testing. Works well on my machine so far.
Created attachment 11701 [details] linux-2.4.2-ac7-p3-usb-slab.diff
It has been decided to go ahead with the fix.