> >> 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 _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

Re: Exactly that commit (was Re: Latest -current 100% hang at th