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
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?
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
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.
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
Created attachment 2070 [details] Test PCI patch This patch moves some of the x86 specific yenta initialisation to x86 files.
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.
No response from bug submitter; this bug will be closed in on the 7th of March.
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
Created attachment 2780 [details] output from lspci -vvxxx (as root)
Created attachment 2781 [details] /proc/iomem
Created attachment 2782 [details] /proc/ioports
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.
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.
Created attachment 2815 [details] Patch to drivers/pcmcia/yenta.c
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.
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
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.
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.
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.
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
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.
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
Greg: as you're using a proprietary module, we can't help you here. You need to contact the vendor of this module instead.
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.
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.
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.