r8169, 2.6.2-rc2, Sager 4780 laptop

r8169, 2.6.2-rc2, Sager 4780 laptop

[bhartin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2898 bytes --]


(This was meant for author of the patches located at 
http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.2-rc1/, who states to CC 
the netdev list in regards to help with these patches.  Unfortunately, the 
author only stated to CC this list, but didn't include his own email.)

I've been looking through your patches as a source for help with my new 
laptop.  It's a Sager 4780, which uses an RTL-8169 on board.  It is an 
internal PCI version.

Under kernel 2.4.22, this NIC works perfectly.

Under 2.6.1 and 2.6.2-rc2, I have the following situation.

When I scp a file onto the laptop across the NIC, I get about 
4.5Mbyte/sec, and once it reaches about 13MByte transferred, the NIC 
ceases to function.  No oops messages, no errors.  You can't ping in or 
out of the interface any longer.

When you scp a file from the laptop to elsewhere, it transfers at about 
700kbyte/sec, and once it reaches a little over 6MByte, the entire system 
locks up, hard.

This has been done on two completely different networks with varying 
hardware, as to rule out anything related to such.

I have tried your 2.6.2-rc1 patches against 2.6.2-rc2 (they apply 
cleanly).  The driver behaves the same as before.

When I apply your 2.6.1 patches against 2.6.1, I get varying responses.  
I tried a few combinations (following your order as listed).  The most
notable effect of any of them is the r8169-init-one.patch.  When I apply
that, insmod or modprobe lock up when inserting the module.  They are
unkillable processes at that point.  I even tried applying all the patches
except that one and the ethtool patch (it won't apply cleanly without the
init-one patch applied).  When I did this, I started getting messages
about "eth0: Too much work at interrupt!"  Once this occured, I rebooted
back into a stable 2.4.22 kernel.  The NIC wasn't responding.  I even
tried booting into WinXP, but the NIC still wouldn't respond.  I was
finally forced to remove the battery from the laptop (not meant to be a
user task, as it is under a screwed-down cover).  Once this was done, it
finally cleared the NIC properly and allowed me to continue.

I attempted a similar run with the 2.6.2-rc1 patches, cutting out the last 
patch on the list one-by-one.

Attached is a tar.gz containing the outputs you request in your README, 
plus 'lspci -v' output and my .config for the kernel.  This data was 
collected from a fresh 2.6.2-rc2 bootup, using your full set of 2.6.2-rc1 
patches, manually doing a 'modprobe r8169' once booted up.  The system is 
running a P4 with HT enabled, with an SMP kernel.

I'm not at all familiar with kernel debugging, but I should be able to 
carry out any tasks needed, given some minor instructions.

Please CC replies to my email address, as I'm not part of this mailing 
list.

Thanks,

Bradley Hartin - bhartin@straus-frank.com
Communications and Network Administrator
Straus-Frank Company

[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 14383 bytes --]

Re: r8169, 2.6.2-rc2, Sager 4780 laptop

[Francois Romieu]

bhartin@straus-frank.com <bhartin@straus-frank.com> :
[...]
> Attached is a tar.gz containing the outputs you request in your README, 
> plus 'lspci -v' output and my .config for the kernel.  This data was 
> collected from a fresh 2.6.2-rc2 bootup, using your full set of 2.6.2-rc1 
> patches, manually doing a 'modprobe r8169' once booted up.  The system is 
> running a P4 with HT enabled, with an SMP kernel.

There has been report of non-regression on non-SMP kernel with the following
patches applied (2.6.2-rc1 serie):
r8169-tx-index-overflow.patch
r8169-dma-api-tx.patch
r8169-dma-api-rx-buffers.patch
r8169-dma-api-tx-buffers.patch
r8169-rx_copybreak.patch
r8169-mac-phy-version.patch
r8169-init_one.patch
r8169-timer.patch
r8169-hw_start.patch
r8169-intr_mask.patch
r8169-suspend.patch
r8169-endianness.patch
r8169-getstats.patch

Can you confirm that the driver behaves the same as the standard driver
with a non-SMP enabled kernel ?

Does it make a difference if you give an 'acpi=off' option at boot time ?

r8169-addr-high.patch is not doing its job on amd64 so it is not suggested
to use it at all.

There is something broken wrt SMP and the r8169 patches: do not use both at
the same time. I still have to find what happens here.

--
Ueimor

Re: r8169, 2.6.2-rc2, Sager 4780 laptop

[bhartin]

Okay, I patched using only the patches listed below.  These are actually 
applied against 2.6.2-rc2, since I don't have 2.6.2-rc1 on hand at the 
moment, and your patches still apply cleanly.

acpi=off 
- RX - Pushed about a gig, averaging 8.2MB/sec.  Appeared to work ok.
- TX - Once I hit 642MB transfered (avg 8.9MB/sec), the system locked up 
hard.

SMP off, acpi on
- TX - Hard lock at 307MB.

SMP off, acpi off
- TX - Hard lock at 345MB.

I'll try to investigate further tomorrow.  I have to go out of town 
starting Thursday, and was hoping to have everything working by then.  
Unfortunately, I have other problems to deal with as well (ati-drivers, 
slmodem, etc).

Thanks

On Mon, 26 Jan 2004, Francois Romieu wrote:

> bhartin@straus-frank.com <bhartin@straus-frank.com> :
> [...]
> > Attached is a tar.gz containing the outputs you request in your README, 
> > plus 'lspci -v' output and my .config for the kernel.  This data was 
> > collected from a fresh 2.6.2-rc2 bootup, using your full set of 2.6.2-rc1 
> > patches, manually doing a 'modprobe r8169' once booted up.  The system is 
> > running a P4 with HT enabled, with an SMP kernel.
> 
> There has been report of non-regression on non-SMP kernel with the following
> patches applied (2.6.2-rc1 serie):
> r8169-tx-index-overflow.patch
> r8169-dma-api-tx.patch
> r8169-dma-api-rx-buffers.patch
> r8169-dma-api-tx-buffers.patch
> r8169-rx_copybreak.patch
> r8169-mac-phy-version.patch
> r8169-init_one.patch
> r8169-timer.patch
> r8169-hw_start.patch
> r8169-intr_mask.patch
> r8169-suspend.patch
> r8169-endianness.patch
> r8169-getstats.patch
> 
> Can you confirm that the driver behaves the same as the standard driver
> with a non-SMP enabled kernel ?
> 
> Does it make a difference if you give an 'acpi=off' option at boot time ?
> 
> r8169-addr-high.patch is not doing its job on amd64 so it is not suggested
> to use it at all.
> 
> There is something broken wrt SMP and the r8169 patches: do not use both at
> the same time. I still have to find what happens here.
> 
> --
> Ueimor
> 

Bradley Hartin - bhartin@straus-frank.com
Communications and Network Administrator
Straus-Frank Company

Re: r8169, 2.6.2-rc2, Sager 4780 laptop

[bhartin]

Francois:

I don't remember if I ever did reply to you last time concerning this.  
Since I emailed you, I've tried many, many versions of the 2.6.x series 
kernels and superpatch variants.  The only change was with today's release 
of 2.6.5.  I now get the message "eth0: Too much work at interrupt!" prior 
to the interface locking up.

I still have absolutely no problems with the 2.4.x kernels with respect to 
the networking (I have video/AGP issues with it though, but that's another 
story).

Trying the same kernel with SMP and ACPI disabled:  Rather than the 
interface locking up (the NIC failing to transmit or receive), the entire 
system locks up hard.

All of these tests are done on a 100Mbit network, both on an unmanaged 
Linksys switch and on a Cisco 2948G, with the same results.  The test is 
done by doing an scp to copy a remote file to the local filesystem.  The 
lockups occur anywhere from 45MBytes to 95MBytes transferred.

I haven't tried your latest set of patches because I haven't been able to 
find the URL for them again (I got carried away cleaning up my bookmarks 
recently).  Let me know if there are any newer ones you'd like for me to 
try.

Bradley Hartin - bhartin@straus-frank.com
Communications and Network Administrator
Straus-Frank Company
Thanks,

On Mon, 26 Jan 2004, Francois Romieu wrote:

> bhartin@straus-frank.com <bhartin@straus-frank.com> :
> [...]
> > Attached is a tar.gz containing the outputs you request in your README, 
> > plus 'lspci -v' output and my .config for the kernel.  This data was 
> > collected from a fresh 2.6.2-rc2 bootup, using your full set of 2.6.2-rc1 
> > patches, manually doing a 'modprobe r8169' once booted up.  The system is 
> > running a P4 with HT enabled, with an SMP kernel.
> 
> There has been report of non-regression on non-SMP kernel with the following
> patches applied (2.6.2-rc1 serie):
> r8169-tx-index-overflow.patch
> r8169-dma-api-tx.patch
> r8169-dma-api-rx-buffers.patch
> r8169-dma-api-tx-buffers.patch
> r8169-rx_copybreak.patch
> r8169-mac-phy-version.patch
> r8169-init_one.patch
> r8169-timer.patch
> r8169-hw_start.patch
> r8169-intr_mask.patch
> r8169-suspend.patch
> r8169-endianness.patch
> r8169-getstats.patch
> 
> Can you confirm that the driver behaves the same as the standard driver
> with a non-SMP enabled kernel ?
> 
> Does it make a difference if you give an 'acpi=off' option at boot time ?
> 
> r8169-addr-high.patch is not doing its job on amd64 so it is not suggested
> to use it at all.
> 
> There is something broken wrt SMP and the r8169 patches: do not use both at
> the same time. I still have to find what happens here.
> 
> --
> Ueimor

Re: r8169, 2.6.2-rc2, Sager 4780 laptop

[Francois Romieu]

bhartin@straus-frank.com <bhartin@straus-frank.com> :
[...]
> I haven't tried your latest set of patches because I haven't been able to 
> find the URL for them again (I got carried away cleaning up my bookmarks 
> recently).  Let me know if there are any newer ones you'd like for me to 
> try.

http://www.fr.zoreil.com/people/francois/misc/20040329-2.6.5-rc2-r8169.c-test.patch

It removes a possible loop in the Tx irq handler and should save some cpu
cycles as well. Apply against 2.6.5.

--
Ueimor

Re: r8169, 2.6.2-rc2, Sager 4780 laptop

[bhartin]

Here are the results using this new patch:

No SMP, no ACPI:  Appears to work well--transferred about 8 gigs okay
With SMP, with ACPI:  Interface locks up after a few MB
With SMP, no ACPI:  Interface locks up after a few MB
No SMP, with ACPI:  Appears to work well--transferred about 8 gigs okay

My laptop is *finally* reaching full usability!  Thanks!

I can live without SMP--this is just a single P4/HT, so I'm not losing 
much.

Thanks again.  If there is any debugging info you need towards fixing the 
SMP compatibility issue, just let me know, but I'm not in a hurry for 
it.

Bradley Hartin - bhartin@straus-frank.com
Communications and Network Administrator
Straus-Frank Company
Thanks,

On Mon, 5 Apr 2004, Francois Romieu wrote:

> bhartin@straus-frank.com <bhartin@straus-frank.com> :
> [...]
> > I haven't tried your latest set of patches because I haven't been able to 
> > find the URL for them again (I got carried away cleaning up my bookmarks 
> > recently).  Let me know if there are any newer ones you'd like for me to 
> > try.
> 
> http://www.fr.zoreil.com/people/francois/misc/20040329-2.6.5-rc2-r8169.c-test.patch
> 
> It removes a possible loop in the Tx irq handler and should save some cpu
> cycles as well. Apply against 2.6.5.
> 
> --
> Ueimor
> 

Bradley Hartin - bhartin@straus-frank.com
Communications and Network Administrator
Straus-Frank Company

Re: r8169, 2.6.2-rc2, Sager 4780 laptop

[bhartin]

On Wed, 7 Apr 2004, Francois Romieu wrote:

> Hmmm... Something like "no PHY Reset ack. Giving up." I guess. Ok, I'll
> add it to the queue, the locking between the phy_timer() and the irq handler
> looks strange.

I got my laptop back up and found the messages logged:

kernel: r8169: eth0: Reset RTL8169s PHY

I didn't see exactly at what point this started happening during the 
shutdown, but the message repeated about 500 times before the system 
logger was stopped.

Again, I've had no issues so far during normal use.  There are no abnormal 
timeouts, and transfer rates appear within normal ranges.  (I've only used 
it on 100bT switches so far, no 10bT or gigabit.)

> As a general note, do not hesitate to post on/Cc: netdev as it can be of
> interest to other people as well.

I meant to, but must have hit no when Pine asked about replying to all 
recipients.

> Thanks for the report.

Not a problem at all.  I'm just glad to finally get this thing working!

Bradley Hartin - bhartin@straus-frank.com
Communications and Network Administrator
Straus-Frank Company

Re: r8169, 2.6.2-rc2, Sager 4780 laptop

[Francois Romieu]

bhartin@straus-frank.com <bhartin@straus-frank.com> :
[...]
> I got my laptop back up and found the messages logged:
> 
> kernel: r8169: eth0: Reset RTL8169s PHY
> 
> I didn't see exactly at what point this started happening during the 
> shutdown, but the message repeated about 500 times before the system 
> logger was stopped.

It implies a minimum of 6000 invocations of rtl8169_phy_timer(). 

*doh*

Please apply patch below.



mod_timer() expects an absolute time, not a relative offset.


 drivers/net/r8169.c |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

diff -puN drivers/net/r8169.c~r8169-mod_timer drivers/net/r8169.c
--- linux-2.6.5/drivers/net/r8169.c~r8169-mod_timer	2004-04-07 01:30:14.000000000 +0200
+++ linux-2.6.5-fr/drivers/net/r8169.c	2004-04-07 01:32:53.000000000 +0200
@@ -617,7 +617,7 @@ static void rtl8169_phy_timer(unsigned l
 		}
 	}
 
