On Wed, 2011-08-10 at 16:45 +0200, Karsten Malcher wrote:
> Hello,
>
> because this bug seems to have some deep problems i contacted the support of Realtek.
> In the time between i got help from Mr. Cheng from Realtek.
> The problem is not solved up to now, but i will post what we have found out so far:
>
>
> RTL8169 series are PCI Gigabit Ethernet Controller.
> The r8168 driver is for PCI-E products, not PCI products!
Right.
> One assumption was that there is a problem with the CPU power saving.
> So I disabled cool'n quiet in the BIOS and obviously it makes an effect!
>
> I could perform ping to my router without packet loss, but contact to the
> IMAP-Server fails.
> This seems to be the right way to come closer to the problem.
> The question is why the frequency stepping of the cpu has effect to the ethernet
> problem?
Each AMD64 CPU also includes a memory controller. If the memory
controller enters a power saving state it may delay transferring packets
to memory and could cause packets to be lost. I don't know whether that
is a likely problem with this specific combination of chips. Also it
should not be a problem unless you have quite high packet rates.
> All my tests where made with the newest driver version 6.015.00 for RTL8169.
>
> Another problem is that Mr. Cheng requested the driver informations:
>
> root@PC# ethtool -i eth2
> driver: r8169
> version: 2.3LK-NAPI
> firmware-version:
> bus-info: 0000:02:07.0
>
> Mr. Cheng writes to me that it is the inbox driver version, not the realtek driver
> version.
> Can anybody say what the "inbox driver" is?
Microsoft calls the drivers they distribute with Windows 'inbox'. So I
suppose he means it is the driver included with Linux (we usually call
this 'in-tree').
> lsmod shows to me that the r8169 driver is loaded - so i can't understand this?
It is an in-tree version of r8169 and not a version provided directly by
Realtek.
> I will made some further tests now with cool'n quiet disabled.
> Some ideas how i can debug the problem in detail would be helpful.
Maybe you could use tcpdump to record the packets on both ends of the
network connection? Since you say that the IMAP connection fails, you
should be able to record the packets in that connection by running:
tcpdump -i eth0 -w imap.pcap port 143
This creates a file 'imap.pcap'. If you run that on both the client and
the server (and rename one of the files) then we may be able to compare
those files and that may point to what specific traffic the driver or
hardware has a problem with. The Realtek support people may find this
useful as well.
Before sending a packet capture file, please check that you did not
include your IMAP password! By default tcpdump only records the first
part of each packet, so this probably won't happen, but do check.
Ben.
Attachment:
signature.asc
Description: This is a digitally signed message part