netdev - Re: Re: Strange connection slowdown on pcnet32

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: <20070220214433.GA22467@csclub.uwaterloo.ca>
Date:	Tue, 20 Feb 2007 16:44:33 -0500
From:	lsorense@...lub.uwaterloo.ca (Lennart Sorensen)
To:	pcnet32@...izon.net
Cc:	netdev@...r.kernel.org
Subject: Re: Re: Strange connection slowdown on pcnet32

On Mon, Feb 19, 2007 at 06:59:16PM -0500, Lennart Sorensen wrote:
> I am also noticing the receive error count going up, and the source is
> this code:
> 
> if (status & 0x01)      /* Only count a general error at the */
>        lp->stats.rx_errors++;  /* end of a packet. */
> 
> It appears this means I am receiving a frame marked with "End Of Packet"
> but without "Start of Packet".  I have no idea how that happens, but it
> shouldn't be able to make the driver and MAC stop processing the receive
> ring.

Well the packets actually have both start and end marked, but also have
overflow marked, so the cpu simply isn't keeping up it seems (It is
taking about 100% of the cpu to push through 6500KB/s).  Certainly the
CONFIG_X86_OOSTORE makes a major difference, although I am still not
sure why.  Simply skipping ahead one or two receive descriptors when the
current one is marked as owned by the MAC but the one a few ahead is
owned by the CPU allows it to continue receiving when it happens.  I
really want to find out why it happens though, although I am not sure
how to go about doing that.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html