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  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]
Date:	Tue, 14 Aug 2007 22:46:52 -0700
From:	Bruce Cole <>
Subject: Re: Realtek r8168 slow outbound transfer - potential fix/workaround 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
More majordomo info at

Powered by blists - more mailing lists