Well, then is there any way for any user to control how the
interrupts are dished out (assigned), say for example by moving cards
around in the slots? Can the kernel be patched to "hardwire" the
assignment of interrupts? (I'm talking a customs patch that only I
apply, not a general patch for everyone).

Or is this entirely an initialization problem deep in the kernel
code? Is there any timeline for fixing it or is it a part of the
longer-term PCI cleanup I've read about?

It's probably a problem retreiving interrupt infos from the MacOS
"hacked" device-tree in the kernel on oldworld. That's why I need your
device tree.

Timeline and Linux are non-matching concepts ;) It will be fixed once
someone figures out exactly where the error is.

I am relatively limited in how I can move cards around as my earlier
post reporting my slot summary will attest to,

<http://lists.linuxppc.org/listarcs/linuxppc-dev/200011/msg00187.html>,


In addition, yesterday I speculated that the dual IRQ 23 might help
explain why I was having 2.2.18preX boot problems with the aic7xxx.

Well, it can. I didn't notice that in the reports you sent me earlier, sorry.

This can't really be the case because one of the slot summary tests
was to remove the USB card (and all others). There was no difference,
so my boot issue remains a separate one with its odd workaround.

Well, maybe the adaptec interrupt is wrong, not the USB one ?

The bug you were having with the Adaptec sounds really weird, according
to the tests you did, it looks like for some reason, either the kernel
is beeing damaged or something in the kernel is trashing memory.
(There's no other explanation for the crash inside __ioremap).

It could be a bootloader problem, did you try with different versions of
BootX & miBoot ?

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/