HEAD panic with ofw_pcibus.c 1.21 on Blade 100

[Marius Strobl]

On Mon, Sep 01, 2008 at 03:13:28PM -0600, Justin T. Gibbs wrote:
> The driver isn't buggy.  This particular hardware can only be identified
> via an invasive probe.

I meant misbehaving from the sparc64 point of view, not
buggy in general.

> 
> Just returning early is a hack.  How does Sparc64 exclude other, non-PNP
> devices from its probe sequence?

It doesn't and invasive probes involving I/O or memory space
accesses aren't supported. There are no ISA-slots in sparc64
machines and in general one can only regard the devices in
the device tree provided by the firmware (which one can
consider as PNP-mechanism) as existent and functional so
supporting invasive probes or non-PNP devices doesn't make
much sense from a hardware point of view.

> They all have #ifdefs in them for
> Sparc64 and every other platform that gives a bus fault for touching
> a location that is unmapped?

The other ISA drivers doing invasive probes aren't relevant
for sparc64 as they either simply can't show up in a sparc64
machine. Some drivers with multiple bus front-ends also aren't
in GENERIC as their core f.e. doesn't use bus_dma(9) or isn't
endian-clean and therefore doesn't work on sparc64 so far
anyway. It's just ahc(4) which is in GENERIC as the PCI
variant works but brings in an invasive probe.

> There's no generic method for trapping
> bus faults during invasive probes so that panics are avoided?

There's a procedure for configuration space accesses but
for I/O and memory space one can really just ignore bus
faults if there's a way to tell the host-to-foo driver
that they are expected f.e. due to invasive probing.

> There's
> no generic method for flagging probes as invasive so that they
> simply are never called (or compiled in) on platforms that cannot
> tolerate them?

Not as far as I can tell.

> 
> If you absolutely have to remove the probe just for sparc, it would
> be better to figure out how to just avoid compiling in that probe
> (config spec change "optional isa_nonpnp", or similar?).

What I think would be the right thing to do in this regard
is splitting the ISA drivers and bus front-ends into bus
front-ends for LPC or LPC-like busses (i.e. on-board PNP-
only/firmware enumerated) and real ISA busses (non-PNP,
cards in real slots). Though as far as I know there's more
to LPC in terms of ACPI-probing which I currently don't
understand and I admit that I'm reluctant to doing that
much work just to keep a single bus front-end from probing...

Marius