linux-kernel - Re: 2.6.20-rc4-mm1 USB (asix) problem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <1168889276.19899.105.camel@dhollis-lnx.sunera.com>
Date:	Mon, 15 Jan 2007 19:27:56 +0000
From:	David Hollis <dhollis@...ehollis.com>
To:	ebuddington@...leyan.edu
Cc:	linux-kernel@...r.kernel.org
Subject: Re: 2.6.20-rc4-mm1 USB (asix) problem

On Sat, 2007-01-13 at 15:31 -0500, Eric Buddington wrote:
> The following problem occured on an Athlon64 X2 under 2.6.20-rc4-mm1,
> but not 2.6.20-rc3-mm1.
> 
> I'm using two D-Link DUB-E100 USB ethernet adapters, using the 'asix'
> driver. When I upgraded to 2.6.20-rc4-mm1, they were still recognized,
> but various ifconfig operations on them (up/down, changing IP) caused
> a system freeze (including caps lock/num lock lights) for many seconds.
> I do not believe there was anything new in dmesg when the system
> resumed. USB debugging was not turned on at the time, though the
> problem is repeatable.
> 
> Also, no packets actually made it out of the adapters (watching from
> other systems on the network).
> 
> Since this is a system we need running and networked, I can't do
> extensive testing on it, but I might be to bring it down for a few
> quick tests if that would help.

Do you happen to have a Rev. B1 DLink adapter?  If so, the only change
that was put in (PHY Select fix) should actually make these devices
work.  Can you check the top of the ax88772_bind() call in your file and
see if it has this bit:

        if ((ret = asix_write_cmd(dev, AX_CMD_SW_PHY_SELECT,
                                1, 0, 0, buf)) < 0) {
                dbg("Select PHY #1 failed: %d", ret);
                goto out2;
        }


That '1' after the AX_CMD_SW_PHY_SELECT was the key to that patch.  If
yours is 1, you could try setting it to 0, though that should make
things not work.  I'd very interested if it made things work for you.
BTW, the ramifications of this bug were similar to what you describe:
the interface would come up, look fine but just wouldn't send or receive
any packets. The hard lock-ups and such are likely from something else.

-- 
David Hollis <dhollis@...ehollis.com>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/