ia64/171814: [panic] bioq_init or bioq_remove (unsure which)

[John Baldwin]

On Tuesday, September 25, 2012 1:20:14 pm Paul Procacci wrote:
> The following reply was made to PR ia64/171814; it has been noted by GNATS.
> 
> From: Paul Procacci <pprocacci at gmail.com>
> To: John Baldwin <jhb at freebsd.org>
> Cc: freebsd-ia64 at freebsd.org, freebsd-gnats-submit at freebsd.org
> Subject: Re: ia64/171814: [panic] bioq_init or bioq_remove (unsure which)
> Date: Tue, 25 Sep 2012 12:11:17 -0500
> 
>  --047d7b66f839532c0a04ca89cbf7
>  Content-Type: text/plain; charset=ISO-8859-1
>  
>  Thanks John for your response.
>  
>  Here is the output provided what you had explained to do:
>  
>  
>  0xffffffff80865023 is in devstat_remove_entry
>  (/usr/src/sys/kern/subr_devstat.c:193).
>  188
>  189             /* Remove this entry from the devstat queue */
>  190             atomic_add_acq_int(&ds->sequence1, 1);
>  191             if (ds->id == NULL) {
>  192                     devstat_num_devs--;
>  193                     STAILQ_REMOVE(devstat_head, ds, devstat, 
dev_links);
>  194             }
>  195             devstat_free(ds);
>  196             devstat_generation++;
>  197             mtx_unlock(&devstat_mutex);

I think the devstat entry must have been destroyed twice somehow.

Earlier in geom_subr.c the devstat entry is created with a unit of -1:

struct g_consumer *
g_new_consumer(struct g_geom *gp)
{
	...
	cp->stat = devstat_new_entry(cp, -1, 0, DEVSTAT_ALL_SUPPORTED,
	    DEVSTAT_TYPE_DIRECT, DEVSTAT_PRIORITY_MAX);
}

That should result in devstat_new_entry() setting ds->id to 'cp' (which is 
clearly not NULL), so it shouldn't even attempt the STAILQ_REMOVE(), but that 
is where it appears to have faulted.

-- 
John Baldwin