[etherlab-dev] ec_r8169 clears MAC address when unloading on kernel 3.14

[Sebastien Blanchet]

Hi,

When stopping ethercat on a Linux 3.14 kernel while using the ec_r8169,
the MAC address of the Realtek Ethernet Controller is cleared. It becomes 
00:00:00:00:00:00.

The card can still be used, but you have to specify the new null MAC address 
when loading ec_master the next time. The only way to restore the original MAC 
address is to power off the computer.

After many tests, I have discovered that:
- this bug does not happen on 3.4 kernel
- this bug does not happen with ec_e1000e
- this bug does not happen with ec_generic + r8169

- this bug happens on i386 and x86_64 architectures with a 3.14 kernel
- this bug happens on any computer I have (Beckhoff c6920-0040, Beckhoff 
c6920-0050, Shuttle DS47 )
- this bug happens on any Realtek boards I have. ( two different RTL8168E 
[TP-Link TG3468 V2] and one RTL8111G [Shuttle DS47] )
- the bug happens only if ec_master and ec_r8169 are both loaded (if you just 
load/unload ec_r8169 alone, the MAC address is not destroyed)

If you have a Realtek Ethernet Controller and a 3.14 kernel, you can reproduce 
the bug with the attached script. Just specify the MAC address as argument. For 
example

# ./ec_r8169_bug.sh 60:e3:27:01:68:4d

If you wish additional information, I can run other tests.



Additional details
===================
I use
- EtherCAT: Master driver 1.5.2 0f4b7d799c44  with kernel 3.14.65-rt68 i686
- EtherCAT: Master driver 1.5.2 2eff7c993a63 with kernel 3.4.4-rt13 i686
- EtherCAT: Master driver 1.5.2  with kernel 3.14.39-rt37 x86_64

My distribution are Debian 7 with a 3.4rt kernel  (i386) and Debian 8 with a 
3.14rt kernel (i686 and amd64 architecture)


This is the output of "lspci -v" for a RTL8168E on a TP-Link TG3468V2
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 
PCI Express Gigabit Ethernet Controller (rev 06)
	Subsystem: Device 7470:3468
	Flags: bus master, fast devsel, latency 0, IRQ 53
	I/O ports at d000 [size=256]
	Memory at f7c00000 (64-bit, non-prefetchable) [size=4K]
	Memory at f0000000 (64-bit, prefetchable) [size=16K]
	Capabilities: [40] Power Management version 3
	Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [70] Express Endpoint, MSI 01
	Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
	Capabilities: [d0] Vital Product Data
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [140] Virtual Channel
	Capabilities: [160] Device Serial Number 6d-12-00-00-68-4c-e0-00
	Kernel driver in use: ec_r8169

This is the output of "lspci -v" for a RTL8111G in my Shuttle DS47
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 
PCI Express Gigabit Ethernet Controller (rev 0c)
	Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Device 4018
	Flags: bus master, fast devsel, latency 0, IRQ 41
	I/O ports at c000 [size=256]
	Memory at f7800000 (64-bit, non-prefetchable) [size=4K]
	Memory at f0000000 (64-bit, prefetchable) [size=16K]
	Capabilities: [40] Power Management version 3
	Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [70] Express Endpoint, MSI 01
	Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
	Capabilities: [d0] Vital Product Data
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [140] Virtual Channel
	Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00
	Capabilities: [170] Latency Tolerance Reporting
	Kernel driver in use: ec_r8169

best regards,
-- 
Sebastien BLANCHET

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ec_r8169_bug.sh
Type: application/x-shellscript
Size: 513 bytes
Desc: not available
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20161215/fccfce30/attachment-0003.bin>