netdev - Re: Realtek r8168 slow outbound transfer

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>] [day] [month] [year] [list]

Message-ID: <46C2934C.9060907@gmail.com>
Date:	Tue, 14 Aug 2007 22:46:52 -0700
From:	Bruce Cole <bacole@...il.com>
To:	gundy@...et.net.au
CC:	netdev@...r.kernel.org, bacole@...il.com
Subject: Re: Realtek r8168 slow outbound transfer - potential fix/workaround

gundy@...et.net.au wrote:
> Bruce,
>
> I settled on using ndelay(10) rather than udelay(25) in the end..  
> it's probably a bit safer & less likely to cause problems with higher 
> throughputs.
Yes, I saw that you later recommended the change but opted to try it the 
way you tested first. 
>
> When I was diagnosing the problem I used 2 machines.  One machine was 
> running Samba on linux (the 'problem' machine), and one was a windows 
> XP machine.
Likewise, tho I also tested vista.
>
> I used tcpdump to capture the traffic on the Samba machine, and used 
> wireshark to capture the traffic on the windows machine.  What i found 
> was happening was that samba was attempting to send two packets to the 
> windows machine in quick succession (ie. something in the order of a 
> 1/10,000th or less of a second apart).  Although both packets showed 
> up in the tcpdump output from the linux machine, only the first packet 
> appeared to be making it to the windows machine.   Because the second 
> packet was 'lost', it had to be retried after a delay and this is what 
> was causing the abysmal performance.
>
> The reasoning behind my patch was that I figured the TxPoll register 
> wasn't being given enough time to reset itself after sending the 
> previous packet.   I may or may not have been correct with that 
> assumption, but as you noticed the delay does seem to make it behave a 
> bit better.
Disclaimer: I haven't seen the definition for that register so I'm just 
guessing here.
I suppose the danger is that your fix may just be changing the timing 
around such that the time-dependent bug does not occur as readily, yet a 
bug remains.  Does anyone have the programming spec for this chip from 
realtek, or are we all just forced to guess :)?
>
> I understand that Francios came up with a similar patch that he said 
> also worked, and that he thought was a bit more robust than my 
> method.  I'd check with him on what the status of that particular 
> patch is.
Thanks, I don't see that patch in 2.6.23-rc3 but I'll try Francios' 
recommendations first and if that doesn't work I'll test out things with 
the shorter ndelay().

-
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