RE: int. assignment on SMP + ServerWorks chipset

RE: int. assignment on SMP + ServerWorks chipset

[Linus Torvalds]

On Mon, 15 Jan 2001, Dunlap, Randy wrote:
> 
> Thanks for looking into this.  I'll be out of touch for
> the rest of this week, but Petr (pem@informatics.muni.cz)
> should be able to test patches that Ingo comes up with.
> 
> > Ok. That means that the problem is that we _should_ look at 
> > the pirq table even if we use the IO-APIC.
> 
> How do we know when to do this?

It's kind of nasty. The IO-APIC detection will disable the pirq table
stuff, see pci-irq.c:

                /* If we're using the I/O APIC, avoid using the PCI IRQ routing table */
                if (io_apic_assign_pci_irqs)
                        pirq_table = NULL;

now, you could just remove that logic, but I suspect that you'd get
problems simply because the interrupt will then get routing information,
but either the IO-APIC re-naming logic has already moved the irq and it
will be routed to the wrong entry.

So what I _think_ is the correct change is to do roughly this in
arch/i386/kernel/pci-irq.c:

 - in pcibios_fixup_irqs(), remove the

	#idef CONFIG_X86_IO_APIC
		...
	#endif

   section entirely.

 - in pcibios_enable_irq(), at the _end_ (after having enabled the irq
   with "pcibios_lookup_irq(dev, 1)", do something like

	irq = IO_APIC_get_PCI_irq_vector(dev->bus->number, PCI_SLOT(dev->devfn), pin);
	if (irq > 0)
		dev->irq = irq;

and add a LOT of debug printk's, and enable DEBUG in pci-i386.h.

It probably won't work on the first try (even if I explained the above
well enough), so send me and Ingo dmesg output, and maybe we'll figure out
something.

And if anybody else understands pirq routing, speak up. It's a black art.

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: int. assignment on SMP + ServerWorks chipset

[Tim Hockin]

> And if anybody else understands pirq routing, speak up. It's a black art.
> 

I have some experience with PIRQ and Serverworks, but I missed the first
bit of this discussion - can someone catch me up?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: int. assignment on SMP + ServerWorks chipset

[Duncan Laurie]

On Tue, 16 Jan 2001, torvalds@transmeta.com wrote:
 >
 > On Mon, 15 Jan 2001, Randy.Dunlap wrote:
 > >
 > > A Linux-USB user (pem@ = Petr) reported that USB (OHCI) wasn't
 > > working on his Intel STL2 system.  This system uses a ServerWorks
 > > chipset, hence the OHCI part.
 >
 > Does it work with "noapic"?
 >
 > It is entirely possible that we should try to use the pirq tables even
 > with the apic, and just make sure that we use the untranslated PCI irq
 > number for testing etc.
 >

This may actually be an MP BIOS bug...

According to the boot log, the MP table I/O Interrupt entry for the
USB controller (PCI device 00:0f:02) is:

   Int: type 0, pol 3, trig 3, bus 0, IRQ 3c, APIC ID 5, APIC INT 00

Which specifies the destination APIC ID 5 (corresponding to the 2nd
IO-APIC, used solely to distribute PCI interrupts) and destination INT
pin 0.  So when the IO-APICs are programmed this IRQ is remapped to:

   PCI->APIC IRQ transform: (B0,I15,P0) -> 16

The problem is the USB Interrupt is internally routed and should use
the ISA IO-APIC for the destination APIC, and a valid ISA IRQ for the
destination INT.  The MP table entry and corresponding IRQ transform
should look something like this:

   [I used INT 09 simply because it wasn't already assigned...]

   Int: type 0, pol 3, trig 3, bus 0, IRQ 3c, APIC ID 4, APIC INT 09
   PCI->APIC IRQ transform: (B0,I15,P0) -> 9

Here's a patch to find & correct this entry on boot.  Its not pretty,
and should ONLY be used to verify this particular fix--any real solution
will have to be done in the BIOS.  (there doesn't seem to be an easy way
to alter specific MP table entries outside of the BIOS, especially if
they happen to exist in write-protected memory regions...)

There may be bogus data in the PIRQ table as well, which is why this
explicitly routes the interrupt & sets the ELCR.  If you enable DEBUG
in pci-i386.h and re-send the dmesg output I will look it over.

    -duncan


--- linux/arch/i386/kernel/mpparse.c	Tue Nov 14 22:25:34 2000
+++ linux~/arch/i386/kernel/mpparse.c	Tue Jan 16 17:11:07 2001
@@ -237,6 +237,37 @@
  	 
	m->mpc_irqtype, m->mpc_irqflag & 3,
  	 
	(m->mpc_irqflag >> 2) & 3, m->mpc_srcbus,
  	 
	m->mpc_srcbusirq, m->mpc_dstapic, m->mpc_dstirq);
+
+ 
if ((m->mpc_irqtype == 0) && ((m->mpc_irqflag & 3) == 3) &&
+ 
     ((m->mpc_irqflag >> 2) == 3) && (m->mpc_srcbus == 0) &&
+ 
     (m->mpc_dstapic == 5) && (m->mpc_srcbusirq == 0x3c))
