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
| ||
|
Date: Tue, 18 Sep 2007 02:03:58 -0400 From: Bill Fink <billfink@...dspring.com> To: "Brandeburg, Jesse" <jesse.brandeburg@...el.com> Cc: "L F" <lfabio.linux@...il.com>, "Kok, Auke-jan H" <auke-jan.h.kok@...el.com>, "James Chapman" <jchapman@...alix.com>, <netdev@...r.kernel.org> Subject: Re: e1000 driver and samba On Mon, 17 Sep 2007, Brandeburg, Jesse wrote: > L F wrote: > > On 9/17/07, Kok, Auke <auke-jan.h.kok@...el.com> wrote: > >> The statistic we were looking at _will_ increase when running in > >> half duplex, but if it increases when running in full duplex might > >> indicate a hardware failure. Probably you have fixed the issue with > >> the CAT6 cable. > > Uhm, 'fixed' may be premature: I restarted the machine and with 22 > > hours uptime I am getting: > > tx_deferred_ok: 36254 > > > >> Can you run this new configuration with the old cable? that would > >> eliminate the cable (or not) > > I most certainly can. This seems to have gotten worse by a factor or > > 100 or more.. so am I to suspect the new cable? > > > >> A single port failure on a switch can also happen, and samba is > >> definately > >> a good test for defective hardware. I cannot rule out anything from > >> the information we have gotten yet. > > True, but I tried changing the switch ports with little change. > > Putting a client on the same switch port yielded no errors on the > > client, although unfortunately I don't have ethtool statistics on XP. > > The switch, btw, is a fairly generic GS108 from Netgear (there > > actually are two). > > it may be not well documented, but the hardware has several states that > it can get into that can cause tx_deferred counter to increment. None > of them are fatal to traffic, it is mainly an informational statistic. > > in this case it is in the "due to receiving flow control; tx is paused" > state... > > he has 488 rx flow control xoff/xon, which means the switch is being > overloaded and sending flow control, or the switch is passing through > flow control packets (which it should not since they are multicast) and > (some) client is overloaded. > > can you turn off flow control at the server? ethtool -A ethX rx off tx > off or load the driver with parameter FlowControl=0 With the 7.6.5 > driver at least you'll get confirmation of the flow control change on > the "Link Up:" line. It may also be a useful test to disable hardware TSO support via "ethtool -K ethX tso off". -Bill - 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
Powered by blists - more mailing lists