Bug 1840 - PCI: Failed to allocate ressource 0 (ef010000-ef003fff) with Proxim 8480
Summary: PCI: Failed to allocate ressource 0 (ef010000-ef003fff) with Proxim 8480
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Drivers
Classification: Unclassified
Component: PCMCIA (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Dominik Brodowski
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-01-12 00:44 UTC by Jens Kammann
Modified: 2008-04-05 22:00 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.0-final
Tree: Mainline
Regression: ---


Attachments
lspci -vv (7.85 KB, text/plain)
2004-01-12 06:55 UTC, Jens Kammann
Details
lspci -vv / Yenta Sockets not loaded (7.24 KB, text/plain)
2004-01-12 10:10 UTC, Jens Kammann
Details
Test PCI patch (2.80 KB, patch)
2004-02-09 15:14 UTC, Russell King
Details | Diff
output from lspci -vvxxx (as root) (31.18 KB, text/plain)
2004-05-03 17:03 UTC, Alistair Strachan
Details
/proc/iomem (1.21 KB, text/plain)
2004-05-03 17:04 UTC, Alistair Strachan
Details
/proc/ioports (818 bytes, text/plain)
2004-05-03 17:05 UTC, Alistair Strachan
Details
Patch to drivers/pcmcia/yenta.c (768 bytes, patch)
2004-05-08 07:55 UTC, Alec H. Peterson
Details | Diff
boottested patch (687 bytes, text/plain)
2004-05-13 10:40 UTC, Alistair Strachan
Details

Description Jens Kammann 2004-01-12 00:44:40 UTC
Distribution: gentoo with 2.6.0 kernel, Cardservices/PCMCIA compiled in
Hardware Environment: embedded PC (VIA Eden), Proxim 8480-WD IEEE802.11a/b/g
WiFi-Card (CardBus) 
Software Environment: MadWifi-Driver
Problem Description:
After inserting a Proxim 8480-WD card, the following error is reported to syslog:

"PCI: Failed to allocate ressource 0 (ef010000-ef003fff)"

Note that start address > end address.
The card does not initialize and so the MadWifi does not find the card.
(I tested serval cards of the same model - same error)

Steps to reproduce:
I posted the problem already to
https://sourceforge.net/tracker/?func=detail&atid=202405&aid=861599&group_id=2405
At that time I was using the older kernel 2.4.22 and was referred to a kernel
bug which should be fixed in the 2.6 version. Unfortunately the same error
occurs with the latest kernel.

Jens
Comment 1 Russell King 2004-01-12 06:17:56 UTC
It would be useful to see the output of lspci -vvv and /proc/iomem so that
we can see how the PCI bus has been setup.  Could you add these to this bug
please?
Comment 2 Jens Kammann 2004-01-12 06:55:13 UTC
Created attachment 1843 [details]
lspci -vv 

lspci -vv output attached ("Proxim Card" is listed as the last entry).
Here's also the output of  /proc/iomem:
-------------------------------
00000000-0009ffff : System RAM
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000f0000-000fffff : System ROM
00100000-1f7fffff : System RAM
  00100000-002adfc4 : Kernel code
  002adfc5-0035ce9f : Kernel data
1f800000-1fffffff : reserved
e0000000-e7ffffff : PCI Bus #01
  e0000000-e7ffffff : 0000:01:00.0
e8000000-ebffffff : 0000:00:00.0
ec000000-edffffff : PCI Bus #01
  ed000000-ed07ffff : 0000:01:00.0
ef000000-ef001fff : PCI CardBus #02
ef002000-ef003fff : PCI CardBus #02
ef004000-ef004fff : 0000:00:0c.1
  ef004000-ef004fff : yenta_socket
ef005000-ef006fff : PCI CardBus #06
ef007000-ef008fff : PCI CardBus #06
ef009000-ef0090ff : 0000:00:0f.0
  ef009000-ef0090ff : 8139too
ef00a000-ef00afff : 0000:00:0c.0
  ef00a000-ef00afff : yenta_socket
ffff0000-ffffffff : reserved
Comment 3 Russell King 2004-01-12 07:24:00 UTC
Ok.  It seems that your cardbus bridges have rather small memory windows
(only 8K).  I'm willing to bet that the Proxim card wants 64K of memory,
so the allocation correctly fails.

The real bug is why do you only have 8K memory windows.  I suspect your
BIOS may be setting this up, and Linux is blindly believing it.

To confirm this, we need to prevent yenta_socket initialising the hardware
and then obtain a new lspci -vv dump.  I stress that this dump must be
obtained before yenta has initialised, so it's probably best to deconfigure
it from your kernel and disable PCMCIA startup, reboot, and then double-check
by ensuring there are no "Yenta" messages in the kernel message log.

Thanks.
Comment 4 Jens Kammann 2004-01-12 10:10:17 UTC
Created attachment 1845 [details]
lspci -vv / Yenta Sockets not loaded

I recompiled the kernerl without card services and rebootet without loading the
 pcmcia modules (no Yenta messages in syslog, Status LED on Controller: off)

Attached is the new output of lspci.

Jens
Comment 5 Russell King 2004-02-09 15:14:46 UTC
Created attachment 2070 [details]
Test PCI patch

This patch moves some of the x86 specific yenta initialisation to x86 files.
Comment 6 Russell King 2004-02-09 15:16:12 UTC
Ok, the patch I just added should fix this problem, although I'm not completely
happy with it.  Let me know if it solves your issue.
Comment 7 Russell King 2004-03-01 11:44:54 UTC
No response from bug submitter; this bug will be closed in on the 7th of March.
Comment 8 Jens Kammann 2004-03-02 05:00:29 UTC
Sorry for not getting back earlier --too busy...
Well, the bug solved the problem in a way - the card is now being recognized
correctly. 
However, the card does not function as expected. The MadWiFi driver should set
the Proxim card in a search-mode (scanning different frequencies for W-LAN
Access Points) which does not work.
I am not sure if this is still related to this bug. It might be a problem with
the MadWiFi driver itself. It's still listed as buggy on Gentoo's online package
databases.
I'll give it again a try with the latest version "0.1_pre20040212", maybe things
 will change.

Jens
Comment 9 Alistair Strachan 2004-05-03 17:03:58 UTC
Created attachment 2780 [details]
output from lspci -vvxxx (as root)
Comment 10 Alistair Strachan 2004-05-03 17:04:41 UTC
Created attachment 2781 [details]
/proc/iomem
Comment 11 Alistair Strachan 2004-05-03 17:05:07 UTC
Created attachment 2782 [details]
/proc/ioports
Comment 12 Alistair Strachan 2004-05-03 17:05:41 UTC
I have a similar problem with a Ricoh PCMCIA bridge. Tried the attached patch,   
I get the following messages at boottime.   
   
Find attached the results of cat /proc/iomem, cat /proc/ioports and lspci   
-vvxxx. This may be of some help.   
Comment 13 Alistair Strachan 2004-05-03 17:08:46 UTC
In dmesg, with patch: 
 
PCI: cardbus bridge: 0000:01:07.0 
PCI: Failed to allocate resource 7(2000000) for 0000:01:07.0 
PCI: Failed to allocate resource 8(2000000) for 0000:01:07.0 
PCI: Failed to allocate resource 10(1000) for 0000:01:07.0 
 
http://lists.infradead.org/pipermail/linux-pcmcia/2004-May/000813.html 
 
See this thread for more information. 
Comment 14 Alec H. Peterson 2004-05-08 07:55:53 UTC
Created attachment 2815 [details]
Patch to drivers/pcmcia/yenta.c
Comment 15 Alec H. Peterson 2004-05-08 07:57:26 UTC
Greetings all.  I have a similar problem, and for me at least the problem was not only the size of the 
block, but the alignment.  My card (A NetGear WG511) was requesting 8K, but it only ended up with 4K 
because the 8K was only 4k aligned, not 8k.  The patch I just attached should deal with the issue, I 
would love to hear feedback on it.
Comment 16 Alistair Strachan 2004-05-08 10:44:37 UTC
Confirmed as working with Alec's patch. Great timing! 
 
Linux Kernel Card Services 
  options:  [pci] [cardbus] [pm] 
Yenta: CardBus bridge found at 0000:01:07.0 [0000:0000] 
yenta 0000:01:07.0: Preassigned resource start e3024000end e3020fff too small 
or not aligned. 
yenta 0000:01:07.0: Preassigned resource start e3021000end e3022fff too small 
or not aligned. 
yenta 0000:01:07.0: Preassigned resource 2 busy, reconfiguring... 
Yenta: ISA IRQ mask 0x0000, PCI irq 19 
Socket status: 30000820 
PCI: Enabling device 0000:02:00.0 (0000 -> 0002) 
eth1: prism54 driver detected card model: 3COM 3CRWE154G72 
eth1: islpci_open() 
eth1: resetting device... 
eth1: uploading firmware... 
eth1: firmware uploaded done, now triggering reset... 
 
[alistair] 18:44 [~] ifconfig eth1 
eth1      Link encap:Ethernet  HWaddr 00:0D:54:A2:4B:DA 
          inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.0.0 
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1 
          RX packets:30695 errors:0 dropped:0 overruns:0 frame:0 
          TX packets:54304 errors:0 dropped:0 overruns:0 carrier:0 
          collisions:0 txqueuelen:1000 
          RX bytes:1987234 (1.8 Mb)  TX bytes:72723936 (69.3 Mb) 
          Interrupt:19 
 
[alistair] 18:45 [~] iwconfig eth1 
eth1      IEEE 802.11b/g  ESSID:"SEVENTEN" 
          Mode:Master  Channel:11  Access Point: 00:0D:54:A2:4B:DA 
          Bit Rate:54Mb/s   Tx-Power=31 dBm   Sensitivity=20/200 
          Retry min limit:8   RTS thr:2347 B   Fragment thr:2346 B 
          Link Quality:50  Signal level:0  Noise level:227 
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0 
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0 
Comment 17 Alec H. Peterson 2004-05-09 15:16:50 UTC
Actually, I retract my previous comment about the first patch not working.  Clearly the memory region 
is large enough that the alignment of the region itself is not important since what matters is the 
alignment of the region being given to the CardBus cards.
Comment 18 Alistair Strachan 2004-05-12 10:46:46 UTC
RMK's patch definitely does not fix my problem, Alec's does. 
 
It seems the problem is not a Linux bug, but an oversight in certain PC 
BIOSes. The PCMCIA bridge product with the problem does *not* work at all in 
Windows XP. With Alec's patch, it works to exact specification for both PCMCIA 
16bit and Cardbus 32bit cards, in Linux. Without the patch, the card works for 
PCMCIA 16bit devices, but Cardbus devices do *not* work. 
 
I can only assume your workaround is valid, even if it is technically a hack. 
Comment 19 Alistair Strachan 2004-05-13 10:40:07 UTC
Created attachment 2853 [details]
boottested patch

This patch should be the equivalent (cleaned up) variant for Linux 2.6.x. Boot
tested on 2.6.6-mm1.
Comment 20 Dave Beckett 2004-07-16 13:27:34 UTC
I was having this bug with a Ricoh Bridge and prism54-based wifi card
in the cardbus slot. I applied the patch in comment #19
to 2.6.6 (debian kernel) and it all works fine after that.

I get the following console messages as it tries to load yenta:

Jul 16 17:49:17 rutan kernel: Yenta: CardBus bridge found at 0000:00:0a.0
[1106:aa01]
Jul 16 17:49:17 rutan kernel: yenta 0000:00:0a.0: Preassigned resource start
3925872640 end 3925880831 too small or not aligned.
Jul 16 17:49:17 rutan kernel: yenta 0000:00:0a.0: Preassigned resource start
3925880832 end 3925889023 too small or not aligned.
Jul 16 17:49:17 rutan kernel: Yenta: ISA IRQ mask 0x0c00, PCI irq 12
Jul 16 17:49:17 rutan kernel: Socket status: 30000820
Jul 16 17:49:17 rutan kernel: Yenta: CardBus bridge found at 0000:00:0a.1
[1106:aa01]
Jul 16 17:49:17 rutan kernel: yenta 0000:00:0a.1: Preassigned resource start
3925893120 end 3925901311 too small or not aligned.
Jul 16 17:49:17 rutan kernel: yenta 0000:00:0a.1: Preassigned resource start
3925901312 end 3925909503 too small or not aligned.
Jul 16 17:49:17 rutan kernel: Yenta: ISA IRQ mask 0x0c00, PCI irq 7

lspci -vv says:

0000:00:0a.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 80)
        Subsystem: VIA Technologies, Inc.: Unknown device aa01
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 168
        Interrupt: pin A routed to IRQ 12
        Region 0: Memory at ea000000 (32-bit, non-prefetchable)
        Bus: primary=00, secondary=02, subordinate=05, sec-latency=176
        Memory window 0: 10000000-103ff000 (prefetchable)
        Memory window 1: 10400000-107ff000
        I/O window 0: 00009000-00009403
        I/O window 1: 00009800-00009c03
        BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt- PostWrite+
        16-bit legacy interface ports at 0001

0000:00:0a.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 80)
        Subsystem: VIA Technologies, Inc.: Unknown device aa01
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 168
        Interrupt: pin B routed to IRQ 7
        Region 0: Memory at ea005000 (32-bit, non-prefetchable)
        Bus: primary=00, secondary=06, subordinate=09, sec-latency=176
        Memory window 0: 10800000-10bff000 (prefetchable)
        Memory window 1: 10c00000-10fff000
        I/O window 0: 0000a000-0000a403
        I/O window 1: 0000a800-0000ac03
        BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt+ PostWrite+
        16-bit legacy interface ports at 0001

Comment 21 Alistair Strachan 2004-08-17 11:11:24 UTC
Microsoft claim the problem is related to some buggy ACPI BIOSes. 
 
RMK, any comments? 
 
http://support.microsoft.com/?kbid=840171 for more information. This hotfix 
gave me use of my bridge in Windows XP, but it assigns a very odd address 
space (nothing like the hack above does). 
 
If details of those regions are required, I can post it. 
Comment 22 Greg Rusenovich 2004-11-02 16:43:09 UTC
I am having a similar problem, but with a Proxim 8470-WD card.

Ihave applied the patch, but still get the same problem.  

PCI: Failed to allocate resource 0(e2010000-e2004fff) for 0000:02:00.0
ath_hal: no version for "struct_module" found: kernel tainted.
ath_hal: module license 'Proprietary' taints kernel.
ath_hal: 0.9.12.14 (AR5210, AR5211, AR5212)
wlan: 0.8.4.4 (EXPERIMENTAL)
ath_rate_onoe: 1.0
ath_pci: 0.9.4.11 (EXPERIMENTAL)
PCI: Enabling device 0000:02:00.0 (0000 -> 0002)
ath_pci: cannot reserve PCI memory region
Comment 23 Dominik Brodowski 2004-12-29 13:26:10 UTC
Greg: as you're using a proprietary module, we can't help you here. You need to
contact the vendor of this module instead.
Comment 24 Dominik Brodowski 2005-02-27 03:33:31 UTC
please try out passing "bios_override=1" to the yenta_socket driver (if you
built it into the kernel, pass yenta_socket.bios=override=1 on the boot command
line, else do "modprobe bios_override=1". 2.6.11-rc5 kernel is best suited for
this test.
Comment 25 Dominik Brodowski 2005-06-12 14:56:07 UTC
four different bugs in this bug entry, most of them solved, the last one being
caused by a proprietary module with no response from the bug reporter.
Comment 26 Jorge Contreras 2008-04-05 22:00:38 UTC
The yenta_socket option is actually:

override_bios=1

Not bios_override.

I know this is a 2.6 kernel, but it seems to have fixed the problem on my 2.4.34 kernel.

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