Created attachment 362026 [details]
Output of lspci
When trying to perform a rsync operation, as part of a rsnapshot backup, the entire network interface hangs. No packets are sent or received. After I cancel the rsync command, it takes about 10m for the network to recover.
It does recover, but stays unusable this whole period. Pings sent to the affected machine are either dropped or are replied with huge delays, sometimes as large as 90s.
This bug appears only in kernel-126.96.36.199-43.fc11.x86_64. I can reproduce it every time with the command below. If I boot with kernel-188.8.131.52-217.2.16.fc11.x86_64 it never appears.
The rsync command that triggers is very basic, something like:
/usr/bin/rsync -a --delete --numeric-ids --relative --delete-excluded \
--exclude=.gvfs --rsh=/usr/bin/ssh <auser>@<ahost>:<adir> \
I really don't know what kind of information may be useful for a issue like this. I'm attaching the output of lspci to describe the affected hardware. The affected network interface is a Intel PRO/100 using the e100 driver.
same problem here with e100 since 184.108.40.206-43.fc11.x86_64, everything fine with 2.6.29.* and below (at least since Fedora 9). I did not try rsync, a "wget some.host/bigfile" is enough. An ifdown/ifup-cycle reanimates the interface.
lspci -vv output:
02:00.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 0c)
Subsystem: Intel Corporation EtherExpress PRO/100 S Server Adapter
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64 (2000ns min, 14000ns max), Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at fe7df000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at dcc0 [size=64]
Region 2: Memory at fe7e0000 (32-bit, non-prefetchable) [size=128K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=2 PME-
Kernel driver in use: e100
Kernel modules: e100
I'm about to go back to kernel-220.127.116.11-217.2.16.fc11.x86_64 for the time being... but I'll try kernel-18.104.22.168-53.fc11 if I'll get around to it (though there's nothing mentioned in the changelog about it).
22.214.171.124 has an e100 patch but it's hard to tell if it fixes this. Do your kernel boot messages contain this line?:
PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
(In reply to comment #2)
> 126.96.36.199 has an e100 patch but it's hard to tell if it fixes this. Do your
> kernel boot messages contain this line?:
> PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
It does indeed.
You mean this in changelog?
Author: Krzysztof Hałasa <firstname.lastname@example.org>
Date: Sun Aug 23 19:02:13 2009 -0700
E100: fix interaction with swiotlb on X86.
This patch, while not yet making the driver conform to the PCI DMA API,
allows it to work correctly on X86 with swiotlb (while not breaking
My system is running x86_64, so I wonder if that would help...
But reading e.g. this thread, it could: http://email@example.com/msg06246.html
I even thought about trying kernel-2.6.31-40.fc12 (hoping that it's installible on my FC11 system and won't break anything else)...
I also wonder, why my system needs SWIOTLB at all. Seems that my Pentium E2160 has no IOMMU...
Looks like that is the fix. And SWIOTLB is used when there is no iommu...
(In reply to comment #4)
I see on koji you build kernel-188.8.131.52-64.fc11. Runs fine here and fixes the problem. Thanks!