Re: 2.4.0-test12: SiS pirq handling..

[Linus Torvalds]

On Mon, 29 Jan 2001, Aaron Tiensivu wrote:
> 
> Problem still exists, diffed to last kernel:

Yes. But everything works for you, no? Including USB?

The problem is that you have this routing table entry:

	00:01 slot=00 0:62/1eb8 1:00/0000 2:00/0000 3:00/0000

which is really for the USB chip (PCI id 00:01.2), and which the PCI code
_does_ find for the USB chip. So it should set up the routing happily, and
everything should be ok.

The trouble is that the routing table entry _also_ gets a false match to
the IDE chip (PCI id 00:01.1), which doesn't get routed through the above
AT ALL. So every time it sees either the USB or the IDE device, it will
notice that there is a bogus routing table entry associated with the IDE
device.

As a result, 2.4.1-pre12 will now complain (twice - once when it tries to
find the IDE irq route, the other time when it tries to find the USB irq
route) that there seems to be a routing table conflict for device 00:01.1.

In reality, the IDE device is routed with a fixed routing by the BIOS, and
the BIOS has also set the device "irqline" config space entry to point to
the proper table. So the IDE controller should work fine - and in fact it
is this second piece of information from the PCI config space that makes
Linux notice the conflict in the first place.

So it does appear that everything is fine. Linux should be doing exactly
the right thing on your board now, and USB _should_ work for you. The
complaints are real, and more importantly I now think we understand _why_
they happen.

It probably all used to work for you before, but we didn't really know
_why_. Which is almost as nasty a situation as not working at all.

Basically, the way your chipset is laid out PCI-wise, they are
subfunctions of the same device (subfunction 1 is IDE, subfunction 2 is
USB. Because of this they share an irq routing entry, and if they were to
NOT clash they should have been given separate "irq pin" numbers in their
config space. So a _good_ routing entry might have looked like

	00:01 slot=00 0:fe/4000 1:62/1eb8 2:00/0000 3:00/0000

where the IDE device has "irqpin=1" and the USB device has "irqpin=2", and
USB points to link 62, while IDE points to link fe (ie "hardcode to 14").

But the BIOS didn't do this properly, and as a result we get these pirq
clashes. Which are real, but should be harmless.

Now, will the two people in the world who know the pirq black magic now
stand up and confirm or deride my interpretation?

		Linus