LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 11-22-2017, 02:15 PM   #1
FlinchX
Member
 
Registered: Nov 2017
Distribution: Slackware Linux
Posts: 666

Rep: Reputation: Disabled
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:

Code:
# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="xx:xx:xx:xx:xx:xx", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
(I have grayed out the MAC address)

I have plugged in a second network card - a TP-LINK TG-3468. A couple of
searches show that it is Linux friendly. Then strange things start happening.

Snippet 1 from the output of dmesg:

Code:
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control
r8169 0000:03:00.0 eth0: RTL8168c/8111c at 0xffffc900003fe000, xx:xx:xx:xx:xx:xx, XID 1c4000c0 IRQ 30
r8169 0000:03:00.0 eth0: jumbo features [frames: 6128 bytes, tx checksumming: ko]
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 0000:04:00.0: can't disable ASPM; OS doesn't have ASPM control
r8169 0000:04:00.0 eth1: RTL8168e/8111e at 0xffffc90001aac000, xx:xx:xx:xx:xx:xx, XID 0c200000 IRQ 31
r8169 0000:04:00.0 eth1: jumbo features [frames: 9200 bytes, tx checksumming: ko]
Notice that it looks like there are two network cards (there are two indeed),
but their MAC address shows up the same.

Snippet 2 from the output of dmesg:

Code:
i2c /dev entries driver
Here the booting process stops for good seconds (20-30 at least). Right after
that the next line in the log is:

Code:
r8169 0000:04:00.0 eth125: renamed from eth1
and then the boot process continues.

A few lines below there's another network related message:

Snippet 3 from the output of dmesg:

Code:
udevd[695]: Error changing net interface name eth125 to eth0: File exists
After the boot process is completed and I log in, here is the output of
'ifconfig -a'

