From owner-freebsd-sparc64@FreeBSD.ORG Mon Sep 1 23:16:07 2008 Return-Path: Delivered-To: freebsd-sparc64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14EE21065680; Mon, 1 Sep 2008 23:16:07 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 78BA68FC0C; Mon, 1 Sep 2008 23:16:06 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id m81NG5X6019875; Tue, 2 Sep 2008 01:16:05 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id m81NG58n019874; Tue, 2 Sep 2008 01:16:05 +0200 (CEST) (envelope-from marius) Date: Tue, 2 Sep 2008 01:16:04 +0200 From: Marius Strobl To: "Justin T. Gibbs" Message-ID: <20080901231604.GH80839@alchemy.franken.de> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48BC5AF8.50600@scsiguy.com> User-Agent: Mutt/1.4.2.3i Cc: gibbs@FreeBSD.org, Gavin Atkinson , freebsd-sparc64@FreeBSD.org Subject: Re: HEAD panic with ofw_pcibus.c 1.21 on Blade 100 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 23:16:07 -0000 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