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

On 6/25/11 12:39 AM, Andrey Chernov wrote:
>  On Fri, Jun 24, 2011 at 09:09:08PM -0400, Justin T. Gibbs wrote:
> >> 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
> > why.
>
>  Could you just postpone GEOM calls after any probe will be completed? It
>  seems GEOM goes here even before probe and waits for probe forever. What
>  probe waits in the same time is unclear for me (ccb_scan), but CD devices
>  are slow and may not survive such multisleeping, missing some 
responses in
>  the middle.

The problem is not GEOM.  It's not the thread waiting in ccb_scan - that
thread is designed to wait there until an asynchronous device
arrival/departure event occurs which is not the case here.  The problem 
is in
or below CAM, and that problem is causing the probe to never complete.

> > Are you positive it is this specific SVN revision that prevents cd0
> > from probing properly and not one of my previous CAM commits?

>  I use splitting by half method to find exact date which boots, then see
>  the next commit above that date. Pre-commit kernel goes to multiuser and
>  network is alive. I don't test CDs are working, I'll do that later and
>  report it.

So you know that revisions 223081, 223084, 223085, and 223089 all boot
just fine?  I committed five revisions on that date.  223099 just happens
to be the last one for that day.

--
Justin