Re: [Bugme-new] [Bug 30952] New: asix driver broken since 2.6.35

Re: [Bugme-new] [Bug 30952] New: asix driver broken since 2.6.35

[Andrew Morton]

(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

The reporter says "workaround suggested in:
https://bugzilla.kernel.org/show_bug.cgi?id=16831 seems to work well
for me as well".  That workaround appears to be "dump the kernel driver
and use the driver off the vendor's website".


On Sat, 12 Mar 2011 14:02:37 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=30952
> 
>            Summary: asix driver broken since 2.6.35
>            Product: Drivers
>            Version: 2.5
>     Kernel Version: 2.6.35+
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: Network
>         AssignedTo: drivers_network@kernel-bugs.osdl.org
>         ReportedBy: lipski.bogdan@gmail.com
>         Regression: Yes
> 
> 
> Hey,
> 
> there a few reports in here logged but I am not sure if they are 100% the same,
> anyway you can close this one as duplicate if so.
> https://bugzilla.kernel.org/show_bug.cgi?id=16831
> https://bugzilla.kernel.org/show_bug.cgi?id=29082
> 
> config:
> - gentoo x64, fully updated
> - tried kernels 2.6.36/2.6.37/2.6.37.3
> - network card d-link dub-e100:
> asix 5-2:1.0: eth2: register 'asix' at usb-0000:00:1d.7-2, ASIX AX88772 USB 2.0
> Ethernet
> 
> Bus 005 Device 002: ID 2001:3c05 D-Link Corp. [hex] DUB-E100 Fast Ethernet
> [asix]
> Device Descriptor:
>   bLength                18
>   bDescriptorType         1
>   bcdUSB               2.00
>   bDeviceClass          255 Vendor Specific Class
>   bDeviceSubClass       255 Vendor Specific Subclass
>   bDeviceProtocol         0
>   bMaxPacketSize0        64
>   idVendor           0x2001 D-Link Corp. [hex]
>   idProduct          0x3c05 DUB-E100 Fast Ethernet [asix]
>   bcdDevice            0.01
>   iManufacturer           1 D-Link Corporation
>   iProduct                2 DUB-E100
>   iSerial                 3 000001
>   bNumConfigurations      1
> 
> card is connected directly to scientific atlanta epc2203 cable/voip modem for
> internet access, reason is isp locks it down to mac address and i really don't
> like calling them in case motherboard changes etc...
> 
> 
> the problem:
> 1. under 2.6.34 (tried 2.6.34-gentoo) everything seems to be well.
> 2. patch from 2.6.35/signed off by Jussi Kivilinna "[PATCH] asix: check packet
> size against mtu+ETH_HLEN instead of ETH_FRAME_LEN"
> => since this patch I am getting a lot of "asix_rx_fixup() Bad RX Length" and
> packets get dropped, under ifconfig I see RX error counter increasing for every
> message logged in dmesg, number of RX errors can shoot up easily to couple
> hundred thousands in just a few hours.
> 3. tried to revert this patch in 2.6.37.3 as it seems to be just a one-liner,
> but it looks like other patches applied to asix.c since 2.6.34 have also some
> influence. anyway when reverting this single patch the behaviour with plenty of
> error messages logged under dmesg stops and there are no RX errors logged under
> ifconfig. however it seems that after some time card starts loosing the packets
> again - i will update this report later if I have any further findings.
> 

Re: [Bugme-new] [Bug 30952] New: asix driver broken since 2.6.35

[David Miller]

From: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Date: Mon, 14 Mar 2011 14:43:09 -0700

> 
> (switched to email.  Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
> 
> The reporter says "workaround suggested in:
> https://bugzilla.kernel.org/show_bug.cgi?id=16831 seems to work well
> for me as well".  That workaround appears to be "dump the kernel driver
> and use the driver off the vendor's website".

This is an issue you've brought up to me several months ago.

I started looking into it, but because the vendor driver development
happens in a completely different universe the divergence noise is
substantial and it's a huge effort to consolidate these two drivers.

I think that until the vendor starts to care, nothing is going to
happen to resolve these ASIC driver bugs.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bugme-new] [Bug 30952] New: asix driver broken since 2.6.35

[Andrew Morton]

On Mon, 14 Mar 2011 14:45:53 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:

> From: Andrew Morton <akpm@linux-foundation.org>
> Date: Mon, 14 Mar 2011 14:43:09 -0700
> 
> > 
> > (switched to email.  Please respond via emailed reply-to-all, not via the
> > bugzilla web interface).
> > 
> > The reporter says "workaround suggested in:
> > https://bugzilla.kernel.org/show_bug.cgi?id=16831 seems to work well
> > for me as well".  That workaround appears to be "dump the kernel driver
> > and use the driver off the vendor's website".
> 
> This is an issue you've brought up to me several months ago.
> 
> I started looking into it, but because the vendor driver development
> happens in a completely different universe the divergence noise is
> substantial and it's a huge effort to consolidate these two drivers.
> 
> I think that until the vendor starts to care, nothing is going to
> happen to resolve these ASIC driver bugs.

Yup.  I suppose an alternative approach might be to feed the current
vendor driver through the drivers/staging process (preferably with
their assistance!) then run with two alternative drivers for a
while and eventually remove the old one.

But that's without having looked at the vendor code.  Is it a Big Mess?

Re: [Bugme-new] [Bug 30952] New: asix driver broken since 2.6.35

[David Miller]

From: Andrew Morton <akpm@linux-foundation.org>
Date: Mon, 14 Mar 2011 14:49:54 -0700

> But that's without having looked at the vendor code.  Is it a Big Mess?

The vendor took the upstream driver at a point a year or two in the
past then did whatever they want with it.

They made no effort to "merge" in changes made to the upstream driver
during this time, so there is serious divergence especially in the PHY
handling which is probably where all the problems are in the upstream
driver.

Even the table of device IDs for probing is orderred and arranged
differently.