* [BUG] Ricoh Cardbus -> Can't get interrupts
@ 2003-11-24 23:57 Jean Tourrilhes
2003-11-25 0:16 ` glee
` (2 more replies)
0 siblings, 3 replies; 23+ messages in thread
From: Jean Tourrilhes @ 2003-11-24 23:57 UTC (permalink / raw)
To: linux-pcmcia, Linux kernel mailing list; +Cc: David Hinds, Pavel Roskin
Hi,
I have a new Ricoh PCI-Carbus bridge and the kernel
2.6.0-test9 doesn't seem to configure it properly (see below).
With the old Pcmcia package, the i82365 module had a bunch of
module options to change various irq stuff (see Pcmcia Howto 5.2). A
quick look in yenta_socket failed to show any module options, which
seems odd.
What is the correct way to workaround this stuff ?
Thanks in advance...
Jean
--------------------------------------------------
Nov 24 11:33:54 lagaffe kernel: Linux Kernel Card Services
Nov 24 11:33:54 lagaffe kernel: options: [pci] [cardbus] [pm]
Nov 24 11:33:54 lagaffe kernel: Intel PCIC probe: not found.
Nov 24 11:33:54 lagaffe kernel: PCI: Enabling device 0000:00:13.0 (0000 -> 0002)
Nov 24 11:33:54 lagaffe kernel: PCI: No IRQ known for interrupt pin A of device 0000:00:13.0. Probably buggy MP table.
Nov 24 11:33:54 lagaffe kernel: Yenta: CardBus bridge found at 0000:00:13.0 [0000:0000]
Nov 24 11:33:54 lagaffe kernel: Yenta: ISA IRQ list 0000, PCI irq0
Nov 24 11:33:54 lagaffe kernel: Socket status: 30000006
Nov 24 11:33:54 lagaffe kernel: cs: IO port probe 0x0c00-0x0cff: clean.
Nov 24 11:33:54 lagaffe kernel: cs: IO port probe 0x0800-0x08ff: clean.
Nov 24 11:33:54 lagaffe kernel: cs: IO port probe 0x0100-0x04ff: excluding 0x1f0-0x1f7 0x220-0x22f 0x330-0x337 0x378-0x37f 0x388-0x39f 0x3c0-0x3df 0x3f0-0x3ff 0x4d0-0x4d7
Nov 24 11:33:54 lagaffe kernel: cs: IO port probe 0x0a00-0x0aff: clean.
Nov 24 11:39:43 lagaffe kernel: cs: memory probe 0xa0000000-0xa0ffffff: clean.
Nov 24 11:39:43 lagaffe kernel: airo: Probing for PCI adapters
Nov 24 11:39:43 lagaffe kernel: airo: Finished probing for PCI adapters
Nov 24 11:39:43 lagaffe kernel: airo_cs: RequestIRQ: Resource in use
--------------------------------------------------
# cat /proc/interrupts
CPU0 CPU1
0: 394423 11 IO-APIC-edge timer
1: 8 1 IO-APIC-edge i8042
2: 0 0 XT-PIC cascade
8: 2 1 IO-APIC-edge rtc
12: 91 1 IO-APIC-edge i8042
16: 5315 1 IO-APIC-level aic7xxx, HP J2585B
NMI: 0 0
LOC: 394311 394310
ERR: 0
MIS: 0
--------------------------------------------------
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [BUG] Ricoh Cardbus -> Can't get interrupts
2003-11-24 23:57 [BUG] Ricoh Cardbus -> Can't get interrupts Jean Tourrilhes
@ 2003-11-25 0:16 ` glee
2003-11-25 0:37 ` Jean Tourrilhes
2003-11-25 0:26 ` David Hinds
2003-11-25 2:03 ` Linus Torvalds
2 siblings, 1 reply; 23+ messages in thread
From: glee @ 2003-11-25 0:16 UTC (permalink / raw)
To: jt; +Cc: linux-pcmcia, Linux kernel mailing list, David Hinds, Pavel Roskin
On Mon, Nov 24, 2003 at 03:57:27PM -0800, Jean Tourrilhes wrote:
> Hi,
>
> I have a new Ricoh PCI-Carbus bridge and the kernel
> 2.6.0-test9 doesn't seem to configure it properly (see below).
> With the old Pcmcia package, the i82365 module had a bunch of
> module options to change various irq stuff (see Pcmcia Howto 5.2). A
> quick look in yenta_socket failed to show any module options, which
> seems odd.
> What is the correct way to workaround this stuff ?
>
I have one of these cards. In 2.4.x I used pci=biosirq to get around
it. (BTW, this will oops with a 2.2 kernel, just for the record).
- g.
--
geoff.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [BUG] Ricoh Cardbus -> Can't get interrupts
2003-11-24 23:57 [BUG] Ricoh Cardbus -> Can't get interrupts Jean Tourrilhes
2003-11-25 0:16 ` glee
@ 2003-11-25 0:26 ` David Hinds
2003-11-25 0:49 ` Jean Tourrilhes
2003-11-25 2:03 ` Linus Torvalds
2 siblings, 1 reply; 23+ messages in thread
From: David Hinds @ 2003-11-25 0:26 UTC (permalink / raw)
To: jt; +Cc: linux-pcmcia, Linux kernel mailing list, David Hinds
On Mon, Nov 24, 2003 at 03:57:27PM -0800, Jean Tourrilhes wrote:
> Hi,
>
> I have a new Ricoh PCI-Carbus bridge and the kernel
> 2.6.0-test9 doesn't seem to configure it properly (see below).
> With the old Pcmcia package, the i82365 module had a bunch of
> module options to change various irq stuff (see Pcmcia Howto 5.2). A
> quick look in yenta_socket failed to show any module options, which
> seems odd.
> What is the correct way to workaround this stuff ?
Does this system do ACPI? Do you have that configured in your kernel?
The yenta module doesn't have any options for overriding interrupt
settings. It relies on the PCI subsystem has to do the right thing.
-- Dave
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [BUG] Ricoh Cardbus -> Can't get interrupts
2003-11-25 0:16 ` glee
@ 2003-11-25 0:37 ` Jean Tourrilhes
0 siblings, 0 replies; 23+ messages in thread
From: Jean Tourrilhes @ 2003-11-25 0:37 UTC (permalink / raw)
To: glee; +Cc: linux-pcmcia, Linux kernel mailing list
On Tue, Nov 25, 2003 at 08:16:09AM +0800, glee@gnupilgrims.org wrote:
> On Mon, Nov 24, 2003 at 03:57:27PM -0800, Jean Tourrilhes wrote:
> > Hi,
> >
> > I have a new Ricoh PCI-Carbus bridge and the kernel
> > 2.6.0-test9 doesn't seem to configure it properly (see below).
> > With the old Pcmcia package, the i82365 module had a bunch of
> > module options to change various irq stuff (see Pcmcia Howto 5.2). A
> > quick look in yenta_socket failed to show any module options, which
> > seems odd.
> > What is the correct way to workaround this stuff ?
> >
>
>
> I have one of these cards. In 2.4.x I used pci=biosirq to get around
> it. (BTW, this will oops with a 2.2 kernel, just for the record).
>
> - g.
That's a trick I didn't know about. I tried it, but it doesn't
work (same problem). That doesn't surprise me because the BIOS doesn't
know about this add-on card.
> geoff.
Jean
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [BUG] Ricoh Cardbus -> Can't get interrupts
2003-11-25 0:26 ` David Hinds
@ 2003-11-25 0:49 ` Jean Tourrilhes
2003-11-25 2:06 ` Linus Torvalds
0 siblings, 1 reply; 23+ messages in thread
From: Jean Tourrilhes @ 2003-11-25 0:49 UTC (permalink / raw)
To: David Hinds; +Cc: linux-pcmcia, Linux kernel mailing list
On Mon, Nov 24, 2003 at 04:26:28PM -0800, David Hinds wrote:
> On Mon, Nov 24, 2003 at 03:57:27PM -0800, Jean Tourrilhes wrote:
> > Hi,
> >
> > I have a new Ricoh PCI-Carbus bridge and the kernel
> > 2.6.0-test9 doesn't seem to configure it properly (see below).
> > With the old Pcmcia package, the i82365 module had a bunch of
> > module options to change various irq stuff (see Pcmcia Howto 5.2). A
> > quick look in yenta_socket failed to show any module options, which
> > seems odd.
> > What is the correct way to workaround this stuff ?
>
> Does this system do ACPI?
This is a box from 1998, and the manual doesn't mention
anything about ACPI. I highly doubt it would support ACPI, but how do
I check that ?
> Do you have that configured in your kernel?
Could try.
> The yenta module doesn't have any options for overriding interrupt
> settings. It relies on the PCI subsystem has to do the right thing.
Which in this case failed. I think all I need is to configure
cp_pci_irq to the proper value.
> -- Dave
Jean
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [BUG] Ricoh Cardbus -> Can't get interrupts
2003-11-24 23:57 [BUG] Ricoh Cardbus -> Can't get interrupts Jean Tourrilhes
2003-11-25 0:16 ` glee
2003-11-25 0:26 ` David Hinds
@ 2003-11-25 2:03 ` Linus Torvalds
2003-11-25 2:24 ` Linus Torvalds
2 siblings, 1 reply; 23+ messages in thread
From: Linus Torvalds @ 2003-11-25 2:03 UTC (permalink / raw)
To: jt; +Cc: linux-pcmcia, Linux kernel mailing list, David Hinds, Pavel Roskin
On Mon, 24 Nov 2003, Jean Tourrilhes wrote:
>
> I have a new Ricoh PCI-Carbus bridge and the kernel
> 2.6.0-test9 doesn't seem to configure it properly (see below).
Have you tried with ACPI? And conversely, if you're already using ACPI for
PCI irq routing, have you tried with "pci=noacpi"?
Basically, it looks like there is no irq routing information for the chip.
Which is deadly for any PCI device - we can figure out pretty much
everything else, but not the irq.
We don't ever try to autoprobe for PCI interrupts, because it's fragile
and tends to cause lockups on any hardware where the irq is shared with
something else. So PCI devices require irq routing information somewhere
(usually PIRQ table in the BIOS or the ACPI tables).
Linus
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [BUG] Ricoh Cardbus -> Can't get interrupts
2003-11-25 0:49 ` Jean Tourrilhes
@ 2003-11-25 2:06 ` Linus Torvalds
2003-11-25 2:33 ` Jean Tourrilhes
0 siblings, 1 reply; 23+ messages in thread
From: Linus Torvalds @ 2003-11-25 2:06 UTC (permalink / raw)
To: jt; +Cc: David Hinds, linux-pcmcia, Linux kernel mailing list
On Mon, 24 Nov 2003, Jean Tourrilhes wrote:
>
> This is a box from 1998, and the manual doesn't mention
> anything about ACPI. I highly doubt it would support ACPI, but how do
> I check that ?
Enable CONFIG_ACPI and CONFIG_ACPI_BOOT.
> Which in this case failed. I think all I need is to configure
> cp_pci_irq to the proper value.
That may work, but it equally well might not. Quite often the irq routing
actually has to physically connect the irq line (well, "physically" in
this case is a matter of reprogramming the proper southbridge registers).
Linus
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [BUG] Ricoh Cardbus -> Can't get interrupts
2003-11-25 2:03 ` Linus Torvalds
@ 2003-11-25 2:24 ` Linus Torvalds
2003-11-25 2:56 ` Jean Tourrilhes
0 siblings, 1 reply; 23+ messages in thread
From: Linus Torvalds @ 2003-11-25 2:24 UTC (permalink / raw)
To: jt; +Cc: linux-pcmcia, Linux kernel mailing list, David Hinds, Pavel Roskin
On Mon, 24 Nov 2003, Linus Torvalds wrote:
>
> We don't ever try to autoprobe for PCI interrupts, because it's fragile
> and tends to cause lockups on any hardware where the irq is shared with
> something else
Side note as way of explanation: autoprobing for ISA interrupts only works
because they are edge-triggered, so even if they are shared - which is
against the ISA spec, but commonly done anyway - the autoprobe would just
fail, not lock up the machine.
PCI interrupts are not only _routinely_ shared (making them fundamentally
harder to probe for), but they are level-triggered, so if you don't shut
them off in the interrupt handler, you end up with a dead machine that
constantly takes interrupts.
These days, our improved irq handler infrastructure could actually pick
out the shared interrupts from the probed ones (now that drivers return a
status word saying whether the irq was for an existing driver or not), so
we could some day allow even PCI drivers to autodetect the irq if
everything else fails.
But it's _very_ rare to see it fail. The 2.4.x cardbus driver does the
same thing, and I don't know of any consistent failure patterns. What kind
of strange machine is this, Jean? Prototype with a broken BIOS?
Linus
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [BUG] Ricoh Cardbus -> Can't get interrupts
2003-11-25 2:06 ` Linus Torvalds
@ 2003-11-25 2:33 ` Jean Tourrilhes
2003-11-25 2:49 ` Linus Torvalds
0 siblings, 1 reply; 23+ messages in thread
From: Jean Tourrilhes @ 2003-11-25 2:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Hinds, linux-pcmcia, Linux kernel mailing list
On Mon, Nov 24, 2003 at 06:06:51PM -0800, Linus Torvalds wrote:
>
> On Mon, 24 Nov 2003, Jean Tourrilhes wrote:
> >
> > This is a box from 1998, and the manual doesn't mention
> > anything about ACPI. I highly doubt it would support ACPI, but how do
> > I check that ?
>
> Enable CONFIG_ACPI and CONFIG_ACPI_BOOT.
----------------------------------------------------
ACPI: Subsystem revision 20031002
ACPI: System description tables not found
ACPI-0084: *** Error: acpi_load_tables: Could not get RSDP, AE_NOT_FOUND
ACPI-0134: *** Error: acpi_load_tables: Could not load tables: AE_NOT_FOUND
ACPI: Unable to load the System Description Tables
----------------------------------------------------
> > Which in this case failed. I think all I need is to configure
> > cp_pci_irq to the proper value.
>
> That may work, but it equally well might not. Quite often the irq routing
> actually has to physically connect the irq line (well, "physically" in
> this case is a matter of reprogramming the proper southbridge registers).
In the case of the old Pcmcia package, there was a bunch of
options to take care of that, such as "cb_pci_irq". I didn't try yet
the old Pcmcia package to check if this option is working, because I
would need to recompile a kernel 2.4.X. But, if the old Pcmcia package
was able to do it, it's not impossible.
> Linus
Currently, I managed to narrow down to :
-------------------------------------------------
PCI: Using IRQ router PIIX [8086/7110] at 0000:00:07.0
PCI: IRQ fixup
querying PCI -> IRQ mapping bus:0, slot:7, pin:3.
pin_2_irq idx:9, apic:0, pin:19.
PCI->APIC IRQ transform: (B0,I7,P3) -> 19
querying PCI -> IRQ mapping bus:0, slot:8, pin:0.
pin_2_irq idx:16, apic:0, pin:16.
PCI->APIC IRQ transform: (B0,I8,P0) -> 16
querying PCI -> IRQ mapping bus:0, slot:17, pin:0.
pin_2_irq idx:19, apic:0, pin:18.
PCI->APIC IRQ transform: (B0,I17,P0) -> 18
querying PCI -> IRQ mapping bus:0, slot:18, pin:0.
pin_2_irq idx:20, apic:0, pin:16.
PCI->APIC IRQ transform: (B0,I18,P0) -> 16
querying PCI -> IRQ mapping bus:0, slot:19, pin:0.
querying PCI -> IRQ mapping bus:1, slot:0, pin:0.
pin_2_irq idx:21, apic:0, pin:18.
PCI->APIC IRQ transform: (B1,I0,P0) -> 18
querying PCI -> IRQ mapping bus:2, slot:4, pin:0.
pin_2_irq idx:17, apic:0, pin:17.
PCI->APIC IRQ transform: (B2,I4,P0) -> 17
querying PCI -> IRQ mapping bus:2, slot:5, pin:0.
pin_2_irq idx:18, apic:0, pin:18.
PCI->APIC IRQ transform: (B2,I5,P0) -> 18
-------------------------------------------------
The Pcmcia bridge is in slot 19.
Thanks a lot !
Jean
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [BUG] Ricoh Cardbus -> Can't get interrupts
2003-11-25 2:33 ` Jean Tourrilhes
@ 2003-11-25 2:49 ` Linus Torvalds
2003-11-25 2:52 ` Linus Torvalds
2003-11-25 3:08 ` Davide Libenzi
0 siblings, 2 replies; 23+ messages in thread
From: Linus Torvalds @ 2003-11-25 2:49 UTC (permalink / raw)
To: jt; +Cc: David Hinds, linux-pcmcia, Linux kernel mailing list
On Mon, 24 Nov 2003, Jean Tourrilhes wrote:
>
> Currently, I managed to narrow down to :
> -------------------------------------------------
> PCI: Using IRQ router PIIX [8086/7110] at 0000:00:07.0
Can you do a "dump_pirq"? (Found on http://www.kernelnewbies.org/scripts/
among other places, maybe there are newer versions, David would know).
Linus
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [BUG] Ricoh Cardbus -> Can't get interrupts
2003-11-25 2:49 ` Linus Torvalds
@ 2003-11-25 2:52 ` Linus Torvalds
2003-11-25 3:11 ` Jean Tourrilhes
2003-11-25 3:08 ` Davide Libenzi
1 sibling, 1 reply; 23+ messages in thread
From: Linus Torvalds @ 2003-11-25 2:52 UTC (permalink / raw)
To: jt; +Cc: David Hinds, linux-pcmcia, Linux kernel mailing list
On Mon, 24 Nov 2003, Linus Torvalds wrote:
>
> Can you do a "dump_pirq"?
Oh, and a "lspci -vvxxx" as root too? Along with info on the machine?
Linus
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [BUG] Ricoh Cardbus -> Can't get interrupts
2003-11-25 2:24 ` Linus Torvalds
@ 2003-11-25 2:56 ` Jean Tourrilhes
2003-11-25 3:03 ` Linus Torvalds
2003-11-25 10:41 ` Jes Sorensen
0 siblings, 2 replies; 23+ messages in thread
From: Jean Tourrilhes @ 2003-11-25 2:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-pcmcia, Linux kernel mailing list, David Hinds
On Mon, Nov 24, 2003 at 06:24:54PM -0800, Linus Torvalds wrote:
>
> But it's _very_ rare to see it fail. The 2.4.x cardbus driver does the
> same thing, and I don't know of any consistent failure patterns. What kind
> of strange machine is this, Jean? Prototype with a broken BIOS?
Standard HP Kayak XU300, standard BIOS. Dual P550.
------------------------------------
00:00.0 Host bridge: Intel Corp. 440BX/ZX - 82443BX/ZX Host bridge (rev 03)
00:01.0 PCI bridge: Intel Corp. 440BX/ZX - 82443BX/ZX AGP bridge (rev 03)
00:07.0 ISA bridge: Intel Corp. 82371AB PIIX4 ISA (rev 02)
00:07.1 IDE interface: Intel Corp. 82371AB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corp. 82371AB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corp. 82371AB PIIX4 ACPI (rev 02)
00:08.0 SCSI storage controller: Adaptec AIC-7880U (rev 01)
00:10.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03)
00:11.0 USB Controller: OPTi Inc. 82C861 (rev 10)
00:12.0 Ethernet controller: Hewlett-Packard Company J2585B
00:13.0 CardBus bridge: Ricoh Co Ltd RL5c475 (rev 80)
01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G100 [Productiva] AGP (rev 01)
02:04.0 SCSI storage controller: LSI Logic / Symbios Logic (formerly NCR) 53c875 (rev 26)
02:05.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 36)
------------------------------------
Don't get me wrong, PCI-CardBus add-on cards seem to always be
a pain, whereas laptop seems to always have the right magic. I already
tried unsuccessfully to add a TI PCI-Pcmcia on another box, and this
was similar, whereas my laptops are always working out of the box.
If you wonder why I'm doing that, well, there is not many SMP
laptops to try wireless driver on ;-)
> Linus
Thanks.
Jean
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [BUG] Ricoh Cardbus -> Can't get interrupts
2003-11-25 2:56 ` Jean Tourrilhes
@ 2003-11-25 3:03 ` Linus Torvalds
2003-11-25 3:38 ` Jean Tourrilhes
2003-11-25 10:41 ` Jes Sorensen
1 sibling, 1 reply; 23+ messages in thread
From: Linus Torvalds @ 2003-11-25 3:03 UTC (permalink / raw)
To: jt; +Cc: linux-pcmcia, Linux kernel mailing list, David Hinds
On Mon, 24 Nov 2003, Jean Tourrilhes wrote:
>
> Don't get me wrong, PCI-CardBus add-on cards seem to always be a
> pain, whereas laptop seems to always have the right magic. I already
> tried unsuccessfully to add a TI PCI-Pcmcia on another box, and this was
> similar, whereas my laptops are always working out of the box.
Hmm.. So this is literally a PCI card you've added?
Try putting it into another slot, if so. It literally looked from your
debug output like it was just that slot that didn't have an irq route for
it.
Linus
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [BUG] Ricoh Cardbus -> Can't get interrupts
2003-11-25 2:49 ` Linus Torvalds
2003-11-25 2:52 ` Linus Torvalds
@ 2003-11-25 3:08 ` Davide Libenzi
2003-11-26 1:59 ` Jean Tourrilhes
2003-11-27 18:56 ` David Hinds
1 sibling, 2 replies; 23+ messages in thread
From: Davide Libenzi @ 2003-11-25 3:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: jt, David Hinds, linux-pcmcia, Linux kernel mailing list
On Mon, 24 Nov 2003, Linus Torvalds wrote:
>
> On Mon, 24 Nov 2003, Jean Tourrilhes wrote:
> >
> > Currently, I managed to narrow down to :
> > -------------------------------------------------
> > PCI: Using IRQ router PIIX [8086/7110] at 0000:00:07.0
>
> Can you do a "dump_pirq"? (Found on http://www.kernelnewbies.org/scripts/
> among other places, maybe there are newer versions, David would know).
I didn't want to post this because I was ashamed of the fix, but w/out
this my orinoco cardbus gets an interrupt one every ten boots. This is
against 2.4.20 ...
- Davide
diff -Nru linux-2.4.20-8ref/drivers/pcmcia/cs.c linux-2.4.20-8custom/drivers/pcmcia/cs.c
--- linux-2.4.20-8ref/drivers/pcmcia/cs.c 2003-05-27 21:30:12.527683232 -0700
+++ linux-2.4.20-8custom/drivers/pcmcia/cs.c 2003-05-27 19:59:55.000000000 -0700
@@ -1859,6 +1859,7 @@
socket_info_t *s;
config_t *c;
int ret = 0, irq = 0;
+ u_int attr;
if (CHECK_HANDLE(handle))
return CS_BAD_HANDLE;
@@ -1902,18 +1903,36 @@
}
#endif
}
- if (ret != 0) return ret;
+ if (ret != 0) {
+ if (!s->cap.pci_irq)
+ return ret;
+ irq = s->cap.pci_irq;
+ }
+ attr = req->Attributes;
if (req->Attributes & IRQ_HANDLE_PRESENT) {
+ int share_irq;
+
+ share_irq = (attr & IRQ_TYPE_DYNAMIC_SHARING) ||
+ (s->functions > 1) ||
+ (irq == s->cap.pci_irq);
+ retry:
if (bus_request_irq(s->cap.bus, irq, req->Handler,
- ((req->Attributes & IRQ_TYPE_DYNAMIC_SHARING) ||
- (s->functions > 1) ||
- (irq == s->cap.pci_irq)) ? SA_SHIRQ : 0,
- handle->dev_info, req->Instance))
- return CS_IN_USE;
+ share_irq ? SA_SHIRQ : 0,
+ handle->dev_info, req->Instance)) {
+ if (!share_irq) {
+ share_irq = 1;
+ goto retry;
+ }
+ return CS_IN_USE;
+ }
+ if (share_irq) {
+ attr &= ~IRQ_TYPE_EXCLUSIVE;
+ attr |= IRQ_TYPE_DYNAMIC_SHARING;
+ }
}
-
- c->irq.Attributes = req->Attributes;
+
+ c->irq.Attributes = attr;
s->irq.AssignedIRQ = req->AssignedIRQ = irq;
s->irq.Config++;
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [BUG] Ricoh Cardbus -> Can't get interrupts
2003-11-25 2:52 ` Linus Torvalds
@ 2003-11-25 3:11 ` Jean Tourrilhes
2003-11-25 3:25 ` Linus Torvalds
0 siblings, 1 reply; 23+ messages in thread
From: Jean Tourrilhes @ 2003-11-25 3:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Hinds, linux-pcmcia, Linux kernel mailing list
On Mon, Nov 24, 2003 at 06:52:39PM -0800, Linus Torvalds wrote:
>
>
> On Mon, 24 Nov 2003, Linus Torvalds wrote:
> >
> > Can you do a "dump_pirq"?
>
> Oh, and a "lspci -vvxxx" as root too? Along with info on the machine?
>
> Linus
Don't waste too much time on that, it might be hopeless. I
personally don't believe that the kernel code will ever get it right,
so I'm really looking at adding some override for this specific
situation.
Jean
---------------------------------------------------------------------
Interrupt routing table found at address 0xfdf30:
Version 1.0, size 0x00b0
Interrupt router is device 00:07.0
PCI exclusive interrupt mask: 0x0000 []
Compatible router: vendor 0x8086 device 0x122e
Device 00:10.0 (slot 1): PCI bridge
INTA: link 0x61, irq mask 0x5af8 [3,4,5,6,7,9,11,12,14]
INTB: link 0x62, irq mask 0x5af8 [3,4,5,6,7,9,11,12,14]
INTC: link 0x63, irq mask 0x5af8 [3,4,5,6,7,9,11,12,14]
INTD: link 0x60, irq mask 0x5af8 [3,4,5,6,7,9,11,12,14]
Device 00:11.0 (slot 2): USB Controller
INTA: link 0x62, irq mask 0x5af8 [3,4,5,6,7,9,11,12,14]
INTB: link 0x63, irq mask 0x5af8 [3,4,5,6,7,9,11,12,14]
INTC: link 0x60, irq mask 0x5af8 [3,4,5,6,7,9,11,12,14]
INTD: link 0x61, irq mask 0x5af8 [3,4,5,6,7,9,11,12,14]
Device 00:12.0 (slot 3): Ethernet controller
INTA: link 0x60, irq mask 0x5af8 [3,4,5,6,7,9,11,12,14]
INTB: link 0x61, irq mask 0x5af8 [3,4,5,6,7,9,11,12,14]
INTC: link 0x62, irq mask 0x5af8 [3,4,5,6,7,9,11,12,14]
INTD: link 0x63, irq mask 0x5af8 [3,4,5,6,7,9,11,12,14]
Device 00:13.0 (slot 4): CardBus bridge
INTA: link 0x61, irq mask 0x5af8 [3,4,5,6,7,9,11,12,14]
INTB: link 0x62, irq mask 0x5af8 [3,4,5,6,7,9,11,12,14]
INTC: link 0x63, irq mask 0x5af8 [3,4,5,6,7,9,11,12,14]
INTD: link 0x60, irq mask 0x5af8 [3,4,5,6,7,9,11,12,14]
Device 00:00.0 (slot 0): Host bridge
Device 00:07.0 (slot 0): ISA bridge
INTA: link 0x60, irq mask 0x5af8 [3,4,5,6,7,9,11,12,14]
INTB: link 0x61, irq mask 0x5af8 [3,4,5,6,7,9,11,12,14]
INTC: link 0x62, irq mask 0x5af8 [3,4,5,6,7,9,11,12,14]
INTD: link 0x63, irq mask 0x5af8 [3,4,5,6,7,9,11,12,14]
Device 00:01.0 (slot 0): PCI bridge
Device 01:00.0 (slot 33): VGA compatible controller
INTA: link 0x62, irq mask 0x5af8 [3,4,5,6,7,9,11,12,14]
INTB: link 0x63, irq mask 0x5af8 [3,4,5,6,7,9,11,12,14]
Device 00:08.0 (slot 0): SCSI storage controller
INTA: link 0x60, irq mask 0x5af8 [3,4,5,6,7,9,11,12,14]
Interrupt router at 00:07.0: Intel 82371AB PIIX4/PIIX4E PCI-to-ISA bridge
PIRQ1 (link 0x60): irq 9
PIRQ2 (link 0x61): irq 9
PIRQ3 (link 0x62): irq 9
PIRQ4 (link 0x63): irq 9
Serial IRQ: [disabled] [quiet] [frame=21] [pulse=4]
Level mask: 0x0200 [9]
---------------------------------------------------------------------
00:00.0 Host bridge: Intel Corp. 440BX/ZX - 82443BX/ZX Host bridge (rev 03)
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: 64
Region 0: Memory at f8000000 (32-bit, prefetchable) [size=64M]
Capabilities: [a0] AGP version 1.0
Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
00: 86 80 90 71 06 01 10 22 03 00 00 06 00 40 00 00
10: 08 00 00 f8 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 8c 01 00 fa 00 00 00 09 03 10 11 00 00 11 11 11
60: 10 10 20 20 20 20 20 20 00 03 68 01 a0 8a 00 00
70: 20 1f 0a 38 22 00 17 00 23 05 94 00 10 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 02 00 00 00 04 61 00 00 00 05 00 00 00 00 00 00
a0: 02 00 10 00 03 02 00 1f 00 00 00 00 00 00 00 00
b0: 00 00 00 00 30 00 00 00 00 00 00 00 20 10 00 00
c0: 00 00 00 00 00 00 00 00 18 0c ff ff 61 00 00 00
d0: 00 00 00 00 00 00 00 80 0c 00 00 00 00 00 00 00
e0: d4 b6 ff e3 91 3e 00 80 2c d3 f7 cf 9d 3e 00 00
f0: 40 01 00 00 00 f8 00 60 20 0f 00 00 00 00 00 00
00:01.0 PCI bridge: Intel Corp. 440BX/ZX - 82443BX/ZX AGP bridge (rev 03) (prog-
if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop- ParErr- Step
ping- SERR- FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
Latency: 128
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
Memory behind bridge: fe000000-febfffff
Prefetchable memory behind bridge: f6000000-f6ffffff
BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B+
00: 86 80 91 71 1f 00 20 02 03 00 04 06 00 80 01 00
10: 00 00 00 00 00 00 00 00 00 01 01 40 f0 00 a0 22
20: 00 fe b0 fe 00 f6 f0 f6 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8c 00
40: 00 00 00 00 00 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: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 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
00:07.0 ISA bridge: Intel Corp. 82371AB PIIX4 ISA (rev 02)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Step
ping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
Latency: 0
00: 86 80 10 71 0f 01 80 02 02 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 4d 00 70 01
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 09 09 09 09 10 00 00 00 00 f2 80 00 00 00 00 00
70: 00 00 00 00 00 00 0c 0c 00 00 00 00 00 00 00 00
80: 00 00 07 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 45 50 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 28 0f 00 00 00 00 00 00
00:07.1 IDE interface: Intel Corp. 82371AB PIIX4 IDE (rev 01) (prog-if 80 [Maste
r])
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
Latency: 64
Region 4: I/O ports at fcd0 [size=16]
00: 86 80 11 71 05 00 80 02 01 80 01 01 00 40 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: d1 fc 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 03 a1 00 00 00 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: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 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 28 0f 00 00 00 00 00 00
00:07.2 USB Controller: Intel Corp. 82371AB PIIX4 USB (rev 01) (prog-if 00 [UHCI
])
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
Interrupt: pin D routed to IRQ 19
Region 4: I/O ports at fce0 [disabled] [size=32]
00: 86 80 12 71 00 00 80 02 01 00 03 0c 00 40 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: e1 fc 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 09 04 00 00
40: 00 00 00 00 00 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: 10 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: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 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 28 0f 00 00 00 00 00 00
00:07.3 Bridge: Intel Corp. 82371AB PIIX4 ACPI (rev 02)
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
Interrupt: pin ? routed to IRQ 9
00: 86 80 13 71 03 00 80 02 02 00 80 06 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 01 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 14 00 00 02 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: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 81 21 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 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 01 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 28 0f 00 00 00 00 00 00
00:08.0 SCSI storage controller: Adaptec AIC-7880U (rev 01)
Subsystem: Adaptec AIC-7880P Ultra/Ultra Wide SCSI Chipset
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Step
ping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
Latency: 64 (2000ns min, 2000ns max), cache line size 08
Interrupt: pin A routed to IRQ 16
Region 0: I/O ports at f800 [disabled] [size=256]
Region 1: Memory at fedff000 (32-bit, non-prefetchable) [size=4K]
Expansion ROM at <unassigned> [disabled] [size=64K]
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot
-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 04 90 78 80 16 00 90 02 01 00 00 01 08 40 00 00
10: 01 f8 00 00 00 f0 df fe 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 04 90 80 78
30: 00 00 00 00 dc 00 00 00 00 00 00 00 09 01 08 08
40: a0 15 00 80 a0 15 00 80 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: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 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 01 00 21 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
00:10.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03) (prog-i
f 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
Latency: 64, cache line size 08
Bus: primary=00, secondary=02, subordinate=02, sec-latency=68
I/O behind bridge: 00007000-00007fff
Memory behind bridge: fdf00000-fdffffff
BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=220mA PME(D0-,D1-,D2-,D3h
ot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Bridge: PM- B3+
00: 11 10 24 00 07 00 90 02 03 00 04 06 08 40 01 00
10: 00 00 00 00 00 00 00 00 00 02 02 44 71 71 80 22
20: f0 fd f0 fd f1 ff 01 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 dc 00 00 00 00 00 00 00 00 00 04 00
40: 00 00 00 02 00 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 3e 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 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 01 00 01 01
e0: 00 00 40 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
00:11.0 USB Controller: OPTi Inc. 82C861 (rev 10) (prog-if 10 [OHCI])
Subsystem: OPTi Inc. 82C861
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr- Step
ping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 18
Region 0: Memory at fedfe000 (32-bit, non-prefetchable) [disabled] [size
=4K]
00: 45 10 61 c8 10 00 80 02 10 10 03 0c 08 40 00 00
10: 00 e0 df fe 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 45 10 61 c8
30: 00 00 00 00 00 00 00 00 00 00 00 00 09 01 00 00
40: 00 00 0f 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 01 26 00 30 33 33 33 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: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 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
00:12.0 Ethernet controller: Hewlett-Packard Company J2585B
Subsystem: Hewlett-Packard Company J2585B DeskDirect 10/100VG NIC
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Step
ping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
Latency: 64 (2000ns min, 8000ns max), cache line size 08
Interrupt: pin A routed to IRQ 16
Region 0: I/O ports at f400 [size=256]
Region 1: Memory at fedfc000 (32-bit, non-prefetchable) [disabled] [size
=8K]
00: 3c 10 31 10 15 00 80 02 00 00 00 02 08 40 00 00
10: 01 f4 00 00 00 c0 df fe 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 41 10
30: 00 00 00 00 00 00 00 00 00 00 00 00 09 01 08 20
40: 08 00 00 00 00 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: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 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
00:13.0 CardBus bridge: Ricoh Co Ltd RL5c475 (rev 80)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
Latency: 168
Interrupt: pin A routed to IRQ 0
Region 0: Memory at 10000000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=00, secondary=03, subordinate=06, sec-latency=176
Memory window 0: 10400000-107ff000 (prefetchable)
Memory window 1: 10800000-10bff000
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
00: 80 11 75 04 07 00 10 02 80 00 07 06 00 a8 02 00
10: 00 00 00 10 dc 00 00 02 00 03 06 b0 00 00 40 10
20: 00 f0 7f 10 00 00 80 10 00 f0 bf 10 00 40 00 00
30: fc 40 00 00 00 44 00 00 fc 44 00 00 00 01 00 05
40: 00 00 00 00 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: 01 00 00 00 00 03 00 00 63 04 63 04 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 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 01 00 0a fe
e0: 00 40 c0 24 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
01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G100 [Productiva] A
GP (rev 01) (prog-if 00 [VGA])
Subsystem: Matrox Graphics, Inc.: Unknown device 2125
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping+ SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
Latency: 64
Interrupt: pin A routed to IRQ 18
Region 0: Memory at f6000000 (32-bit, prefetchable) [size=16M]
Region 1: Memory at febf8000 (32-bit, non-prefetchable) [size=16K]
Region 2: Memory at fe000000 (32-bit, non-prefetchable) [size=8M]
Expansion ROM at <unassigned> [disabled] [size=64K]
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot
-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [f0] AGP version 1.0
Status: RQ=1 SBA+ 64bit- FW- Rate=x1
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
00: 2b 10 01 10 87 00 90 02 01 00 00 03 00 40 00 00
10: 08 00 00 f6 00 80 bf fe 00 00 00 fe 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 2b 10 25 21
30: 00 00 00 00 dc 00 00 00 00 00 00 00 09 01 00 00
40: a9 91 07 40 08 3c 00 00 00 00 59 00 00 00 00 00
50: 07 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: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 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 01 f0 21 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 02 00 10 00 01 02 00 01 00 00 00 00 00 00 00 00
02:04.0 SCSI storage controller: LSI Logic / Symbios Logic (formerly NCR) 53c875
(rev 26)
Subsystem: LSI Logic / Symbios Logic (formerly NCR): Unknown device 1000
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Step
ping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
Latency: 64 (4250ns min, 16000ns max), cache line size 08
Interrupt: pin A routed to IRQ 17
Region 0: I/O ports at 7800 [size=256]
Region 1: Memory at fdfff800 (32-bit, non-prefetchable) [size=256]
Region 2: Memory at fdffe000 (32-bit, non-prefetchable) [size=4K]
Expansion ROM at <unassigned> [disabled] [size=256K]
Capabilities: [40] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot
-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 00 10 0f 00 17 00 10 02 26 00 00 01 08 40 00 00
10: 01 78 00 00 00 f8 ff fd 00 e0 ff fd 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 10 00 10
30: 00 00 00 00 40 00 00 00 00 00 00 00 09 01 11 40
40: 01 00 01 00 00 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: c0 00 00 00 00 00 00 0f 00 00 05 00 80 00 08 02
90: 00 00 00 00 00 ff ff ff 00 f0 31 60 00 00 00 00
a0: 00 00 00 e2 00 00 00 00 00 00 00 00 00 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 81 70 0e 00 00 00 00 f7 00 00 00
d0: 01 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 23 73 50 10 79 cb 2c 1b 06 0b 21 41 7a 1b 66 cb
f0: 75 46 94 3c 9b ff e1 84 02 04 41 0b fa 76 fb f8
02:05.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (
rev 36)
Subsystem: Hewlett-Packard Company Ethernet with LAN remote power Adapte
r
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
Latency: 64 (6000ns min, 6000ns max)
Interrupt: pin A routed to IRQ 18
Region 0: I/O ports at 7ce0 [size=32]
Region 1: Memory at fdfff400 (32-bit, non-prefetchable) [size=32]
Expansion ROM at <unassigned> [disabled] [size=1M]
Capabilities: [40] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=220mA PME(D0+,D1+,D2+,D3h
ot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
00: 22 10 00 20 07 00 90 02 36 00 00 02 00 40 00 00
10: e1 7c 00 00 00 f4 ff fd 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 6e 10
30: 00 00 00 00 40 00 00 00 00 00 00 00 09 01 18 18
40: 01 00 11 ff 00 20 00 14 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: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 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
---------------------------------------------------------------------
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [BUG] Ricoh Cardbus -> Can't get interrupts
2003-11-25 3:11 ` Jean Tourrilhes
@ 2003-11-25 3:25 ` Linus Torvalds
[not found] ` <20031125034815.GC4483@bougret.hpl.hp.com>
0 siblings, 1 reply; 23+ messages in thread
From: Linus Torvalds @ 2003-11-25 3:25 UTC (permalink / raw)
To: jt; +Cc: David Hinds, linux-pcmcia, Linux kernel mailing list
On Mon, 24 Nov 2003, Jean Tourrilhes wrote:
>
> Don't waste too much time on that, it might be hopeless. I
> personally don't believe that the kernel code will ever get it right,
> so I'm really looking at adding some override for this specific
> situation.
The kernel is actually very good at getting the PCI irq's right - if it
doesn't, _no_ PCI card will function right. This is definitely not a
"Cardbus is special" issue - the irq routing tables are used for every
single thing out there.
And in fact your tables seem to have the thing:
> Device 00:13.0 (slot 4): CardBus bridge
> INTA: link 0x61, irq mask 0x5af8 [3,4,5,6,7,9,11,12,14]
> INTB: link 0x62, irq mask 0x5af8 [3,4,5,6,7,9,11,12,14]
> INTC: link 0x63, irq mask 0x5af8 [3,4,5,6,7,9,11,12,14]
> INTD: link 0x60, irq mask 0x5af8 [3,4,5,6,7,9,11,12,14]
Can you enable DEBUG in "arch/i386/pci/pci.h"?
AHH.. I think I know what's up. Your PIRQ table is fine, but your MP table
probably doesn't translate the legacy IRQ into the APIC one.
You may be able to boot a UP kernel properly, but I'm sure that the MP
thing is solvable too. Send the whole dmesg out, with DEBUG enabled both
in pci.h and in "include/asm-i386/apic.h".
Linus
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [BUG] Ricoh Cardbus -> Can't get interrupts
2003-11-25 3:03 ` Linus Torvalds
@ 2003-11-25 3:38 ` Jean Tourrilhes
0 siblings, 0 replies; 23+ messages in thread
From: Jean Tourrilhes @ 2003-11-25 3:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-pcmcia, Linux kernel mailing list, David Hinds
On Mon, Nov 24, 2003 at 07:03:04PM -0800, Linus Torvalds wrote:
>
>
>
> On Mon, 24 Nov 2003, Jean Tourrilhes wrote:
> >
> > Don't get me wrong, PCI-CardBus add-on cards seem to always be a
> > pain, whereas laptop seems to always have the right magic. I already
> > tried unsuccessfully to add a TI PCI-Pcmcia on another box, and this was
> > similar, whereas my laptops are always working out of the box.
>
> Hmm.. So this is literally a PCI card you've added?
Yep. I'm replaing my old ISA->Pcmcia with something that can
support the latest wireless Cardbus cards.
> Try putting it into another slot, if so. It literally looked from your
> debug output like it was just that slot that didn't have an irq route for
> it.
I already did that, because it's in Dave's howto. In the
middle slot (swap with HP100VG Ethernet), it was using pirq 60, which
is the same that is used by aic7xxx. Now, it's back to pirq 61.
> Linus
Jean
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [BUG] Ricoh Cardbus -> Can't get interrupts
2003-11-25 2:56 ` Jean Tourrilhes
2003-11-25 3:03 ` Linus Torvalds
@ 2003-11-25 10:41 ` Jes Sorensen
1 sibling, 0 replies; 23+ messages in thread
From: Jes Sorensen @ 2003-11-25 10:41 UTC (permalink / raw)
To: jt; +Cc: linux-pcmcia, Linux kernel mailing list
>>>>> "Jean" == Jean Tourrilhes <jt@bougret.hpl.hp.com> writes:
Jean> Don't get me wrong, PCI-CardBus add-on cards seem to always be
Jean> a pain, whereas laptop seems to always have the right magic. I
Jean> already tried unsuccessfully to add a TI PCI-Pcmcia on another
Jean> box, and this was similar, whereas my laptops are always working
Jean> out of the box. If you wonder why I'm doing that, well, there
Jean> is not many SMP laptops to try wireless driver on ;-)
Actualy no, Sony laptops are notorious for getting the interrupt logic
wrong with the Ricoh cardbus chips. Without ACPI IRQ routing enabled
you don't see a thing on those laptops.
Cheers,
Jes
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [BUG] Ricoh Cardbus -> Can't get interrupts
[not found] ` <Pine.LNX.4.58.0311242100540.1599@home.osdl.org>
@ 2003-11-26 1:54 ` Jean Tourrilhes
0 siblings, 0 replies; 23+ messages in thread
From: Jean Tourrilhes @ 2003-11-26 1:54 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ingo Molnar, David Hinds, linux-pcmcia, Linux kernel mailing list
On Mon, Nov 24, 2003 at 09:17:21PM -0800, Linus Torvalds wrote:
>
>
> On Mon, 24 Nov 2003, Linus Torvalds wrote:
> >
> > That "Bus 0 IRQ 44" should actually be it: that decodes to bus 0, slot 17,
> > pin 0. Exactly what we want.
>
> Never mind. We didn't want 17, we wanted 19. 17 was the USB thing.
>
> Slot 18 was Ethernet, and slot 19 was your cardbus bridge.
>
> However, you said that it still didn't work when you switched the ethernet
> and cardbus cards around, which actually makes me suspect that slot 19 got
> dynamically turned into _this_ entry by the BIOS:
>
> > Int: type 0, pol 3, trig 3, bus 1, IRQ 00, APIC ID 2, APIC INT 12
Wrong, this is my AGP Matrox card.
The correct answer is that it's nowhere to be found in the
APIC table.
> ie it has noticed that slot 19 contains a PCI->CardBus bridge, and thus
> instead of calling it "bus 0, irq 4c" (which would be slot 19 on bus 0),
> it has the IRQ translation as "bus 1, irq 0" (which is "slot 0 on bus 1").
>
> And indeed, we won't find that for the PCI->Cardbus bridge chip. But it
> kind of makes sense, because the device _behind_ the bridge (which will
> have the same irq) will indeed be "slot 0 on bus 1").
Nope, Bus 1 is the AGP. Bus 2 is a PCI multifunction
card. Carbus cards appear on Bus 3, but I don't think any of the info
from Bus 3 is very useful.
> Just for fun, could you switch the ethernet/cardbus cards around again,
> and see if that "bus 1" line moves up one (current slot 18 aka "irq 48"),
> and the one that is now "bus 1" ends up being "bus 0, IRQ 4C" (ie slot 19
> which now would have the ethernet card instead of a PCI bridge).
I did that, "bus 1" remained the same and the Ethernet was
moved from irq 48 to irq 4C.
> Ingo, any ideas on how to handle this sanely?
>
> Jean - you could just _force_ the match, by special-casing it, and seeing
> it it works. We actaully already try the _other_ way in
>
> arch/i386/pci/irq.c: pcibios_fixup_irqs()
>
> if we don't find a translation, we try to find a translation through the
> _parent_ infromation, but we never think to ask "oh, if we are a bridge,
> maybe we should ask the child".
I tried that. But, the list of childs is empty. Well, I guess
that when next point to the list head, it's empty ;-)
Note that I tried that without any CardBus device in the
slot. Maybe if there was a CardBus card in it, we may get one
child. But, I don't want to depend on that.
> Linus
The fix is simple. We just need a "manual override". It's
basically impossible for the kernel to find the right answer without
some outside help. This was the conclusion that David Hinds reached
with the Pcmcia package (see Pcmcia Howto 5.2).
The patch below just does that. I tried this patch with a 16
bits Pcmcia card (ISA irq) and a 32 bits Carbus card (PCI irq), and
both work fine (I just need the magic sequence "manual_pci_irq=0,19,17").
You may no like this kind of ugly patch, but it brings feature
parity with respect to the old Pcmcia package.
Anyway, thanks greatly for the help, you lead me in the right
direction and I now have a workable solution.
Have fun...
Jean
-------------------------------------------------------------
diff -u -p linux/arch/i386/pci/irq.j1.c linux/arch/i386/pci/irq.c
--- linux/arch/i386/pci/irq.j1.c Tue Nov 25 10:36:45 2003
+++ linux/arch/i386/pci/irq.c Tue Nov 25 17:35:44 2003
@@ -693,6 +693,43 @@ static int pcibios_lookup_irq(struct pci
return 1;
}
+#define MAX_MIRQS 4
+int manual_irq_entries[MAX_MIRQS][3]; /* bus/slot/irq */
+int manual_irqs_enabled; /* = 0 */
+
+static int __init manual_irq_setup(char *str)
+{
+ int i, max;
+ int ints[(MAX_MIRQS*3)+1];
+
+ get_options(str, ARRAY_SIZE(ints), ints);
+
+ for (i = 0; i < MAX_MIRQS; i++)
+ manual_irq_entries[i][0] = -1;
+
+ manual_irqs_enabled = 1;
+
+ max = MAX_MIRQS * 3;
+ if (ints[0] < max)
+ max = ints[0];
+ max = max / 3;
+
+ for (i = 0; i < max; i++) {
+ /* Fill our mapping table */
+ manual_irq_entries[i][0] = ints[(3*i) + 1];
+ manual_irq_entries[i][1] = ints[(3*i) + 2];
+ manual_irq_entries[i][2] = ints[(3*i) + 3];
+
+ printk(KERN_DEBUG "Manual PCI %d:%d -> IRQ %d\n",
+ manual_irq_entries[i][0],
+ manual_irq_entries[i][1],
+ manual_irq_entries[i][2]);
+ }
+ return 1;
+}
+
+__setup("manual_pci_irq=", manual_irq_setup);
+
static void __init pcibios_fixup_irqs(void)
{
struct pci_dev *dev = NULL;
@@ -757,6 +794,30 @@ static void __init pcibios_fixup_irqs(vo
*/
if (pin && !dev->irq)
pcibios_lookup_irq(dev, 0);
+
+ /*
+ * Manual fixups. Use at your own risks. Jean II
+ * This assume that the PCI IRQ routing is done right,
+ * and it's just the BIOS that ignore the card. If you
+ * need to also fixup the PCI IRQ routing, you will
+ * probably need to use the "pirq=" option.
+ * I use this hack to get a PCI-CardBus add-on adapter
+ * to be recognised on my destktop.
+ * Jean II
+ */
+ if (manual_irqs_enabled) {
+ int i;
+ for(i = 0; i < MAX_MIRQS; i++)
+ if ((dev->bus->number ==
+ manual_irq_entries[i][0])
+ && (PCI_SLOT(dev->devfn) ==
+ manual_irq_entries[i][1])) {
+ printk(KERN_INFO "PCI->APIC IRQ manual fixup: (B%d,I%d) -> %d\n",
+ dev->bus->number, PCI_SLOT(dev->devfn), manual_irq_entries[i][2]);
+ dev->irq = manual_irq_entries[i][2];
+ pci_write_config_byte(dev, PCI_INTERRUPT_LINE, manual_irq_entries[i][2]);
+ }
+ }
}
}
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [BUG] Ricoh Cardbus -> Can't get interrupts
2003-11-25 3:08 ` Davide Libenzi
@ 2003-11-26 1:59 ` Jean Tourrilhes
2003-11-26 2:17 ` Davide Libenzi
2003-11-27 18:56 ` David Hinds
1 sibling, 1 reply; 23+ messages in thread
From: Jean Tourrilhes @ 2003-11-26 1:59 UTC (permalink / raw)
To: Davide Libenzi; +Cc: linux-pcmcia, Linux kernel mailing list
On Mon, Nov 24, 2003 at 07:08:26PM -0800, Davide Libenzi wrote:
> On Mon, 24 Nov 2003, Linus Torvalds wrote:
>
> >
> > On Mon, 24 Nov 2003, Jean Tourrilhes wrote:
> > >
> > > Currently, I managed to narrow down to :
> > > -------------------------------------------------
> > > PCI: Using IRQ router PIIX [8086/7110] at 0000:00:07.0
> >
> > Can you do a "dump_pirq"? (Found on http://www.kernelnewbies.org/scripts/
> > among other places, maybe there are newer versions, David would know).
>
> I didn't want to post this because I was ashamed of the fix, but w/out
> this my orinoco cardbus gets an interrupt one every ten boots. This is
> against 2.4.20 ...
>
>
>
> - Davide
I believe your issue is unrelated to mine. You seem to have a
problem with interrupt sharing. You may want to try the Pcmcia mailing
list or talk to David.
Note that the usual Orinoco is 16 bits, so not CardBus ;-)
Good luck !
Jean
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [BUG] Ricoh Cardbus -> Can't get interrupts
2003-11-26 1:59 ` Jean Tourrilhes
@ 2003-11-26 2:17 ` Davide Libenzi
0 siblings, 0 replies; 23+ messages in thread
From: Davide Libenzi @ 2003-11-26 2:17 UTC (permalink / raw)
To: jt; +Cc: linux-pcmcia, Linux kernel mailing list
On Tue, 25 Nov 2003, Jean Tourrilhes wrote:
> I believe your issue is unrelated to mine. You seem to have a
> problem with interrupt sharing. You may want to try the Pcmcia mailing
> list or talk to David.
With that patch my card works 100%, while w/out it gets an interrupt at
boot about once every ten. Now that the SiS IRQ routing has been fixed,
that is the only patch required to have my laptop to work correctly. Yes,
it is unrelated to your issue ;)
- Davide
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [BUG] Ricoh Cardbus -> Can't get interrupts
2003-11-25 3:08 ` Davide Libenzi
2003-11-26 1:59 ` Jean Tourrilhes
@ 2003-11-27 18:56 ` David Hinds
2003-11-27 20:15 ` Davide Libenzi
1 sibling, 1 reply; 23+ messages in thread
From: David Hinds @ 2003-11-27 18:56 UTC (permalink / raw)
To: Davide Libenzi; +Cc: Linux kernel mailing list
On Mon, Nov 24, 2003 at 07:08:26PM -0800, Davide Libenzi wrote:
>
> I didn't want to post this because I was ashamed of the fix, but w/out
> this my orinoco cardbus gets an interrupt one every ten boots. This is
> against 2.4.20 ...
>
> - Davide
Your patch seems to do two things:
First, it automatically falls back on using a socket's PCI interrupt
if its ISA interrupts are not available. That part seems ok.
But, it also falls back on sharing an interrupt if a driver requested
an exclusive interrupt and that was not available. This part is not
ok. The original code will share a PCI interrupt automatically, but
will not share an ISA interrupt except under certain circumstances
(for multifunction cards or when the driver specifically requests it).
Sharing ISA interrupts is unsafe and should never be done blindly.
-- Dave
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [BUG] Ricoh Cardbus -> Can't get interrupts
2003-11-27 18:56 ` David Hinds
@ 2003-11-27 20:15 ` Davide Libenzi
0 siblings, 0 replies; 23+ messages in thread
From: Davide Libenzi @ 2003-11-27 20:15 UTC (permalink / raw)
To: David Hinds; +Cc: Linux kernel mailing list
On Thu, 27 Nov 2003, David Hinds wrote:
> On Mon, Nov 24, 2003 at 07:08:26PM -0800, Davide Libenzi wrote:
> >
> > I didn't want to post this because I was ashamed of the fix, but w/out
> > this my orinoco cardbus gets an interrupt one every ten boots. This is
> > against 2.4.20 ...
> >
> > - Davide
>
> Your patch seems to do two things:
>
> First, it automatically falls back on using a socket's PCI interrupt
> if its ISA interrupts are not available. That part seems ok.
>
> But, it also falls back on sharing an interrupt if a driver requested
> an exclusive interrupt and that was not available. This part is not
> ok. The original code will share a PCI interrupt automatically, but
> will not share an ISA interrupt except under certain circumstances
> (for multifunction cards or when the driver specifically requests it).
> Sharing ISA interrupts is unsafe and should never be done blindly.
I told you it was bogus :) Seriously, I don't even know if the "bogus path"
is ever taken, I believe not. I did a quick fix at the beginning and I
did not look at it anymore. I'll give it a shot ...
- Davide
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2003-11-27 20:15 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-11-24 23:57 [BUG] Ricoh Cardbus -> Can't get interrupts Jean Tourrilhes
2003-11-25 0:16 ` glee
2003-11-25 0:37 ` Jean Tourrilhes
2003-11-25 0:26 ` David Hinds
2003-11-25 0:49 ` Jean Tourrilhes
2003-11-25 2:06 ` Linus Torvalds
2003-11-25 2:33 ` Jean Tourrilhes
2003-11-25 2:49 ` Linus Torvalds
2003-11-25 2:52 ` Linus Torvalds
2003-11-25 3:11 ` Jean Tourrilhes
2003-11-25 3:25 ` Linus Torvalds
[not found] ` <20031125034815.GC4483@bougret.hpl.hp.com>
[not found] ` <Pine.LNX.4.58.0311242028220.1599@home.osdl.org>
[not found] ` <Pine.LNX.4.58.0311242100540.1599@home.osdl.org>
2003-11-26 1:54 ` Jean Tourrilhes
2003-11-25 3:08 ` Davide Libenzi
2003-11-26 1:59 ` Jean Tourrilhes
2003-11-26 2:17 ` Davide Libenzi
2003-11-27 18:56 ` David Hinds
2003-11-27 20:15 ` Davide Libenzi
2003-11-25 2:03 ` Linus Torvalds
2003-11-25 2:24 ` Linus Torvalds
2003-11-25 2:56 ` Jean Tourrilhes
2003-11-25 3:03 ` Linus Torvalds
2003-11-25 3:38 ` Jean Tourrilhes
2003-11-25 10:41 ` Jes Sorensen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).