int. assignment on SMP + ServerWorks chipset
Quoted 7 lines · On Tue, 16 Jan 2001, [email protected] wrote:
Quoted 4 lines · Randy.Dunlap
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.
Quoted 6 lines
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
arch/i386/kernel/mpparse.c +0 -0
@@ -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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 5 lines · Duncan Laurie
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 [email protected]
http://www.fi.muni.cz/~pem
---------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 3 lines · Duncan Laurie
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.hand 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 [email protected]
http://www.fi.muni.cz/~pem --------------------------------------------------------------- 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 fixupPCI->APIC IRQ transform: (B1,I4,P0) -> 16PCI->APIC IRQ transform: (B1,I4,P1) -> 17PCI->APIC IRQ transform: (B0,I2,P0) -> 19PCI->APIC IRQ transform: (B0,I3,P0) -> 18PCI->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.htmleepro100.c: $Revision: 1.35 $ 2000/11/17 Modified by Andrey V. Savochkin <[email protected]> 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 usbdevfsusb.c: registered new driver hubusb-ohci.c: USB OHCI at membase 0xc8806000, IRQ 9usb-ohci.c: usb-00:0f.2, PCI device 1166:0220 (ServerWorks)usb.c: new USB bus registered, assigned bus number 1hub.c: USB hub foundhub.c: 4 ports detectedusb.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
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
arch/i386/kernel/io_apic.c +37 -0
@@ -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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 1 line · Duncan Laurie
...
Quoted 5 lines
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]
...
Quoted 2 lines
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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/
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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Hi Duncan and Randy,
I tested Duncan's patch. It works for me with parameters "mpint=5,0,4,9".
Quoted 5 lines · Duncan Laurie
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_pirqutility 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 [email protected]
http://www.fi.muni.cz/~pem
---------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/