2008-01-10 19:20:58

by Alistair John Strachan

[permalink] [raw]
Subject: Re: r8169 and out of space

Bugzilla for this report: http://bugzilla.kernel.org/show_bug.cgi?id=9468

On Thursday 10 January 2008 17:28:22 you wrote:
> I saw your thread on LKML about the problem with r8169. Did you ever
> find a patch or solution?

No, we have not diagnosed the cause of the problem, beyond the swiotlb usage.
I'm adding the r8169 maintainer, linux-net and linux-kernel to CC, to pass on
your information, I hope you don't mind.

> I have a Abit AB9 Pro motherboard with Intel P965 chipset, 4gb of
> memory, and two onboard r8169. The kernel is
> kernel-2.6.23.9-85.fc8.x86_64. I am using jumbo frames, the MTU set at
> 5924. The error is mentions 5946 bytes. 5946 - 5924 is 22. The same as
> your 7200 MTU subtracted from your bytes, 7222.
>
> I can set my MTU to 7200, and I can ping with 60000 byte packets just
> fine, but tcp connections hang unless I set the MTU to 5924 or lower.
> The other side is a Nvidia based board with a forcedeth driver that has
> in the past taken 9000 just fine.

--
Cheers,
Alistair.

137/1 Warrender Park Road, Edinburgh, UK.


2008-01-10 21:10:27

by Francois Romieu

[permalink] [raw]
Subject: Re: r8169 and out of space

Alistair John Strachan <[email protected]> :
[..]
> No, we have not diagnosed the cause of the problem, beyond the swiotlb usage.
> I'm adding the r8169 maintainer, linux-net and linux-kernel to CC, to pass on
> your information, I hope you don't mind.

swiotlb fragmentation perhaps ?

Switching the driver to be page based on Rx would help then.

[...]
> > I have a Abit AB9 Pro motherboard with Intel P965 chipset, 4gb of
> > memory, and two onboard r8169.

Which r8169 model exactly ?

--
Ueimor

2008-01-10 21:49:24

by Nathan Grennan

[permalink] [raw]
Subject: Re: r8169 and out of space

Francois Romieu wrote:
> Alistair John Strachan <[email protected]> :
> [..]
>
>> No, we have not diagnosed the cause of the problem, beyond the swiotlb usage.
>> I'm adding the r8169 maintainer, linux-net and linux-kernel to CC, to pass on
>> your information, I hope you don't mind.
>>
>
> swiotlb fragmentation perhaps ?
>
> Switching the driver to be page based on Rx would help then.
>
> [...]
>
>>> I have a Abit AB9 Pro motherboard with Intel P965 chipset, 4gb of
>>> memory, and two onboard r8169.
>>>
>
> Which r8169 model exactly ?
>
>
Here is some of the output from lspci -vv.

03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
Subsystem: ABIT Computer Corp. Unknown device 240b
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
Subsystem: ABIT Computer Corp. Unknown device 240b


I think I fixed the the 5924 vs 7200 issue by upgrading to
kernel-2.6.23.13-104.fc8.x86_64.

2008-01-11 04:54:27

by Nathan Grennan

[permalink] [raw]
Subject: Re: r8169 and out of space

Francois Romieu wrote:
> Alistair John Strachan <[email protected]> :
> [..]
>
>> No, we have not diagnosed the cause of the problem, beyond the swiotlb usage.
>> I'm adding the r8169 maintainer, linux-net and linux-kernel to CC, to pass on
>> your information, I hope you don't mind.
>>
>
> swiotlb fragmentation perhaps ?
>
> Switching the driver to be page based on Rx would help then.
>
> [...]
>
>>> I have a Abit AB9 Pro motherboard with Intel P965 chipset, 4gb of
>>> memory, and two onboard r8169.
>>>
>
> Which r8169 model exactly ?
>
>
I seem to have been wrong about the kernel update fixing my mtu issue.
I am not 100% sure, but I think 7200 works if the forcedeth system is
sending, but not if the r8169 system is sending.

I tried a mtu of 3000, and basically the same errors, but I did
noticed something interesting. Note the three different byte sizes.

DMA: Out of SW-IOMMU space for 2410 bytes at device 0000:03:00.0
DMA: Out of SW-IOMMU space for 3014 bytes at device 0000:03:00.0
DMA: Out of SW-IOMMU space for 3014 bytes at device 0000:03:00.0
DMA: Out of SW-IOMMU space for 3022 bytes at device 0000:03:00.0


On a side note, leaving the mtu at 1500 seems to work without error,
and I get about the same performance.