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