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 <[email protected]>
> To: John Baldwin <[email protected]>
> Cc: [email protected], [email protected]
> 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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-geom
To unsubscribe, send any mail to "[email protected]"
