Linux PCMCIA Card Services

Logged In: YES
user_id=84183

Ah, I see I did turn on the in-kernel hermes/orinoco driver
too. Not sure what I was thinking when I did that.
Rebuilding the kernel without that gives me a working 2.4.21
kernel and pcmcia-cs 3.2.2, and the orinoco driver loading.

The original problem does appear to be resolved with that
workaround -- it appears to be entirely due to the wrong
interupt routing information being recorded/detected, which
is really rather frustrating as the point of PCI, ACPI, etc,
was to avoid having to guess these things...

So yes, close the bug. And thanks for your help.

Ewen

Logged In: YES
user_id=7760

Regarding the orinoco_cs problem...

Make sure that all orinoco/hermes related options in your
kernel configuration are disabled. This sounds like a
classic mixup between kernel modules and modules from the
pcmcia-cs package, which have different and incompatible
versions of the orinoco driver. You can verify this by doing:

find /lib/modules -name 'orinoco*'

Also if you upgrade to the current pcmcia-cs beta for 3.2.5,
you'll get an updated orinoco driver, and also won't need to
apply the i82365 patch. I will close this bug since the
original problem seems to be more or less resolved.

-- Dave

Logged In: YES
user_id=84183

I've _finally_ got around to trying your suggestion (my
apologies again for the delay).

The good news is that by forcing the PCI IRQ to be 10 (for
both Cardbus bridges) not only does the IRQ scan proceed
safely even if other things (such as the eepro100) have been
initialised, but card inserts/ejects actually work correctly
(with do_scan=0 I could bypass the IRQ scan and use PCMCIA
cards, but card inserts/ejects would cause a lockup).

This means that both the BIOS IRQ routing (which says that
the O2Micro OZ6933 is on IRQ 11), and the ACPI IRQ routing
(which also says that the O2Micro OZ6933 is on IRQ 11) are
_both_ wrong. Sigh.

The one other thing I've found is that (at least with
2.4.21, a recent ACPI patch, etc), I need "pci=noacpi" (ie,
don't use the ACPI IRQ routing) for the ISA interrupts (eg,
from my PCMCIA (16-bit) modem card) to work. Without that,
no interrupts are received on the card, and I/O is veryvery
slow (ie, polling occassionally slow). With "pci=noacpi" I
get proper ISA interrupts from the 16-bit card, and it's
quite usable.

So the magic recipe seems to be:
- change i82365.c to use pci_irq_list if set, even if it can
find another IRQ
- pci_irq_list=10,10,10 (ie, use IRQ 10 for all Cardbus
bridges)
- add pci=noacpi to kernel boot line, at least if using a
recent ACPI patch

The only sad thing is that the Wireless card no longer works
with kernel 2.4.21 (plus patches), and PCMCIA-CS 3.2.2,
because the orinoco_cs module fails to load due to missing
symbols. As best I can tell this is because the exported
symbols from orinoco.c (orinoco_shutdown, orinoco_reset,
orinoco_proc_dev_cleanup, orinoco_proc_dev_init) aren't
being decorated (a la modversions) in the orinoco.o.
(Trying to load orinoco_cs fails with a complaint those
symbols aren't defined; yet doing strings on orinoco.o shows
them just without the modversions decorations.)

Next time I get some spare time I'll try rebuilding the
kernel and modules without modversions enabled, and see if
that fixes it. (Strangely I've used modversions on many
other kernels, including with pcmcia-cs 3.2.2, and it worked
there.)

Thanks for your help in getting this far.

Ewen

Logged In: YES
user_id=84183

Sorry for the very long delay in responding. The short
answer is "no", I haven't had a chance to try out the
suggsested fix. The last 4 weeks have been filled with an
overseas business trip where there was far more than 4 weeks
of work to get done. I hope to get a chance to look at this
by the end of this month.

Logged In: YES
user_id=7760

Have you had a chance to try out my suggested fix to the
i82365 module?

-- Dave

Logged In: YES
user_id=7760

Sorry, my error, the i82365 driver only interprets pci_irq_list if
a bridge doesn't already have an interrupt assigned.

If you're up for it, try editing i82365.c and change:

if ((irq == 0) && (pci_csc || pci_int))
irq = pci_irq_list[s - socket];

to:

if (pci_csc || pci_int)
irq = pci_irq_list[s - socket];

rebuild/install, then try the pci_irq_list=10,10,10 option.

-- Dave

Logged In: YES
user_id=84183

