Exactly that commit (was Re: Latest -current 100% hang at the late boot stage)

Justin T. Gibbs gibbs at FreeBSD.org
Sat Jun 25 01:09:18 UTC 2011

On 6/24/11 6:26 PM, Andrey Chernov wrote:
>  On Fri, Jun 24, 2011 at 04:20:24PM -0400, Justin T. Gibbs wrote:
> > Instead, I believe that either one of the GEOM taste methods is 
leaking an
> > access reference (so cdclose() is not called), or the CD driver is 
> > to release the hold semaphore during probing. Setting 
> > to '4' will trace the access calls and allow the GEOM side to be 
ruled out.
> > If GEOM is exonerated, we can add tracing to cam_perihp_(un)hold to track
> > this down further.
>  No problem. I just set kern.geom.debugflags=4 in loader.conf and here is
>  new photo (with recent kernel, no patches):
>  http://img803.imageshack.us/img803/4679/25062011006.jpg
>  I skip all noisy parts related to ada0 and ada1 partitions probes.
>  As you can see, only 3 cd0-related geom call issued, right before cd1
>  probe shown. Strange thing is that I see no single cd1-related geom
>  call, but it may be because of hang.

The GEOM processing is serialized, so that is not unexpected.  What your
logs are telling me is that the probe for CD0 is hanging.  I don't know

Are you positive it is this specific SVN revision that prevents cd0
from probing properly and not one of my previous CAM commits?  Just
getting to multi-user doesn't mean we're ok here.  My GEOM changes may
make the system hang earlier, but you'll need to test access to cd0
even if you get to multi-user mode to be sure that the device is
functioning correctly.  I just want to be positive that we're barking
up the right tree.


More information about the freebsd-current mailing list