This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 187000 - Failed to allocate mem resource on sun qfe card in PC
Failed to allocate mem resource on sun qfe card in PC
Status: CLOSED CANTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: John W. Linville
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-27 17:06 EST by Louis Lagendijk
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-05-24 15:16:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
output lspci -nv for sunhme (3.81 KB, application/octet-stream)
2006-05-20 11:36 EDT, Louis Lagendijk
no flags Details

  None (edit)
Description Louis Lagendijk 2006-03-27 17:06:17 EST
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@redhat.com)
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:
Comment 1 John W. Linville 2006-05-17 13:31:14 EDT
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? 
Comment 2 John W. Linville 2006-05-17 13:40:04 EDT
Could you also include the output of running "lspci -nv"?  Thanks! 
Comment 3 Louis Lagendijk 2006-05-20 11:33:29 EDT
(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

Comment 4 Louis Lagendijk 2006-05-20 11:36:27 EDT
Created attachment 129750 [details]
output lspci -nv for sunhme
Comment 5 Louis Lagendijk 2006-05-20 11:40:05 EDT
(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? 
Comment 6 John W. Linville 2006-05-22 10:18:19 EDT
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] 
 
Comment 7 John W. Linville 2006-05-22 10:51:48 EDT
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? :-) 
Comment 8 Louis Lagendijk 2006-05-23 16:20:59 EDT
(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


Comment 9 John W. Linville 2006-05-24 15:16:09 EDT
Well, I'm sorry... :-( 
Comment 10 Louis Lagendijk 2006-06-03 18:00:45 EDT
(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



Note You need to log in before you can comment on or make changes to this bug.