-	mod_timer(timer, RTL8169_PHY_TIMEOUT);
+	mod_timer(timer, jiffies + RTL8169_PHY_TIMEOUT);
 }
 
 static inline void rtl8169_delete_timer(struct net_device *dev)

_

Re: r8169, 2.6.2-rc2, Sager 4780 laptop

[bhartin]

The patch resolved the PHY messages, and I stress-tested the networking 
again--it's still stable.

Thanks!

Bradley Hartin - bhartin@straus-frank.com
Communications and Network Administrator
Straus-Frank Company

On Wed, 7 Apr 2004, Francois Romieu wrote:

> bhartin@straus-frank.com <bhartin@straus-frank.com> :
> [...]
> > I got my laptop back up and found the messages logged:
> > 
> > kernel: r8169: eth0: Reset RTL8169s PHY
> > 
> > I didn't see exactly at what point this started happening during the 
> > shutdown, but the message repeated about 500 times before the system 
> > logger was stopped.
> 
> It implies a minimum of 6000 invocations of rtl8169_phy_timer(). 
> 
> *doh*
> 
> Please apply patch below.
> 
> 
> 
> mod_timer() expects an absolute time, not a relative offset.
> 
> 
>  drivers/net/r8169.c |    2 +-
>  1 files changed, 1 insertion(+), 1 deletion(-)
> 
> diff -puN drivers/net/r8169.c~r8169-mod_timer drivers/net/r8169.c
> --- linux-2.6.5/drivers/net/r8169.c~r8169-mod_timer	2004-04-07 01:30:14.000000000 +0200
> +++ linux-2.6.5-fr/drivers/net/r8169.c	2004-04-07 01:32:53.000000000 +0200
> @@ -617,7 +617,7 @@ static void rtl8169_phy_timer(unsigned l
>  		}
>  	}
>  
> -	mod_timer(timer, RTL8169_PHY_TIMEOUT);
> +	mod_timer(timer, jiffies + RTL8169_PHY_TIMEOUT);
>  }
>  
>  static inline void rtl8169_delete_timer(struct net_device *dev)
> 
> _
> 

