L F wrote:
Aha. This doesn't seem to be in mr. Romieu's patch above: should it go
in on top of that?
His newer
0002-r8169-workaround-against-ignored-TxPoll-writes-8168.patch
does the same thing as the older quoted version, and is also
included in the roll-up patch he pointed you to.
I
Francois Romieu wrote:
Bruce Cole [EMAIL PROTECTED] :
If you look for it on the Realtek cards, there had been sporadic
Nissues up to late 2005. The solution posted universally was 'change
card'.
Yes, that *was* the common recommendation.
There was no such thing as a universal
If you look for it on the Realtek cards, there had been sporadic
Nissues up to late 2005. The solution posted universally was 'change
card'.
Yes, that *was* the common recommendation. But recently I narrowed down the
realtek performance problem most commonly seen with samba (but also
Francois Romieu wrote:
Does acceptable mean that there is a noticeable difference when compared
to the patch based on a busy-waiting loop ?
Would you like me to *just* try patches 1 2, to help narrow down anything?
I expect patch #2 alone to be enough to enhance the performance. If
Just upgraded a motherboard and it came with an onboard
Realtek card which appears to use the r8169 driver. The
machine is a samba server and when serving files to a local
Linux or Windows client, I only get approx 40-60 kbps.
Write performance is fine though, in the tens of mbps and
scp, nfs,
On 8/20/07, Dirk wrote:
So it seems that when the driver tries to queue a packet while the
controller is busy processing the queue, the newly queued packet does
not get noticed by the controller (until further packet activity
occurs).
Perhaps there is a problem with the memory barriers when
So I did some experimenting with locking, but eventually found that this
chunk:
@@ -2677,10 +2681,18 @@ static void rtl8169_tx_interrupt(struct
net_device *dev,
if (tp-dirty_tx != dirty_tx) {
tp-dirty_tx = dirty_tx;
- -smp_wmb();
- -if (netif_queue_stopped(dev)
-
Francois Romieu wrote:
The latest serie of r8169 changes is available against 2.6.23-rc3 as:
http://www.fr.zoreil.com/people/francois/misc/20070818-2.6.23-rc3-r8169-test.patch
or (tarball sits one level higher):
http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.23-rc3/r8169-20070818/
or
Francois Romieu wrote:
Bruce Cole [EMAIL PROTECTED] :
[...]
What's the status of this fix? It (or something more refined) seems
necessary to correct the current performance problems with this driver.
An explanation or something more refined would be welcome.
Are you indicating
[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
David Gundersen [EMAIL PROTECTED] :
Now, on to my workaround. Putting a spin style wait like the following
in front of the line above seemed to solve the problem for me:
if (RTL_R8(TxPoll) NPQ) {
for (i = 20; i 0; i--) {
if (!(RTL_R8(TxPoll) NPQ))
break;
11 matches
Mail list logo
