Bug 1840

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.