Bradley Hartin - bhartin@straus-frank.com
Communications and Network Administrator
Straus-Frank Company

Re: r8169, 2.6.2-rc2, Sager 4780 laptop

[Francois Romieu]

bhartin@straus-frank.com <bhartin@straus-frank.com> :
[...]
> The patch resolved the PHY messages, and I stress-tested the networking 
> again--it's still stable.

Does it allow the link to be recovered if the cable is removed/plugde ?

--
Ueimor

Re: r8169, 2.6.2-rc2, Sager 4780 laptop

[bhartin]

I started a ping, and unplugged the network cable.  I got the 'r8169: 
eth0: Reset RTL8169s PHY' message about once every 11 to 15 seconds.  Once 
plugged back in, the connection recovered immediately.  I repeated this 
several times.  So, it's still generating the messages, but they seem to 
be harmless (at least for the few minutes I was testing this).

On Wed, 7 Apr 2004, Francois Romieu wrote:

> bhartin@straus-frank.com <bhartin@straus-frank.com> :
> [...]
> > The patch resolved the PHY messages, and I stress-tested the networking 
> > again--it's still stable.
> 
> Does it allow the link to be recovered if the cable is removed/plugde ?
> 
> --
> Ueimor
> 

Bradley Hartin - bhartin@straus-frank.com
Communications and Network Administrator
Straus-Frank Company