+ 
{
+ 
	struct mpc_config_intsrc usbint = { MP_INTSRC,
+ 
					    0x00, 0x000f, 0x00,
+ 
					    0x3c, 0x04, 0x09 };
+ 
	unsigned char mask = 1 << (usbint.mpc_dstirq & 7);
+ 
	unsigned int port = 0x4d0 + (usbint.mpc_dstirq >> 3);
+ 
	unsigned char val = inb(port);
+
+ 
	Dprintk("MP BIOS bug, USB INT should use ISA IO-APIC!\n");
+
+ 
	/* fix PIRQ routing entry: index 1 -> dstirq */
+ 
	outb_p(1, 0xc00);
+ 
	outb_p(usbint.mpc_dstirq, 0xc01);
+ 
	if (!(val & mask))
+ 
		outb(val|mask, port);
+
+ 
	/* use modified intsrc struct */
+ 
	mp_irqs[mp_irq_entries] = usbint;
+
+ 
	Dprintk("Int: type %d, pol %d, trig %d, bus %d,"
+ 
		" IRQ %02x, APIC ID %x, APIC INT %02x\n",
+ 
		usbint.mpc_irqtype, usbint.mpc_irqflag & 3,
+ 
		(usbint.mpc_irqflag >> 2) & 3,
+ 
		usbint.mpc_srcbus,  usbint.mpc_srcbusirq,
+ 
		usbint.mpc_dstapic, usbint.mpc_dstirq);
+ 
}
+
  	if (++mp_irq_entries == MAX_IRQ_SOURCES)
  		panic("Max # of irq sources exceeded!!\n");
  }



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: int. assignment on SMP + ServerWorks chipset

[Petr Matula]

