Last update: 21 October 2004.
Please update your bookmarks and links to this site appropriately. This site will be taken off line on 20th April 2005.
I intend to document known problems with the core Linux 2.6 PCMCIA subsystem here, though I'm not tracking PCMCIA card driver problems. These are the responsibility of the individual driver maintainers.
There is also the 2.6 kernel bugzilla, which can be used for core PCMCIA bug reports (ie, socket driver bug reports, core pcmcia subsystem bug reports, and the like.) However, please do not enter PCMCIA card driver bugs under the "PCMCIA" category - they come my way; I don't have any real interest in sorting these out. These should be posted to the mailing list (see below.)
It seems that some PCMCIA controllers refuse to apply power to the socket when we ask them to. The reason this occurs is presently a complete mystery - it just appears that some laptops with identical PCMCIA bridges have this problem and others do not. This has been seen on the following machines:
| Machine | Bridge | Comment |
|---|---|---|
| Unknown machine | Ricoh Co Ltd RL5c475 (rev 80) | (went away after reboot) |
| Unknown machine | TI PCI1225 | |
| Sony VAIO PCG-871L | Ricoh Co Ltd RL5c476 II | |
| JVC mininote | Ricoh Co Ltd RL5c476 II (rev 88) | |
| Toshiba Tecra 530CDT | TOPIC95 | |
| Packard Bell "i go" | TI PCI1250 | We know that this bridge does work on other laptops. |
| VIA EPIA M-II 10K board | Ricoh Co Ltd RL5c476 II (rev 80) |
David Hinds does give a suggestion for TI1225-based PCI adapters:
Some TI 1225 PCI adapters require setting bit 27 (P2CCLK) of the System Control Register (PCI configuration register at 0x80-0x83). As far as I know, there is no way for software to tell when this is required. In the pcmcia-cs package, the i28365 driver has a module parameter for setting this; you could try just using "setpci".In order to do this, use setpci, eg:
# setpci -s 0a.0 0x80.l 0044b060 # setpci -s 0a.0 0x80.l=0x0844b060where "0a.0" is the PCI bus ID of the Cardbus bridge, and 0x0844b060 is the value reported for the register (0044b060 in the example above) bitwise orred with 0x08000000. Do NOT copy the number in this example verbatim - doing so may cause your laptop to crash.
If that doesn't work, please mail a report including:
Also consider sending a report if you have one of the machines listed above and it does work - this is equally as important as the failure cases.
Thanks.
This is similar to the above problem - some PCMICA bridges refuse to remove socket power when we ask them to. Again, there doesn't seem to be any reasoning or pattern behind this. This has been seen on laptops:
| Machine | Bridge | Comment |
|---|---|---|
| Compaq R3000Z notebook | TI ??? | |
| IBM ThinkPad T23 | Unknown cardbus bridge | |
| Powerbook | TI PCI1510 | |
| Toshiba A60-302 | TI PCI1410 |
Note: This problem may be caused by a resource clash between the PCMCIA socket and system RAM. If the PCMCIA bridge Memory resource (shown by lspci) is below the upper most address of system RAM, then that will cause various problems with PCMCIA. Eg, If you have 1GB of RAM, the PCMCIA bridge memory resource must be above 0x40000000.
This can occur if you pass the mem= parameter to the kernel, or you have a buggy BIOS. An example of a buggy BIOS is:
BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009f000 (usable) BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved) BIOS-e820: 00000000000ce000 - 00000000000d0000 (reserved) BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000000f6f0000 (usable) BIOS-e820: 000000000f6f0000 - 000000000f700000 (reserved) BIOS-e820: 000000000f700000 - 000000003f6f0000 (usable) BIOS-e820: 000000003f6f0000 - 000000003f6f8000 (ACPI data) BIOS-e820: 000000003f6f8000 - 000000003f6fa000 (ACPI NVS) BIOS-e820: 000000003f700000 - 0000000040000000 (reserved) BIOS-e820: 00000000ff800000 - 0000000100000000 (reserved)Note the hole between 000000003f6fa000 and 000000003f700000.
3f6f8000-3f6f9fff : ACPI Non-volatile Storage 3f6fa000-3f6fa3ff : 0000:00:1f.1 3f6fb000-3f6fbfff : 0000:02:01.0 3f6fb000-3f6fbfff : yenta_socket 3f700000-3fffffff : reserved
02:01.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 02)
Subsystem: IBM: Unknown device 054e
Flags: bus master, medium devsel, latency 168, IRQ 11
Memory at 3f6fb000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=02, secondary=03, subordinate=06, sec-latency=176
Memory window 0: 40000000-403ff000 (prefetchable)
Memory window 1: 40400000-407ff000
I/O window 0: 00004000-000040ff
I/O window 1: 00004400-000044ff
16-bit legacy interface ports at 0001
The solution is to manually reserve this memory region by adding
reserve=0x3f6fb000,0x5000 to the kernel command line.If this does not appear to be the case, or does not solve the problem, please mail the complete kernel messages to the mailing list (details given above).
This Thinkpad does not like us placing the Yenta bridge into PCI D3 state. See this patch for a possible fix.
This dumps the CardBus bridge registers. Currently, it only knows about Texas Instruments and some Ricoh CardBus bridges, but will dump the generic registers for all CardBus bridges.