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

On Mon, Jun 20, 2011 at 15:46:56 +0400, Andrey Chernov wrote:
> On Mon, Jun 20, 2011 at 11:01:46AM +0300, Kostik Belousov wrote:
> > On Mon, Jun 20, 2011 at 11:02:22AM +0400, Andrey Chernov wrote:
> > > On Sun, Jun 19, 2011 at 08:15:43PM -0600, Justin T. Gibbs wrote:
> > > > On 6/19/11 6:19 PM, Andrey Chernov wrote:
> > > > > Exactly that commit is responsible for boot hang.
> > > > > Please fix.
> > > > > BTW, I have MBR on SATA disk (CAM emulated), ICH9.
> > > > 
> > > > Since it works for me, you'll need to provide more information.  Can you
> > > > at least drop into kdb to determine the likely source of the hang by
> > > > getting a stack trace of all processes to see where they are sleeping
> > > > and dumping lock information?
> > > 
> > > I drop into DDB and put 'bt' console photo in the very first message of 
> > > this thread - nothing unusual seen in the main stack. Could you please 
> > > specify exact DDB commands you want to be issued by me? No dump can be 
> > > provided since nothing is mounted yet including swap,
> > > 
> > > BTW, I remember I saw previously unseen warnings with post Jun 14 kernels:
> > > "xpt_action_default: CCB type 0xe not supported"
> > > 
> > > 'ps' inside DDB shows [xpt_thrd] at "ccb_scan" wmesg state and [g_event]
> > > at "caplck" wmesg state, [kernel] at "g_waitid" state.
> > > Even don't know, if it matters.
> > 
> > Just in case, please try r223277.
> 
> As the second message in the thread states, I try first even 223296 with 
> the same hang and the same 
> xpt_action_default: CCB type 0xe not supported
> As I think, DDB's 'ps' indicates that kernel waits something from geom and 
> geom waits something from ccb_scan forever, just raw guess. I will be glad to 
> issue more specific DDB commands and upload corresponding photos.
> BTW, pluging and unplugging USB devides works in that stage.

Can you do the following when the hang happens:

ps
alltrace
show locks
show msgbuf

Hopefully that will give us something to start looking at...

This would really work a lot better if there is any way to get a serial
console on the machine.  The above will produce a good bit of output, and
would likely need a lot of pictures.

Since we can't reproduce the problem here, some debugging help would be
greatly appreciated.

Thanks,

Ken
-- 
Kenneth Merry
ken_at_FreeBSD.ORG