[-- Attachment #1: Type: text/plain, Size: 1344 bytes --]

On Mon, Jan 15, 2001 at 08:49:56PM -0800, Linus Torvalds wrote:
> So what I _think_ is the correct change is to do roughly this in
> arch/i386/kernel/pci-irq.c:
> 
>  - in pcibios_fixup_irqs(), remove the
> 
> 	#idef CONFIG_X86_IO_APIC
> 		...
> 	#endif
> 
>    section entirely.
> 
>  - in pcibios_enable_irq(), at the _end_ (after having enabled the irq
>    with "pcibios_lookup_irq(dev, 1)", do something like
> 
> 	irq = IO_APIC_get_PCI_irq_vector(dev->bus->number, PCI_SLOT(dev->devfn), pin);
> 	if (irq > 0)
> 		dev->irq = irq;
> 
> and add a LOT of debug printk's, and enable DEBUG in pci-i386.h.

I did the changes above to 2.4.0 source. 
Kernel with these changes can't detect my SCSI drive. It prints these messages 
in cycle:
SCSI host 0 abort (pid 0) timed out - resetting
SCSI host is being reset for host 0 channel 0
SCSI host 0 channel 0 reset (pid 0) timed out - trying harder
SCSI host is being reset for host 0 channel 0

Same configuration without changes above detects SCSI drive without problem.
For completness, made changes are attached.

Could anybody help?

Petr

---------------------------------------------------------------
 Petr Matula                                    pem@fi.muni.cz
                                    http://www.fi.muni.cz/~pem
---------------------------------------------------------------

[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 2224 bytes --]

--- linux/arch/i386/kernel/pci-irq.c	Thu Jan  4 05:45:26 2001
+++ linux~/arch/i386/kernel/pci-irq.c	Wed Jan 17 17:30:53 2001
@@ -559,40 +559,6 @@
 
 	pci_for_each_dev(dev) {
 		pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &pin);
-#ifdef CONFIG_X86_IO_APIC
-		/*
-		 * Recalculate IRQ numbers if we use the I/O APIC.
-		 */
-		if (io_apic_assign_pci_irqs)
-		{
-			int irq;
-
-			if (pin) {
-				pin--;		/* interrupt pins are numbered starting from 1 */
-				irq = IO_APIC_get_PCI_irq_vector(dev->bus->number, PCI_SLOT(dev->devfn), pin);
-/*
- * Will be removed completely if things work out well with fuzzy parsing
- */
-#if 0
-				if (irq < 0 && dev->bus->parent) { /* go back to the bridge */
-					struct pci_dev * bridge = dev->bus->self;
-
-					pin = (pin + PCI_SLOT(dev->devfn)) % 4;
-					irq = IO_APIC_get_PCI_irq_vector(bridge->bus->number, 
-							PCI_SLOT(bridge->devfn), pin);
-					if (irq >= 0)
-						printk(KERN_WARNING "PCI: using PPB(B%d,I%d,P%d) to get irq %d\n", 
-							bridge->bus->number, PCI_SLOT(bridge->devfn), pin, irq);
-				}
-#endif
-				if (irq >= 0) {
-					printk("PCI->APIC IRQ transform: (B%d,I%d,P%d) -> %d\n",
-						dev->bus->number, PCI_SLOT(dev->devfn), pin, irq);
-					dev->irq = irq;
-				}
-			}
-		}
-#endif
 		/*
 		 * Still no IRQ? Try to lookup one...
 		 */
@@ -612,6 +578,7 @@
 
 void pcibios_enable_irq(struct pci_dev *dev)
 {
+  unsigned int irq;
 	u8 pin;
 	pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &pin);
 	if (pin && !pcibios_lookup_irq(dev, 1) && !dev->irq) {
@@ -624,5 +591,14 @@
 			msg = " Please try using pci=biosirq.";
 		printk(KERN_WARNING "PCI: No IRQ known for interrupt pin %c of device %s.%s\n",
 		       'A' + pin - 1, dev->slot_name, msg);
+
+                printk("Doing: IO_APIC_get_PCI_irq_vector\n");
+                printk("dev->bus->number    : %c\n",dev->bus->number);
+                printk("PCI_SLOT(dev->devfn): %d\n",PCI_SLOT(dev->devfn));
+                printk("pin                 : %hhd\n",pin);
+                irq = IO_APIC_get_PCI_irq_vector(dev->bus->number, PCI_SLOT(dev->devfn), pin);
+                printk("assigned irq        : %u\n",irq);
+                if (irq > 0)
+                  dev->irq = irq;    
 	}
 }

Re: int. assignment on SMP + ServerWorks chipset

[Petr Matula]

On Tue, Jan 16, 2001 at 06:39:46PM -0700, Duncan Laurie wrote:
> Here's a patch to find & correct this entry on boot.  Its not pretty,
> and should ONLY be used to verify this particular fix--any real solution
> will have to be done in the BIOS.  (there doesn't seem to be an easy way
> to alter specific MP table entries outside of the BIOS, especially if
> they happen to exist in write-protected memory regions...)
I wanted to try your patch, but I got:
patch: **** malformed patch at line 12: if ((m->mpc_irqtype == 0) && ((m->mpc_irqflag & 3) == 3) &&

Which kernel is the patch against?

Petr

---------------------------------------------------------------
 Petr Matula                                    pem@fi.muni.cz
                                    http://www.fi.muni.cz/~pem
---------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: int. assignment on SMP + ServerWorks chipset

[Andre Hedrick]

There is a interrupt transaction delay imposed on all interrupts of 600ns
spacing.  It can be turned on/off but this may not help.

Cheers,

On Wed, 17 Jan 2001, Petr Matula wrote:

> On Mon, Jan 15, 2001 at 08:49:56PM -0800, Linus Torvalds wrote:
> > So what I _think_ is the correct change is to do roughly this in
> > arch/i386/kernel/pci-irq.c:
> > 
> >  - in pcibios_fixup_irqs(), remove the
> > 
> > 	#idef CONFIG_X86_IO_APIC
> > 		...
> > 	#endif
> > 
> >    section entirely.
> > 
> >  - in pcibios_enable_irq(), at the _end_ (after having enabled the irq
> >    with "pcibios_lookup_irq(dev, 1)", do something like
> > 
> > 	irq = IO_APIC_get_PCI_irq_vector(dev->bus->number, PCI_SLOT(dev->devfn), pin);
> > 	if (irq > 0)
> > 		dev->irq = irq;
> > 
> > and add a LOT of debug printk's, and enable DEBUG in pci-i386.h.
> 
> I did the changes above to 2.4.0 source. 
> Kernel with these changes can't detect my SCSI drive. It prints these messages 
> in cycle:
> SCSI host 0 abort (pid 0) timed out - resetting
> SCSI host is being reset for host 0 channel 0
> SCSI host 0 channel 0 reset (pid 0) timed out - trying harder
> SCSI host is being reset for host 0 channel 0
> 
> Same configuration without changes above detects SCSI drive without problem.
> For completness, made changes are attached.
> 
> Could anybody help?
> 
> Petr
> 
> ---------------------------------------------------------------
>  Petr Matula                                    pem@fi.muni.cz
>                                     http://www.fi.muni.cz/~pem
> ---------------------------------------------------------------
> 

Andre Hedrick
Linux ATA Development

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: int. assignment on SMP + ServerWorks chipset

[Linus Torvalds]

On Wed, 17 Jan 2001, Petr Matula wrote:
> 
> I did the changes above to 2.4.0 source. 

Did you also remove the two lines that disabled pirq routing if an IO-APIC
was enabled?

> Kernel with these changes can't detect my SCSI drive. It prints these messages 
> in cycle:

Which SCSI adapter is this? It may be that you have one of the drivers
that does not do "pci_enable_dev()" at initialization time..

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: int. assignment on SMP + ServerWorks chipset

[Petr Matula]

On Wed, Jan 17, 2001 at 01:33:42PM -0800, Linus Torvalds wrote:
> Did you also remove the two lines that disabled pirq routing if an IO-APIC
> was enabled?
Yesterday not, today yes. But it's the same.

> > Kernel with these changes can't detect my SCSI drive. It prints these messages 
> > in cycle:
> 
> Which SCSI adapter is this? It may be that you have one of the drivers
> that does not do "pci_enable_dev()" at initialization time..
SCSI storage controller: Adaptec 7899P (rev 0).
  IRQ 16.
  Master Capable.  Latency=72.  Min Gnt=40.Max Lat=25.
  I/O at 0x5800 [0x58ff].
  Non-prefetchable 64 bit memory at 0xfd000000 [0xfd000fff].

Used kernel options:
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_SD_EXTRA_DEVS=40
CONFIG_SCSI_DEBUG_QUEUES=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_AIC7XXX=y
CONFIG_AIC7XXX_CMDS_PER_DEVICE=8
CONFIG_AIC7XXX_RESET_DELAY=10

Petr

---------------------------------------------------------------
 Petr Matula                                    pem@fi.muni.cz
                                    http://www.fi.muni.cz/~pem
---------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: int. assignment on SMP + ServerWorks chipset

[Petr Matula]

[-- Attachment #1: Type: text/plain, Size: 741 bytes --]

On Tue, Jan 16, 2001 at 06:39:46PM -0700, Duncan Laurie wrote:
> There may be bogus data in the PIRQ table as well, which is why this
> explicitly routes the interrupt & sets the ELCR.  If you enable DEBUG
> in pci-i386.h and re-send the dmesg output I will look it over.
I tied your patch. dmesg output si attached.

Without this patch the smp kernel crashes when my USB printer is detected.
With this patch only a USB Hub is detected but not the printer. It seems to
be stable.

Petr

---------------------------------------------------------------
 Petr Matula                                    pem@fi.muni.cz
                                    http://www.fi.muni.cz/~pem
---------------------------------------------------------------

[-- Attachment #2: dmesg --]
[-- Type: text/plain, Size: 7638 bytes --]

    31
 01 003 03  0    0    0   0   0    1    1    39
 02 000 00  1    0    0   0   0    0    0    00
 03 003 03  0    0    0   0   0    1    1    41
 04 003 03  0    0    0   0   0    1    1    49
 05 000 00  1    0    0   0   0    0    0    00
 06 003 03  0    0    0   0   0    1    1    51
 07 003 03  0    0    0   0   0    1    1    59
 08 003 03  0    0    0   0   0    1    1    61
 09 003 03  1    1    0   1   0    1    1    69
 0a 000 00  1    0    0   0   0    0    0    00
 0b 000 00  1    0    0   0   0    0    0    00
 0c 003 03  0    0    0   0   0    1    1    71
 0d 000 00  1    0    0   0   0    0    0    00
 0e 003 03  0    0    0   0   0    1    1    79
 0f 003 03  0    0    0   0   0    1    1    81

IO APIC #5......
.... register #00: 05000000
.......    : physical APIC id: 05
.... register #01: 000F0011
.......     : max redirection entries: 000F
.......     : IO APIC version: 0011
.... register #02: 01000000
.......     : arbitration: 01
.... IRQ redirection table:
 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:   
 00 003 03  1    1    0   1   0    1    1    89
 01 003 03  1    1    0   1   0    1    1    91
 02 003 03  1    1    0   1   0    1    1    99
 03 003 03  1    1    0   1   0    1    1    A1
 04 000 00  1    0    0   0   0    0    0    00
 05 000 00  1    0    0   0   0    0    0    00
 06 000 00  1    0    0   0   0    0    0    00
 07 000 00  1    0    0   0   0    0    0    00
 08 000 00  1    0    0   0   0    0    0    00
 09 000 00  1    0    0   0   0    0    0    00
 0a 000 00  1    0    0   0   0    0    0    00
 0b 000 00  1    0    0   0   0    0    0    00
 0c 000 00  1    0    0   0   0    0    0    00
 0d 000 00  1    0    0   0   0    0    0    00
 0e 000 00  1    0    0   0   0    0    0    00
 0f 000 00  1    0    0   0   0    0    0    00
IRQ to pin mappings:
IRQ1 -> 1
IRQ3 -> 3
IRQ4 -> 4
IRQ6 -> 6
IRQ7 -> 7
IRQ8 -> 8
IRQ9 -> 9
IRQ12 -> 12
IRQ13 -> 13
IRQ14 -> 14
IRQ15 -> 15
IRQ16 -> 0
IRQ17 -> 1
IRQ18 -> 2
IRQ19 -> 3
.................................... done.
calibrating APIC timer ...
..... CPU clock speed is 666.5365 MHz.
..... host bus clock speed is 133.3070 MHz.
cpu: 0, clocks: 1333070, slice: 444356
CPU0<T0:1333056,T1:888688,D:12,S:444356,C:1333070>
cpu: 1, clocks: 1333070, slice: 444356
CPU1<T0:1333056,T1:444336,D:8,S:444356,C:1333070>
checking TSC synchronization across CPUs: passed.
Setting commenced=1, go go go
PCI: BIOS32 Service Directory structure at 0xc00f6b80
PCI: BIOS32 Service Directory entry at 0xfd98e
PCI: BIOS probe returned s=00 hw=01 ver=02.10 l=01
PCI: PCI BIOS revision 2.10 entry at 0xfdb57, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: ServerWorks host bridge: secondary bus 00
PCI: ServerWorks host bridge: secondary bus 01
PCI: Scanning for ghost devices on bus 1
PCI: IDE base address fixup for 00:0f.1
PCI: Scanning for ghost devices on bus 0
PCI: IRQ init
PCI: IRQ fixup
PCI->APIC IRQ transform: (B1,I4,P0) -> 16
PCI->APIC IRQ transform: (B1,I4,P1) -> 17
PCI->APIC IRQ transform: (B0,I2,P0) -> 19
PCI->APIC IRQ transform: (B0,I3,P0) -> 18
PCI->APIC IRQ transform: (B0,I15,P0) -> 9
PCI: Allocating resources
PCI: Resource 00005800-000058ff (f=101, d=0, p=0)
PCI: Resource fd000000-fd000fff (f=204, d=0, p=0)
PCI: Resource 00006000-000060ff (f=101, d=0, p=0)
PCI: Resource fd001000-fd001fff (f=204, d=0, p=0)
PCI: Resource fc000000-fcffffff (f=1208, d=0, p=0)
PCI: Resource 00005000-000050ff (f=101, d=0, p=0)
PCI: Resource fb100000-fb100fff (f=200, d=0, p=0)
PCI: Resource fb101000-fb101fff (f=200, d=0, p=0)
PCI: Resource 00005400-0000543f (f=101, d=0, p=0)
PCI: Resource fb000000-fb0fffff (f=200, d=0, p=0)
PCI: Resource 00005440-0000544f (f=101, d=0, p=0)
PCI: Resource fb102000-fb102fff (f=200, d=0, p=0)
PCI: Sorting device list...
isapnp: Scanning for Pnp cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
DMI 2.3 present.
51 structures occupying 1651 bytes.
DMI table at 0x000EF5A0.
BIOS Vendor: Intel Corporation
BIOS Version: STL20.86B.0017.P01.0011291152
BIOS Release: 11/29/2000
System Vendor: Intel.
Product Name: STL2.
Version  .
Serial Number  .
Board Vendor: Intel.
Board Name: STL2.
Board Version: A28808-301.
Asset Tag: 0000000000000000.
Starting kswapd v1.8
parport0: PC-style at 0x378 [PCSPP(,...)]
pty: 256 Unix98 ptys configured
lp0: using parport0 (polling).
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ServerWorks OSB4: IDE controller on PCI bus 00 dev 79
ServerWorks OSB4: chipset revision 0
ServerWorks OSB4: not 100% native mode: will probe irqs later
hd0: C/H/S=22505/247/228 from BIOS ignored
hda: IBM-DPTA-372730, ATA DISK drive
hdb: NEC CD-ROM DRIVE:282, ATAPI CDROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: 53464320 sectors (27374 MB) w/1961KiB Cache, CHS=53040/16/63
hdb: ATAPI 40X CD-ROM drive, 128kB Cache
Uniform CD-ROM driver Revision: 3.12
Partition check:
 hda: [PTBL] [3328/255/63] hda1
Floppy drive(s): fd0 is 1.44M
FDC 0 is a National Semiconductor PC87306
Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
Real Time Clock Driver v1.10d
eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html
eepro100.c: $Revision: 1.35 $ 2000/11/17 Modified by Andrey V. Savochkin <saw@saw.sw.com.sg> and others
eth0: OEM i82557/i82558 10/100 Ethernet, 00:D0:B7:B6:58:CB, IRQ 18.
  Receiver lock-up bug exists -- enabling work-around.
  Board assembly 000000-000, Physical connectors present: RJ45
  Primary interface chip i82555 PHY #1.
  General self-test: passed.
  Serial sub-system self-test: passed.
  Internal registers self-test: passed.
  ROM checksum self-test: passed (0x04f4518b).
SCSI subsystem driver Revision: 1.00
(scsi0) <Adaptec AIC-7899 Ultra 160/m SCSI host adapter> found at PCI 1/4/0
(scsi0) Wide Channel A, SCSI ID=7, 32/255 SCBs
(scsi0) Downloading sequencer code... 392 instructions downloaded
(scsi1) <Adaptec AIC-7899 Ultra 160/m SCSI host adapter> found at PCI 1/4/1
(scsi1) Wide Channel B, SCSI ID=7, 32/255 SCBs
(scsi1) Downloading sequencer code... 392 instructions downloaded
scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0
       <Adaptec AIC-7899 Ultra 160/m SCSI host adapter>
scsi1 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0
       <Adaptec AIC-7899 Ultra 160/m SCSI host adapter>
(scsi0:0:0:0) Synchronous at 160.0 Mbyte/sec, offset 63.
  Vendor: SEAGATE   Model: ST318404LW        Rev: 0006
  Type:   Direct-Access                      ANSI SCSI revision: 03
Detected scsi disk sda at scsi0, channel 0, id 0, lun 0
SCSI device sda: 35843670 512-byte hdwr sectors (18352 MB)
 sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 >
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb-ohci.c: USB OHCI at membase 0xc8806000, IRQ 9
usb-ohci.c: usb-00:0f.2, PCI device 1166:0220 (ServerWorks)
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 4 ports detected
usb.c: registered new driver usblp
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 8192 bind 8192)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 196k freed
Adding Swap: 489940k swap-space (priority -1)
nfs warning: mount version older than kernel

RE: int. assignment on SMP + ServerWorks chipset

[Dunlap, Randy]

Hi Duncan,

Your temporary patch enables my USB host controller and USB devices
(mouse, hub, and keyboard) to work on an STL2 system.


> From: Duncan Laurie [mailto:duncan@virtualwire.org]
> Sent: Tuesday, January 16, 2001 5:40 PM
> To: linux-kernel@vger.kernel.org
> Cc: randy.dunlap@intel.com; torvalds@transmeta.com;
> pem@informatics.muni.cz
> Subject: RE: int. assignment on SMP + ServerWorks chipset
> 
...
> This may actually be an MP BIOS bug...

Yes, I was also thinking this.  I'll check with some other
people on it tomorrow.

Thanks,
~Randy
_______________________________________________
|randy.dunlap_at_intel.com        503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
-----------------------------------------------

> According to the boot log, the MP table I/O Interrupt entry for the
> USB controller (PCI device 00:0f:02) is:
> 
>    Int: type 0, pol 3, trig 3, bus 0, IRQ 3c, APIC ID 5, APIC INT 00
> 
> Which specifies the destination APIC ID 5 (corresponding to the 2nd
> IO-APIC, used solely to distribute PCI interrupts) and destination INT
> pin 0.  So when the IO-APICs are programmed this IRQ is remapped to:
> 
>    PCI->APIC IRQ transform: (B0,I15,P0) -> 16
> 
> The problem is the USB Interrupt is internally routed and should use
> the ISA IO-APIC for the destination APIC, and a valid ISA IRQ for the
> destination INT.  The MP table entry and corresponding IRQ transform
> should look something like this:
> 
>    [I used INT 09 simply because it wasn't already assigned...]
> 
>    Int: type 0, pol 3, trig 3, bus 0, IRQ 3c, APIC ID 4, APIC INT 09
>    PCI->APIC IRQ transform: (B0,I15,P0) -> 9
> 
> Here's a patch to find & correct this entry on boot.  Its not pretty,
> and should ONLY be used to verify this particular fix--any 
> real solution
> will have to be done in the BIOS.  (there doesn't seem to be 
> an easy way
> to alter specific MP table entries outside of the BIOS, especially if
> they happen to exist in write-protected memory regions...)
> 
> There may be bogus data in the PIRQ table as well, which is why this
> explicitly routes the interrupt & sets the ELCR.  If you enable DEBUG
> in pci-i386.h and re-send the dmesg output I will look it over.
> 
>     -duncan
> 
> 
> --- linux/arch/i386/kernel/mpparse.c	Tue Nov 14 22:25:34 2000
> +++ linux~/arch/i386/kernel/mpparse.c	Tue Jan 16 17:11:07 2001
> @@ -237,6 +237,37 @@
>   	 
> 	m->mpc_irqtype, m->mpc_irqflag & 3,
>   	 
> 	(m->mpc_irqflag >> 2) & 3, m->mpc_srcbus,
>   	 
> 	m->mpc_srcbusirq, m->mpc_dstapic, m->mpc_dstirq);
> +
> + 
> if ((m->mpc_irqtype == 0) && ((m->mpc_irqflag & 3) == 3) &&
> + 
>      ((m->mpc_irqflag >> 2) == 3) && (m->mpc_srcbus == 0) &&
> + 
>      (m->mpc_dstapic == 5) && (m->mpc_srcbusirq == 0x3c))
> + 
> {
> + 
> 	struct mpc_config_intsrc usbint = { MP_INTSRC,
> + 
> 					    0x00, 0x000f, 0x00,
> + 
> 					    0x3c, 0x04, 0x09 };
> + 
> 	unsigned char mask = 1 << (usbint.mpc_dstirq & 7);
> + 
> 	unsigned int port = 0x4d0 + (usbint.mpc_dstirq >> 3);
> + 
> 	unsigned char val = inb(port);
> +
> + 
> 	Dprintk("MP BIOS bug, USB INT should use ISA IO-APIC!\n");
> +
> + 
> 	/* fix PIRQ routing entry: index 1 -> dstirq */
> + 
> 	outb_p(1, 0xc00);
> + 
> 	outb_p(usbint.mpc_dstirq, 0xc01);
> + 
> 	if (!(val & mask))
> + 
> 		outb(val|mask, port);
> +
> + 
> 	/* use modified intsrc struct */
> + 
> 	mp_irqs[mp_irq_entries] = usbint;
> +
> + 
> 	Dprintk("Int: type %d, pol %d, trig %d, bus %d,"
> + 
> 		" IRQ %02x, APIC ID %x, APIC INT %02x\n",
> + 
> 		usbint.mpc_irqtype, usbint.mpc_irqflag & 3,
> + 
> 		(usbint.mpc_irqflag >> 2) & 3,
> + 
> 		usbint.mpc_srcbus,  usbint.mpc_srcbusirq,
> + 
> 		usbint.mpc_dstapic, usbint.mpc_dstirq);
> + 
> }
> +
>   	if (++mp_irq_entries == MAX_IRQ_SOURCES)
>   		panic("Max # of irq sources exceeded!!\n");
>   }

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: int. assignment on SMP + ServerWorks chipset

[Duncan Laurie]

On Thu, 18 Jan 2001, Petr Matula wrote:
| On Tue, Jan 16, 2001 at 06:39:46PM -0700, Duncan Laurie wrote:
| > There may be bogus data in the PIRQ table as well, which is why this
| > explicitly routes the interrupt & sets the ELCR.  If you enable DEBUG
| > in pci-i386.h and re-send the dmesg output I will look it over.
| I tied your patch. dmesg output si attached.
| 
| Without this patch the smp kernel crashes when my USB printer is detected.
| With this patch only a USB Hub is detected but not the printer. It seems to
| be stable.
| 
| Petr
|

Hi Petr,

I didn't consider that your hardware would have subtle differences
than Mr. Dunlap's Intel SBT2 board, but these could have made the
hard-coded values in the patch invalid.  So instead try the attached
patch, and this time you'll need to plug in some values into a boot
parameter to override the mptable entry.

This "mpint=" parameter allows you to alter a specific (IO)INT mptable
entry destination APIC and INT.  It takes four arguments, the first
two for looking up the entry to change in the current mptable by APIC
and INT, and the second two are for the new APIC and INT values to use.
(I also have an expanded version that allows more detailed
modifications but the number of arguments gets out of hand very fast)

The values to use depend on what your system is configured to use
for the USB interrupt.  This can be obtained by using the dump_pirq
utility from the recent pcmcia utilities.  (I made some modifications
to recognize the ServerWorks IRQ router which is available from
ftp://virtualwire.org/dump_pirq)

The output you are looking for should look something like this:

Device 00:0f.0 (slot 0): ISA bridge
    INTA: link 0x01, irq mask 0x0400 [10]

The USB device is actually function 2, but uses INTA#.  The irq
mask value should give you the new INT value to put in the
mptable.  The old INT value can be read from the dmesg output
or by compiling and running mptable, which I also made available
at ftp://virtualwire.org/mptable.c.  (it appears to be '0' on your
hardware as well as Mr. Dunlap's)  The destination APIC should just
be the ID of the first IO-APIC in the system, in this case 4.

So based on the example above, you would add "mpint=5,0,4,10" to
the boot parameters.  One caveat, this doesn't actually change the
mptable as it is stored in memory so if you use the mptable program
to view it you will still see the original values.

Good luck, and feel free to send me the output from "dump_pirq"
and "mptable" if it doesn't work..

  -duncan


--- linux.orig/arch/i386/kernel/io_apic.c	Sun Oct  1 20:35:15 2000
+++ linux-2.4.1-pre8/arch/i386/kernel/io_apic.c	Sun Jan 21 21:08:42 2001
@@ -229,6 +229,43 @@
 }
 
 /*
+ * "mpint=oldAPIC,oldINT,newAPIC,newINT"
+ */
+static int __init ioapic_mpint_setup(char *str)
+{
+       struct mpc_config_intsrc newint;
+       int ints[5];
+       int i;
+
+       get_options(str, ARRAY_SIZE(ints), ints);
+       if (ints[0] < 4)
+               return 0;
+
+       for (i = 0; i < nr_ioapics; i++)
+               if (mp_ioapics[i].mpc_apicid == ints[1])
+                       ints[1] = i;
+
+       i = find_irq_entry(ints[1], ints[2], mp_INT);
+       if (i < 0)
+               return 0;
+
+       printk(KERN_DEBUG "(old) mpint: APIC ID %1d, APIC INT %02x\n",
+              mp_irqs[i].mpc_dstapic, mp_irqs[i].mpc_dstirq);
+
+       memcpy(&newint, &mp_irqs[i], sizeof(newint));
+       newint.mpc_dstapic = ints[3];
+       newint.mpc_dstirq = ints[4];
+       mp_irqs[i] = newint;
+
+       printk(KERN_DEBUG "(new) mpint: APIC ID %1d, APIC INT %02x\n",
+              mp_irqs[i].mpc_dstapic, mp_irqs[i].mpc_dstirq);
+
+       return 1;
+}
+
+__setup("mpint=", ioapic_mpint_setup);
+
+/*
  * Find the pin to which IRQ[irq] (ISA) is connected
  */
 static int __init find_isa_irq_pin(int irq, int type)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: int. assignment on SMP + ServerWorks chipset

[Dunlap, Randy]

Hi Duncan,

> From: Duncan Laurie [mailto:duncan@virtualwire.org]
> 
> Hi Petr,
> 
> I didn't consider that your hardware would have subtle differences
> than Mr. Dunlap's Intel SBT2 board, but these could have made the
> hard-coded values in the patch invalid.  So instead try the attached
> patch, and this time you'll need to plug in some values into a boot
> parameter to override the mptable entry.

Petr's listing of /proc/interrupts also did not use IRQ 9
(from Jan. 11, 2001 email).

I expect that our STL2 boards are very much alike, with possible
differences in processor speed and RAM size.  I also have
disabled SCSI in BIOS SETUP while Petr has not, since he is using
SCSI disks and I am using IDE.

> This "mpint=" parameter allows you to alter a specific (IO)INT mptable
> entry destination APIC and INT.  It takes four arguments, the first
> two for looking up the entry to change in the current mptable by APIC
> and INT, and the second two are for the new APIC and INT 
> values to use.
> (I also have an expanded version that allows more detailed
> modifications but the number of arguments gets out of hand very fast)
> 
> The values to use depend on what your system is configured to use
> for the USB interrupt.  This can be obtained by using the dump_pirq
> utility from the recent pcmcia utilities.  (I made some modifications
> to recognize the ServerWorks IRQ router which is available from
> ftp://virtualwire.org/dump_pirq)

Thanks for that.

> The output you are looking for should look something like this:
> 
> Device 00:0f.0 (slot 0): ISA bridge
>     INTA: link 0x01, irq mask 0x0400 [10]
> 
> The USB device is actually function 2, but uses INTA#.  The irq
> mask value should give you the new INT value to put in the
> mptable.  The old INT value can be read from the dmesg output
> or by compiling and running mptable, which I also made available
> at ftp://virtualwire.org/mptable.c.  (it appears to be '0' on your
> hardware as well as Mr. Dunlap's)  The destination APIC should just
> be the ID of the first IO-APIC in the system, in this case 4.

I had also ported that program a few months ago, but was
advised against it since the BIOS can build the MP table
dynamically, and it could be from a skeleton table in EEPROM,
so the mptable program could find and print the wrong version
of the table.  Just a small warning.

> So based on the example above, you would add "mpint=5,0,4,10" to
> the boot parameters.  One caveat, this doesn't actually change the
> mptable as it is stored in memory so if you use the mptable program
> to view it you will still see the original values.

Duncan, do you still think that there might be a BIOS MP table
error?  Also, what would you propose as a long-term solution to
this problem?  This patch or something else?

Thanks,
~Randy


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: int. assignment on SMP + ServerWorks chipset

[Randy.Dunlap]

Duncan Laurie wrote:
> 
...
> 
> The output you are looking for should look something like this:
> 
> Device 00:0f.0 (slot 0): ISA bridge
>     INTA: link 0x01, irq mask 0x0400 [10]
... 
> Good luck, and feel free to send me the output from "dump_pirq"
> and "mptable" if it doesn't work..

Hi Duncan,

(BTW, it's an STL2 board, not SBT2.  And it's Randy, not Mr. Dunlap. :)

Here's my output from dump_pirq.  Is the PCI router info unique
enough so that you'll need to debug it instead of me doing so?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[root@localhost src]# ./dump_pirq
 
Interrupt routing table found at address 0xfdf10
  Version 1.0, 0 bytes
  Interrupt router is device ff:1f.7
  PCI exclusive interrupt mask: 0x0000 []
 
Interrupt router at ff:1f.7:
Could not read router info from /proc/bus/pci/ff/1f.7.
[root@localhost src]#
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Thanks,
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: int. assignment on SMP + ServerWorks chipset

[Duncan Laurie]

On Mon, 22 Jan 2001, Randy.Dunlap wrote:
| 
| (BTW, it's an STL2 board, not SBT2.  And it's Randy, not Mr. Dunlap. :)
| 

Hi Randy,
(I'll spare you the formality ;)

Oops, I knew it was an STL2, but somehow couldn't get it right in the
message..  It looks like they both use ServerWorks LE chipsets, do you
know if the SBT2 has the same problem?

I did see that your BIOS is build 16 (STL20.86B.0016.P01.0010111108)
while Petr has build 17 (STL20.86B.0017.P01.0011291152) which also
appears to be the latest release.  Not that it has any affect on this
particular problem, but it might explain why the patch worked for you
and not him.

I looked at the Technical Product Specification,
(ftp://download.intel.com/support/motherboards/server/stl2/stl2_tps.pdf)
and it appears that they have released BIOS updates to fix Errata 
regarding Linux boot problems, so chances are good that it may be fixed
by a future update.  Until then, the 'mpint' parameter patch seems
pretty harmless, yet flexible enough to handle subtle differences
in hardware and configuration.

However, there are also hooks for a 16KB region of user-supplied BIOS
code that could possibly be used to fixup the mptable.  The info and
instructions are in section 4.5.2.1 of the tech spec for anyone with
hardware brave enough to give it a shot...  (this looks like a pretty
cool feature, hopefully other MB vendors will take the hint)

|
| Here's my output from dump_pirq.  Is the PCI router info unique
| enough so that you'll need to debug it instead of me doing so?
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| [root@localhost src]# ./dump_pirq
|  
| Interrupt routing table found at address 0xfdf10
|   Version 1.0, 0 bytes
|   Interrupt router is device ff:1f.7
|   PCI exclusive interrupt mask: 0x0000 []
|  
| Interrupt router at ff:1f.7:
| Could not read router info from /proc/bus/pci/ff/1f.7.
| [root@localhost src]#
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|

Hrm, this certainly doesn't look right.  You mentioned in a previous
message that changing the OS type from PnP-aware did not have any
effect, but if disabled the BIOS might not be creating the PIRQ
tables.  Hopefully it will still take care of the IRQ routing, which
means you should be able to read the value directly.  (it better or
USB shouldn't work in UP!)  Try the following program:

-----------------------------------------------
/* compile with gcc -O */
#include <stdio.h>
#include <stdlib.h>
#include <sys/io.h>

int main(void) {
    if (iopl(3) < 0) exit(1);
    outb(1, 0xc00);
    printf("USB Interrupt: %d\n", inb(0xc01));
    exit(0);
}
-----------------------------------------------

Good luck,
  -duncan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: int. assignment on SMP + ServerWorks chipset

[Dunlap, Randy]

> From: Duncan Laurie [mailto:duncan@virtualwire.org]
> 
> On Mon, 22 Jan 2001, Randy.Dunlap wrote:
> 
> Hi Randy,
> 
> Oops, I knew it was an STL2, but somehow couldn't get it right in the
> message..  It looks like they both use ServerWorks LE chipsets, do you
> know if the SBT2 has the same problem?

I don't have an SBT2 to test, but it's likely that they share
this problem.  The only difference in them is supposed to be
SBT2 using bigger/faster processors.

> I did see that your BIOS is build 16 (STL20.86B.0016.P01.0010111108)
> while Petr has build 17 (STL20.86B.0017.P01.0011291152) which also
> appears to be the latest release.  Not that it has any affect on this
> particular problem, but it might explain why the patch worked for you
> and not him.
> 
> I looked at the Technical Product Specification,
> (ftp://download.intel.com/support/motherboards/server/stl2/stl
2_tps.pdf)
> and it appears that they have released BIOS updates to fix Errata 
> regarding Linux boot problems, so chances are good that it may be fixed
> by a future update.  Until then, the 'mpint' parameter patch seems
> pretty harmless, yet flexible enough to handle subtle differences
> in hardware and configuration.

Yes, I tested that one as well and it works for me, using
"mpint=5,0,4,9".
But now I need to upgrade the BIOS and I can't run phlash.exe!!!

...

| Here's my output from dump_pirq.  Is the PCI router info unique
| enough so that you'll need to debug it instead of me doing so?
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| [root@localhost src]# ./dump_pirq
|  
| Interrupt routing table found at address 0xfdf10
|   Version 1.0, 0 bytes
|   Interrupt router is device ff:1f.7
|   PCI exclusive interrupt mask: 0x0000 []
|  
| Interrupt router at ff:1f.7:
| Could not read router info from /proc/bus/pci/ff/1f.7.
| [root@localhost src]#
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|

> Hrm, this certainly doesn't look right.  You mentioned in a previous
> message that changing the OS type from PnP-aware did not have any
> effect, but if disabled the BIOS might not be creating the PIRQ
> tables.  Hopefully it will still take care of the IRQ routing, which
> means you should be able to read the value directly.  (it better or
> USB shouldn't work in UP!)  Try the following program:

USB works in UP mode (smp kernel, with "nosmp noapic").

dump_pirq in UP mode, PNP OS = Yes or No, gives the same
output as above.  I'd still like to get dump_pirq
working if you have something else that I could try.

-----------------------------------------------
USB Interrupt: 9
-----------------------------------------------

Yes, the BIOS assigns interrupt 9 to USB.  9 is the correct
value as far as the BIOS is concerned.

BTW, where is the <irq_routing_table> structure defined, in what
spec?

~Randy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: int. assignment on SMP + ServerWorks chipset

[Petr Matula]

Hi Duncan and Randy,

I tested Duncan's patch. It works for me with parameters "mpint=5,0,4,9".

On Sun, Jan 21, 2001 at 09:54:23PM -0700, Duncan Laurie wrote:
> The values to use depend on what your system is configured to use
> for the USB interrupt.  This can be obtained by using the dump_pirq
> utility from the recent pcmcia utilities.  (I made some modifications
> to recognize the ServerWorks IRQ router which is available from
> ftp://virtualwire.org/dump_pirq)
dump_pirq gives me the same output like to Randy. I used the small 
program posted by Duncan to find the new USB interrupt.

If I understand it well, it's time to wait for BIOS upgrade and 
meanwhile Duncan's patch must be used, isn't it?

Thank you very much for all your help.

Petr

P.S. I'm sorry for the delay. I couldn't reboot the system because
it was in use by other users of our group.

---------------------------------------------------------------
 Petr Matula                                    pem@fi.muni.cz
                                    http://www.fi.muni.cz/~pem
---------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/