Code:
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.137.22  netmask 255.255.255.0  broadcast 192.168.137.255
        inet6 fe80::7285:c2ff:fe28:87ab  prefixlen 64  scopeid 0x20<link>
        ether xx:xx:xx:xx:xx:xx txqueuelen 1000  (Ethernet)
        RX packets 37  bytes 5092 (4.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 27  bytes 3583 (3.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth125: flags=4098<BROADCAST,MULTICAST>  mtu 1500
        ether xx:xx:xx:xx:xx:xx txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
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:

Code:
# lspci -vvv
Code:
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 02)
	Subsystem: ASRock Incorporation Motherboard (one of many)
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 30
	Region 0: I/O ports at d000 [size=256]
	Region 2: Memory at f3210000 (64-bit, prefetchable) [size=4K]
	Region 4: Memory at f3200000 (64-bit, prefetchable) [size=64K]
	Expansion ROM at f3220000 [disabled] [size=64K]
	Capabilities: [40] Power Management version 3
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [50] MSI: Enable+ Count=1/2 Maskable- 64bit+
		Address: 00000000fee0f00c  Data: 4172
	Capabilities: [70] Express (v1) Endpoint, MSI 01
		DevCap:	MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <8us
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 10.000W
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 4096 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <512ns, L1 <64us
			ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
	Capabilities: [b0] MSI-X: Enable- Count=2 Masked-
		Vector table: BAR=4 offset=00000000
		PBA: BAR=4 offset=00000800
	Capabilities: [d0] Vital Product Data
		Unknown small resource type 00, will not decode more.
	Capabilities: [100 v1] Advanced Error Reporting
		UESta:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
		UEMsk:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
		UESvrt:	DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
		CESta:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
		CEMsk:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
		AERCap:	First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
	Capabilities: [140 v1] Virtual Channel
		Caps:	LPEVC=0 RefClk=100ns PATEntryBits=1
		Arb:	Fixed- WRR32- WRR64- WRR128-
		Ctrl:	ArbSelect=Fixed
		Status:	InProgress-
		VC0:	Caps:	PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
			Arb:	Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
			Ctrl:	Enable+ ID=0 ArbSelect=Fixed TC/VC=01
			Status:	NegoPending- InProgress-
	Capabilities: [160 v1] Device Serial Number zz-zz-zz-zz-zz-zz-zz-zz
	Kernel driver in use: r8169
	Kernel modules: r8169

04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
	Subsystem: ASRock Incorporation Motherboard (one of many)
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 31
	Region 0: I/O ports at c000 [size=256]
	Region 2: Memory at f3104000 (64-bit, non-prefetchable) [size=4K]
	Region 4: Memory at f3100000 (64-bit, prefetchable) [size=16K]
	Capabilities: [40] Power Management version 3
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
		Address: 0000000000000000  Data: 0000
	Capabilities: [70] Express (v2) Endpoint, MSI 01
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 10.000W
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <512ns, L1 <64us
			ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- CommClk+
			ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR-, OBFF Not Supported
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
		LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
			 EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
	Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
		Vector table: BAR=4 offset=00000000
		PBA: BAR=4 offset=00000800
	Capabilities: [d0] Vital Product Data
		Unknown small resource type 05, will not decode more.
	Capabilities: [100 v1] Advanced Error Reporting
		UESta:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
		UEMsk:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
		UESvrt:	DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
		CESta:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
		CEMsk:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
		AERCap:	First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
	Capabilities: [140 v1] Virtual Channel
		Caps:	LPEVC=0 RefClk=100ns PATEntryBits=1
		Arb:	Fixed- WRR32- WRR64- WRR128-
		Ctrl:	ArbSelect=Fixed
		Status:	InProgress-
		VC0:	Caps:	PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
			Arb:	Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
			Ctrl:	Enable+ ID=0 ArbSelect=Fixed TC/VC=01
			Status:	NegoPending- InProgress-
	Capabilities: [160 v1] Device Serial Number zz-zz-zz-zz-zz-zz-zz-zz
	Kernel driver in use: r8169
	Kernel modules: r8169
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:

Code:
# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="xx:xx:xx:xx:xx:xx", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# external
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="yy:yy:yy:yy:yy:yy", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
But this did not change anything. After a reboot the problem persists.
 
Old 11-22-2017, 03:22 PM   #2
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 3,333

Rep: Reputation: Disabled
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.
 
3 members found this post helpful.
Old 11-22-2017, 04:05 PM   #3
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: McKinney, Texas
Distribution: Slackware64 15.0
Posts: 3,858

Rep: Reputation: 2225Reputation: 2225Reputation: 2225Reputation: 2225Reputation: 2225Reputation: 2225Reputation: 2225Reputation: 2225Reputation: 2225Reputation: 2225Reputation: 2225
While old, this may be of some use: https://www.linuxquestions.org/quest...debian-886789/
 
Old 11-22-2017, 04:18 PM   #4
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,634

Rep: Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929
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
this might give you some explanations:
https://github.com/systemd/systemd/issues/2657
 
1 members found this post helpful.
Old 11-22-2017, 06:14 PM   #5
FlinchX
Member
 
Registered: Nov 2017
Distribution: Slackware Linux
Posts: 666

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Ser Olmy View Post
Which kernel are you running?
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 View Post
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 View Post
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.
 
Old 11-22-2017, 07:00 PM   #6
FlinchX
Member
 
Registered: Nov 2017
Distribution: Slackware Linux
Posts: 666

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by abga View Post
(kernel version ??? - run uname -a )
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 View Post
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 View Post
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?
 
Old 11-22-2017, 08:45 PM   #7
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 8,792

Rep: Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656
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.
 
1 members found this post helpful.
Old 11-22-2017, 09:01 PM   #8
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,634

Rep: Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929
I'm wondering how did you get the first r8169 adapter working out-of-the-box in the first place, this fellow Slacker had issues with it:
https://www.linuxquestions.org/quest...on-4175616651/

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
 
1 members found this post helpful.
Old 11-23-2017, 01:11 AM   #9
FlinchX
Member
 
Registered: Nov 2017
Distribution: Slackware Linux
Posts: 666

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by abga View Post
I'm wondering how did you get the first r8169 adapter working out-of-the-box in the first place, this fellow Slacker had issues with it:
https://www.linuxquestions.org/quest...on-4175616651/
I did nothing else than doing a full install, the integrated NIC just worked.

Quote:
Originally Posted by abga View Post
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):

