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

> From: Duncan Laurie []
> On Mon, 22 Jan 2001, Randy.Dunlap wrote:
> Hi Randy,
> Oops, I knew it was an STL2, but somehow couldn't get it right in the
> message.. It looks like they both use ServerWorks LE chipsets, do you
> know if the SBT2 has the same problem?

I don't have an SBT2 to test, but it's likely that they share
this problem. The only difference in them is supposed to be
SBT2 using bigger/faster processors.

> I did see that your BIOS is build 16 (STL20.86B.0016.P01.0010111108)
> while Petr has build 17 (STL20.86B.0017.P01.0011291152) which also
> appears to be the latest release. Not that it has any affect on this
> particular problem, but it might explain why the patch worked for you
> and not him.
> I looked at the Technical Product Specification,
> (
> 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
But now I need to upgrade the BIOS and I can't run phlash.exe!!!


| Here's my output from dump_pirq. Is the PCI router info unique
| enough so that you'll need to debug it instead of me doing so?
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| [root@localhost src]# ./dump_pirq
| Interrupt routing table found at address 0xfdf10
| Version 1.0, 0 bytes
| Interrupt router is device ff:1f.7
| PCI exclusive interrupt mask: 0x0000 []
| Interrupt router at ff:1f.7:
| Could not read router info from /proc/bus/pci/ff/1f.7.
| [root@localhost src]#
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

> Hrm, this certainly doesn't look right. You mentioned in a previous
> message that changing the OS type from PnP-aware did not have any
> effect, but if disabled the BIOS might not be creating the PIRQ
> tables. Hopefully it will still take care of the IRQ routing, which
> means you should be able to read the value directly. (it better or
> USB shouldn't work in UP!) Try the following program:

USB works in UP mode (smp kernel, with "nosmp noapic").

dump_pirq in UP mode, PNP OS = Yes or No, gives the same
output as above. I'd still like to get dump_pirq
working if you have something else that I could try.

USB Interrupt: 9

Yes, the BIOS assigns interrupt 9 to USB. 9 is the correct
value as far as the BIOS is concerned.

BTW, where is the <irq_routing_table> structure defined, in what


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:15    [W:0.056 / U:5.364 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site