Date: Tue, 2 Sep 2008 01:16:04 +0200 From: Marius Strobl <marius@alchemy.franken.de> To: "Justin T. Gibbs" <gibbs@scsiguy.com> Cc: gibbs@FreeBSD.org, Gavin Atkinson <gavin@FreeBSD.org>, freebsd-sparc64@FreeBSD.org Subject: Re: HEAD panic with ofw_pcibus.c 1.21 on Blade 100 Message-ID: <20080901231604.GH80839@alchemy.franken.de> In-Reply-To: <48BC5AF8.50600@scsiguy.com> References: <1220278827.70590.35.camel@buffy.york.ac.uk> <20080901161850.GE80839@alchemy.franken.de> <1220287328.70590.46.camel@buffy.york.ac.uk> <20080901194726.GG80839@alchemy.franken.de> <48BC5AF8.50600@scsiguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080901231604.GH80839>