[lkml]   [2001]   [Jan]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: int. assignment on SMP + ServerWorks chipset
Hi Duncan,

> From: Duncan Laurie []
> 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

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 (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?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:13    [W:0.034 / U:3.872 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site