Description of problem:
In the boot log, we find the following lines:
ACPI: PCI interrupt 0000:00:0a.0[A] -> GSI 12 (level, low) -> IRQ 12
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
0000:00:0a.0: 3Com PCI 3c905B Cyclone 100baseTx at 0xdc00. Vers LK1.1.19
divert: allocating divert_blk for eth0
ACPI: PCI interrupt 0000:00:0b.0[A] -> GSI 10 (level, low) -> IRQ 10
0000:00:0b.0: 3Com PCI 3c905C Tornado at 0xe000. Vers LK1.1.19
divert: allocating divert_blk for eth1
sis900.c: v1.08.07 11/02/2003
ACPI: PCI interrupt 0000:00:04.0[A] -> GSI 10 (level, low) -> IRQ 10
divert: allocating divert_blk for eth2
eth2: Realtek RTL8201 PHY transceiver found at address 1.
eth2: Using transceiver found at address 1 as default
eth2: SiS 900 PCI Fast Ethernet at 0xbc00, IRQ 10, 00:0d:61:5d:47:f9.
As one can see, the ouput of the sis900 driver is marginally more useful,
as it prints the device name and MAC address. Shouldn't the "3c59x" do so,
Version-Release number of selected component (if applicable):
This isn't a bug, and not something we should spend our time on.
The initalization strings printed when a driver is inserted into the kernel
provide whatever information the author deems relevant during the initzliation
process. While printing the set of mac addresses that a card may contain may be
usefull, this strings are generated within individual drivers, so this is not a
scalable to large numbers of drivers, and as such is not usefull for much beyond
There are several standard methods for retrieving MAC addresses from interfaces
in existance already. ifconfig provides MAC address information, as does the
use of lspci in conjunction with the sysfs interface. udev rules can be added
to automatically trigger the printing of this information to the syslog in a
consistent manner if you need the information during boot.
If you really feel strongly about the addition of this feature to the 3c59x
driver, you can propose it upstream (for which there will likely not be much
resistance) and then we will incorporate it in a future RHEL release, but shy of
that, you already have better, more consistent and standard methods for
obtaining this information.
Don't forget ethtool...
> If you really feel strongly (...)
No, no, as I said it's "picky". I agree that consistency on driver
initialization output is not exactly top priority.
Thanks for the extensive clarifications.