Messages in this thread | | | From | "Dunlap, Randy" <> | Subject | RE: int. assignment on SMP + ServerWorks chipset | Date | Mon, 22 Jan 2001 17:52:23 -0800 |
| |
> From: Duncan Laurie [mailto:duncan@virtualwire.org] > > 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, > (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: 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 spec?
~Randy
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |