Date: Thu, 27 Nov 2003 16:54:31 +1030 From: Greg 'groggy' Lehey <grog@FreeBSD.org> To: Cosmin Stroe <cosmin@hehipc.phy.uic.edu> Cc: freebsd-current@freebsd.org Subject: Re: requesting vinum help Message-ID: <20031127062431.GX82843@wantadilla.lemis.com> In-Reply-To: <Pine.LNX.4.44.0311270001010.14925-100000@hehipc.phy.uic.edu> References: <20031126230447.GM82843@wantadilla.lemis.com> <Pine.LNX.4.44.0311270001010.14925-100000@hehipc.phy.uic.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
--rD8YjznDeXmDvfGj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thursday, 27 November 2003 at 0:13:09 -0600, Cosmin Stroe wrote: > On Thu, 27 Nov 2003, Greg 'groggy' Lehey wrote: > >> On Wednesday, 26 November 2003 at 12:04:52 -0600, Cosmin Stroe wrote: >>> >>> I am using vinum atm, and I am having serious problems with it. After >>> about 16 hrs of writing data to a vinum volume via NFS at a constant data >>> stream of 200k/sec and reading at 400k/sec at the same time, the whole >>> machine just freezes, hard. The only thing I can do is reboot. This >>> behavior appears in 4.8 and 5-CURRENT. I have no indication of what is >>> wrong, or how to go about finding it out. The problem is either with NFS >>> or Vinum, and I'm leaning towards Vinum (because of the failure in both >>> -STABLE and -CURRENT). >>> >>> I'm not the kind of person that relies on other people, and I like to fix >>> my own problems, but this is a problem which I cannot fix at this time. >>> So, I'm planning to look through the code of vinum and start messing with >>> it to figure out how it works and how to debug it. >> >> This is unlikely to get you very far. Some more details (offline if >> you prefer) would be handy, but as you say, you can't even be sure >> that it's Vinum. The best thing would be to get the system into the >> kernel debugger at the point of freeze, if that's possible, and try to >> work out what has happened. > > Quick question: If this is a software problem with vinum, there > should be no way it can hard lock a machine. Is this assumption > correct ? Heh. Depends on what you mean by a software problem. The right kind of software problem anywhere can hard lock machines :-( > I should be able to invoke the kernel debugger by pressing the > hotkey (ctrl+alt+esc) while the machine is locked and get a > backtrace (altho i'd be in an ISR servicing the hotkey, so i'm not > sure it'd do much good). It would enable you to look around and figure out what's gone wrong. > Any special suggestions on debugging this kind of freezing problem ? > The hardware has been tested and it's good (CPU,RAM,HDs). (some kind > of watchdog in software ??) I have some debugging help in Vinum which will log what's going on, but it doesn't help much in the case of a hard freeze. It could be a deadlock. Do you have swap on Vinum? Greg -- See complete headers for address and phone numbers. --rD8YjznDeXmDvfGj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQE/xZifIubykFB6QiMRAhFZAJ95leZtVEl6nCG0eCND6ifMByj3mgCglHGD ZwlbXPRTLFA4VLjig9RlQog= =99lG -----END PGP SIGNATURE----- --rD8YjznDeXmDvfGj--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031127062431.GX82843>