This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cyg_scheduler_read_lock() seems wrong in the synthetic environment


>>>>> "Dan" == Dan Jakubiec <djakubiec@yahoo.com> writes:

    Dan> We are running eCos on an ARM7 platform and shadowing this
    Dan> development in a Linux synthetic environment. I noticed that
    Dan> in the synthetic environment the scheduler lock count seems
    Dan> to be "off-by-one". When running in "thread context",
    Dan> cyg_scheduler_read_lock() always reports 1 (instead of 0) and
    Dan> DSR report >= 2. The lock count never drops below 1.

    Dan> On our real ARM hardware, the lock counts look right: 0 for
    Dan> thread context, >= 1 for DSRs. However, both environments
    Dan> seem to be working fine.

    Dan> Is this expected behavior or is something wrong? Can someone
    Dan> explain what is/should be going on here?

It is not expected behaviour. As far as the kernel is concerned the
synthetic target HAL should behave the same as any other HAL. In fact
there is only one place in the HAL that even knows about the scheduler
lock: the interrupt handler needs to increment the lock early on.

A lot of eCos will actually continue running happily even if the
scheduler is permanently locked. However there will be no preemption
of threads and no timeslicing, because the interrupt handling code
will always think that the foreground thread was in a critical section
and must be allowed to complete.

As an experiment I just tried a clean build of the synthetic target in
the default configuration. Then I modified the kernel's timeslice.c
test, adding some diag_printf()'s and calls to
cyg_scheduler_read_lock(). The test passes and the reported scheduler
lock value is always 0, as it should be. This implies the problem is
not with the synthetic target HAL, instead something else is leaving
the scheduler locked.

Bart

-- 
Bart Veer                       eCos Configuration 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]