[ECOS] NIOS2 kernel tests failing

[ECOS] NIOS2 kernel tests failing

[Grant Edwards]

I've been unable to get all of the kernel tests to pass on a
NIOS2 platform.  Four fail consistently:

   except1.cxx
   kexcept1.cxx
   kmutex3.c
   mutex3.c

I presume the first two are expected failures because the
-fno-exceptions flag is used during compilation.  But, I don't
know of any reason why the mutex3 tests shouldn't work.  Has
anybody else been able to get any of these four tests to pass
on a NIOS2 platform?

FWIW, here is the output from those four tests:


GDB:<handle SIGBUS nostop>
GDB:<handle SIGSEGV nostop>
GDB:<handle SIGFPE nostop>
INFO:<handler 1 called>
INFO:<handler 1 returned>
PASS:<Attempting to provoke exception>
FAIL:<Couldn't cause exception> Line: 200, File: /nios/Altera/kits/nios2_51/components/ecos/ecos-current/packages/kernel/current/tests/except1.cxx
EXIT:<done>


GDB:<handle SIGBUS nostop>
GDB:<handle SIGSEGV nostop>
GDB:<handle SIGFPE nostop>
INFO:<handler 1 called>
INFO:<handler 1 returned>
PASS:<Attempting to provoke exception>
FAIL:<Couldn't cause exception> Line: 211, File: /nios/Altera/kits/nios2_51/components/ecos/ecos-current/packages/kernel/current/tests/kexcept1.c
EXIT:<done>



INFO:<Control Thread running>

----- [ 0] New Cycle: 0x00, Threads 1a inactive, 2a inactive, 3a inactive -----
INFO:<Thread 1 running>
INFO:<Thread 2 running>
INFO:<Thread 3 running>
INFO:<Thread 1 exit>
INFO:<Checking priority scheme: dynamic-default-inherit>
INFO:<Thread 3 exit>
PASS:<Thread 2 exiting, AOK>

----- [ 1] New Cycle: 0x01, Threads 1a run early, 2a inactive, 3a inactive -----
INFO:<Thread 1 running>
INFO:<Extra thread 1a running>
INFO:<Thread 2 running>
INFO:<Thread 3 running>
INFO:<Extra thread 1a resumed>
INFO:<Extra thread 1a locked>
INFO:<Thread 1 exit>
INFO:<Extra thread 1a unlocked>
INFO:<Extra thread 1a exiting>
INFO:<Checking priority scheme: dynamic-default-inherit>
INFO:<Thread 3 exit>
PASS:<Thread 2 exiting, AOK>

----- [ 2] New Cycle: 0x10, Threads 1a run late, 2a inactive, 3a inactive -----
INFO:<Thread 1 running>
INFO:<Extra thread 1a running>
INFO:<Thread 2 running>
INFO:<Thread 3 running>
INFO:<Thread 1 exit>
INFO:<Extra thread 1a resumed>
INFO:<Extra thread 1a locked>
INFO:<Extra thread 1a unlocked>
INFO:<Extra thread 1a exiting>
INFO:<Checking priority scheme: dynamic-default-inherit>
INFO:<Thread 3 exit>
PASS:<Thread 2 exiting, AOK>

----- [ 3] New Cycle: 0x02, Threads 1a inactive, 2a run early, 3a inactive -----
INFO:<Thread 1 running>
INFO:<Thread 2 running>
INFO:<Extra thread 2a running>
INFO:<Thread 3 running>
INFO:<Extra thread 2a resumed>
INFO:<Extra thread 2a locked>
INFO:<Thread 1 exit>
INFO:<Checking priority scheme: dynamic-default-inherit>
INFO:<Extra thread 2a unlocked>
INFO:<Extra thread 2a exiting>
INFO:<Thread 3 exit>
PASS:<Thread 2 exiting, AOK>

----- [ 4] New Cycle: 0x03, Threads 1a run early, 2a run early, 3a inactive -----
INFO:<Thread 1 running>
INFO:<Extra thread 1a running>
INFO:<Thread 2 running>
INFO:<Extra thread 2a running>
INFO:<Thread 3 running>
INFO:<Extra thread 1a resumed>
INFO:<Extra thread 2a resumed>
INFO:<Extra thread 1a locked>
INFO:<Extra thread 2a locked>
INFO:<Thread 1 exit>
INFO:<Extra thread 1a unlocked>
INFO:<Extra thread 1a exiting>
INFO:<Checking priority scheme: dynamic-default-inherit>
INFO:<Extra thread 2a unlocked>
INFO:<Extra thread 2a exiting>
INFO:<Thread 3 exit>
PASS:<Thread 2 exiting, AOK>

----- [ 5] New Cycle: 0x12, Threads 1a run late, 2a run early, 3a inactive -----
INFO:<Thread 1 running>
INFO:<Extra thread 1a running>
INFO:<Thread 2 running>
INFO:<Extra thread 2a running>
INFO:<Thread 3 running>
INFO:<Extra thread 2a resumed>
INFO:<Extra thread 2a locked>
INFO:<Thread 1 exit>
INFO:<Extra thread 1a resumed>
INFO:<Extra thread 1a locked>
INFO:<Extra thread 1a unlocked>
INFO:<Extra thread 1a exiting>
INFO:<Checking priority scheme: dynamic-default-inherit>
INFO:<Extra thread 2a unlocked>
INFO:<Extra thread 2a exiting>
INFO:<Thread 3 exit>
PASS:<Thread 2 exiting, AOK>

----- [ 6] New Cycle: 0x20, Threads 1a inactive, 2a run late, 3a inactive -----
INFO:<Thread 1 running>
INFO:<Thread 2 running>
INFO:<Extra thread 2a running>
INFO:<Thread 3 running>
INFO:<Thread 1 exit>
INFO:<Checking priority scheme: dynamic-default-inherit>
INFO:<Extra thread 2a resumed>
INFO:<Extra thread 2a locked>
INFO:<Extra thread 2a unlocked>
INFO:<Extra thFAIL:<Thread 3 has not ended> Line: 346, File: /nios/Altera/kits/nios2_51/components/ecos/ecos-current/packages/kernel/current/tests/kmutex3.c




INFO:<Control Thread running>

----- [ 0] New Cycle: 0x00, Threads 1a inactive, 2a inactive, 3a inactive -----
INFO:<Thread 1 running>
INFO:<Thread 2 running>
INFO:<Thread 3 running>
INFO:<Thread 1 exit>
INFO:<Checking priority scheme: dynamic-default-inherit>
INFO:<Thread 3 exit>
PASS:<Thread 2 exiting, AOK>

----- [ 1] New Cycle: 0x01, Threads 1a run early, 2a inactive, 3a inactive -----
INFO:<Thread 1 running>
INFO:<Extra thread 1a running>
INFO:<Thread 2 running>
INFO:<Thread 3 running>
INFO:<Extra thread 1a resumed>
INFO:<Extra thread 1a locked>
INFO:<Thread 1 exit>
INFO:<Extra thread 1a unlocked>
INFO:<Extra thread 1a exiting>
INFO:<Checking priority scheme: dynamic-default-inherit>
INFO:<Thread 3 exit>
PASS:<Thread 2 exiting, AOK>

----- [ 2] New Cycle: 0x10, Threads 1a run late, 2a inactive, 3a inactive -----
INFO:<Thread 1 running>
INFO:<Extra thread 1a running>
INFO:<Thread 2 running>
INFO:<Thread 3 running>
INFO:<Thread 1 exit>
INFO:<Extra thread 1a resumed>
INFO:<Extra thread 1a locked>
INFO:<Extra thread 1a unlocked>
INFO:<Extra thread 1a exiting>
INFO:<Checking priority scheme: dynamic-default-inherit>
INFO:<Thread 3 exit>
PASS:<Thread 2 exiting, AOK>

