Date: Tue, 29 Feb 2000 01:17:37 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Greg Lehey <grog@lemis.com> Cc: 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: <20000229011737.C21720@fw.wintelcom.net> In-Reply-To: <20000229183706.D16629@freebie.lemis.com>; from grog@lemis.com on Tue, Feb 29, 2000 at 06:37:07PM %2B1030 References: <200002290614.WAA16809@freefall.freebsd.org> <20000229002459.B21720@fw.wintelcom.net> <20000229183706.D16629@freebie.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Greg Lehey <grog@lemis.com> [000229 00:37] wrote: > On Tuesday, 29 February 2000 at 0:25:00 -0800, Alfred Perlstein wrote: > > * Greg Lehey <grog@FreeBSD.org> [000228 22:45] wrote: > >> grog 2000/02/28 22:14:45 PST > >> > >> Modified files: > >> sys/dev/vinum vinumrequest.c > >> Log: > >> launch_requests: If too many requests are active, include PCATCH in > >> the tsleep call flags. > >> > >> Submitted-by: Bernd Walter <ticso@cicely.de> > > > > grrr! > > > > while ((drive->active >= DRIVE_MAXACTIVE) /* it has too much to do already, */ > >>> (vinum_conf.active >= VINUM_MAXACTIVE)) /* or too many requests globally */ > > - tsleep(&launch_requests, PRIBIO, "vinbuf", 0); /* wait for it to subside */ > > + tsleep(&launch_requests, PRIBIO | PCATCH, "vinbuf", 0); /* wait for it to subside */ > > drive->active++; > > > > please back this out, i've already fixed this twice, if you actually > > get a signal you'll spin in the kernel. > > > > the correct solution must check the return from tsleep and actually > > do something with an error return, for now we've agreed to ignore > > signals until a safe return can be implemented. PCATCH must be > > removed. > > OK, make a suggestion. Remove 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 > 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. Bernd can have his system lockup and I won't really care. This isn't like half the time PCATCH here will work and do something benificial, <em>it will lock up every single time</em>. 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. 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. thanks, -Alfred 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?20000229011737.C21720>