ehci + axe panics
Luke
luked at pobox.com
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
support?
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