HEAD panic with ofw_pcibus.c 1.21 on Blade 100

Justin T. Gibbs gibbs at scsiguy.com
Mon Sep 1 21:38:06 UTC 2008

The driver isn't buggy.  This particular hardware can only be identified
via an invasive probe.

Just returning early is a hack.  How does Sparc64 exclude other, non-PNP
devices from its probe sequence?  They all have #ifdefs in them for
Sparc64 and every other platform that gives a bus fault for touching
a location that is unmapped?  There's no generic method for trapping
bus faults during invasive probes so that panics are avoided?  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?

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?).


Marius Strobl wrote:
> On Mon, Sep 01, 2008 at 05:42:08PM +0100, Gavin Atkinson wrote:
>> On Mon, 2008-09-01 at 18:18 +0200, Marius Strobl wrote:
>>> On Mon, Sep 01, 2008 at 03:20:27PM +0100, Gavin Atkinson wrote:
>>>> Hi all,
>>>> My Blade 100 now panics on boot with HEAD, and I've tracked it down to
>>>> sys/sparc64/pci/ofw_pcibus.c 1.21 (SVN r182108) by marius at .
>>> The most likely reason for this is a buggy driver. In this
>>> case the culprit appears to be the ISA front-end of ahc(4),
>>> which assumes that it can do bus space reads and writes at
>>> addresses that may in fact be assigned to a non-ahc(4)-
>>> compatible device or none at all. While writing something
>>> at an address that may no belong to the expected device
>>> probably is a bad idea in generally, reading to and writing
>>> from unassigned addresses may also trigger exceptions on
>>> sparc64. I'm unsure how to really fix ahc(4) regarding this,
>>> I think it should be okay though to only do it on i386 where
>>> the address range in question probably is reserved for such
>>> purposes (and which also is the only architecture FreeBSD
>>> currently runs on where a machine might have an ISA-slot
>>> and thus can use that front-end at all).
>>> Justin, do you approve the below patch?
>>> Marius
>>> Index: ahc_isa.c
>>> ===================================================================
>>> --- ahc_isa.c	(revision 182474)
>>> +++ ahc_isa.c	(working copy)
>>> @@ -82,6 +82,12 @@ ahc_isa_identify(driver_t *driver, device_t parent
>>>  	int slot;
>>>  	int max_slot;
>>> +#if !defined(__i386__)
>>> +	/*
>>> +	 * Don't assume we can get away with the blind bus space
>>> +	 * reads and writes which ahc_isa_find_device() does.
>>> +	 */
>>> +#endif
>>>  	max_slot = 14;
>>>  	for (slot = 0; slot <= max_slot; slot++) {
>>>  		struct aic7770_identity *entry;
>> This patch (with the addition of a "return;" inside the #ifdef which I'm
>> assuming was forgotten!) gets me booting again with stock ofw_pcibus.c.
> Oops, the "return;" was missing of course.
> Marius

More information about the freebsd-sparc64 mailing list