[Barrelfish-users] No serial input

[Baumann Andrew]

Oh, I've got it. terminal_read() dispatches on a private waitset that is specific to the terminal driver, but in order for the binding to complete someone needs to dispatch the default waitset (which contains the monitor binding).

In that case, perhaps the right solution is to make terminal_want_stdin() block dispatching the default waitset until the binding completes. It's a bit of a kludge, but so is the whole terminal_want_stdin API.

Andrew

> -----Original Message-----
> From: Simon Gerber [mailto:simu at vis.ethz.ch]
> Sent: Tuesday, 8 November 2011 14:51
> To: Baumann Andrew
> Cc: barrelfish-users at lists.inf.ethz.ch
> Subject: RE: [Barrelfish-users] No serial input
> 
> Hi Andrew,
> 
> As far as I can tell, in the case where serial input does not work,
> serial_bind_cb never gets called and fish is waiting to dispatch an
> event in terminal_read. Do you have any idea why this is?
> 
> -- Simon
> 
> On Tue, 8 Nov 2011 12:51:48 +0000, Baumann  Andrew wrote:
> > Hi Simon,
> >
> > I don't think this is the problem. serial_bind_cb() checks for
> > state->want_stdin, and if so sends the associate_stdin message
> > whenever it runs. This may be after terminal_want_stdin has returned,
> > but that's fine as long as the message send doesn't fail. There is a
> > problem that it has no way to report the error code if the message
> > send fails, but in the current tree this should just result in an
> > assertion failure and crash of the program, not silent failure. The
> > only way I could see this failing silently in the way you describe is
> > if you're compiling without assertions, in which case the error will
> > go undetected. There should really be a USER_PANIC_ERR call in there
> > rather than just an assertion to catch this.
> >
> > Cheers,
> > Andrew
> >
> >> -----Original Message-----
> >> From: Simon Gerber [mailto:simu at vis.ethz.ch]
> >> Sent: Tuesday, 8 November 2011 13:06
> >> To: barrelfish-users at lists.inf.ethz.ch
> >> Subject: Re: [Barrelfish-users] No serial input
> >>
> >> Hi,
> >>
> >>  From what I can tell, if terminal_want_stdin needs to look up and
> >> bind
> >> to the serial service, the code after the lookup runs before the
> >> bind_cb
> >> completes and thus the check for state->serial != NULL before
> >> associating stdin fails and terminal_want_stdin returns with
> >> SYS_ERR_OK
> >> without having actually grabbed stdin.
> >>
> >> I assume this should be fixed by busy-waiting on the completion of
> >> serial_bind_cb? Or is there a better way of doing this?
> >>
> >> Cheers,
> >>
> >> -- Simon Gerber
> >>
> >> On Sun, 6 Nov 2011 17:26:47 +0000, Baumann  Andrew wrote:
> >> > Hi,
> >> >
> >> > This sounds like a startup race. I can't tell you the solution,
> >> but I
> >> > can give you clues where to look: lib/barrelfish/terminal.c
> >> > terminal_init() does a  nonblocking lookup for the serial driver,
> >> and
> >> > if it is already registered, it connects to it. Otherwise if it
> >> isn't
> >> > already present, fish's main() will start without a binding to the
> >> > serial driver, but the call to terminal_want_stdin() should cause
> >> the
> >> > binding to be established (this time in a blocking fashion),
> >> assuming
> >> > you didn't pass "keyboard" as one of the command-line parameters
> >> to
> >> > fish. I would stick some debug into terminal.c and try to
> >> understand
> >> > what is happening when you block.
> >> >
> >> > Hope this helps,
> >> > Andrew
> >> >
> >> >> -----Original Message-----
> >> >> From: Mark Nevill [mailto:nevillm at ethz.ch]
> >> >> Sent: Thursday, 3 November 2011 16:01
> >> >> To: barrelfish-users at lists.inf.ethz.ch
> >> >> Subject: [Barrelfish-users] No serial input
> >> >>
> >> >> Hi everyone!
> >> >>
> >> >> When booting Barrelfish repeatedly in qemu, rarely the two lines
> >> >> below
> >> >> appear:
> >> >>
> >> >> chips: client waiting for serial
> >> >> chips: notifying client about serial
> >> >>
> >> >> If these lines appear, fish does not receive serial input.
> >> >>
> >> >> This particularly affects our pending merge of our AHCI driver
> >> >> project, as we get these messages far more often (this is
> >> probably
> >> >> due
> >> >> to the AHCI driver delaying the initialisation of the serial
> >> >> driver).
> >> >>
> >> >> Has anybody else encountered this issue?
> >> >>
> >> >> Regards,
> >> >>
> >> >> -- Mark & Simon
> >> >>
> >> >> _______________________________________________
> >> >> Barrelfish-users mailing list
> >> >> Barrelfish-users at lists.inf.ethz.ch
> >> >> https://lists.inf.ethz.ch/mailman/listinfo/barrelfish-users
> >> >
> >> > _______________________________________________
> >> > Barrelfish-users mailing list
> >> > Barrelfish-users at lists.inf.ethz.ch
> >> > https://lists.inf.ethz.ch/mailman/listinfo/barrelfish-users
> >>
> >>
> >> _______________________________________________
> >> Barrelfish-users mailing list
> >> Barrelfish-users at lists.inf.ethz.ch
> >> https://lists.inf.ethz.ch/mailman/listinfo/barrelfish-users