Red Hat Bugzilla – Bug 212542
r8169 driver misses device id
Last modified: 2014-06-29 18:57:55 EDT
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):
Steps to Reproduce:
1. Boot fedora on board with a Realtek chip having the above ID
r8169 is not loaded, device not claimed
r8169 claims the device
Created attachment 139611 [details]
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.
Ok, thanks. I didn't see it in netdev-2.6 at first, but now I realize how I
Created attachment 139618 [details]
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.
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.
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/
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.