This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: gets() and task scheduling stopped
- From: Gary Thomas <gthomas at redhat dot com>
- To: Jonathan Larmour <jlarmour at redhat dot com>
- Cc: Sam Sortais <sams at myself dot com>,eCos Discussion <ecos-discuss at sources dot redhat dot com>
- Date: 10 Jan 2002 14:12:41 -0700
- Subject: Re: [ECOS] gets() and task scheduling stopped
- References: <20020110182217.8439.qmail@iname.com> <3C3DECBA.30D246D7@redhat.com>
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.