usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic

[Pyun YongHyeon]

On Tue, Jul 20, 2010 at 04:10:03PM +0000, Derrick Brashear wrote:
> The following reply was made to PR usb/140883; it has been noted by GNATS.
> 
> From: Derrick Brashear <shadow at gmail.com>
> To: bug-followup at FreeBSD.org
> Cc:  
> Subject: Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short 
> 	period of traffic
> Date: Tue, 20 Jul 2010 11:39:28 -0400
> 
>  Happens with non-gig adapters also:
>  axe0: <vendor 0x13b1 product 0x0018, rev 2.00/0.01, addr 2> on usbus2
>  ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
>  
>  axe1: <vendor 0x13b1 product 0x0018, rev 2.00/0.01, addr 3> on usbus2
>  ukphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
>  
>  USB200M v2.
>  
>  USB_ERR_TIMEOUT until a reset is forced after a large amount of data
>  passes, e.g.
>  Jul 20 01:50:38 rtr kernel: axe_bulk_write_callback: transfer error,
>  USB_ERR_TIMEOUT
>  Jul 20 01:50:48 rtr kernel: axe_bulk_write_callback: transfer error,
>  USB_ERR_TIMEOUT
>  Jul 20 01:50:57 rtr kernel: axe_bulk_write_callback: transfer error,
>  USB_ERR_TIMEOUT
>  Jul 20 01:51:01 rtr kernel: axe_bulk_read_callback: bulk read error,
>  USB_ERR_CANCELLED
>  Jul 20 01:51:01 rtr kernel: axe_bulk_write_callback: transfer error,
>  USB_ERR_CANCELLED
>  Jul 20 01:51:13 rtr kernel: axe_bulk_read_callback: bulk read error,
>  USB_ERR_CANCELLED
>  
>  and data continues to be able to be read after writing it fails, as
>  described in the original PR.
>  

I think your issue is different from the PR. There are several
AX88178 variants that use different PHY and each controller/PHY
combination require different GPIO programming and PHY specific
initialization. Hans committed that part to P4 but it's not in
CURRENT yet.

Your controller looks like AX88772A, a second generation of
AX88172. It's known that there is AX88772B, another variant of
AX88772A, which can offload TX/RX checksum computation from CPU.
These controllers seem to require controller specific magic to
power up PHY as well as new GPIO configuration. Unfortunately it
looks hard to write patches without real hardware access and ASIX
no more provide data sheet for these newer controllers.

>  sysctl -a|grep date
>  kern.osreldate: 801000
>