[PATCH 1/1] Fix bugs determining active VT consoles
remco at rvt.com
Fri Aug 31 11:33:28 PDT 2007
On Friday 31 August 2007, Joe Marcus Clarke wrote:
> On Fri, 2007-08-31 at 12:46 -0400, William Jon McCann wrote:
> > On 8/31/07, Joe Marcus Clarke <marcus at freebsd.org> wrote:
> > > On Fri, 2007-08-31 at 12:22 -0400, William Jon McCann wrote:
> > > > On 8/30/07, Joe Marcus Clarke <marcus at freebsd.org> wrote:
> > > > > On FreeBSD, having a process sit in VT_WAITACTIVE can cause kernel
> > > > > panics or unkillable processes that consume 100% of the CPU. To
> > > > > work around this problem, replace the model where individual
> > > > > threads call VT_WAITACTIVE with a g_timeout model which checks the
> > > > > active VT every second, and queues an event when it changes.
> > > >
> > > > As I said in the other mail, I don't think we want to do this. Can
> > > > you describe why you think this isn't a FreeBSD kernel bug?
> > >
> > > I missed the other email, sorry. From my reading of what this ioctl is
> > > supposed to do, it is typically called after activating a given VT to
> > > ensure that the VT is active before proceeding. It should not be
> > > something a program sits in for long periods of time.
> > According to what or whom?
> I read it from Linux Journal:
> That made me think it's used more to see if the switch is complete than
> as an event driver.
This article is from 1994! Nowhere does it indicate a problem with
How does this relate to FreeBSD and a potential problem there?
Could you please explain what makes you think there is a FreeBSD bug that
makes VT_WAITACTIVE risky to use, and why you think working around a problem
is better than fixing it?
Remco Treffkorn (RT445)
remco at rvt.com (831) 685-1201
More information about the hal