This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: cyg_scheduler_read_lock() seems wrong in the synthetic environment
- From: Nick Garnett <nickg at ecoscentric dot com>
- To: Dan Jakubiec <djakubiec at yahoo dot com>
- Cc: ecos-discuss at sources dot redhat dot com
- Date: 09 Dec 2003 09:56:50 +0000
- Subject: Re: [ECOS] cyg_scheduler_read_lock() seems wrong in the synthetic environment
- References: <20031208201132.62398.qmail@web21207.mail.yahoo.com>
Dan Jakubiec <djakubiec@yahoo.com> writes:
> We are running eCos on an ARM7 platform and shadowing this development
> in a Linux synthetic environment. I noticed that in the synthetic
> environment the scheduler lock count seems to be "off-by-one". When
> running in "thread context", cyg_scheduler_read_lock() always reports 1
> (instead of 0) and DSR report >= 2. The lock count never drops below
> 1.
>
> On our real ARM hardware, the lock counts look right: 0 for thread
> context, >= 1 for DSRs. However, both environments seem to be working
> fine.
>
> Is this expected behavior or is something wrong? Can someone explain
> what is/should be going on here?
It is unlikely that the kernel is doing something wrong here. Bart's
tests suggest that the HAL is not misbehaving either. The most likely
candidate is probably one of the device drivers. These claim the
scheduler lock, and if there is a bug somewhere that allows it to
escaped without unlocking, then you will get the effect you are
seeing. So, work out which drivers you are using and take a look at
those.
--
Nick Garnett eCos Kernel Architect
http://www.ecoscentric.com The eCos and RedBoot experts
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss