Description of problem: When I install a Sun quad fast ethernet card, the kernel gives me: ACPI: PCI interrupt 0000:02:00.1[B] -> GSI 5 (level, low) -> IRQ 5 sunhme.c:v2.02 24/Aug/2003 David S. Miller (davem) divert: allocating divert_blk for eth0 eth0-3: Quattro HME (PCI/CheerIO) 10/100baseT Ethernet DEC 21153 PCI Bridge eth0: Quattro HME slot 0 (PCI/CheerIO) 10/100baseT Ethernet 08:00:20:b4:2f:6c ACPI: PCI interrupt 0000:02:01.1[B] -> GSI 11 (level, low) -> IRQ 11 PCI: Failed to allocate mem resource #6:1000000@e3000000 for 0000:02:01.1 divert: allocating divert_blk for eth1 eth1: Quattro HME slot 1 (PCI/CheerIO) 10/100baseT Ethernet 08:00:20:06:ad:d7 ACPI: PCI interrupt 0000:02:02.1[B] -> GSI 10 (level, low) -> IRQ 10 PCI: Failed to allocate mem resource #6:1000000@e3000000 for 0000:02:02.1 divert: allocating divert_blk for eth2 eth2: Quattro HME slot 2 (PCI/CheerIO) 10/100baseT Ethernet 08:00:20:a7:0e:32 ACPI: PCI interrupt 0000:02:03.1[B] -> GSI 11 (level, low) -> IRQ 11 PCI: Failed to allocate mem resource #6:1000000@e3000000 for 0000:02:03.1 divert: allocating divert_blk for eth3 eth3: Quattro HME slot 3 (PCI/CheerIO) 10/100baseT Ethernet 08:00:20:43:80:28 the mac addresses of eth1-3 are not correct (sould be the same as for eth0, ending with 6d, 6e, 6f) this is using an Epox 8k3a motherboard. it used to work with an asus k7m. It used to work Version-Release number of selected component (if applicable): 2.6.9-34.EL How reproducible: always as soon as ethernet card is activated Actual results: see error messages above Expected results: mac-addresses should be set correctly Additional info:
The sunhme driver will assign a semi-random MAC address when it can't map a PCI ROM for the device. My guess is that the four-port card only has one ROM (mapped to the first device), so three of the devices get semi-random addresses. Does this cause a functional (i.e. "on the wire") problem?
Could you also include the output of running "lspci -nv"? Thanks!
(In reply to comment #2) > Could you also include the output of running "lspci -nv"? Thanks! (In reply to comment #1) > The sunhme driver will assign a semi-random MAC address when it can't map a > PCI ROM for the device. My guess is that the four-port card only has one ROM > (mapped to the first device), so three of the devices get semi-random > addresses. > > Does this cause a functional (i.e. "on the wire") problem? No, it appears to work ok, the only problem is the alocation of the correct ethx-address. Re-shuffling does not work as there is no stable mac-address. Aprt from the mac-address and the error messages, I have not seen any problems
Created attachment 129750 [details] output lspci -nv for sunhme
(In reply to comment #1) > The sunhme driver will assign a semi-random MAC address when it can't map a > PCI ROM for the device. My guess is that the four-port card only has one ROM > (mapped to the first device), so three of the devices get semi-random > addresses. No, the card works ok (including mac-allocation in an old ASUS motheboard. It could be a bios problem maybe? I have seen the same problem in a somewhat reecent HP Xeon board. But again, it DOES work in some other mobo. If the driver would just autoincrement the mac address, I would already be happy. > > Does this cause a functional (i.e. "on the wire") problem?
02:00.0 Class 0680: 108e:1000 (rev 01) Flags: bus master, medium devsel, latency 32, IRQ 11 Memory at db000000 (32-bit, non-prefetchable) [size=16M] Memory at e0000000 (32-bit, non-prefetchable) [size=8M] 02:00.1 Class 0200: 108e:1001 (rev 01) Flags: bus master, medium devsel, latency 32, IRQ 5 Memory at e2008000 (32-bit, non-prefetchable) [size=32K] Expansion ROM at dc000000 [disabled] [size=16M] 02:01.0 Class 0680: 108e:1000 (rev 01) Flags: bus master, medium devsel, latency 32, IRQ 5 Memory at dd000000 (32-bit, non-prefetchable) [size=16M] Memory at e1000000 (32-bit, non-prefetchable) [size=8M] 02:01.1 Class 0200: 108e:1001 (rev 01) Flags: bus master, medium devsel, latency 32, IRQ 11 Memory at e2010000 (32-bit, non-prefetchable) [size=32K] 02:02.0 Class 0680: 108e:1000 (rev 01) Flags: bus master, medium devsel, latency 32, IRQ 11 Memory at de000000 (32-bit, non-prefetchable) [size=16M] Memory at e0800000 (32-bit, non-prefetchable) [size=8M] 02:02.1 Class 0200: 108e:1001 (rev 01) Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at e2000000 (32-bit, non-prefetchable) [size=32K] 02:03.0 Class 0680: 108e:1000 (rev 01) Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at df000000 (32-bit, non-prefetchable) [size=16M] Memory at e1800000 (32-bit, non-prefetchable) [size=8M] 02:03.1 Class 0200: 108e:1001 (rev 01) Flags: bus master, medium devsel, latency 32, IRQ 11 Memory at e2018000 (32-bit, non-prefetchable) [size=32K]
The 108e:1000 are "EBUS" devices, which I gather are bridges to some sort of SPARC-specific bus. I don't know what (if any) role they play on non-SPARC systems. The 108e:1001 are the actual ethernet devices. Please notice how only 02:00.1 has an "Expansion ROM" listed. This suggest so me that either a) my guess from comment 1 is correct; or, b) your BIOS is not setting-up the PCI stuff correctly for this card. The information from comment 5 would seem to support this. Do you have the most up-to-date BIOS loaded on your motherboard? I would definitely suggest an updated BIOS if at all possible. If that doesn't fix the issue, I don't know what can be done. I don't see anything that would allow the kernel to presume that you are dealing with a quad card rather than four individual devices. So, assigning sequential MAC addresses doesn't seem any more supportable than assigning random addresses. The only other option would be to disable the ports completely, which doesn't seem any more helpful. So, let's hope that a BIOS update is helpful? :-)
(In reply to comment #7) > The 108e:1000 are "EBUS" devices, which I gather are bridges to some sort of > SPARC-specific bus. I don't know what (if any) role they play on non-SPARC > systems. > > The 108e:1001 are the actual ethernet devices. Please notice how only 02:00.1 > has an "Expansion ROM" listed. > As you can see in the lsmod made on a machine where the card works, the expansion rom is available, so I appear to have a broken bios :-( 02:00.0 Class 0680: 108e:1000 (rev 01) Flags: bus master, medium devsel, latency 32, IRQ 5 Memory at de000000 (32-bit, non-prefetchable) [size=16M] Memory at df000000 (32-bit, non-prefetchable) [size=8M] Expansion ROM at dd000000 [disabled] [size=16M] 02:00.1 Class 0200: 108e:1001 (rev 01) Flags: bus master, medium devsel, latency 32, IRQ 11 Memory at dfef8000 (32-bit, non-prefetchable) [size=32K] Expansion ROM at c4000000 [disabled] [size=16M] 02:01.0 Class 0680: 108e:1000 (rev 01) Flags: bus master, medium devsel, latency 32, IRQ 11 Memory at dc000000 (32-bit, non-prefetchable) [size=16M] Memory at db800000 (32-bit, non-prefetchable) [size=8M] Expansion ROM at da000000 [disabled] [size=16M] 02:01.1 Class 0200: 108e:1001 (rev 01) Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at dfef0000 (32-bit, non-prefetchable) [size=32K] Expansion ROM at c5000000 [disabled] [size=16M] 02:02.0 Class 0680: 108e:1000 (rev 01) Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at d9000000 (32-bit, non-prefetchable) [size=16M] Memory at db000000 (32-bit, non-prefetchable) [size=8M] Expansion ROM at d8000000 [disabled] [size=16M] 02:02.1 Class 0200: 108e:1001 (rev 01) Flags: bus master, medium devsel, latency 32, IRQ 3 Memory at dfee8000 (32-bit, non-prefetchable) [size=32K] Expansion ROM at c6000000 [disabled] [size=16M] 02:03.0 Class 0680: 108e:1000 (rev 01) Flags: bus master, medium devsel, latency 32, IRQ 3 Memory at d7000000 (32-bit, non-prefetchable) [size=16M] Memory at d6800000 (32-bit, non-prefetchable) [size=8M] Expansion ROM at d5000000 [disabled] [size=16M] 02:03.1 Class 0200: 108e:1001 (rev 01) Flags: bus master, medium devsel, latency 32, IRQ 5 Memory at dfee0000 (32-bit, non-prefetchable) [size=32K] Expansion ROM at c7000000 [disabled] [size=16M] > > So, let's hope that a BIOS update is helpful? :-) I do have the latest bios, so there appears to be no fix :-( Anyhow, thanks for the help
Well, I'm sorry... :-(
(In reply to comment #9) > Well, I'm sorry... :-( Ok,for the record: I found a workaround that works pretty weel: specify the option macaddr in /etc/modprobe.conf. The driver will then stsrt allocatng mac-addresses starting from the value specified. E.g. options sunhme macaddr=8,0,32,1,2,3