> It's a wee bit less brain-damaged than crackly sound cards with
> only 24 out of 32 address lines wired.
True ;-)
> At any rate, the issue is in all
> likelihood that that support file is being circumvented.
Those functions that need alteration aren't "switched" between
different arches like that. The patch just hardcodes arch specific
crud into general code, and would never be submittable. There was
some clean way to fix it suggested, but I forget what it was at
the moment ... will work it out again with Greg.
> It's obviously
> getting wrong information when it asks to read from a given bus as
> there are no PCI devices off of node 0 (as this hasn't worked in a long
> time), so perhaps a disassembly or other fishing around will reveal
> whose pci config space accessors are actually being called here.
Does it really matter who's registers we're reading when using
pointers we know are corrupted garbage? Far better to fix the
pointers than fuss around working what they ended up pointing
at this spin of the bottle ...
IIRC, it's getting mislead by the PCI-PCI bridge itself, which is
always returning the local bus number of 3 no matter which quad
it's on. It's not the read operations themselves that are borked
(this time), it's the data that the bridge is returning is being
"misinterpreted".
M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 07 2002 - 22:00:20 EST