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

[Kris Kennaway]

Oleg Derevenetz wrote:
>>> > > 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,
> 
> It is possible, but unlikely:
> 
> 1. I have simular symptoms on another AMD64 machine with 6.2 (uname -a 
> from this machine listed in PR kern/104406 in my followup at Wed, 7 Mar 
> 2007 05:10:59 +0300), but they are rare and this machine is in 
> production, so I can't make experiments with it;
> 2. All these hardware successfully works earlier with FreeBSD 4.6.
> 
>> what disk device do you have?
> 
> Dumpdev is swap partition on da0 (single physical disk) that connected 
> to Mylex AcceleRAID 170 RAID controller. The problem arrives when I copy 
> large amount of files from FTP to another disk (da1) that is connected 
> to the same RAID controller.

If the driver or controller is misbehaving it could explain both 
problems.  Any chance you can get another disk in there on a different 
controller to dump onto?

Kris