Most recent kernel where this bug did not occur: Distribution: Hardware Environment: RTL8111B/RTL8168B Software Environment: Boot linux PXE Problem Description: Hangs due to NIC eth0 down when 10/100 is used, times out Steps to reproduce: when using with 10/1000 it works with out any problem. r8169.c has pCI ID 10ec:8136 Realtek has provided r1000 alpha5 driver but its not a in kernel driver.
The descritpion is a bit terse. Let's rephrase: - the linux kernel is loaded via PXE - when connected to a gigabit switch, the boot proceeds without error - when connected to a different, fast 100 switch, the network adapter does not negotiate the link correctly and the boot process takes age Questions: - does the 8168 chipset stand on a removable PCI card or is it a LOM ? Brand name will be welcome, both for the adapter/motherboard and for the switches - is the kernel/the module given any extra parameter during boot ? - are you able to log-in if you wait long enough ? - if so, does it make a difference if you kick the adapter with mii-tool ? Extra data: - please send 'lspci -vvx'
Its not a removable PCI card. System does not boot at all. The NIC LED shuts off and message on screen says RPC error. The NIC vendor is REALTEK and its PCI ID 10ec:8136. pxe boot parameters used are as follows DEFAULT bzImage nfsroot=ia32 apm=off reboot=c,b console=tty3 IPAPPEND 1
Created attachment 9298 [details] r1000 driver provided by realtek please adopt the new parameters into r8169 driver or create another entry into drivers list with this driver. The chip is RTL8101E (PCI express)
Created attachment 9302 [details] Modify the cache line size PCI register
Realtek's driver adds no significant difference when compared to the previous version I have (read: nothing related to link management). I'll work something: the in-kernel driver does not take MII_LPA into account. It seems rather stupid. -- Ueimor
Created attachment 9305 [details] There are 3 pictures, see them in order to get the boot sequence and failure
See attached pictures. During pxe boot it finds the ip but link shuts down. so no further booting occurs. The LEDs on the NIC also turned OFF at this point. According to REALTEK r1000 driver works as a module(r1000.ko) in fedora 5.
The pictures are taken after I applied the patch "Modify the cache line size PCI register".
Good news, I have successfully booted both 10/100 and 10/1000 in test environment with the following steps. Steps to Success: 1) I have taken the r1000_v1.05Beta3-1 (as atatched)driver and only extracted r1000_n.c and r1000_ioctl.c files. 2) modified the /usr/src/linux-2.6.19-rc2-git3/drivers/net/Makefile in my kernel tree to compile these 2 c files instead of r8169.c. I assume that same could be done with rc-1 3) This compiled clean except for one warning as follows: drivers/net/r1000_n.c: In function 'r1000_open':drivers/net/r1000_n.c:757: warning: passing argument 2 of 'request_irq' from incompatible pointer type 4) Other than one warning, driver seems to be loading and booting using pxe and I can see the network. can we just starts using Realtek implmentation or separate the r8169 for non realtek Ids only, making them mutually exclusive.
> can we just starts using Realtek implmentation In your own kernel ? Sure. In mainline ? I don't hope so. > or separate the r8169 for non realtek Ids only, making them mutually exclusive. See answer above and bug #7243. -- Ueimor
Can you send the output of 'mii-tool -vv ethX' for your device with r1000 driver ? It would help to compare with different reports. Thanks in advance. -- Ueimor
When mii-tool -vv eth0 is executed it says the following msg SIOCGMIIPHY on 'eth0' failed: Operation not supported
bugme-daemon@bugzilla.kernel.org <bugme-daemon@bugzilla.kernel.org> : [...] > When mii-tool -vv eth0 is executed it says the following msg > > SIOCGMIIPHY on 'eth0' failed: Operation not supported Sh*t, I forgot that Realtek's r1000 does not support the MII ioctl (nor a lot of ethtool command either). Nevermind.
Can you try the new attached patch ?
Created attachment 9309 [details] Disable the pause capability
no improvement with the last patch "Disable the pause capability". system still locks because NIC is shutting itself. NO LED activity after messages say eth0: link down. we fail for rpc error.
Created attachment 9312 [details] Reset the PHY at boot time
Can you add the patch above on top of yesterday's one ? You should notice an extra infor or error message related to the eth device in the console. -- Ueimor
hurray, It worked, I can boot using 2.6.19-rc2+3rdpatch. System boot to NFS and I can see the network. Thanks If you need any logs let me know.
syed.azam@hp.com : [...] > If you need any logs let me know. lspci -vvx of the whole system + dmesg from boot + detailled dump of the registers through mii-tool would be welcome to keep a trace. -- Ueimor