Exactly that commit (was Re: Latest -current 100% hang at the
late boot stage)
Justin T. Gibbs
gibbs at FreeBSD.org
Sat Jun 25 11:27:30 UTC 2011
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
> 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
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.
More information about the freebsd-current