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. > 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. 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. -- http://ache.vniz.net/Received on Sat Jun 25 2011 - 02:39:21 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:15 UTC