The option "pci_irq_list=10,10,10" appears to make no
difference at all; the O2Micro OZ6933 is still found at IRQ
11, it still reports "PCI irq 11 test failed" if the
eepro100 is not active, and still hangs immediately prior to
reporting that if the eepro100 is active. Perhaps the
option isn't being processed as expected?

Screen grab from run without eepro100 loaded:

-=- cut here -=-
basilica:~# modprobe pcmcia_core
Linux PCMCIA Card Services 3.2.2
kernel build: 2.4.19 unknown
options: [pci] [cardbus] [apm]
basilica:~# modprobe i82365 pci_irq_list=10,10,10
Intel ISA/PCI/CardBus PCIC probe:
PCI: Enabling device 01:05.0 (0000 -> 0002)
PCI: Found IRQ 10 for device 01:05.0
PCI: Sharing IRQ 10 with 01:08.0
TI 1410 rev 01 PCI-to-CardBus at slot 01:05, mem 0x80102000
host opts [0]: [pci only] [pci irq 10] [lat 32/176] [bus
2/5]
PCI card interrupts, PCI status changes
PCI: Found IRQ 11 for device 01:09.0
PCI: Sharing IRQ 11 with 00:1d.1
PCI: Sharing IRQ 11 with 01:09.1
PCI: Found IRQ 11 for device 01:09.1
PCI: Sharing IRQ 11 with 00:1d.1
PCI: Sharing IRQ 11 with 01:09.0
O2Micro OZ6933 rev 02 PCI-to-CardBus at slot 01:09, mem
0x80103000
host opts [0]: [pci/way] [pci irq 11] [lat 32/176] [bus 6/9]
host opts [1]: [pci/way] [pci irq 11] [lat 32/176] [bus
10/13]
PCI irq 11 test failed
ISA irqs (default) = 3,4,5,7,15 polling interval = 1000 ms
-=- cut here -=-

(If the eepro100 is loaded then the system is locked sold
after printing host opts[1] for the O2Micro bridge.)

It appears to me that irrespective of the cause we need to
narrow the issue down inside the i82365 initialisation code;
if you can suggest suitable points I'm happy to instrumet
the i82365.c module, and rebuild it, so we get more
informaton about what is being attempted immediately prior
to the system hanging.

Logged In: YES
user_id=7760

I think your theory about an interaction between the two
CardBus bridges is wrong. You've got an interrupt sharing
problem. When you insert or remove a card, that should
generate a PCI interrupt. Your Toshiba bridge claims that it
is on PCI irq 11, however, the i82365 module reports that its
interrupt test fails with this setting. The lock-up if you have
the eepro100 driver loaded indicates that maybe this bridge is
actually triggering PCI irq 10. The eepro100 doesn't know
how to turn off this interrupt once triggered, and the i82365
driver is waiting for it on irq 11, so you get a lock-up.

Try loading the i82365 module with:

pci_irq_list=10,10,10

and no other options.

-- Dave

Logged In: YES
user_id=84183

Retested with Linux 2.4.19, PCMCIA-CS 3.2.2 (from Debian
Unstable source package, from pcmcia-cs.sourceforge.net).

With no special options, if (PCI) eepro100 ethernet is
initialised, system hangs during PCI IRQ scan on
intitialising the second (O2Micro) cardbus controller, as
with earlier versions. Hang is after reporting "host opts"
settings for O2Micro, but prior to any IRQ reports.

With pci_int=0 pci_csc=0 kernel panics (or oopses in
modprobe, and then hangs). This is repeatable with that
pair of settings. It happens too quickly for me to notice
if this is on the TI 1410 or the O2Micro cardbus controller;
if relevant I can probably do serial-console to grab the info.

With pci_int=0 (no setting for pci_csc) 2 times out of 3
system was able to initiliase both cardbus bridges, without
hanging, even when eepro100 was already initialised (the
other time it hung; not sure why). However this leaves the
Wavelan card behind the TI 1410 reporting "*NO* interrupt",
which isn't really suitable for a network card. (Presumably
the Wavelan card and/or the TI 1410 is PCI only.)

With "do_scan=0 irq_list=3,4,5,7,12,15" system reliably
initialises both card bus controllers, including PCI
interrupts for the TI 1410 cardbus bridge and Wavelan card,
even after eepro100 has been initialised.

This would be a viable work around, except that the system
freezes solid on insertion of pcmcia (16-bit) modem card
with "do_scan=0 irq_list=..." (even for a more abbreviated
irq_list than above; even with irq_list=5,15 it still
freezes, and I'm virtually certain those two interrupts
aren't in use. 5 is what is typically assigned to the modem
card on insert in the default configuration). The same card
does work reliably if pcmcia-cs is started without any
special options (providing pcmcia-cs is started before the
eepro100 is initialised).

In the "do_scan=0 irq_list=..." situation, ystem freezes
with no output messages, no beeps, nothing, on insertion of
card. Console mode cursor continues flashing, but
keyboard, etc, non-responsive.

My current working theory is that the major issue in my
system is that ther eare two separate cardbus bridges, from
two manufacturers, and that something in the
initialisation/probing of the second one causes issues for
the other one (or interferes with the detection for the
other one). One factor lending weight to this their is that
the TI 1410 cardbus bridge, which is always initialised
first, is using irq 10, as is the eepro100. If the eepro100
is not initialised then at the time the O2Micro cardbus
scans, etc, are done only the TI 1410 is using IRQ 10. If
it is initialised there are two devices sharing IRQ 10.

I do not know what the issue is that causes a system freeze
on pcmcia card insert if do_scan=0, but it may be related.

Since I cannot find any way to initialise only one card at a
time, it is difficult to test this theory (eg, to test that
the O2Micro would be okay if it were the only cardbus bridge
initialised, or that the TI 1410 would have the same problem
if it were the second cardbus controller initalised). Since
the machine is a laptop and everything is integrated there's
no obvious "remove the hardware" trick to work around the
lack of software controls to do that type of test.

I'm happy to try to extract more debugging information if
suitable points for printk() printouts or similar can be
suggested.

dmesg details for 3.2.2 with do_scan=0 follows, followed by
dump of pci irq routing table.

-=- dmesg with do_scan=0 -=-
Linux PCMCIA Card Services 3.2.2
kernel build: 2.4.19 unknown
options: [pci] [cardbus] [apm]
Intel ISA/PCI/CardBus PCIC probe:
PCI: Enabling device 01:05.0 (0000 -> 0002)
PCI: Found IRQ 10 for device 01:05.0
PCI: Sharing IRQ 10 with 01:08.0
TI 1410 rev 01 PCI-to-CardBus at slot 01:05, mem 0x80102000
host opts [0]: [pci only] [pci irq 10] [lat 32/176] [bus
2/5]
PCI card interrupts, PCI status changes
PCI: Found IRQ 11 for device 01:09.0
PCI: Sharing IRQ 11 with 00:1d.1
PCI: Sharing IRQ 11 with 01:09.1
PCI: Found IRQ 11 for device 01:09.1
PCI: Sharing IRQ 11 with 00:1d.1
PCI: Sharing IRQ 11 with 01:09.0
O2Micro OZ6933 rev 02 PCI-to-CardBus at slot 01:09, mem
0x80103000
host opts [0]: [pci/way] [pci irq 11] [lat 32/176] [bus 6/9]
host opts [1]: [pci/way] [pci irq 11] [lat 32/176] [bus
10/13]
ISA irqs (default) = 3,4,5,7,12,15 PCI status changes
cs: memory probe 0xa0000000-0xa0ffffff: clean.
hermes.c: 5 Apr 2002 David Gibson <hermes@gibson.dropbear.id.au>
orinoco.c 0.11b (David Gibson <hermes@gibson.dropbear.id.au>
and others)
orinoco_cs.c 0.11b (David Gibson
<hermes@gibson.dropbear.id.au> and others)
cs: IO port probe 0x0100-0x04ff: excluding 0x170-0x177
0x240-0x247 0x370-0x377 0
x380-0x38f 0x3c0-0x3df 0x4d0-0x4d7
cs: IO port probe 0x0178-0x023f: clean.
cs: IO port probe 0x0248-0x036f: clean.
cs: IO port probe 0x0378-0x037f: clean.
cs: IO port probe 0x0390-0x03bf: clean.
cs: IO port probe 0x03e0-0x04cf: clean.
cs: IO port probe 0x04d8-0x04ff: clean.
cs: IO port probe 0x0800-0x08ff: clean.
cs: IO port probe 0x0a00-0x0aff: clean.
cs: IO port probe 0x0c00-0x0cff: clean.
eth1: Station identity 001f:0001:0006:0010
eth1: Looks like a Lucent/Agere firmware version 6.16
eth1: Ad-hoc demo mode supported
eth1: IEEE standard IBSS ad-hoc mode supported
eth1: WEP supported, 104-bit key
eth1: MAC address 00:02:2D:43:F2:8C
eth1: Station name "HERMES I"
eth1: ready
eth1: index 0x01: Vcc 3.3, irq 10, io 0x0100-0x013f

-=- dmesg with do_scan=0 -=-

-=- dump_pirq -=-
Interrupt routing table found at address 0xfb700:
Version 1.0, size 0x0090
Interrupt router is device 00:1f.0
PCI exclusive interrupt mask: 0x0000 []
Compatible router: vendor 0x8086 device 0x248c

Device 00:02.0 (slot 0): VGA compatible controller
INTA: link 0x60, irq mask 0x0800 [11]
lspci: -f: Invalid slot number

Device 00:1f.0 (slot 0):
INTA: link 0x60, irq mask 0x1ef8 [3,4,5,6,7,9,10,11,12]
INTB: link 0x61, irq mask 0x1ef8 [3,4,5,6,7,9,10,11,12]
INTC: link 0x62, irq mask 0x1ef8 [3,4,5,6,7,9,10,11,12]
INTD: link 0x63, irq mask 0x1ef8 [3,4,5,6,7,9,10,11,12]

Device 00:1d.0 (slot 0): USB Controller
INTA: link 0x60, irq mask 0x0800 [11]
INTB: link 0x63, irq mask 0x0800 [11]
INTC: link 0x62, irq mask 0x0800 [11]

Device 01:09.0 (slot 0): CardBus bridge
INTA: link 0x63, irq mask 0x0800 [11]
INTB: link 0x63, irq mask 0x0800 [11]

Device 01:08.0 (slot 0): Ethernet controller
INTA: link 0x68, irq mask 0x0400 [10]

Device 01:03.0 (slot 0): FireWire (IEEE 1394)
INTA: link 0x69, irq mask 0x0400 [10]

Device 01:05.0 (slot 0): CardBus bridge
INTA: link 0x68, irq mask 0x0400 [10]

Interrupt router at 00:1f.0: unknown vendor 0x8086 device 0x248c
PIRQ? (link 0x68): irq 10
PIRQ? (link 0x69): irq 10
PIRQ? (link 0x60): irq 11
PIRQ? (link 0x61): unrouted?
PIRQ? (link 0x62): irq 11
PIRQ? (link 0x63): irq 11
-=- dump_pirq -=-

(lspci claims that 00:1f.* is an Intel 82801CAM chip,
providing various functions. See lspci -v report in
original bug)

Logged In: YES
user_id=84183

One more test completed. I've tried a PCMCIA modem (fairly
generic 56K hardware PCMCIA (16-bit) modem) in the cardbus
slot connected to the O2Micro bridge. The modem does
basically work. I can dial out, connect to a server, login,
etc. There were two oddnesses:

1. there is no "modem dialing/connecting" noise (with ATL3,
ATM1) even though in another laptop the connection progress
noises are quite audible with those settings on this modem.
(How is this normally achieved? Audio routed through to the
laptop audio? Or pizzeo speaker on the modem card?)

2. While the modem was quite responsive through minicom in
single user mode (prior to loading any modules such as the
eepro100); when I first tried it in multiuser mode it was
very very slow (15-16 characters at a time fairly slowly,
with large pauses in between, even offline doing at&v). I
_think_ this may simply be IRQ allocation choice, since
ejecting and reinserting the card appears to (a) have given
it a new IRQ, and (b) resolved the speed issue. (So
probably this can be controlled by excluding the
going-to-be-used IRQs from the ISA PCMCIA cards with the
standard PCMCIA-CS options.)

Anyway this proves (to me at least) that the bridge is
sufficiently well detected to be able to use PCMCIA cards in
the cardbus socket, give or take the care required to bring
up the PCMCIA-CS without locking the system up (ie, ensuring
the eepro100 isn't loaded/active).

I suspect that the SmartCard reader on this bridge would
probably work if I taught PCMCIA-CS to recognise it as an
IDE-like device; I will experiment with this when I have
some more spare time.

I would still be interested to know if it is possible to
bring up only one PCI<->CardBus bridge at a time, for
diagnostic purposes, and also for on-battery power saving.

Ewen

Logged In: YES
user_id=84183

I've done some more research. Firstly from reading the i386
PCI kernel source it appears that it will say it is guessing
if it doesn't recognise the interrupt router completely.
AFAICT you can override the interrupts with setpci (from the
pciutils), but this really only changes the message unless
you set another IRQ.

The other thing I found is that perhaps this laptop doesn't
actually have an O2Micro OZ6933 Cardbus controller (which is
what both lspci and PCMCIA-CS 3.1.33 say). Possibly it has
an O2Micro OZ711E1 chip
(http://www.o2micro.com/products/prod_prodsmartcard.html)
which is a cardbus controller with the choice of two cardbus
ports, or one cardbus port and one smartcard reader.

This laptop (Acer Travelmate 361EVi) has one Cardbus port,
and one smartcard reader, and PCMCIA-CS reports an
unrecognised smart card reader when PCMCIA-CS is loaded. So
it would seem "obvious" that they might have used that
O2Micro OZ711E1 chip instead.

The O2Micro OZ711E1 chip is apparently electrically
compatible with the O2Micro OZ6933 chip; I don't know if it
is 100% programmatically compatible. If it isn't 100%
compatible, that may explain the reports that the PCI IRQ
test failed.

Logged In: YES
user_id=84183

According to /proc/interrupts, and lspci -v, eth0 (the
eepro100) interface is using IRQ 10, not IRQ 11. (IRQ 11 is
the interrupt guessed by the PCMCIA-CS code for the O2Micro
bridge, and also shown in lspci -v. The only other thing
listed on IRQ11 is the USB bridges, and the status of those
does't appear to affect the problem.)

So while it does sound plausible that there would be an
issue with guessing IRQs, I'm not clear how the IRQ11 guess
would interact with the eepro100 interface being active on
IRQ10.

/proc/interrupts contains:

-=- cut here -=
CPU0
0: 224821 XT-PIC timer
1: 5543 XT-PIC keyboard
2: 0 XT-PIC cascade
3: 11132 XT-PIC serial
8: 3 XT-PIC rtc
9: 0 XT-PIC acpi
10: 9619 XT-PIC eth0, Intel ICH
11: 0 XT-PIC usb-uhci, usb-uhci,
usb-uhci
12: 18502 XT-PIC PS/2 Mouse
14: 5728 XT-PIC ide0
NMI: 0
LOC: 224785
ERR: 0
MIS: 0
-=- cut here -=-

lspci -v output is already attached to this bug.

Do the reports from the PCI subsystem come from the Linux
kernel? Or the PCMCIA-CS modules? (I'm wondering which I
should look to investigate why it is "guessing" the IRQ.)

BTW, this laptop is configured with ACPI (and the Linux
kernel ACPI information is enabled), so it may be retrieving
this information from the ACPI tables.

Finally, is there any way that I can tell the PCMCIA-CS to
use only one of the two PCI<->Cardbus bridges in the laptop?
I would like to be able to test activating them one at a
time, and see if that resolves the problem, or allows one of
them to be usable even if the other isn't immediately
useful.

Ewen

Logged In: YES
user_id=7760

My suspicion is that the:

> PCI: Guessed IRQ 11 for device 01:09.0

stuff is assigning the wrong irq to the O2Micro bridge.
The interrupt test is then triggering the interrupt shared
with the ethernet interface, which can't clear the
interrupt, so you get a lockup.

As for what to do about it, I'm not sure what it means when
the PCI subsystem says it is "guessing", or whether you can
override its guess.

-- Dave

Logged In: YES
user_id=84183

(Okay, it's definite. Something about SourceForge's
bugtracking system and Mozilla 0.97 do not play nicely
together. A submission with Netscape 4 went through easily;
submissions with Mozilla 0.97 apparently hung, but it
appears two of my 6 attempts went through. Will have to try
upgrading to Mozilla 0.99 soon and see what happens.)

Subsequent to this report, I built a Linux 2.4.18 kernel,
and PCMCIA-CS 3.1.33, and tried again. The Cardbus bridge
was then identified as an O2Micro cardbus bridge (which I
see is very newly supported) by the PCMCIA-CS, and also by
lspci. (I did try to post a new bug report with these
updated details; but ran into the same issue with Mozilla
again.)

Symptoms are essentially unchanged, except that it appears
that with 3.1.33 the eepro100 module must be loaded _and_
the interface up to get a lockup; I _think_ that if the
eepro100 module is loaded, but the interface hasn't been
brought up there is no lockup with 3.1.33 (and I think there
was with 3.1.31).

I can definitely load the eepro100 module after the
PCMCIA-CS and bring it up, and it will work fine. I do not
know if anything behind the O2Micro cardbus bridge works
correctly though, as I haven't been able to test this yet.

Suggestions for what to try next to narrow down where the
lockup occurs welcomed. I'm happy to try upgrading to a
development version if it might fix the problem, or reveal
more about what is going wrong.

Ewen