Re: int. assignment on SMP + ServerWorks chipset
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[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/
Re: int. assignment on SMP + ServerWorks chipset
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[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/
RE: int. assignment on SMP + ServerWorks chipset
> From: Duncan Laurie [mailto:[EMAIL PROTECTED]] > > 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.001008) > 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: 0x [] | | 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 structure defined, in what spec? ~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/
Re: int. assignment on SMP + ServerWorks chipset
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.001008)
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: 0x []
|
| 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
#include
#include
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/
Re: int. assignment on SMP + ServerWorks chipset
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: 0x [] 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/
RE: int. assignment on SMP + ServerWorks chipset
Hi Duncan, > From: Duncan Laurie [mailto:[EMAIL PROTECTED]] > > 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: int. assignment on SMP + ServerWorks chipset
Hi Duncan, From: Duncan Laurie [mailto:[EMAIL PROTECTED]] 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: int. assignment on SMP + ServerWorks chipset
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: 0x [] 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/
Re: int. assignment on SMP + ServerWorks chipset
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.001008)
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: 0x []
|
| 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/
Re: int. assignment on SMP + ServerWorks chipset
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(, _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/
RE: int. assignment on SMP + ServerWorks chipset
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:[EMAIL PROTECTED]]
> Sent: Tuesday, January 16, 2001 5:40 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> 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.com503-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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
RE: int. assignment on SMP + ServerWorks chipset
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:[EMAIL PROTECTED]]
Sent: Tuesday, January 16, 2001 5:40 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
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.com503-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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: int. assignment on SMP + ServerWorks chipset
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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: int. assignment on SMP + ServerWorks chipset
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[EMAIL PROTECTED] http://www.fi.muni.cz/~pem --- 31 01 003 03 000 0 01139 02 000 00 100 0 00000 03 003 03 000 0 01141 04 003 03 000 0 01149 05 000 00 100 0 00000 06 003 03 000 0 01151 07 003 03 000 0 01159 08 003 03 000 0 01161 09 003 03 110 1 01169 0a 000 00 100 0 00000 0b 000 00 100 0 00000 0c 003 03 000 0 01171 0d 000 00 100 0 00000 0e 003 03 000 0 01179 0f 003 03 000 0 01181 IO APIC #5.. register #00: 0500 ...: physical APIC id: 05 register #01: 000F0011 ... : max redirection entries: 000F ... : IO APIC version: 0011 register #02: 0100 ... : arbitration: 01 IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 003 03 110 1 01189 01 003 03 110 1 01191 02 003 03 110 1 01199 03 003 03 110 1 011A1 04 000 00 100 0 00000 05 000 00 100 0 00000 06 000 00 100 0 00000 07 000 00 100 0 00000 08 000 00 100 0 00000 09 000 00 100 0 00000 0a 000 00 100 0 00000 0b 000 00 100 0 00000 0c 000 00 100 0 00000 0d 000 00 100 0 00000 0e 000 00 100 0 00000 0f 000 00 100 0 00000 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 cpu: 1, clocks: 1333070, slice: 444356 CPU1 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 5800-58ff (f=101, d=0, p=0) PCI: Resource fd00-fd000fff (f=204, d=0, p=0) PCI: Resource 6000-60ff (f=101, d=0, p=0) PCI: Resource fd001000-fd001fff (f=204, d=0, p=0) PCI: Resource fc00-fcff (f=1208, d=0, p=0) PCI: Resource 5000-50ff (f=101, d=0, p=0) PCI: Resource fb10-fb100fff (f=200, d=0, p=0) PCI: Resource fb101000-fb101fff (f=200, d=0, p=0) PCI: Resource 5400-543f (f=101, d=0, p=0) PCI: Resource fb00-fb0f (f=200, d=0, p=0) PCI: Resource 5440-544f (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: . Starting kswapd v1.8 parport0: PC-style at 0x378
Re: int. assignment on SMP + ServerWorks chipset
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[EMAIL PROTECTED] http://www.fi.muni.cz/~pem --- 31 01 003 03 000 0 01139 02 000 00 100 0 00000 03 003 03 000 0 01141 04 003 03 000 0 01149 05 000 00 100 0 00000 06 003 03 000 0 01151 07 003 03 000 0 01159 08 003 03 000 0 01161 09 003 03 110 1 01169 0a 000 00 100 0 00000 0b 000 00 100 0 00000 0c 003 03 000 0 01171 0d 000 00 100 0 00000 0e 003 03 000 0 01179 0f 003 03 000 0 01181 IO APIC #5.. register #00: 0500 ...: physical APIC id: 05 register #01: 000F0011 ... : max redirection entries: 000F ... : IO APIC version: 0011 register #02: 0100 ... : arbitration: 01 IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 003 03 110 1 01189 01 003 03 110 1 01191 02 003 03 110 1 01199 03 003 03 110 1 011A1 04 000 00 100 0 00000 05 000 00 100 0 00000 06 000 00 100 0 00000 07 000 00 100 0 00000 08 000 00 100 0 00000 09 000 00 100 0 00000 0a 000 00 100 0 00000 0b 000 00 100 0 00000 0c 000 00 100 0 00000 0d 000 00 100 0 00000 0e 000 00 100 0 00000 0f 000 00 100 0 00000 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 CPU0T0:1333056,T1:888688,D:12,S:444356,C:1333070 cpu: 1, clocks: 1333070, slice: 444356 CPU1T0: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 5800-58ff (f=101, d=0, p=0) PCI: Resource fd00-fd000fff (f=204, d=0, p=0) PCI: Resource 6000-60ff (f=101, d=0, p=0) PCI: Resource fd001000-fd001fff (f=204, d=0, p=0) PCI: Resource fc00-fcff (f=1208, d=0, p=0) PCI: Resource 5000-50ff (f=101, d=0, p=0) PCI: Resource fb10-fb100fff (f=200, d=0, p=0) PCI: Resource fb101000-fb101fff (f=200, d=0, p=0) PCI: Resource 5400-543f (f=101, d=0, p=0) PCI: Resource fb00-fb0f (f=200, d=0, p=0) PCI: Resource 5440-544f (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:
Re: int. assignment on SMP + ServerWorks chipset
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 0xfd00 [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[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/
Re: int. assignment on SMP + ServerWorks chipset
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: int. assignment on SMP + ServerWorks chipset
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[EMAIL PROTECTED] > 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: int. assignment on SMP + ServerWorks chipset
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[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/
Re: int. assignment on SMP + ServerWorks chipset
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[EMAIL PROTECTED]
http://www.fi.muni.cz/~pem
---
--- linux/arch/i386/kernel/pci-irq.cThu 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, );
-#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, );
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
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[EMAIL PROTECTED]
http://www.fi.muni.cz/~pem
---
--- linux/arch/i386/kernel/pci-irq.cThu 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
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[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/
Re: int. assignment on SMP + ServerWorks chipset
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[EMAIL PROTECTED] 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: int. assignment on SMP + ServerWorks chipset
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: int. assignment on SMP + ServerWorks chipset
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 0xfd00 [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[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/
RE: int. assignment on SMP + ServerWorks chipset
On Tue, 16 Jan 2001, [EMAIL PROTECTED] 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.cTue 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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
RE: int. assignment on SMP + ServerWorks chipset
On Tue, 16 Jan 2001, [EMAIL PROTECTED] 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.cTue 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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: int. assignment on SMP + ServerWorks chipset
> 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: int. assignment on SMP + ServerWorks chipset
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 ([EMAIL PROTECTED]) > 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: int. assignment on SMP + ServerWorks chipset
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 ([EMAIL PROTECTED]) 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: int. assignment on SMP + ServerWorks chipset
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
