kern/104406: [ufs] Processes get stuck in "ufs" state underpersistent CPU load

[Alfred Perlstein]

* Oleg Derevenetz <oleg at vsi.ru> [071020 09:58] wrote:
> > > Can anyone take a look on PR kern/104406 ? I got repeatable hang
> situation,
> > > but I can't obtain a kernel dump to get result of all show commands from
> > > here:
> > >
> > >
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html
> > >
> > > After my break to debugger using Ctrl+Alt+Esc sequence and entering a
> > > "panic" command kernel does not wrote a kernel dump but seems to hang.
> Can
> > > anyone describe how to obtain a kernel dump in this situation, or at
> least
> > > say - which output of show commands need in first place to debug this ?
> > > Output of all suggested commands is huge and I afraid of making mistake
> > > when carrying this output from screen to list of paper and back :-)
> >
> > Oleg, one thing you can do to make this less painful is to
> > run your machine's console over serial port.
> >
> > First get a crossover serial cable, make sure it works from one
> > box to another, it should be easy to run "tip com1" on both
> > boxes to ensure that it works.
> >
> > Then you just need to add console=comconsole to /boot/loader.conf
> > and your box's console should come over serial.
> >
> > Then on the machine watching the console, you can just do this:
> >
> > % script
> > Script started, output file is typescript
> > % tip com1
> > ...do ddb stuff now...
> > ...stop tip
> > % exit
> >
> > now you should have everything logged into a file called "typescript"
> > should save you a big headache.
> 
> Thanks, I'll try it in the monday morning.
> 
> > As far as getting a dump from ddb, try this:
> >
> > ddb> call doadump
> >
> > I'm completely at a loss why this isn't a base ddb command "dump"
> > but whatever... :)
> 
> Unfortunately, this doesn't work too. I called duty personnel in this
> datacenter and asked them to do this, and person on duty tells me that after
> he enters this command something like that arrives on monitor:
> 
> db> call doadump
> Dumping 3072 MB
> 
> Dump aborted error I/O
> Dump failed. (Error 5)

Hmnmm, that seems like you might be having a hardware problem,
what disk device do you have?  

Have you also enabled kernel dumps via /etc/rc.conf:dumpdev= 
?

-- 
- Alfred Perlstein