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/
