[EMAIL PROTECTED] 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
