Re: [RFT] Realtek 8168 ethernet support
Hi, sorry for the delayed response... On 13/06/06 00:29, Francois Romieu wrote: wget goes faster, right ? Do you have some vmstat 1 output at hand for it ? It does indeed go faster, and it seems a little bit more reliable, but with big enough transfers it locks up too. See commandline-2.txt and vmstat-2.txt - it gets through around 600-700MB before locking up. I also noticed that at 3-4 points during the transfer it seemed to pause, and then continue. Ok but can you set correctly the link with the command which was told to fail in you first mail ? The patch could fix it. Yes, indeed: doing ethtool -s eth0 speed 10 autoneg off switches it to the slow speed, and keeps it there too (at 10Mb/s). ethtool eth0 still reports Advertised auto-negotiation: Yes and Auto-negotiation: on, which is probably not right. It also reports Advertised link modes: 10baseT/Full only, which is probably correct. It only actually restarts auto-negotiation when I issue the command ethtool -s eth0 autoneg on, at which point the speeds goes back up to 1000Mb/s - the expected behaviour. So it seems ethtool works better than before wrt auto-negotiation. Can you try something like: dd if=/dev/zero bs=1024k count=1000 | ssh -c blowfish hell dd of=/tmp/1000m.bin Well this transfer (from shuttle - hell) completed successfully. See commandline-3.txt and vmstat-3.txt; However I noticed the speed was only around 7 MB/s and wondered if the link speed was maybe set to 100Mb/s, so I immediately afterwards did a wget-test again, which locked up after only 5%. The wget test however did confirm the link speed to be 1000Mb/s. See commandline-4.txt and vmstat-4.txt for that last, short test. May I assume that the freeze locks everything (keyboard, mouse, led) beyond the scp command itself ? Yes indeed. My (usb) keyboard doesn't respond at all anymore, networking is completely out, (usb) mouse freezes too. SysRq doesn't seem to help much either. -- Mourad shuttle:~# wget http://hell/testfile.bin --18:39:21-- http://hell/testfile.bin = `testfile.bin' Resolving hell... 10.10.1.1 Connecting to hell|10.10.1.1|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1,073,741,824 (1.0G) [application/octet-stream] 56% [ ] 602,018,040 27.70M/sETA 00:17 shuttle:~# dd if=/dev/zero bs=1024k count=1000 | ssh -c blowfish hell dd of=/tmp/1000m.bin Password: 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 155.971 seconds, 6.7 MB/s 2047951+99 records in 2048000+0 records out 1048576000 bytes (1.0 GB) copied, 140.689 seconds, 7.5 MB/s shuttle:~# shuttle:~# wget http://hell/testfile.bin --18:57:26-- http://hell/testfile.bin = `testfile.bin' Resolving hell... 10.10.1.1 Connecting to hell|10.10.1.1|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1,073,741,824 (1.0G) [application/octet-stream] 5% [] 57,266,17630.30M/s shuttle:~# vmstat 1 procs ---memory-- ---swap-- -io --system-- cpu r b swpd free buff cache si sobibo incs us sy id wa 0 0 0 983108 4672 29140003311 45264 1 6 92 1 0 0 0 983108 4672 2914000 0 0 45818 0 2 98 0 0 0 0 982556 4688 2958800 464 0 49265 1 2 90 7 0 0 0 981316 4692 3072000 0 0 2029 162 0 2 98 0 0 0 0 951804 4724 5932400 0 0 38927 3128 1 42 57 0 0 1 0 911380 4764 9652800 4 66940 50360 10405 3 63 33 1 0 1 0 875916 4796 13171600 0 0 41138 4251 5 69 0 26 1 1 0 842684 4828 16480400 0 0 38724 4368 3 66 0 31 1 1 0 807468 4872 19929600 0 204 43170 4254 4 59 9 28 1 0 0 772748 4908 23277200 4 32516 39246 4071 3 67 22 8 0 2 0 737656 4940 26625600 0 97720 38868 4612 4 66 30 0 0 2 0 737532 4940 26625600 0 32768 66323 0 5 0 95 0 2 0 738772 4940 26625600 0 6724 55119 0 3 0 97 1 1 0 718436 4972 28860800 0 196 26291 2494 3 47 1 49 0 0 0 676276 5012 32910800 0 0 54791 4380 3 59 2 36 0 2 0 639944 5048 36237600 4 81856 44893 7185 2 54 9 35 0 2 0 640564 5048 36237600 0 14268 61819 0 2 0 98 0 2 0 641928 5048 36237600 024 55318 0 2 0 98 0 1 0 608944 5088 39601600 0 128 45004 9135 4 52 6 38 0 1 0 571868 5124 43154400 0 0 47833 9603 2 59 12 27 1 1 0 529212 5160 47110400 0 84548 52399 4222 2 61 5 32 1 3 0 493500 5200 50649200 4 16384 40790 4236 6 74 0 20 0 3 0 459276 5232 54068400
Re: [RFT] Realtek 8168 ethernet support
On 12/06/06 01:30, Francois Romieu wrote: The patch below agaisnt 2.6.17-rc6 includes the following changes: Just FYI: I just tried this patch set, but it doesn't do anything for the freeze at high speed I mentioned on 2006-06-09. It still locks up. (As an additional data point: I installed win2k on this machine, and it seems to have no problems transferring at high speeds. Just wanted to try to rule out faulty hardware.) Thanks, -- Mourad DC - 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
r8169: freeze at high speeds
Hello, I have a problem where my machine freezes as soon as I send it data at high speeds. It works perfectly fine when transferring files slowly (over the internet for instance). But after sending some data for a few seconds at relatively high speed (let's say 10MB/sec), the whole machine just freezes. I've had it happen at relatively low speeds too (1MB/sec), but it's much less frequent. When I stick to really slow speeds, I can work without problems for days. I'm using the latest Debian kernel, which is based on 2.6.16.17 at the moment. btw: I tried using ethtool to force it on 100Mbit, but it seems to have little effect (it stays put on 1000Mbit). Autonegotiation stays on even after trying to switch it off manually. The machine is a nforce2-based k7 (no SMP). One possibly weird thing is that my SATA controller and my RT8169 are both on the same PCI card (behind a PCI bridge) - lspci is attached. I tried the patch that Francois Romieu posted on 2006-04-18, but it still locks up. I also tried the r1000 driver from Realtek themselves, but that one locks up too. btw2: I do often use nvidia's binary driver, but I made sure it had never been loaded when testing (fresh reboot, without nvidia.ko ever being loaded). Is this a known issue? Can I do anything to track down this bug? Thank you, -- Mourad DC 00:00.0 Host bridge: nVidia Corporation nForce2 AGP (different version?) (rev c1) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Region 0: Memory at e000 (32-bit, prefetchable) [size=128M] Capabilities: [40] AGP version 3.0 Status: RQ=32 Iso- ArqSz=2 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3+ Rate=x4,x8 Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x8 Capabilities: [60] HyperTransport: Host or Secondary Interface Command: WarmRst+ DblEnd- Link Control: CFlE- CST- CFE- LkFail- Init+ EOC- TXO- CRCErr=0 Link Config: MLWI=8bit MLWO=8bit LWI=8bit LWO=8bit Revision ID: 0.16 00:00.1 RAM memory: nVidia Corporation nForce2 Memory Controller 1 (rev c1) Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Unknown device f541 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- 00:00.2 RAM memory: nVidia Corporation nForce2 Memory Controller 4 (rev c1) Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Unknown device f541 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- 00:00.3 RAM memory: nVidia Corporation nForce2 Memory Controller 3 (rev c1) Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Unknown device f541 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- 00:00.4 RAM memory: nVidia Corporation nForce2 Memory Controller 2 (rev c1) Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Unknown device f541 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- 00:00.5 RAM memory: nVidia Corporation nForce2 Memory Controller 5 (rev c1) Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Unknown device f541 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- 00:01.0 ISA bridge: nVidia Corporation nForce2 ISA Bridge (rev a4) Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Unknown device f541 Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Capabilities: [48] HyperTransport: Slave or Primary Interface Command: BaseUnitID=1 UnitCnt=15 MastHost- DefDir- Link Control 0: CFlE- CST- CFE- LkFail- Init+ EOC+ TXO- CRCErr=0 Link Config 0: MLWI=8bit MLWO=8bit LWI=8bit LWO=8bit Link Control 1: CFlE- CST- CFE- LkFail- Init+ EOC- TXO+ CRCErr=0 Link Config 1: MLWI=8bit MLWO=8bit LWI=8bit LWO=8bit Revision ID: 0.00 00:01.1 SMBus: nVidia Corporation nForce2 SMBus (MCP) (rev a2) Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer
