PCI IRQ problems -- update

PCI IRQ problems -- update

[Jim Paris]

This is an update on my laptop's IRQ problem I mentioned back in Oct:
  http://lkml.org/lkml/2004/10/15/20
    
In short, all PCI IRQs are routed via ACPI to PIC IRQ 9.  When the
PIIX IDE device is enabled, it pulls on that interrupt until it gets
disabled ("nobody cared").  ide0 then continues to work on IRQ 14, but
all other devices are broken since IRQ 9 is disabled.

My previous solution was to use Alan Cox's "irqpoll" patch which
allowed the other devices to still function.  That's a hack and I
wanted to find a real way to fix it.

It turns out that IDE is the only device connected to LNKC.  I changed
the ACPI DSDT so that LNKC points to the unused IRQ 5, and all of my
problems magically went away.  This is still a hack, but seems to work.

I'm not sure how to get to the root cause of the problem, though.  For
starters: where _should_ the INTA of the IDE card go, if anywhere?  If
my laptop's IDE is routed to and pulling on IRQ 9, how can it still be
functioning on IRQ 14?  Or, if the routing doesn't matter, is there
anything I can do to prevent it from pulling on 9?

-jim

Re: PCI IRQ problems -- update

[Alan Cox]

On Sad, 2004-12-11 at 17:35, Jim Paris wrote:
> In short, all PCI IRQs are routed via ACPI to PIC IRQ 9.  When the
> PIIX IDE device is enabled, it pulls on that interrupt until it gets
> disabled ("nobody cared").  ide0 then continues to work on IRQ 14, but
> all other devices are broken since IRQ 9 is disabled.

The PIIX should be in legacy mode by default in which case it would be
on
IRQ 14/15 only. Can you post boot messages ?

> I'm not sure how to get to the root cause of the problem, though.  For
> starters: where _should_ the INTA of the IDE card go, if anywhere?  If

Quite possibly nowhere. IDE controllers have two modes one in which they
are normal PCI devices (and use INTA) and one in which they are "legacy"
compatible and use IRQ14/15 directly so they work with pre-PCI operating
systems.

> my laptop's IDE is routed to and pulling on IRQ 9, how can it still be
> functioning on IRQ 14?  Or, if the routing doesn't matter, is there
> anything I can do to prevent it from pulling on 9?

In legacy mode (the mode I would expect at boot) it shouldn't be using
INTA at all.

Re: PCI IRQ problems -- update

[Jim Paris]

> The PIIX should be in legacy mode by default in which case it would be
> on IRQ 14/15 only. Can you post boot messages ?

Sure.  This is with the PIIX interrupt rerouted to IRQ 5:
  https://jim.sh/svn/jim/devl/toughbook/log/irq5
Portions of note:

Linux version 2.6.10-rc3 (jim@hypnosis) (gcc version 3.3.4 (Debian 1:3.3.4-13)) #6 Sat Dec 11 11:33:57 EST 2004
...
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-1 of IDE controller 0000:00:1f.1
...
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH3M: IDE controller at PCI slot 0000:00:1f.1
PCI: Enabling device 0000:00:1f.1 (0005 -> 0007)
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 5
PCI: setting IRQ 5 as level-triggered
ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 5 (level, low) -> IRQ 5
ICH3M: chipset revision 2
ICH3M: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0x1840-0x1847, BIOS settings: hda:DMA, hdb:pio
Probing IDE interface ide0...

> > I'm not sure how to get to the root cause of the problem, though.  For
> > starters: where _should_ the INTA of the IDE card go, if anywhere?  If
> 
> Quite possibly nowhere. IDE controllers have two modes one in which they
> are normal PCI devices (and use INTA) and one in which they are "legacy"
> compatible and use IRQ14/15 directly so they work with pre-PCI operating
> systems.

OK, I see.  Does Linux leave it in legacy mode even when using a
specific driver like piix?  Do you know how I can get more information
on the state of it at boot, to see if BIOS did leave it in legacy
mode? 

-jim

Re: PCI IRQ problems -- update

[Alan Cox]

On Sad, 2004-12-11 at 20:02, Jim Paris wrote:
> OK, I see.  Does Linux leave it in legacy mode even when using a
> specific driver like piix?  Do you know how I can get more information
> on the state of it at boot, to see if BIOS did leave it in legacy
> mode? 

We have to take it as it comes. Vendors sometimes don't even both wiring
INTA so bad things occur if you change the mode of the chip. Plus a lot
of IDE devices are buggy in this area (as you notied with ICH3M).

Re: PCI IRQ problems -- update

[Jim Paris]

> The PIIX should be in legacy mode by default in which case it would be
> on IRQ 14/15 only. Can you post boot messages ?

This is interesting:

$ lspci -x -s 1f.1
0000:00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 02)
00: 86 80 8a 24 07 00 80 02 02 8e 01 01 00 00 00 00
10: f1 01 00 00 f5 03 00 00 01 00 00 00 01 00 00 00
20: 41 18 00 00 00 00 10 e0 00 00 00 00 f7 10 38 83
30: 00 00 00 00 00 00 00 00 00 00 00 00 ff 01 00 00

The ICH3-M datasheet says offset 0x09 is the Programming Interface
register.  Default value is 0x8A (legacy on both), value here is 0x8E
(legacy on primary, native on secondary).  This mixed-mode setting
is noted as a disallowed combination in the datasheet.

So it looks like my BIOS is screwing me.  Where could/should I fix
this up?

-jim

[PATCH] Re: PCI IRQ problems -- update

[Jim Paris]

> The ICH3-M datasheet says offset 0x09 is the Programming Interface
> register.  Default value is 0x8A (legacy on both), value here is 0x8E
> (legacy on primary, native on secondary).  This mixed-mode setting
> is noted as a disallowed combination in the datasheet.
> 
> So it looks like my BIOS is screwing me.  Where could/should I fix
> this up?

I added a quirk for this case.  This is against 2.6.10-rc3, and it
makes all of my problems go away cleanly.  Is this reasonable?

-jim

--- a/drivers/pci/quirks.c	2004-12-10 19:18:50.000000000 -0500
+++ b/drivers/pci/quirks.c	2004-12-11 16:32:41.000000000 -0500
@@ -717,6 +717,26 @@
 }
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_CSB5IDE, quirk_svwks_csb5ide );
 
+/*
+ *	Intel 82801CAM ICH3-M datasheet says IDE modes must be the same
+ */
+static void __init quirk_ide_samemode(struct pci_dev *pdev)
+{
+	u8 prog;
+	pci_read_config_byte(pdev, PCI_CLASS_PROG, &prog);
+	if ( ((prog & 1) && !(prog & 4)) || ((prog & 4) && !(prog & 1)) )
+	{
+		printk(KERN_INFO
+		       "PCI: IDE mode mismatch; forcing legacy mode\n");
+		prog &= ~5;
+		pdev->class &= ~5;
+		pci_write_config_byte(pdev, PCI_CLASS_PROG, prog);
+		/* need to re-assign BARs for compat mode */
+		quirk_ide_bases(pdev);
+	}
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801CA_10, quirk_ide_samemode);
+
 /* This was originally an Alpha specific thing, but it really fits here.
  * The i82375 PCI/EISA bridge appears as non-classified. Fix that.
  */

Re: [PATCH] Re: PCI IRQ problems -- update

[Alan Cox]

On Sad, 2004-12-11 at 22:03, Jim Paris wrote:
> I added a quirk for this case.  This is against 2.6.10-rc3, and it
> makes all of my problems go away cleanly.  Is this reasonable?

I think so. You might want to send a copy to linux-ide@vger.kernel.org
so that Bartlomiej doesn't miss it.

Re: PCI IRQ problems -- update

[Alan Cox]

On Sad, 2004-12-11 at 20:23, Jim Paris wrote:
> The ICH3-M datasheet says offset 0x09 is the Programming Interface
> register.  Default value is 0x8A (legacy on both), value here is 0x8E
> (legacy on primary, native on secondary).  This mixed-mode setting
> is noted as a disallowed combination in the datasheet.
> 
> So it looks like my BIOS is screwing me.  Where could/should I fix
> this up?

A PCI quirk would be the obvious place, or in the ICH driver
(drivers/ide/pci/piix). You might want to print it early in boot and
make sure it was the BIOS not the kernel that did it.