Date: Tue, 24 Feb 2009 07:02:31 +0200 From: Dimitar Vasilev <dimitar.vassilev@gmail.com> To: Carl <k0802647@telus.net> Cc: freebsd-fs@freebsd.org, Robert Watson <rwatson@freebsd.org> Subject: Re: UFS2 and/or sparse file bug causing copy process to land in 'D'' state? Message-ID: <59adc1a0902232102q6c0f6034r354ff9ad3a2b3222@mail.gmail.com> In-Reply-To: <49A3357A.7080008@telus.net> References: <49A10626.8060705@telus.net> <alpine.BSF.2.00.0902231022520.71916@fledge.watson.org> <49A3357A.7080008@telus.net>
next in thread | previous in thread | raw e-mail | index | archive | help
2009/2/24 Carl <k0802647@telus.net> > Robert Watson wrote: > >> It would be interesting to get kernel stack traces of the involved >> processes/threads; there are various ways to do this, such as using DDB. If >> you have a kernel.symbols for the kernel, then you can run kgdb on >> kernel.symbols and /dev/mem to generate traces without interrupting >> operation (although if the system is in the throes of deadlocking, that may >> not be a concern or even possible). You can also use procstat -kk to >> retrieve kernel stack traces, with a bit less information (such as no >> arguments) to help narrow things down more. >> >> Unfortunately, debugging this type of problem, as you've intuited, is best >> done with serial console access and a local box so that the debugging >> information can be extracted. It would be interesting to know if you can >> force a crashdump on the box to get the information for post-mortem >> debugging. This may be possible using "reboot -d" -- I've never used this, >> but have every reason to think it will work. >> > > I have both a local and remote box. The problems I'm seeing are all > occurring on the local box because as yet I cannot afford to cause them on a > remote box. > > If you were to guess I've never used DDB or any other kernel debugging, > you'd be spot on. I'm currently running the 7.0-RELEASE GENERIC kernel. I > see a /boot/kernel/kernel.symbols in the filesystem. The system is nominally > headless with a serial console, although I primarily use SSH. Even if I knew > what to do with them, actually collecting kernel dumps is a hit or miss > affair because of gmirror, but this particular problem doesn't cause kernel > core dumps on its own (thankfully, since gmirror resyncs take a long time on > terabyte drives). So, if you were able to clearly spell out the stripped > down steps I should take in conjunction with my earlier truncate sequence > and if it doesn't require rebuilding the kernel, I might be able to > accommodate. Learning all about kernel debugging would be interesting but > doesn't fit in my schedule right now. > > Anyone willing to attempt to reproduce this problem on their system? > > > Carl / K0802647 > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > Hi Carl, How about a soekris board, a USB stick and a null modem cable for collecting data from the local box? Or a laptop with a USB to serial adapter ? Cheers, Dimitar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?59adc1a0902232102q6c0f6034r354ff9ad3a2b3222>