Re: [ECOS] gets() and task scheduling stopped

[Jonathan Larmour <jlarmour at redhat dot com>]

Gary Thomas wrote:
> 
> On Thu, 2002-01-10 at 12:34, Jonathan Larmour wrote:
> > Sam Sortais wrote:
> > >
> > > >Sam Sortais wrote:
> > > >[snip]
> > > >> For what I understand with gdb it seems to
> > > >> be stuck at the bottom of this
> > > >> sequence of calls gets() -> refill_?() ->
> > > >> read() -> readwrite() ->
> > > >> dev_fo_read() -> cyg_io_read() -> tty_read() ->cyg_io_read() ->
> > > >> serial_read() -> haldiag_getc() -> HAL_DIAG_READ->?
> > > >> The scheduler is locked at many levels in
> > > >> the previous calls. I was also
> > > >> looking at a loop in tty_read() which is
> > > >> done after a lock? but I do not
> > > >> catch all the details of this low level
> > > >> code.
> >
> > Looking at these functions I'm afraid I still haven't noticed where the
> > scheduler gets locked. There are many places where a mutex gets locked, but
> > not the entire scheduler.
> 
> If he's using RedBoot for the HAL diag channel, then both the scheduler
> gets locked and interrupts are turned off while inside of RedBoot.

The call trace above implies this isn't the case (no mention of
hal_if_diag_read_char), but of course this might be wrong. If it is wrong,
that would indeed explain it.

I know it's a bit late, but I wonder if we should have defined
CYGACC_COMM_IF_GETC_NONBLOCK instead of CYGACC_COMM_IF_GETC so the looping
is done outside of the ROM monitor. Maybe we should, and switch to that?

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine