cardmgr doesn't recognize inserted cards in IBM Thinkpads
Brought to you by:
dahinds
Menu
▾
▴
#328 cardmgr doesn't recognize inserted cards in IBM Thinkpads
Hallo,
thanks for the great pcmcia work, but now I have a
problem with my new IBM Thinkpad R40 2722-GDG (Debian
testing/unstable, Kernel 2.4.22-ac1)
The Bus is recognized:
Sep 4 13:58:48 think kernel: Linux Kernel Card
Services 3.1.22
Sep 4 13:58:48 think kernel: options: [pci] [cardbus]
[pm]
Sep 4 13:58:48 think kernel: PCI: Found IRQ 7 for
device 02:00.0
Sep 4 13:58:48 think kernel: PCI: Sharing IRQ 7 with
00:1d.1
Sep 4 13:58:49 think kernel: Yenta IRQ list 0030, PCI irq7
Sep 4 13:58:49 think kernel: Socket status: 30000007
Sep 4 13:58:49 think kernel: cs: IO port probe
0x0c00-0x0cff: clean.
Sep 4 13:58:49 think kernel: cs: IO port probe
0x0800-0x08ff: clean.
Sep 4 13:58:49 think kernel: cs: IO port probe
0x0100-0x04ff: clean.
Sep 4 13:58:49 think kernel: cs: IO port probe
0x1000-0x17ff: excluding 0x1600-0x1607 0x1610-0x1617 0
x1620-0x1637
Sep 4 13:58:49 think kernel: cs: IO port probe
0x0a00-0x0aff: clean.
But cardmgr doesn't recognize the insertion of a card.
I have to do an /etc/init.d/pcmcia restart or an
cardctl insert.
I'm using apm at the moment, but witch acpi it also
doesn't work.
Here is an lspci:
00:00.0 Host bridge: Intel Corp.: Unknown device 3340
(rev 03)
00:01.0 PCI bridge: Intel Corp.: Unknown device 3341
(rev 03)
00:1d.0 USB Controller: Intel Corp. 82801DB USB (Hub
#1) (rev 01)
00:1d.1 USB Controller: Intel Corp. 82801DB USB (Hub
#2) (rev 01)
00:1d.2 USB Controller: Intel Corp. 82801DB USB (Hub
#3) (rev 01)
00:1d.7 USB Controller: Intel Corp. 82801DB USB EHCI
Controller (rev 01)
00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge
(rev 81)
00:1f.0 ISA bridge: Intel Corp.: Unknown device 24cc
(rev 01)
00:1f.1 IDE interface: Intel Corp.: Unknown device 24ca
(rev 01)
00:1f.3 SMBus: Intel Corp. 82801DB SMBus (rev 01)
00:1f.5 Multimedia audio controller: Intel Corp.
82801DB AC'97 Audio (rev 01)
00:1f.6 Modem: Intel Corp. 82801DB AC'97 Modem (rev 01)
01:00.0 VGA compatible controller: ATI Technologies Inc
Radeon Mobility M7 LW [Radeon Mobility 7500]
02:00.0 CardBus bridge: Texas Instruments PCI1510 PC
card Cardbus Controller
02:02.0 Ethernet controller: Unknown device 168c:0012
(rev 01)
02:07.0 FireWire (IEEE 1394): Texas Instruments
TSB43AB21 IEEE-1394a-2000 Controller (PHY/Link)
02:08.0 Ethernet controller: Intel Corp. 82801BD
PRO/100 VE (MOB) Ethernet Controller (rev 81)
02:00.0 CardBus bridge: Texas Instruments PCI1510 PC
card Cardbus Controller
Subsystem: IBM: Unknown device 0528
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, cache line size 20
Interrupt: pin A routed to IRQ 7
Region 0: Memory at 30001000 (32-bit,
non-prefetchable) [size=4K]
Bus: primary=02, secondary=03, subordinate=05,
sec-latency=176
Memory window 0: 30400000-307ff000 (prefetchable)
Memory window 1: 30800000-30bff000
I/O window 0: 00004000-000040ff
I/O window 1: 00004400-000044ff
BridgeCtl: Parity- SERR- ISA- VGA- MAbort-
>Reset+ 16bInt+ PostWrite+
16-bit legacy interface ports at 0001
My kernel-config is attached.
Please ask for more informations!
Thanks,
Bernd
Kernel .config
Logged In: YES
user_id=721761
i'm sorry, I forgot to log in, the bug report is from me.
Bernd
Logged In: YES
user_id=7760
The interrupt assignment for the bridge (irq 7) looks
suspicious to me. And, if it is wrong, that would explain the
problem.
I would try rebuilding your kernel with ACPI support turned
on. That may change the interrupt assignment.
-- Dave
Logged In: YES
user_id=721761
Hi,
with acpi pcmcia is running @ irq 11, shared with usb-uhci
and e100.
But that didn't solve the problem! Inserted cards still need
a crdctl insert.
(tried latest acpi (already in 2.4.22) + patches from
http://bugme.osdl.org/show_bug.cgi?id=1038 + fixed DSDT table)
Changing the interrupt assignment also doesn't help,
usb-uhci and the cardbus-bridge stay on the same irq.
Bernd
zeimetz@rbg.informatik.tu-darmstadt.de
Logged In: YES
user_id=7760
Strange. I would have either expected the irq to stay the
same, or the problem to be fixed.
When you say, "changing the interrupt assignment also
doesn't help", what do you mean by that, exactly?
Are you able to check which interrupt is assigned to the
bridge under Windows?
Your bridge (TI PCI1510) is kind of new so there might be
something special that needs to be done to enable
interrupts. I'll look into that. Could you also post the
output of 'lspci -xxx -s 02:00.0'?
-- Dave
Logged In: YES
user_id=721761
> When you say, "changing the interrupt assignment also
doesn't help", what do you mean by that, exactly?
BIOS-settings. You may change the irq of some devices
there, but it is nowhere mentioned which devices are
affected. Now all settings are on Auto-control. So we have
this irq-assignment:
think:~# cat /proc/interrupts
CPU0
0: 193217 XT-PIC timer
1: 3299 XT-PIC keyboard
2: 0 XT-PIC cascade
3: 0 XT-PIC serial
5: 37071 XT-PIC Intel 82801DB-ICH4
6: 3140 XT-PIC ehci_hcd, eth0
7: 468 XT-PIC usb-uhci, Texas Instruments
PCI1510 PC card Cardbus Controller
8: 4 XT-PIC rtc
9: 0 XT-PIC usb-uhci
11: 112398 XT-PIC ohci1394, usb-uhci,
radeon@PCI:1:0:0
12: 16038 XT-PIC PS/2 Mouse
14: 18956 XT-PIC ide0
15: 4 XT-PIC ide1
NMI: 0
ERR: 0
>Are you able to check which interrupt is assigned to the
bridge under Windows?
yes.
The bridge shares irq 9 with:
- MS ACPI
- ATI Radeon
- 3 USB-Controllers
- PCI to USB enhanced host controller
- wlan mini pci adapter
- ieee-1394 controller
- intel e100
- SoundMAX Integrated Digital Audio
- Agere Systems ac97 Modem
irqs 2, 6, 7, 10, 11 are not used.
bridge uses:
MEM: 000DB000 - 000DBFFF
MEM: EFFFF000 - EFFFFFFF
MEM: FE800000 - FE9FFFFF
MEM: FEBFE000 - FEBFEFFF
EA: 0000FD00 - 0000FDFF
EA: 0000FE00 - 0000FEFF
0 think:~# lspci -xxx -s 02:00.0
02:00.0 CardBus bridge: Texas Instruments PCI1510 PC card
Cardbus Controller
00: 4c 10 56 ac 07 00 10 02 00 00 07 06 20 a8 02 00
10: 00 10 00 30 a0 00 00 02 02 03 05 b0 00 00 40 30
20: 00 f0 7f 30 00 00 80 30 00 f0 bf 30 00 40 00 00
30: fc 40 00 00 00 44 00 00 fc 44 00 00 07 01 c0 05
40: 14 10 28 05 01 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 70 f0 44 08 00 00 00 00 00 00 00 00 02 10 d1 01
90: c0 02 64 40 00 00 00 00 00 00 00 00 00 00 00 00
a0: 01 00 12 fe 00 00 c0 00 01 00 00 00 07 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Bernd
Logged In: YES
user_id=721761
It seems to work after loading the pci_hotplug module and
restarting pcmcia. But you have to wait some minutes (up to
5) until card-changes are recognized. I've mounted the
pcihpfs, but its empty. The pci_hotplug module isn't used by
any other modules and I can remove it without problems.
After that the eject is detected, but not the next insert.
Bernd
Logged In: YES
user_id=721761
oh, next insert was recognized. about 10 minutes later ....
Bernd
Logged In: YES
user_id=7760
Are you sure that pci_hotplug makes a difference? Since you
do not have a PCI Hot Plug controller, I would expect this
module to do exactly nothing when loaded.
If another device shares the interrupt used by the CardBus
controller, and that device generates interrupts, then that
will cause insert/eject to be detected even if the bridge is
not delivering any interrupts on its own. This may cause
things to seem to "fix" the problem... when they are just
coincidences.
-- Dave
Logged In: YES
user_id=721761
No, you're right. The interrupts came from an usb-mouse. I
have an usb-hub which is normally connected to my
workstation so there is a mouse attached to it. I don't use
the mouse with the notebook, but it works and so I have
probably moved it accidently.
But thats a fine workaround ;-)
Bernd