----- [ 3] New Cycle: 0x02, Threads 1a inactive, 2a run early, 3a inactive -----
INFO:<Thread 1 running>
INFO:<Thread 2 running>
INFO:<Extra thread 2a running>
INFO:<Thread 3 running>
INFO:<Extra thread 2a resumed>
INFO:<Extra thread 2a locked>
INFO:<Thread 1 exit>
INFO:<Checking priority scheme: dynamic-default-inherit>
INFO:<Extra thread 2a unlocked>
INFO:<Extra thread 2a exiting>
INFO:<Thread 3 exit>
PASS:<Thread 2 exiting, AOK>

----- [ 4] New Cycle: 0x03, Threads 1a run early, 2a run early, 3a inactive -----
INFO:<Thread 1 running>
INFO:<Extra thread 1a running>
INFO:<Thread 2 running>
INFO:<Extra thread 2a running>
INFO:<Thread 3 running>
INFO:<Extra thread 1a resumed>
INFO:<Extra thread 2a resumed>
INFO:<Extra thread 1a locked>
INFO:<Extra thread 2a locked>
INFO:<Thread 1 exit>
INFO:<Extra thread 1a unlocked>
INFO:<Extra thread 1a exiting>
INFO:<Checking priority scheme: dynamic-default-inherit>
INFO:<Extra thread 2a unlocked>
INFO:<Extra thread 2a exiting>
INFO:<Thread 3 exit>
PASS:<Thread 2 exiting, AOK>

----- [ 5] New Cycle: 0x12, Threads 1a run late, 2a run early, 3a inactive -----
INFO:<Thread 1 running>
INFO:<Extra thread 1a running>
INFO:<Thread 2 running>
INFO:<Extra thread 2a running>
INFO:<Thread 3 running>
INFO:<Extra thread 2a resumed>
INFO:<Extra thread 2a locked>
INFO:<Thread 1 exit>
INFO:<Extra thread 1a resumed>
INFO:<Extra thread 1a locked>
INFO:<Extra thread 1a unlocked>
INFO:<Extra thread 1a exiting>
INFO:<Checking priority scheme: dynamic-default-inherit>
INFO:<Extra thread 2a unlocked>
INFO:<Extra thread 2a exiting>
INFO:<Thread 3 exit>
PASS:<Thread 2 exiting, AOK>

----- [ 6] New Cycle: 0x20, Threads 1a inactive, 2a run late, 3a inactive -----
INFO:<Thread 1 running>
INFO:<Thread 2 running>
INFO:<Extra thread 2a running>
INFO:<Thread 3 running>
INFO:<Thread 1 exit>
INFO:<Checking priority scheme: dynamic-default-inherit>
INFO:<Extra thread 2a resumed>
INFO:<Extra thread 2a locked>
INFO:<Extra thread 2a unlocked>
INFO:<Extra thFAIL:<Thread 3 has not ended> Line: 338, File: /nios/Altera/kits/nios2_51/components/ecos/ecos-current/packages/kernel/current/tests/mutex3.cxx

   
-- 
Grant Edwards                   grante             Yow!  .. My pants just went
                                  at               on a wild rampage through a
                               visi.com            Long Island Bowling Alley!!


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] NIOS2 kernel tests failing

[Nick Garnett]

 Grant Edwards <grante@visi.com> writes:

> I've been unable to get all of the kernel tests to pass on a
> NIOS2 platform.  Four fail consistently:
> 
>    except1.cxx
>    kexcept1.cxx
>    kmutex3.c
>    mutex3.c
> 
> I presume the first two are expected failures because the
> -fno-exceptions flag is used during compilation.

The -fno-exceptions flag turns off C++ exceptions. These tests are
testing hardware exceptions, a totally different thing.

The programs attempt to provoke a hardware exception by first trying
to generate an alignment/bus error/memory management exception by
poking memory; if that fails it tries a divide by zero. If none of
these work, then the test will fail.

I don't know what exceptions the NIOS2 support, so either there are no
suitable exceptions supported, or there is something wrong in the HAL
level code that should deliver the exception to the kernel. Or maybe
something needs to be done in the hardware configuration to enable it.

> But, I don't
> know of any reason why the mutex3 tests shouldn't work.

I cannot see any reason for the mutex3 tests to fail. The fact that
they run through several permutations before failing is odd. Perhaps
it is a stack size or some other memory corruption issue. That is all
I can think it might be at present.


-- 
Nick Garnett                                     eCos Kernel Architect
http://www.ecoscentric.com                The eCos and RedBoot experts
http://www.ecoscentric.com/legal        Legal info, address and number


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: NIOS2 kernel tests failing

[Grant Edwards]

On 2007-01-02, Nick Garnett <nickg@ecoscentric.com> wrote:

>> I've been unable to get all of the kernel tests to pass on a
>> NIOS2 platform.  Four fail consistently:
>> 
>>    except1.cxx
>>    kexcept1.cxx
>>    kmutex3.c
>>    mutex3.c
>> 
>> I presume the first two are expected failures because the
>> -fno-exceptions flag is used during compilation.
>
> The -fno-exceptions flag turns off C++ exceptions. These tests are
> testing hardware exceptions, a totally different thing.

Ah.  That's a clue I was missing.  I'll put those two back on
my list of things to investigate.

> I don't know what exceptions the NIOS2 support, so either there are no
> suitable exceptions supported, or there is something wrong in the HAL
> level code that should deliver the exception to the kernel. Or maybe
> something needs to be done in the hardware configuration to enable it.

If it turns out there are no suitable exceptions supported, I
presume I should somehow disable the that test in CDL?

>> But, I don't know of any reason why the mutex3 tests shouldn't
>> work.
>
> I cannot see any reason for the mutex3 tests to fail. The fact
> that they run through several permutations before failing is
> odd. Perhaps it is a stack size or some other memory
> corruption issue. That is all I can think it might be at
> present.

Thanks.

-- 
Grant Edwards                   grante             Yow!  .. bleakness....
                                  at               desolation.... plastic
                               visi.com            forks...


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: NIOS2 kernel tests failing

[Nick Garnett]

 Grant Edwards <grante@visi.com> writes:

> On 2007-01-02, Nick Garnett <nickg@ecoscentric.com> wrote:

> > I don't know what exceptions the NIOS2 support, so either there are no
> > suitable exceptions supported, or there is something wrong in the HAL
> > level code that should deliver the exception to the kernel. Or maybe
> > something needs to be done in the hardware configuration to enable it.
> 
> If it turns out there are no suitable exceptions supported, I
> presume I should somehow disable the that test in CDL?

The programs also test user delivered exceptions, so it is not a good
idea to disable them entirely. There is already a rather nasty ifndef at
the start of the tests for the ARM PID target which disables the
hardware exception test. It would probably be more sensible to extend
that test to also include the NIOS2. Not nice, but given how rare
non-excepting hardware is, probably the least impact solution.


-- 
Nick Garnett                                     eCos Kernel Architect
http://www.ecoscentric.com                The eCos and RedBoot experts
http://www.ecoscentric.com/legal        Legal info, address and number


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: NIOS2 kernel tests failing

[Grant Edwards]

On 2007-01-02, Nick Garnett <nickg@ecoscentric.com> wrote:

>> I've been unable to get all of the kernel tests to pass on a
>> NIOS2 platform.  Four fail consistently:
>> 
>>    except1.cxx
>>    kexcept1.cxx

[...]

> The programs attempt to provoke a hardware exception by first
> trying to generate an alignment/bus error/memory management
> exception by poking memory;

There are no memory alignment or bus-error exceptions in the
NIOS2 processor and misaligned accesses are forbidden.  The
CPU's reference manual states that misaligned accesses result
in "undefined operation".  Strict interpreation of that allows
the CPU to do absolutely anything when a misaligned operation
occurs.  My guess is that instruction execution continues
normally with an undefined value in the destination register,
but the spec is pretty clear that it's simply not allowed, and
CPU can do absolutely anything if it does happen.

> if that fails it tries a divide by zero.

No execption for that, just undefined values in result
registers.

> If none of these work, then the test will fail.

And it does. :)

The only hardware exceptions that can be caused by software
are:

 trap
 break
 valid but unimplemented instruction

[The last one is different from an undefined (invalid)
instruction -- which again results in "undefined operation".]
 
> I don't know what exceptions the NIOS2 support, so either
> there are no suitable exceptions supported,

It appears there aren't, and doing things like misaligned
memory accesses may result in "udefined operation".

-- 
Grant Edwards                   grante             Yow!  I'm into SOFTWARE!
                                  at               
                               visi.com            


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: NIOS2 kernel tests failing

[Nick Garnett]

 Grant Edwards <grante@visi.com> writes:

> There are no memory alignment or bus-error exceptions in the
> NIOS2 processor and misaligned accesses are forbidden.  The
> CPU's reference manual states that misaligned accesses result
> in "undefined operation".  Strict interpreation of that allows
> the CPU to do absolutely anything when a misaligned operation
> occurs.  My guess is that instruction execution continues
> normally with an undefined value in the destination register,
> but the spec is pretty clear that it's simply not allowed, and
> CPU can do absolutely anything if it does happen.

The usual thing that happens is that the CPU ignores the least
significant 1 or 2 bits of the address, so misaligned accesses are
converted to aligned accesses silently. This used to be the default
for ARM, but it now has an option to raise an alignment exception.

> The only hardware exceptions that can be caused by software
> are:
> 
>  trap
>  break
>  valid but unimplemented instruction

Sadly, it looks like you are out of luck. Disabling the hardware part
of these tests seems the only thing to do.

-- 
Nick Garnett                                     eCos Kernel Architect
http://www.ecoscentric.com                The eCos and RedBoot experts
http://www.ecoscentric.com/legal        Legal info, address and number


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: NIOS2 kernel tests failing

[Grant Edwards]

On 2007-01-02, Nick Garnett <nickg@ecoscentric.com> wrote:
>  Grant Edwards <grante@visi.com> writes:
>
>> There are no memory alignment or bus-error exceptions in the
>> NIOS2 processor and misaligned accesses are forbidden.  The
>> CPU's reference manual states that misaligned accesses result
>> in "undefined operation". [...]
>
> The usual thing that happens is that the CPU ignores the least
> significant 1 or 2 bits of the address, so misaligned accesses are
> converted to aligned accesses silently.

I'm guessing that's what the NIOS2 does as well, but I haven't
verified it.

> This used to be the default for ARM,

Yea, I ran into that unintentionally a couple times. :/

> but it now has an option to raise an alignment exception.
>
>> The only hardware exceptions that can be caused by software
>> are:
>> 
>>  trap
>>  break
>>  valid but unimplemented instruction
>
> Sadly, it looks like you are out of luck. Disabling the
> hardware part of these tests seems the only thing to do.

I'll put that on the list of things to do.  I'd skip the test
entirely, but I gather there is a software portion that is
still doing something useful?

-- 
Grant Edwards                   grante             Yow!  The entire CHINESE
                                  at               WOMEN'S VOLLEYBALL TEAM all
                               visi.com            share ONE personality --
                                                   and have since BIRTH!!


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: NIOS2 kernel tests failing

[Nick Garnett]

 Grant Edwards <grante@visi.com> writes:

> > Sadly, it looks like you are out of luck. Disabling the
> > hardware part of these tests seems the only thing to do.
> 
> I'll put that on the list of things to do.  I'd skip the test
> entirely, but I gather there is a software portion that is
> still doing something useful?

Yes. In addition to fielding hardware exceptions, the kernel support
allows user code to raise an exception by calling
cyg_exception_call_handler(). The test does this to check that the
kernel-level support is functional. It's still worth testing that,
even though there are few hardware exceptions to make use of it.


-- 
Nick Garnett                                     eCos Kernel Architect
http://www.ecoscentric.com                The eCos and RedBoot experts
http://www.ecoscentric.com/legal        Legal info, address and number


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss