netdev - Re: kernel BUG in eth_alloc_tx_desc_index at drivers/net/mv643xx

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: <7d01f9f00701090944o62f39fb4yfaa5449c2d2d010d@mail.gmail.com>
Date:	Tue, 9 Jan 2007 18:44:49 +0100
From:	"Thibaut VARENE" <T-Bone@...isc-linux.org>
To:	"Jarek Poplawski" <jarkao2@...pl>
Cc:	netdev@...r.kernel.org, dale@...nsworth.org, mlachwani@...sta.com
Subject: Re: kernel BUG in eth_alloc_tx_desc_index at drivers/net/mv643xx_eth.c:1069!

On 1/9/07, Jarek Poplawski <jarkao2@...pl> wrote:
> On Tue, Jan 09, 2007 at 11:27:59AM +0100, Thibaut VARENE wrote:
> ...
> > I suspected both and changed both the disk and the ram for quality
> > parts, that I tested afterwards. Both passed thorough tests.
> >
> > Finally, using the other NIC on the box (a VIA Rhine II, 100Mbps),
> > works absolutely fine.
>
> If you are not tired, I'd suggest two more tests:

I volunteered to help :)

For the sake of testing up-to-date code, I performed the following
tests with 2.6.20-rc4.

First test was the usual nfs video playback. Crashdump is
panic-2.6.20-rc4-nfs.txt. Went down in about 20mn.

> - as above but with NIC set to 100Mbps also,

Couldn't crash the machine (or at least it didn't happen in the time
frame I was willing to wait for doing ftp downloads, ~20mn). One note
though:

The throughput of the card was terribly sucky when set in 100-FD: I
couldn't get more than 5,5MB/s doing ftp get writing to /dev/null (to
rule out disk perf), ie, half the max link speed, though the /only/
thing I changed in the setup was the link speed (same switch - made
sure it properly detected link speed/duplex, same file server, same
everything else).

When configured in 1000-FD, still writing to /dev/null I could get
about 60MB/s. Again half link speed, but there, I suppose that the
remote fileserver couldn't pull data faster from the disks :)

> - long downloading but without nfs e.g. ftp

That was fast and easy. In 1000-FD, I took down the box in 2s (after
downloading 90MB). Crashdump is panic-2.6.20-rc4-ftp.txt

> (btw. there were some patches after 2.6.19
> for rpc memory races).

It seems that's something else. I think I also reproduced the bug
while surfing the internet with firefox, but I didn't have serial line
hooked to capture a dump, unfortunately.

> PS: Maintainers were cc-ed, I hope?

Now they are :)

HTH

T-Bone

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/

View attachment "panic-2.6.20-rc4-ftp.txt" of type "text/plain" (3726 bytes)

View attachment "panic-2.6.20-rc4-nfs.txt" of type "text/plain" (4455 bytes)