public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* RE: int. assignment on SMP + ServerWorks chipset
@ 2001-01-17  1:39 Duncan Laurie
  2001-01-17 17:53 ` Petr Matula
  2001-01-18  8:58 ` Petr Matula
  0 siblings, 2 replies; 16+ messages in thread
From: Duncan Laurie @ 2001-01-17  1:39 UTC (permalink / raw)
  To: linux-kernel; +Cc: randy.dunlap, torvalds, pem

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/

^ permalink raw reply	[flat|nested] 16+ messages in thread
* RE: int. assignment on SMP + ServerWorks chipset
@ 2001-01-23  1:52 Dunlap, Randy
  0 siblings, 0 replies; 16+ messages in thread
From: Dunlap, Randy @ 2001-01-23  1:52 UTC (permalink / raw)
  To: 'Duncan Laurie'; +Cc: Petr Matula, linux-kernel


> 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/

^ permalink raw reply	[flat|nested] 16+ messages in thread
* RE: int. assignment on SMP + ServerWorks chipset
@ 2001-01-22 17:01 Dunlap, Randy
  0 siblings, 0 replies; 16+ messages in thread
From: Dunlap, Randy @ 2001-01-22 17:01 UTC (permalink / raw)
  To: 'Duncan Laurie', Petr Matula; +Cc: linux-kernel

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/

^ permalink raw reply	[flat|nested] 16+ messages in thread
* RE: int. assignment on SMP + ServerWorks chipset
@ 2001-01-22  0:26 Dunlap, Randy
  0 siblings, 0 replies; 16+ messages in thread
From: Dunlap, Randy @ 2001-01-22  0:26 UTC (permalink / raw)
  To: 'Duncan Laurie', linux-kernel; +Cc: torvalds, pem

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/

^ permalink raw reply	[flat|nested] 16+ messages in thread
[parent not found: <D5E932F578EBD111AC3F00A0C96B1E6F07DBDF24@orsmsx31.jf.intel.com>]
end of thread, other threads:[~2001-01-24  8:44 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-01-17  1:39 int. assignment on SMP + ServerWorks chipset Duncan Laurie
2001-01-17 17:53 ` Petr Matula
2001-01-18  8:58 ` Petr Matula
2001-01-22  4:54   ` Duncan Laurie
2001-01-22 22:05     ` Randy.Dunlap
2001-01-22 23:46       ` Duncan Laurie
2001-01-24  8:43     ` Petr Matula
  -- strict thread matches above, loose matches on Subject: below --
2001-01-23  1:52 Dunlap, Randy
2001-01-22 17:01 Dunlap, Randy
2001-01-22  0:26 Dunlap, Randy
     [not found] <D5E932F578EBD111AC3F00A0C96B1E6F07DBDF24@orsmsx31.jf.intel.com>
2001-01-16  4:49 ` Linus Torvalds
2001-01-16  5:35   ` Tim Hockin
2001-01-17 17:50   ` Petr Matula
2001-01-17 18:11     ` Andre Hedrick
2001-01-17 21:33     ` Linus Torvalds
2001-01-18  7:43       ` Petr Matula

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox