Le 26/11/2018 à 21:27, Mario.Limonciello@xxxxxxxx a écrit :
-----Original Message-----
From: Frédéric Parrenin <frederic.parrenin@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Monday, November 26, 2018 2:08 PM
To: Limonciello, Mario; oneukum@xxxxxxxx; gregkh@xxxxxxxxxxxxxxxxxxx
Cc: bjorn@xxxxxxx; linux-usb@xxxxxxxxxxxxxxx
Subject: Re: Support Mac address pass through on Dell DS1000 dock
[EXTERNAL EMAIL]
Le 26/11/2018 à 19:55, Mario.Limonciello@xxxxxxxx a écrit :
Le 26/11/2018 à 15:21, Mario.Limonciello@xxxxxxxx a écrit :
Any feedback from testing with this debugging patch to identify what's
happening?
This is super strange, but Mac address pass-through is now working in my
configuration, although I did not change anything.
The network is up and running and I have the right Mac Address
I guess I would say try it a few times to see if you can trigger your failure again.
Also it might be worth trying some different permutations of power applied to the
dock before plugging into the machine or after plugging into the machine to see
if there is some correlation with a potential ethernet controller bootup race
condition.
For your information, I recompile the kernel and this is the message I
got in /sys/kernel/debug/dynamic_debug/control:
drivers/net/usb/r8152.c:5149 [r8152]rtl_get_version =_ "Detected version
0x%04x\012"
drivers/net/usb/r8152.c:1178 [r8152]vendor_mac_passthru_addr_read =_
"pass-through bit not set.\012"
drivers/net/usb/r8152.c:1170 [r8152]vendor_mac_passthru_addr_read =_
"Not an AD type.\012"
Not sure if it is the information you were looking for (sorry, I am new
in kernel debugging).
These indicate that you turned on the right dynamic debugging lines, but the
actual
output of them will show up in your kernel log.
If you happen to reproduce the failure again while dynamic debugging is enabled
for those
it should save to the kernel log what is happening.
On a related note, I tried Mac Address pass-through with two different
usbc/rj45 dongles, and they both stopped working (they were before).
It would be most useful if you can share the kernel's output when you have dynamic
debugging enabled as Bjorn said for these other devices so we can see why that's
happening.
So I was wondering, is it possible that the driver makes some permanent
changes to these devices?
I wouldn't expect any "permanent" changes to the device from MAC address
pass through. However I would wonder are you plugging these dongles into
the dock and the dock is staying powered so they can't be updated again?
No, the dongles are plugged directly to the laptop.
If they are not getting power cycled between your tests, maybe the hardware
will not support actually updating the MAC address again?
I know at least in TB16 there is a special flow that clears the MAC address on the
8153-AD when the dock is unplugged so it can be reprogrammed on next plugin.
If you look at the source it's very intentional that the pass through MAC is read
at the time it is. This is before the MAC has even been configured the first time.
If you can please share your kernel output with dynamic debugging turned on
and annotate it along what actions you are performing and the topology of the
dock and dongles we might be able to make better sense of what is happening.
Of course it is possible that both devices had hardware issues, but the
coincidence is surprising.
Is this with a combination of them plugged in?
No, the dongles are plugged separately.
