Date: Wed, 09 Nov 2005 06:56:01 -0700 From: Scott Long <scottl@samsco.org> To: Bruce Evans <bde@zeta.org.au> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Warner Losh <imp@FreeBSD.org>, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern subr_power.c Message-ID: <4371FFF1.7020902@samsco.org> In-Reply-To: <20051109204951.K68350@delplex.bde.org> References: <200511090732.jA97W2ir099375@repoman.freebsd.org> <20051109204951.K68350@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote: > On Wed, 9 Nov 2005, Warner Losh wrote: > >> Modified files: >> sys/kern subr_power.c >> Log: >> Kick off the suspend sequence from the keyboard in a SWI rather than >> in the hardware interrupt context (even if it is likely just an >> ithread). We don't document that suspend/resume routines are run from >> such a context and some of the things that happen in those routines >> aren't interrupt safe. Since there's no real need to run from that >> context, this restores assumptions that suspend routines have made. >> >> This fixes Thierry Herbelot's 'Trying to sleep while sleeping is >> prohibited' problem. > > > Er, SWIs are interrupts too. Trying to sleep in a SWI handler should > cause the same message. This commit uses the general taskqueue SWI > handler. taskqueue(9) implicitly says that only the taskqueue thread > handler can sleep (it gives malloc(M_WAITOK) as an example of something > that can only be done in thread context). > > Bruce You're right, but sleeping in SWI's has never been enforced. CAM relies on it, for better or worse, and until that's fixed it's pointless to start enforcing it. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4371FFF1.7020902>