Re: ehci + axe panics

I have some more information to add to this.
I'm still working on it.

I've added
#define DIAGNOSTIC
#define USB_DEBUG
to usb.h

When I set hw.usb.ehci.debug to 3 or higher.... everything works.  I can 
run ssh sessions across the axe interface and even run iperf.  The higher 
I set hw.usb.ehci.debug, the more debugging information is displayed, and 
the slower the throughput of the connection.  At hw.usb.ehci.debug=3, I'm 
getting around 250Kb/s - similar to the speeds I get when I use the device 
with ohci.
As soon as I drop hw.usb.ehci.debug down to 2 or lower, throughput goes up 
and there's a page fault panic.  Unfortunately, the debugging information 
at level 2 isn't very helpful.

Right up before the panic, there are a few "usbd_transfer_cb: short 
transfer 0 < 2" and "axe1: read PHY failed" interspersed with all of the 
normal spam.  There's normally about three sets of these, then there's a 
page fault panic in one of three or four different places.

I'm trying to get enough information to put together a coherent PR or 
perhaps fix the problem myself, but this seems to be one of those problems 
in science that can't be observed closely without changing it.

I'm still wondering if my device is trying to use a feature of ehci that 
isn't implemented yet... but if it were, why would the device work at low 
throughput?

> Date: Wed, 9 Jun 2004 22:55:13 -0700 (PDT)
> From: Luke <luked_at_pobox.com>
> To: freebsd-current_at_freebsd.org
> Subject: ehci + axe panics
> 
>
> 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.
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>