Code:
SUBSYSTEM=="net", [...] KERNELS=="0000:03:00.0", ATTR{address}=="00:25:90:02:c1:b0", [...] NAME="eth0"
SUBSYSTEM=="net", [...] KERNELS=="0000:04:00.0", ATTR{address}=="00:25:90:02:c1:b0", [...] NAME="eth1"
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:

Code:
SUBSYSTEM=="net", [...] KERNELS=="0000:03:00.0", [...] NAME="eth0"
SUBSYSTEM=="net", [...] KERNELS=="0000:04:00.0", [...] NAME="eth1"
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.
 
Old 11-23-2017, 03:00 AM   #10
FlinchX
Member
 
Registered: Nov 2017
Distribution: Slackware Linux
Posts: 666

Original Poster
Rep: Reputation: Disabled
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
This is on kernel 4.4.88 already.
 
Old 11-23-2017, 03:23 AM   #11
phenixia2003
Senior Member
 
Registered: May 2006
Location: France
Distribution: Slackware
Posts: 1,052

Rep: Reputation: 1008Reputation: 1008Reputation: 1008Reputation: 1008Reputation: 1008Reputation: 1008Reputation: 1008Reputation: 1008
Hello,

Quote:
Originally Posted by FlinchX View Post
I have also tried to download the r8168 driver from Realtek, as suggested above, but build fails:
There's a slackbuild for this realtek driver which builds fine on 14.2.

--
SeB

Last edited by phenixia2003; 11-23-2017 at 03:23 AM. Reason: typo
 
2 members found this post helpful.
Old 11-23-2017, 03:31 AM   #12
FlinchX
Member
 
Registered: Nov 2017
Distribution: Slackware Linux
Posts: 666

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by phenixia2003 View Post
Hello,



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
 
Old 11-23-2017, 10:08 AM   #13
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,634

Rep: Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929
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:
Code:
/usr/sbin/ethtool eth0 | grep -e Speed -e Auto-negotiation
/usr/sbin/ethtool eth1 | grep -e Speed -e Auto-negotiation
Quote:
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
 
Old 11-23-2017, 11:15 AM   #14
FlinchX
Member
 
Registered: Nov 2017
Distribution: Slackware Linux
Posts: 666

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by abga View Post
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:
Code:
/usr/sbin/ethtool eth0 | grep -e Speed -e Auto-negotiation
/usr/sbin/ethtool eth1 | grep -e Speed -e Auto-negotiation
ethtool reports that Auto-negociation is enabled and Speed is 1000Mbps for both cards.

Quote:
Originally Posted by abga View Post
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 View Post
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 View Post
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
 
Old 11-23-2017, 12:50 PM   #15
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 8,792

Rep: Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656
Quote:
Originally Posted by abga View Post
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
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
want your USB Ethernet dongle configured via dhcp as soon as you plug it in ? louigi600 Slackware 0 08-16-2014 06:45 AM
no /dev/sd** device appears when I plug in a card to the laptop's card reader nass Slackware 12 10-16-2010 03:53 PM
Confused about Nvidia in Slackware64 13 arubin Slackware 12 09-18-2009 11:57 AM
Two ethernet, confused on gateway setting johnevans77 Slackware 6 09-28-2007 03:01 AM
Ethernet card on laptop: I installed my D-Link ethernet card into Redhat 9, not detec brighamr Linux - Hardware 0 05-18-2004 12:33 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 09:31 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration