Description of problem: PCI devices with the ID 10ec:8167 (variants of the Realtek 8169/8110) are currently not recognized by the r8169 driver. Putting the above id in /sys/pci/drivers/r8169/new_id makes the driver claim the devices just fine. Version-Release number of selected component (if applicable): kernel-2.6.18-1.2798.fc6 How reproducible: Always Steps to Reproduce: 1. Boot fedora on board with a Realtek chip having the above ID 2. 3. Actual results: r8169 is not loaded, device not claimed Expected results: r8169 claims the device Additional info:
Created attachment 139611 [details] rt8169-add-pciid.patch Seems like this would be the reasonable patch for this. It doesn't appear in the netdev-2.6 tree, so I'll check with Francois.
The patch has been merged between 2.6.18 and 2.6.19-rc1. -- Ueimor
Ok, thanks. I didn't see it in netdev-2.6 at first, but now I realize how I missed it.
Created attachment 139618 [details] rt8169-add-pciid-better.patch This patch is probably better since it actually accounts for some PCI region differences for the newer hardware.
Created attachment 139620 [details] PHY reset at startup If the IDs for the 8168 are added, the patch above may be useful as it fixes an issue of incorrect link negociation that I have been reported. -- Ueimor
Thanks! I'll include that if we take the larger patch. How necessary are the RTL_CFG_X parameters for proper functionality? It seems they would be required for everything to work well, but when someone reported they worked without I began to question their value. I ask because we would probably prefer the patch that only adds additional PCI ID's rather than the larger one that has more changes.
The RTL_CFG_X are needed for the 0x8136 and the 0x8168 which both use a different PCI BAR and require an extra alignement (8 bytes instead of 2). Imho the 8168 user base has grown significantly during the last months. -- Ueimor
This is resolved in 2.6.19, so when the fedora kernels move to 2.6.19 you will get this for free. Are you able to workaround this with some trickery in some of your initialization scripts so the module loads when the box boots?
I can work around this by piping the id into sysfs, yes.
I would suggest keeping that workaround in place until FC6 moves to 2.6.19. We generally don't add patches for new hardware support to Fedora kernels if the support will appear in an upcoming upstream kernel that will get absorbed into FC when it is released. I will probably try and put together an FC6 test kernel and will post to this BZ if/when one is ready.
Well, the MAC address change support in current 2.6.19-rc proved to be fatal for some users anyway :o/ -- Ueimor
This should be resolved with the 2.6.19 kernel. Please re-open this BZ if you continue to have problems on a 2.6.19-based fedora kernel.