[SOLVED] Slackware64-14.2 gets confused when I plug in a second Ethernet card
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Slackware64-14.2 gets confused when I plug in a second Ethernet card
I have installed Slackware64-14.2 on a computer with network card integrated
into the motherboard. After that /etc/udev/rules.d/70.persistent-net.rules
looked like this:
Notice that both eth0 and eth125 (I have no idea why was it named eth125) have
the same MAC address - the one that appeared in dmesg above twice for both
eth0 and eth1.
I am also attaching the relevant snippet from the output of lspci -vvv:
Note: The Device Serial Number for both items is grayed out again, but it's
the same.
When I boot another OS, both network cards are detected fine and work. I have
also used it to find the MAC address of the second network card. Let it be
yy:yy:yy:yy:yy:yy
I have tried to modify /etc/udev/rules.d/70.persistent-net.rules and enforce
it. After my change, the file looks like this:
The network rules are created by eudev, which in turn takes its cues from the kernel. In this case, it seems like the kernel is reporting the same NIC twice, which looks very much like an issue with the RealTek driver.
Which kernel are you running? Could you post the full output from dmesg?
Try booting from a live CD image, like System Rescue CD, and see if the issue persists.
Your /etc/udev/rules.d/70.persistent-net.rules looks OK and it should work (enforce) but your current (kernel version ??? - run uname -a ) r8169 driver (which is known to be buggy) is creating two interfaces. This might work well with only the r8169 card but udevd gets confused when the second card is inserted and tries to allocate a name for it.
I'd suggest to delete the /etc/udev/rules.d/70.persistent-net.rules (backup it somewhere), reboot, check if r8169 is still eth0 and what the TG-3468 got named to, and follow the referenced link and the two utilities from within the last post and rename the interfaces manually at the very beginning of the /etc/rc.d/rc.inet1 script: https://www.linuxquestions.org/quest...9/#post5776770
Regarding the renaming of eth125 (which, without having the complete dmesg output, I guess it's the TG-3468 card - as it looks to remain eth125 from your ifconfig output) into the existing eth0 (already assigned to the r8169) by udedv:
Quote:
udevd[695]: Error changing net interface name eth125 to eth0: File exists
The generic 4.4.14 kernel. It's a fresh Slackware64-14.2 install, I did not apply any updates from patches/ yet. I know I must, but I thought maybe I can settle this NIC issue first, so I won't go back. If none of the suggestions in this thread will work, I will update and try them again, to see if the newer kernel fixes it.
Quote:
Originally Posted by Ser Olmy
Could you post the full output from dmesg?
It is too big to fit into a forum post. I have cut the header and start where I've noticed the network related message. MAC address at line 3 and 7 is grayed, but it's the same for both eth0 and eth1. But I have also posted the full dmesg output here https://dpaste.de/yPDt
Code:
[ 76.592500] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[ 76.592511] r8169 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control
[ 76.593039] r8169 0000:03:00.0 eth0: RTL8168c/8111c at 0xffffc900003fe000, xx:xx:xx:xx:xx:xx, XID 1c4000c0 IRQ 30
[ 76.593047] r8169 0000:03:00.0 eth0: jumbo features [frames: 6128 bytes, tx checksumming: ko]
[ 76.593062] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[ 76.593068] r8169 0000:04:00.0: can't disable ASPM; OS doesn't have ASPM control
[ 76.593568] r8169 0000:04:00.0 eth1: RTL8168e/8111e at 0xffffc90001aac000, xx:xx:xx:xx:xx:xx, XID 0c200000 IRQ 31
[ 76.593576] r8169 0000:04:00.0 eth1: jumbo features [frames: 9200 bytes, tx checksumming: ko]
[ 76.629455] nouveau 0000:01:00.0: bios: version 70.08.ad.00.00
[ 76.629926] nouveau 0000:01:00.0: fb: 2048 MiB DDR3
[ 77.291198] [TTM] Zone kernel: Available graphics memory: 8175316 kiB
[ 77.291203] [TTM] Zone dma32: Available graphics memory: 2097152 kiB
[ 77.291205] [TTM] Initializing pool allocator
[ 77.291209] [TTM] Initializing DMA pool allocator
[ 77.291218] nouveau 0000:01:00.0: DRM: VRAM: 2048 MiB
[ 77.291221] nouveau 0000:01:00.0: DRM: GART: 1048576 MiB
[ 77.291224] nouveau 0000:01:00.0: DRM: TMDS table version 2.0
[ 77.291227] nouveau 0000:01:00.0: DRM: DCB version 4.0
[ 77.291229] nouveau 0000:01:00.0: DRM: DCB outp 00: 01800302 00020030
[ 77.291232] nouveau 0000:01:00.0: DRM: DCB outp 01: 02000300 00000000
[ 77.291234] nouveau 0000:01:00.0: DRM: DCB outp 02: 08011312 00020030
[ 77.291237] nouveau 0000:01:00.0: DRM: DCB outp 03: 04011310 00000000
[ 77.291239] nouveau 0000:01:00.0: DRM: DCB outp 04: 02022362 00020010
[ 77.291241] nouveau 0000:01:00.0: DRM: DCB conn 00: 00001030
[ 77.291243] nouveau 0000:01:00.0: DRM: DCB conn 01: 00002130
[ 77.291245] nouveau 0000:01:00.0: DRM: DCB conn 02: 00010261
[ 77.304658] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 77.304663] [drm] Driver supports precise vblank timestamp query.
[ 77.314892] intel_rapl: Found RAPL domain package
[ 77.314897] intel_rapl: Found RAPL domain core
[ 77.314902] intel_rapl: Found RAPL domain dram
[ 77.360095] nouveau 0000:01:00.0: DRM: MM: using COPY0 for buffer copies
[ 77.470404] nouveau 0000:01:00.0: DRM: allocated 1024x768 fb: 0x60000, bo ffff88007e1f7800
[ 77.470444] fbcon: nouveaufb (fb0) is primary device
[ 77.587469] Console: switching to colour frame buffer device 128x48
[ 77.587853] nouveau 0000:01:00.0: fb0: nouveaufb frame buffer device
[ 77.595870] [drm] Initialized nouveau 1.3.1 20120801 for 0000:01:00.0 on minor 0
[ 78.259503] i2c /dev entries driver
[ 78.418462] r8169 0000:04:00.0 eth125: renamed from eth1
[ 78.433729] input: SIGMACHIP Usb Mouse as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5:1.0/0003:1C4F:0034.0001/input/input12
[ 78.433833] hid-generic 0003:1C4F:0034.0001: input,hidraw0: USB HID v1.10 Mouse [SIGMACHIP Usb Mouse] on usb-0000:00:14.0-5/input0
[ 108.650929] usb 1-5: USB disconnect, device number 2
[ 108.949364] usb 1-5: new low-speed USB device number 3 using xhci_hcd
[ 109.117946] usb 1-5: New USB device found, idVendor=1c4f, idProduct=0034
[ 109.117958] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 109.117966] usb 1-5: Product: Usb Mouse
[ 109.117972] usb 1-5: Manufacturer: SIGMACHIP
[ 109.118086] usb 1-5: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes
[ 109.120715] input: SIGMACHIP Usb Mouse as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5:1.0/0003:1C4F:0034.0002/input/input13
[ 109.120968] hid-generic 0003:1C4F:0034.0002: input,hidraw0: USB HID v1.10 Mouse [SIGMACHIP Usb Mouse] on usb-0000:00:14.0-5/input0
[ 168.616826] udevd[695]: Error changing net interface name eth125 to eth0: File exists
[ 168.982562] Adding 16777212k swap on /dev/mapper/cryptswap. Priority:-1 extents:1 across:16777212k
[ 169.046940] fuse init (API version 7.23)
[ 170.010731] EXT4-fs (dm-0): re-mounted. Opts: (null)
[ 173.335591] EXT4-fs (sdb3): mounted filesystem with ordered data mode. Opts: (null)
[ 173.443142] FAT-fs (sda2): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[ 176.666507] cfg80211: World regulatory domain updated:
[ 176.666509] cfg80211: DFS Master region: unset
[ 176.666510] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[ 176.666511] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[ 176.666512] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz, 92000 KHz AUTO), (N/A, 2000 mBm), (N/A)
[ 176.666513] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A)
[ 176.666514] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A)
[ 176.666515] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s)
[ 176.666516] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
[ 176.666516] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
[ 176.666517] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
[ 176.774296] r8169 0000:03:00.0 eth0: link down
[ 178.764352] r8169 0000:03:00.0 eth0: link up
[ 183.242677] NET: Registered protocol family 10
Quote:
Originally Posted by Ser Olmy
Try booting from a live CD image, like System Rescue CD, and see if the issue persists.
I have just downloaded SystemRescueCd-x86-5.1.2, made a bootable flash drive and booted from it. The problem persists. I'm getting two different network interfaces (albeit named slightly differently), but in the output of ifconfig -a both have the same MAC address. It matches with the MAC address from dmesg, so it's the same NIC - the integrated one.
4.4.14 but I will update to 4.4.88 if I don't manage to get this networking issue fixed first
Quote:
Originally Posted by abga
I'd suggest to delete the /etc/udev/rules.d/70.persistent-net.rules (backup it somewhere), reboot, check if r8169 is still eth0 and what the TG-3468 got named to
I deleted /etc/udev/rules.d/70.persistent-net.rules, rebooted, network cards got named eth0 and eth1 without that big delay, but:
1. ifconfig -a shows that both eth0 and eth1 still have the same MAC address - the integrated NIC
2. after one more reboot the whole problem is back: I get that giant delay again and interfaces named eth0 and eth126 (not eth125 like last time)
Quote:
Originally Posted by abga
follow the referenced link and the two utilities from within the last post and rename the interfaces manually at the very beginning of the /etc/rc.d/rc.inet1 script: https://www.linuxquestions.org/quest...9/#post5776770
Before I get to read the manpages for ifrename and nameif, and try playing with these tools, I have the following questions:
1. As I understand the kernel / udev voodoo happens before rc.inet1, how will my attempt to rename the interfaces get rid of the ugly delay at boot? I certainly don't want to wait for so long during each system boot. Of course I could stick a 'rm /etc/udev/rules.d/70.persistent-net.rules' into the shutdown script so the system always starts with that file missing, but then I'll get different names and will have to look for the correct interface name to rename.
2. I am confused that the MAC address of the second NIC (the TP-LINK one, which I know), doesn't appear anywhere in dmesg. Will attempts to map an interface name by that MAC address using the ifrename/nameif tools work if they didn't work via /etc/udev/rules.d/70.persistent-net.rules?
Considering the kernel is what provides the module for the network cards, the first thing I would do is update to the latest kernel (at least 4.4.88 provided by Slackware, but you could also go to the latest from kernel.org, which is 4.4.100 -- you can either compile it yourself or use 55020's "dusk" kernel packages) to see if the issue has been fixed. You could also try the driver directly from Realtek. I know others have had success with that.
Sorry, I was not aware that the "Linux Friendly" TP-LINK TG-3468 is driven by the same Realtek chip - r8169 and the afferent buggy driver. This explains everything now, especially why and how (same MAC) udev is getting confused. It's a pure driver issue.
Try this workaround - basically you need to tell udev with the help of KERNELS== parameter which card is which in /etc/udev/rules.d/70.persistent-net.rules, do respect the effective MAC addresses corresponding to the cards (pci addresses) listed with lspci: https://ubuntuforums.org/showthread....0#post12093090
On your questions:
1. udev is launched before /etc/rc.d/rc.inet1, you'll find it in /etc/rc.d/rc.S and then again (checked) in /etc/rc.d/rc.M just before /etc/rc.d/rc.inet1
The header of /etc/rc.d/rc.inet1 is an easy and safe (dirty too) place to fine tune/modify your adapters before configuring their addresses.
2. Forget those utilities, you have a driver issue that should be fixed in the kernel / udev zone
Note to myself: it looks like the r8169 driver is haunting me these days, every time I try to help on a system/networking issue the r8169 thing is popping up and telling me to avoid such "Linux Friendly" cards
I did nothing else than doing a full install, the integrated NIC just worked.
Quote:
Originally Posted by abga
Try this workaround - basically you need to tell udev with the help of KERNELS== parameter which card is which in /etc/udev/rules.d/70.persistent-net.rules, do respect the effective MAC addresses corresponding to the cards (pci addresses) listed with lspci: https://ubuntuforums.org/showthread....0#post12093090
Adding this additional data (copypasted from the suggested link, so the MAC addresses are from that example):
only fixes the delay at boot. I'm still getting an eth0 interface and an eth100something interface.
I went one step further and edited /etc/udev/rules.d/70.persistent-net.rules one more time, removing the hardcoded MAC addresses, so it rather looked like this:
One more reboot and this time I get the correct interface names: eth0, eth1.
But the main problem persists: in output of dmesg kernel still reports the same MAC address (the one of the integrated NIC) for both eth0 and eth1.
It looks like it's indeed a kernel/driver issue rather than an udev one, that's why I will attempt a system update later today, which will also upgrade the kernel from 4.4.14 to 4.4.88, and then will report the results here.
Just upgraded the system, problem persists. Kernel 4.4.88 behaves exactly like 4.4.14.
For now I am hesitating to try 4.4.100 as well, because it's unofficial and I'm trying to stay with stock Slackware kernel.
I have also tried to download the r8168 driver from Realtek, as suggested above, but build fails:
Code:
# ls
0010-r8168-8.045.08.tar.bz2
Unpack and get into that directory:
Code:
# ./autorun.sh
Check old driver and unload it.
Build the module and install
arch/x86/Makefile:148: CONFIG_X86_X32 enabled but no binutils support
Makefile:679: Cannot use CONFIG_CC_STACKPROTECTOR_REGULAR: -fstack-protector not supported by compiler
make[2]: *** No rule to make target 'driver/r8168-8.045.08/src'. Stop.
make[1]: *** [clean] Error 2
make: *** [clean] Error 2
There's a slackbuild for this realtek driver which builds fine on 14.2.
--
SeB
For some reason, it never crossed my mind to look on SBo, since in my mind queue getting sbopkg was a few steps away.
I have used the buildscript from SBo and after another reboot everything magically works. So this was indeed a kernel driver issue. Thanks to everyone who helped. Marking the thread as solved.
Last edited by FlinchX; 11-23-2017 at 03:33 AM.
Reason: typo
Happy to hear that you got it finally working! Good to have all this effort documented on this thread.
I was reluctant to advise you to use r8168 driver, because I remember reading somewhere (some very old threads - years ago) that the r8168 driver, while originally provided by Realtek, is not maintained anymore and was incorporated in the new r8169 that is actively maintained by the kernel folks. I'm wondering if you have full Gigabit and Auto-negotiation capabilities with the old r8168 driver you are using now - you can check with:
Adding this additional data (copypasted from the suggested link, so the MAC addresses are from that example):
In my instructions I've specifically used the word effective MAC addresses just fearing that not all drivers would support MAC cloning. I should have used the word real instead, maybe transcribing the instructions from that Ubunutu thread myself would have been a better option, I was just trying to be efficient by only pointing you to that. Worth trying again with the r8169 driver and real MAC addresses.
Should you have a little time, you could provide some feedback to the r8169 driver developers, they surely need it, in order to get this driver fixed in the future kernel releases. It'll help you, the Linux community and nobody will call the otherwise perfect Slackware distro confused again
Last edited by abga; 11-23-2017 at 10:10 AM.
Reason: typo
ethtool reports that Auto-negociation is enabled and Speed is 1000Mbps for both cards.
Quote:
Originally Posted by abga
In my instructions I've specifically used the word effective MAC addresses just fearing that not all drivers would support MAC cloning. I should have used the word real instead, maybe transcribing the instructions from that Ubunutu thread myself would have been a better option, I was just trying to be efficient by only pointing you to that. Worth trying again with the r8169 driver and real MAC addresses.
To avoid any confusion: I have said "I copypasted from the suggested link, so the MAC addresses are from that example" in context of my forum post, to cloak the real MAC addresses of my NICs (Big Brother paranoia, though I won't be surprised if that info slipped somewhere in the huge logs that I've posted). On the real computer, I have used the real MAC addresses of both cards, I did not try to enforce a MAC address change anywhere.
Quote:
Originally Posted by abga
Should you have a little time, you could provide some feedback to the r8169 driver developers, they surely need it, in order to get this driver fixed in the future kernel releases.
Frankly, I have no idea how would I do that, where would I go and what exactly would I say. I only know that kernel devs use mailing lists (I have always had a aversion for email mixed with a phobia for mailing lists) for communication, I randomly read that they are sometimes very harsh on others (usually not personally, but during debates on technical details). I am just a random Internet guy who doesn't even speak English natively (luckily, it was enough to ask for help in this forum and understand the suggestions), so if everything I need worked perfectly right after the Slackware install (I've had such experiences with older versions of Slackware and older hardware from pre-UEFI era), I would just keep staying low-profile under my virtual rock and never come out to cry for help
Quote:
Originally Posted by abga
nobody will call the otherwise perfect Slackware distro confused again
Now that you said that, perhaps I wasn't very careful with my choice of wording (see above about my English skill level). Let me take those words back then and say that I was the confused one
I was reluctant to advise you to use r8168 driver, because I remember reading somewhere (some very old threads - years ago) that the r8168 driver, while originally provided by Realtek, is not maintained anymore and was incorporated in the new r8169 that is actively maintained by the kernel folks.
Realtek seems to be updating their driver. The last update is Sep 2017. Looking at the git log for the SlackBuild, it shows that since it was added to the repo back in Jan 2016, there's been 5 updates.
But I do agree it would be nice to get this information to the kernel developers. It'd be interesting to see if it is fixed in kernels newer than the 4.4 series. They're up to the 4.14 and it's very possible that it was fixed in one of the subsequent kernels and just never backported.
Last edited by bassmadrigal; 11-23-2017 at 12:51 PM.
Reason: Meant to include the link on the first post and forgot
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.