ehci + axe panics

Luke luked at
Thu Jun 10 05:55:33 GMT 2004

I recently built the ehci driver into my CURRENT kernel so that I could 
try out USB 2.0 with my Netgear FA120 USB 2.0 network interface.  I've 
been using it with just ohci for several weeks, and since Ian Dowse's last 
patch to the axe driver, I've had no trouble with it except for the slow 
USB 1 speed.

Since I've started using ehci, I've started getting a variety of different 
kernel panics whenever I ifconfig the axe device and attempt to use it. 
As long as I don't assign an IP address to the device and don't send any 
traffic across it, there's no problem.  I can usually ping across it for a 
few minutes too, but very soon it becomes angry and panics.

I've added "#define USB_DEBUG" to usb.h, rebuilt the kernel, and played 
around with the hw.usb sysctl settings trying to get more information, but 
it all means little to me.

I've seen three varieties of panics so far, and there may be more 
variations.  They're all "Fatal trap 12: page faults".
The most common one I've seen is thrown by (irq9: ehci0), the interrupt 
assigned to my ehci controller.  One variety of it ends with "memcpy", 
preceded by "ehci_idone" and "ehci_checkintr".
Another variety, also thrown by (irq9: ehci0), ends with 
"usb_freemem" preceded by "ehci_freemem", "usb_transfer_complete", 
"ehci_done", and "ehci_checkintr".
The third variety I've seen was thrown by (swi1: net), and I'd seen so 
many variations by now I didn't bother writing it down.

In all cases, a mere second or two  before the panic occurs, the bright 
system message "read PHY failed" appears on the console, sometimes twice.

When I turned up the debugging levels, the "read PHY failed" messages 
became "usbd_transfer_cb: short transfer 0<2" followed by "axe1: read PHY 
failed".  I think this is the key to the whole thing - the herald of the 
coming panic.

Am I attempting to make use of a feature that the ehci driver does not yet 

If anybody would like any debugging information, I'll be happy to provide 
what I'm able.  So far I've been unsuccessful at getting the debugger to 
save a dump to the disk, but I can take scripts and copy down debugger 
traces if that would be useful to anyone.

More information about the freebsd-current mailing list