I believe I have found a critical bug in the smsc75xx driver and would like to know the right way to proceed.
Problem:
1. Environment:
- Multiple hard-wired SMSC LAN7500 devices connected at boot time and never removed (not removable, in my case).
- Tested under the following Ubuntu ARM-based systems:
PandaBoard ES: Linux Panda-216 3.5.0-215-omap4 #22-Ubuntu SMP PREEMPT Mon Nov 19 16:41:38 UTC 2012 armv7l armv7l armv7l GNU/Linux
Variscite OM44 DVK: Linux OM44-134 3.4.0-1487-omap4 #6+var5 SMP PREEMPT Mon Oct 15 19:18:50 IST 2012 armv7l armv7l armv7l GNU/Linux
Custom OM44-based system: Linux OM44-120 3.4.0-1487-omap4 #6+var7 SMP PREEMPT Sun Oct 28 11:51:16 IST 2012 armv7l armv7l armv7l GNU/Linux
2. Observations:
- Expected behavior: A random MAC address is assigned at system start.
- Unexpected behavior: Doing "ifconfig ethX down; ifconfig ethX up" always forces a new random MAC address to be assigned.
- Unexpected behavior: All attempts to manually assign a MAC address are consistently overwritten by a subsequent "ifconfig ethX up".
3. Desired behavior:
- I would like to be able to assign desired MAC addresses to any number of attached smsc75xx devices that will persist across any number of ifconfig up/down cycles.
4. Work-arounds:
- None found. All attempts to manually configure a MAC address (including bootargs) are stepped on by "ifconfig ethX up".
5. Planned hack:
- Modify smsc75xx.c to remove code that sets the random MAC address: If the device does not initialize with a valid MAC address from EEPROM, force the interface to fail until a valid MAC address is (manually) assigned (e.g. by bootargs, custom init scripts, ifconfig, macchanger, etc.).
I'm in no way a kernel or USB or device driver hacker (or even much of a C programmer since my Python religious conversion), so this will be a blind hack that should never be allowed anywhere near the source tree. I haven't even built a kernel or module in 5 years (due to increasingly wonderful vendor and distribution support), so this will be an excruciatingly slow process (self-hosted on an embedded system with only SD storage). Advice from true experts would be massively appreciated.
5. Going Forward:
- What is the "most correct" path to a permanent fix for this bug?
- Are there known-good work-arounds I haven't yet found?
- What more should I do bring needed attention to this bug beyond this report to this list?
TIA,
-BobC
��.n��������+%������w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
