Re: Hurd CVS and X Debugging [Was: Re: Plans for X]
On Tue, Oct 24, 2000 at 11:03:59AM +0200, Marcus Brinkmann wrote:
> On Mon, Oct 23, 2000 at 09:44:01PM -0700, Steve Bowman wrote:
> > Well,
> > the curious thing was that the hurd debs from 1020 cvs don't include the
> > following translators: mouse, kbd, streamdev.
>
> Those are only included in the Debian source. The latter should probably
> be in CVS, but the former both are simply too gross :) streamdev should get
> pluggable modules support and handle kbd, mouse special cases with those.
ACK. When CVS has them or a more intelligent streamdev that handles mouse
and kbd functionality, I'll switch to that. In the meanwhile, I've built
the hurd from the debian 0921 source tar with all debugging symbols and
installed that. I haven't caught the malfunctioning mouse translator
yet but started and stopped X at least 12-15 times without the old error
that it thinks the server is already running. I think that one is gone.
>
> > 4. kbd translator returns Interrupted System Call at open(). I can't
> > reproduce this seperate from the Xserver, so this is a weird problem.
> > Trying several times usually leads to success.
> >
> > Already reported prestarting kbd translator keeps this error from
> > occurring.
>
> I saw this even with a running translator, so no, it doesn't stop it,
> but probably reduces the likelihood of happening.
I haven't seen it yet with a running translator, but it turns out the
mouse translator doesn't need prestarted anyway, only kbd seems to have
this trouble.
>
> > Doesn't fix the problem though. I looked at the X mouse code
> > a bit and it's opening in non-blocking mode. Opening it in blocking mode
> > may hang and we'd have to do ioctl to change mode.
>
> Although supported by glibc, I don't know if change open modes is supported
> by the current kbd,mouse servers. I think I really have to audit the kbd and
> mouse server code, it is quite old, and was never seriously revised.
> Note that the same servers work with 3.3.6 just fine, and I don't think we
> have identified the heart of matter.
>
> > Really, this needs
> > to have some error checking and retry logic. Kbd is probably the same.
>
> Although such code would help here, it shouldn't be necessary. kbd and mouse
> should come up and respond to the open call just fine.
ACK. The problem isn't X here. I think it'd be more robust for a
non-blocking open to retry on failure; maybe I'm thinking of NBIO after
open when EWOULDBLOCK can be returned. This isn't listed as a possible
E return for NB open (but I only checked man, not the source).
In any case, I think the mouse is OK wrt this issue anyway as I mentioned
above.
Also, re: your item 1? (killing translators while X is running). Killing
any of pflocal, mouse, or kbd kills X. mouse and kbd aren't too bad,
X dies, but the OS seems stable and a graceful shutdown can be done.
Killing pflocal is nasty.
>
> Thanks,
> Marcus
--
Steve Bowman <sbowman@frostwork.net> (preferred)
Buckeye, AZ <sbowman@goodnet.com> <bowmanc@acm.org>
<http://www.goodnet.com/~sbowman/>
Powered by Debian GNU/Linux and GNU/Hurd <http://www.debian.org>
Reply to: