Date: Wed, 1 Mar 2000 02:10:58 +0100 From: Bernd Walter <ticso@cicely5.cicely.de> To: Greg Lehey <grog@lemis.com> Cc: Alfred Perlstein <bright@wintelcom.net>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, Bernd Walter <ticso@cicely.de> Subject: Re: cvs commit: src/sys/dev/vinum vinumrequest.c Message-ID: <20000301021057.A30366@cicely5.cicely.de> In-Reply-To: <20000229192854.E16629@freebie.lemis.com> References: <200002290614.WAA16809@freefall.freebsd.org> <20000229002459.B21720@fw.wintelcom.net> <20000229183706.D16629@freebie.lemis.com> <20000229011737.C21720@fw.wintelcom.net> <20000229192854.E16629@freebie.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Feb 29, 2000 at 07:28:54PM +1030, Greg Lehey wrote: > On Tuesday, 29 February 2000 at 1:17:37 -0800, Alfred Perlstein wrote: > > * Greg Lehey <grog@lemis.com> [000229 00:37] wrote: > > Remove PCATCH. :) > > And Bernd? > > I must confess, I got your two reports confused. Both of you said > that it had to be that way round or the system would lock up, and I > wasn't able to reproduce it here. Simply copy small files and hit CTRL-C while copying - you will have a good chance to hang your system with PCATCH. > > >> The trouble is, you and Bernd keep asking for opposite things, and I > >> was getting out of phase on the whole matter. In any case, another No I don't want it here. > >> change I made (MAXREQUESTS = 30000) means that we'll never call tsleep > >> here. > > > > The point is that PCATCH never works here, and that there shouldn't > > be landminds in the code, if someone where to reduce MAXREQUESTS > > to test something they'd have a good chance of getting hit. > > OK, we can remove it again. > > > Bernd can have his system lockup and I won't really care. > > But I would. > > > This isn't like half the time PCATCH here will work and do something > > benificial, <em>it will lock up every single time</em>. > > No, that's not correct. I do test these things before I commit them, > and currently I'm running a Vinum root quite happily with this code. > First you need to have a signal. Yes - but that may happen from time to time. > > > If Bernd wants this to catch signals here, then he should supply > > diffs to act properly when the event happens instead of fatally > > spinning in the kernel wedging my boxes. > > The real issue is that we need to find out what Bernd's problem is. I don't have a problem without - like Alfred I have a problem with. > > > I'm going to spend a couple minutes looking it over to see if I > > can come up with a proper fix, but if no-one steps up with patches > > to correctly handle the signal then the PCATCH flag should be removed. > > Yes, that makes sense. I'll do it first thing tomorrow morning if you > don't send me patches in the meantime. Yes you should - but more interesting is how it came back. I can remember that I send you the diffs that put it accidently back in rev 1.40 but I can't for the current case. I even did't realised first that this is a new case. Asumingly this was only a missunderstanding. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000301021057.A30366>