In message: <20040101155100.GF11668_at_cicely12.cicely.de> Bernd Walter <ticso_at_cicely12.cicely.de> writes: : On Wed, Dec 31, 2003 at 10:22:30PM -0700, M. Warner Losh wrote: : > In message: <20040101013224.GC11668_at_cicely12.cicely.de> : > Bernd Walter <ticso_at_cicely12.cicely.de> writes: : > : The board is an old Asus T2P4 with 3 bridged cards and $PIR table. : > : All IRQs behind bridges get bogusly IRQ4 instead of the right ones. : > : Is this only a problem on some boards or do we have a general irq : > : routing problem with bridges? : > : > It is a problem with some bridges and PCI BIOS interrupt routing. : : The intline registers are correct - that's what used to run since years. : What has the kind of bridge to do with it? just what the code does :-) : > : At least I know that bridge irq routing works fine on alpha. : > : $PIR table claims to only have 7 entries - does this make sense for : > : a 4 slot board? : > : > Maybe you could post it. It makes sense if you have on-board PCI : > devices. : : Is it shown with a boot -v or how can I get it? : The board has 4 slots and the usual bunch of southbridge devices. boot -v with and without your patch. : > : If this is a board specific problem - can we at least add a loader : > : variable to disable routing, so I don't have to patch the source on : > : every update and can run a standart boot disk again? : > : > Did it used to work when we were re-routing all the time? It would be : > easy to add this as an option, but maybe understanding your setup : > might help a little to make our routing code a little smarter. : : It never worked if FreeBSD decides which int to use. : I have to disable routing in pci.c to get back to intline entries. OK. : What do you mean with "when we were re-routing all the time"? : If I don't get it wrong we are re-routing all the time and : take the result if it's a valid int. s/were/weren't/ and it will make sense. We used to not route all the time, and now we do. WarnerReceived on Thu Jan 01 2004 - 08:13:01 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:36 UTC