linux-kernel - Re: sky2 hangs on me again: This time 200 kb/s IPv4 traffic, not easily reproducable

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]

Date:	Sun, 3 Sep 2006 15:55:24 +0200
From:	Denis Vlasenko <vda.linux@...glemail.com>
To:	shogunx <shogunx@...ekfreak.ath.cx>
Cc:	Matthias Hentges <oe@...tges.net>,
	Thomas Glanzmann <sithglan@...d.uni-erlangen.de>,
	Stephen Hemminger <shemminger@...l.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: sky2 hangs on me again: This time 200 kb/s IPv4 traffic, not easily reproducable

On Sunday 03 September 2006 01:49, shogunx wrote:
> > > > Well, it just crapped out on me again :(
> > > >
> > > > Sep  2 23:36:13 localhost kernel: NETDEV WATCHDOG: eth2: transmit timed
> > > > out
> > > > Sep  2 23:36:13 localhost kernel: sky2 hardware hung? flushing
> > > >
> > > > Only a rmmod / modprobe cycle helps at this point.
> > >
> > > Really?  What is the error condition causing it?  On my friends lap, which
> > > has an integrated sky2, his drops out with a full sustained TX...
> > > uploading to another box for example, at about 4-8MB of transfer.  The
> > > fix in his case is ifdown eth0 && ifup eth0.  I have
> > > yet to see the error occur at all on my ExpressCard device, either with
> > > 2.6.18-rc5 or 2.6.17.5.  I built the rc5 as a preemptive measure, but I
> > > cannot get it to fail under any conditions.
> > >
> >
> > I have yet to find a reproduceable way to trigger the bug but I'll try a
> > few things tomorrow.
> > Currently it appears to be completely ranom. I've loaded the driver w/
> > debug=10, maybe it'll give some clues.
> 
> Ack.  Awaiting more info.  I pushed it pretty hard last night with both
> kernel revisions, scp'ing cd iso images and kernel tarballs back and forth
> across the interface, and could not get it to lock.  I am using a 88E8053
> chipset.  I'll ask my friend what chipset his is.  Perhaps its a
> different bug that is hitting you now...

scp isn't "pushing very hard". It takes some time to do ssh crypto
and even if your CPU is fast enough for that to be not an issue,
scp is using TCP, which is _designed_ to not saturate links to 100.00%.

Give it a real hard beating with uni- and bidirectional UDP netcat flood! :)
--
vda

-- 
VGER BF report: U 0.511791
-
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/