Re: Problem with pckbc(4) under NetBSD-5

[buhrow%lothlorien.nfbcal.org@localhost (Brian Buhrow)]

        Hello.  I've switched this thread to tech-kern, because it looks like
the problem is squarely in the kernel.
        Following up on my own post, I've figured out more precisely what is
going on.  Or what appears to be going on.  At this point, I could use some
assistance in getting a bit further.
        What's happening is that I have a process running on /dev/console of
an I386 system using the pc's keyboard.  This process is getting stuck in
the write(2) system call.  In tracing things down, it looks like we're
getting stuck in ttwrite() on line  1935.
The comment above this line says that we're sleeping for carrier to wake
up.  How can carrier ever be down on a wsdisplay(4) output device?
This is with:

/*      $NetBSD: tty.c,v 1.227.4.1 2009/02/06 02:05:18 snj Exp $        */

In looking at the tty.c file, I don't see where a wakeup is ever called
against this particular address.  And, indeed, until the process that gets
stuck here is killed, the process never moves again.
this problem doesn't exist under NetBSD-4, but then the locking code is
completely different under NetBSD-4.
        I can reproduce this problem at will, so if there are any ddb commands
which I can run to provide useful data to track this problem down, I'm
happy to do it.  I'd like to fix this issue, since I cannot upgrade my
workstations until this issue is resolved.
        At the very least, it looks like this sleep ought to timeout
eventually, or it ought to never happen at all in the case of a
wsdisplay(4) output device.

Thoughts?
-Brian

On Jun 4, 12:51am, Brian Buhrow wrote:
} Subject: Problem with pckbc(4) under NetBSD-5
}       Hello.  Under NetBSD-5 I'm seeing a problem where processes running on
} the console tty, i.e. on the pc keyboard on X86 systems, tested with the
} I386 platform,  get into a state where  ps shows them in "ttyraw" state.
} When that happens, the only way to get the keyboard back is to kill the
} login shell for that terminal off, and let init reset the terminal.  I'm
} still trying to see exactly what the trace is for the processes that get
} into this state.  I'm beginning to think that the problem exists under
} NetBSD-4 as well, but that the polling interval is so much faster on  that
} version, that the keyboard recovers on its own before things get really
} stuck.  Has anyone else seen this problem?  I can reproduce it at will,
} almost, but I'm not sure what interaction causes the problem.  It seems to
} happen when I'm using the keyboard heavily, and when there's a lot of
} scrolling going on at the same time.
}       Any thoughts, ideas or what ever would be greatly appreciated.  I'll
} post more as I learn more.  Right now, though, NetBSD-5 doesn't look like
} it will work for me on my workstations.
} -thanks
} -Brian
>-- End of excerpt from Brian Buhrow