Regarding WOL, scratched that one out, apparently there is no way to disable WOL in BIOS, ErP support option is disabled but there is no Wake On LAN option there even though manual suggest there is, quote:

ErP Support
Determines whether to let the system consume less than 1W power in S5 (shutdown) state. (Default:
Disabled)
Note: When this item is set to Enabled, the following four functions will become unavailable:
PME event wake up, power on by mouse, power on by keyboard, and wake on LAN.

So this could be related to WOL, is there any option to reset the NIC completely with a kernel parameter or passing some option to the module ?

Another update, newer drivers for Windows from Realtek is the cause of all of this. When I do a power cycle, boot into Linux and subsequently rebooting to Linux - there are no dropped packets, connection is just fine. 

I havent had these problems before so I thought that this was a regression, but it looks like that the Windows driver update made the connection unusable upon reboot. I've tried everything from turning off power management to switching WOL related settings on/off but upon reboot I get no connection at all or unstable connection in Linux (depending on the settings in Windows).

The "unknown MAC, using family default" line tells that you are using a yet
unknown (8168) chipset. The driver's default choice may work... or not.

Some support for the 8168e was added during the 2.6.29 cycle. I'd suggest
trying the last -rc, especially as it includes changes to avoid any 60s
freeze when trying to load the (optional) 8168e firmware. If things do not
improve and you see no ethical issue with non-GPL firmware, the 8168e firmware
is available at :

http://git.kernel.org/?p=linux/kernel/git/romieu/linux-firmware.git

(the firmware patches the PHY)

Your XID surprizes me. If the 2.6.39-rc driver does not detect your chipset
as a 8168e/8111e, please search the lines below in the driver and remove
the "& 0x9cf0f88f" part. 

        netif_info(tp, probe, dev, "%s at 0x%lx, %pM, XID %08x IRQ %d\n",
                   rtl_chip_info[chipset].name, dev->base_addr, dev->dev_addr,
                   (u32)(RTL_R32(TxConfig) & 0x9cf0f8ff), dev->irq);

Rationale: it will not work better but it will tell the needed bits for
future identification. :o)

Thanks.

-- 
Ueimor

(talking to myself)

The firmware part is right, especially the 60s delay related part, but the
8168e bits are not 2.6.29-rc material. They are in davem's net-next tree
and they won't go into the kernel before 2.6.29.

-- 
Ueimor

I've tried with 2.6.39-rc5 already (without success), but will give it a shot with current mainline, I see that your patch entered mainline after rc5 (commit 953a12cc2889d1be92e80a2d0bab5ffef4942300). Thanx for the guidelines, I'll try with firmware from your tree and modifying the driver - and will report back soon.

I've tripped out about that commit, it hasn't landed to mainline yet.

Ok, I've tried with rc6, no dice. I've copied r8169.c from davem's next to mainline (had to because rc6 doesn't recognize firmware for r8168e yet, missing

#define FIRMWARE_8168E_1        "rtl_nic/rtl8168e-1.fw"
#define FIRMWARE_8168E_2        "rtl_nic/rtl8168e-2.fw"

in r8169.c.

I've tried with and without firmware loaded (although there isn't any verification in dmesg that firmware has or hasn't been loaded), tried with vanilla mainline and with r8169.c in davem's next branch and I still have connection problems with dropped packets.

I removed the part of the netif_info function as instructed and I get a different XID:

[    7.722953] r8169 0000:03:00.0: eth0: RTL8168b/8111b at 0xffffc9000553a000, 1c:6f:65:ca:88:87, XID 2f900d00 IRQ 48

I've compiled r8168 from realtek site (ver. 8.023) and it looks like I have RTL8111F ???

[17409.784303] r8168 Gigabit Ethernet driver 8.023.00-NAPI loaded
[17409.784337] r8168 0000:03:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[17409.784377] r8168 0000:03:00.0: setting latency timer to 64
[17409.785428] r8168 0000:03:00.0: irq 43 for MSI/MSI-X
[17409.785763] eth%d: RTL8168B/8111B at 0xffffc9001951a000, 1c:6f:65:ca:88:87, IRQ 43
[17409.966414] r8168: This product is covered by one or more of the following patents: US5,307,459, US5,434,872, US5,732,094, US6,570,884, US6,115,776, and US6,327,625.
[17409.966417] eth0: Identified chip type is 'RTL8168F/8111F'.
[17409.966418] r8168  Copyright (C) 2011  Realtek NIC software team <nicfae@realtek.com> 

There is no mention on Realtek web page about this chip...

Oh, I forgot, I've compiled kernel from davem's branch again (few commits that entered 6 days ago looked promising) but ethtool reported that firmware isn't loaded (N/A) even though I've copied it to /lib/firmware/rtl_nic/, wich make sense now - we don't have propper identifiers for this chip and for a reason. Is there any chance that we can get some info from Realtek about this NIC anytime soon ? Drivers from their website work propperly, but since they are listed as maintainers for 8169 - I hope that they will cooperate with you on this.

Thanx again Francois for your help.

Hm, I've just compiled r8168-8.024.00 and now the driver identifies NIC as:

eth0: Identified chip type is 'RTL8168E-VL/8111E-VL'

I just bought a new board (Asus M5A78L) with what appears to be the same NIC.
The symptoms are the same as the one reported by Ivan and the driver found on realtek site also identified the card as "RTL8168E-VL/8111E-VL".
I'm currently testing 3.0-rc4, and noticed that the driver in mainline (r8169) starts working after loading and unloading the r8168 driver from realtek.
I'm of course available for further analysis and testing on the NIC.

Those latest patches from Hayes Wang in davem.next.r8169 fixes the problem completele, probably due to

commit 04586b0fc2079f047521b26d7129c6dd2610c291

r8169: support RTL8111E-VL.

Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Acked-by: Francois Romieu <romieu@fr.zoreil.com>


ethtool -i eth0
driver: r8169
version: 2.3LK-NAPI
firmware-version: rtl_nic/rtl8168e-3.fw
bus-info: 0000:03:00.0


dmesg | grep r8169
[   17.832351] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[   17.833785] r8169 0000:03:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[   17.835085] r8169 0000:03:00.0: setting latency timer to 64
[   17.835181] r8169 0000:03:00.0: irq 43 for MSI/MSI-X
[   17.836525] r8169 0000:03:00.0: eth0: RTL8168evl/8111evl at 0xffffc90005b9a000, 1c:6f:65:ca:88:87, XID 0c900800 IRQ 43
[   20.944148] r8169 0000:03:00.0: eth0: link down
[   24.517060] r8169 0000:03:00.0: eth0: link up

Patches tested against 3.0.0-rc7, no connection problems at all. Hope this gets merged in mainline soon, it would be nice to see it in time for 3.1.0 :)

Thanks Francois, Hayes...

(In reply to comment #11)
[...]
> Patches tested against 3.0.0-rc7, no connection problems at all. Hope this
> gets
> merged in mainline soon, it would be nice to see it in time for 3.1.0 :)

It is scheduled so.

Hayes sent a fix for a 8169 regression which appeared in the series.
I'll test it and formally send the resulting series to davem for inclusion
today.

-- 
Ueimor