Date: Tue, 13 Jan 2009 00:13:24 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Garance A Drosihn <drosih@rpi.edu> Cc: freebsd-stable@FreeBSD.org Subject: Re: Big problems with 7.1 locking up :-( Message-ID: <alpine.BSF.2.00.0901130011070.16794@fledge.watson.org> In-Reply-To: <p06240808c5911644dd11@[128.113.24.47]> References: <E1LL6dg-0007CN-DI@dilbert.ticketswitch.com> <042FE04A-2F8D-47DD-8454-7BBA3791D7A8@inoc.net> <p06240802c58db5953598@[128.113.24.47]> <alpine.BSF.2.00.0901121453200.16794@fledge.watson.org> <p06240808c5911644dd11@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 12 Jan 2009, Garance A Drosihn wrote: > He is not eager to do a whole lot of experiments to track down the problem, > since this is happening on busy production machines and he can't afford to > have a lot of downtime on them (especially now that the semester at RPI has > started up). The systems have some large (2 TB) filesystems on them, and > the lockups occur in high disk-I/O situations. He's seeing the problem on > one system which is a dual CPU quad-core xeon, and another which is a 64 bit > P4 with hyperthreading. The one thing in common between the two setups is > that the boot drives + a 3ware controller (with its array of RAID disks) is > moved from one machine to the other one: I think playing the combinatorics game on compile-time flags, kernel features, etc, is probably not the best way to go about debugging this. Instead, I'd debug this as a kernel hang by breaking into the debugger once it occurs, if possible, and ideally on a serial console. Often times hangs can be debugged looking solely at DDB output, or if possible, a crash dump. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0901130011070.16794>