Mac 00:00:00:00:00:01

I saw that firmware update, but as my board has a 2919 date code, and the link/activity LEDs work, I deduced that my board was not affected by that bug.

I’ll try it anyway and see if it does anything.

I have found that in rtl_eeprom.c(not at pc so that file name might be mis spelled), the magic number check fails when testing the eeprom. The value read is 0x0000 instead of the expected value. I assume that it fails to read, returns zero and the driver assumes “no eeprom”.

I will try to follow the trail back further, but the eeprom read calls appear to be some kind of system hooks or something strange, if I recall correctly.

Somehow your device does not read the mac from eeprom.

From our nano, we go through below path.

[ 2.379393] r8168 0000:01:00.0: enabling device (0000 → 0003)
[ 2.379409] r8168 Gigabit Ethernet driver 8.045.08-NAPI loaded
[ 2.393522] r8168 0000:01:00.0 (unnamed net_device) (uninitialized): Invalid ethernet address 00:00:00:00:00:00, trying device tree node
[ 2.393608] r8168 0000:01:00.0 (unnamed net_device) (uninitialized): Found valid ethernet address 00:04:4b:e5:5b:93 from device tree

I have ran the patch. I did patch, but still same after reboot.

If I do a “dtc -I fs /sys/firmware/devicetree/base | grep mac” then I do see the mac address in the device tree, so the driver isn’t pulling it from the device tree as it should?

  nvidia,ethernet-mac = "00:04:4b:e7:17:cc";
  		mac-address = [00 04 4b e7 17 cc];

If I do a “dtc -I fs /sys/firmware/devicetree/base | grep mac” then I do see the mac address in the device tree, so the driver isn’t pulling it from the device tree as it should?

Yes, I would suggest you can RMA your Nano to get a new one.

I think RMA is overkill.

I have narrowed the issue down more.

For some reason your board get a mac of 00:00:00:00:00 from trying to get it from eeprom. Then some code in the driver sees that that is an invalid mac. Then it pulls the mac from the device tree.

My board gets a mac of 00:00:00:00:01, which is a “valid” mac, so the mac from the device tree is not used. I have disabled the “valid mac check” and now get this"

[ 2.861051] r8168 0000:01:00.0 (unnamed net_device) (uninitialized): Invalid ethernet address 00:00:00:00:00:01, trying device tree node
[ 2.861130] r8168 0000:01:00.0 (unnamed net_device) (uninitialized): Found valid ethernet address 00:04:4b:e7:17:cc from device tree

And now my mac address is correct:

3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:04:4b:e7:17:cc brd ff:ff:ff:ff:ff:ff

I’m starting to think that a broken 00:00:00:00:00:01 mac has been written to the OTP in the r8168 and that is being preferred?

I’m starting to think that a broken 00:00:00:00:00:01 mac has been written to the OTP in the r8168 and that is being preferred?

Yes, it is possbile.

I think RMA is overkill.

The decision is up to you. I just feel it is not good to use a module with wrong OTP fused.

After a hard power off and power on, instead of just an sudo reboot, the mac is 00;00;00;00;00;00 as it should be, so maybe the patch just required a full power down?

[ 2.866403] r8168 0000:01:00.0 (unnamed net_device) (uninitialized): Invalid ethernet address 00:00:00:00:00:00, trying device tree node
[ 2.866541] r8168 0000:01:00.0 (unnamed net_device) (uninitialized): Found valid ethernet address 00:04:4b:e7:17:cc from device tree

@marquitos Maybe also try the patch?

Thank you WayneWWW!

1 Like

Confirmed on my side. This script requires a cold boot instead of warm boot (commands).

2 Likes

is this use closed I have 4 jetson Nanos giving me the same problem

Hi quintinsmith334,

Please help to open a new topic with more details. Thanks