Date: Tue, 30 Oct 2007 20:51:15 +0100 From: Kris Kennaway <kris@FreeBSD.org> To: Oleg Derevenetz <oleg@vsi.ru> Cc: Alfred Perlstein <alfred@freebsd.org>, freebsd-stable@freebsd.org Subject: Re: kern/104406: [ufs] Processes get stuck in "ufs" stateunderpersistent CPU load Message-ID: <47278B33.6040904@FreeBSD.org> In-Reply-To: <001201c81353$6b17e300$efc55358@NBOOOD> References: <027d01c8125c$73d4db80$c8c55358@delloleg><20071019220501.GL31826@elvis.mu.org><006d01c8133a$674a90b0$eec55358@W2KOOOD> <20071020192601.GW31826@elvis.mu.org> <001201c81353$6b17e300$efc55358@NBOOOD>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47278B33.6040904>