My box:
Tyan-IIID Dual 166MMX
PCI Network Card on 0x0C (left slot)
PCI Video (diamond) on 0x09 (middle)
PCI Buslogic BT-958 (right) on 0x0b
2.1.80+tcp patch+PGCC 1.01
Kernel did not correctly figure out stuff by itself (guessd that, was
perpaired)
passed pirq=0x0c,0x09,0x0b as per Linus' directons (is scanpci supposed to
have a -f? Mind doesnt Xfree 3.3.1, the newwst right?)
At boot I see the preety table and such..
It says that I've got a broken bios and it's working around it (and shows
my manually entered mapping)
THEN is shows the mapping the bios suggests
PIRQ0 redirected to 20, suspect
PIRQ1 redirected to 19, suspect
PIRQ2 redirected to 18, suspect
[perhaps the bios settings are overwriting the manual settings?]
Then the buslog driver try to go, but fails:
While configuring Buslogic PCI host adaptor
Bus 0 Device 20 I/O address 0x6200 pciaddress 0x0 (yes.. 0x0)
HOST ADAPTOR INTERUPT TEST FAILED
Then it can't find the root device, and stops..
On Tue, 20 Jan 1998, Linus Torvalds wrote:
>
>
> I just put out Linux-2.1.80 on ftp.kernel.org. This release should fix a
> few networking problems, and the NFS client is hopefully fairly stable
> even under the kinds of loads we have here at Transmeta.
>
> The 2.1.80 release also contains some initial ARM support, and contains
> Ingo Molnar's better SMP interrupt handling.
>
> NOTE NOTE NOTE! The new SMP interrupt handling is currently not very good
> at autodetection. This can be a real problem, and _before_ booting the
> 2.1.80 kernel as compiled for SMP you should probably try to figure out a
> possible IRQ override line by doing:
>
> echo -n pirq=; echo `scanpci -f | grep T_L | cut -c56-` | sed 's/ /,/g'
>
> which for me gives
>
> pirq=0x00,0x09,0x0b
>
> Then, after doing the above, boot into 2.1.80 and see if it finds your PCI
> interrupt lines correctly. If it does, everything is fine. If it doesn't,
> you need to boot with the pirq setting that you determined earlier, by
> giving the kernel the pirq data at the bootup command line or by using the
> LILO "append=" feature (or similar features in other bootloaders).
>
> We'll certainly have to make the autodetection work reliably, but in the
> meantime the command-line approach at least gives us a way to test the
> more fundamental impacts of better interrupt handling.
>
> Linus
>