Problem with last two releases

[adamss937]

On some systems, the last two releases crash immediately upon startup.  Rev.5165 and earlier work just fine.  The log file contents are:

LinuxAos (rev.5295): Kernel: Initialized and started.
X11 Display depth = 16


LinuxAos (rev.5295)   2013/04/25  00:40

Trap 4 (Illegal instruction)

    sp = 00000000, fp = B702DBD8, pc = B72D5143

Strings.StrToFloat:202 pc=11131 [00002B7BH] = 10929 + 202 crc=A1AAE660
  s="10.0000"
  r=

LinuxAos (rev.5295)   2013/04/25  00:40

==== recursive Trap4 (Illegal instruction)


----------------------------------------------------


[fld]

The older releases of UnixAos use the valloc() routine to require heap space.
But in the Linux and Unix manuals valloc() is marked obsolete and devellopers
are requested to use posix_memalign() instead. The latest release of UnixAos
switched to posix_memalign().

Unfortunately on some recent Linux distributions only the obsoleted valloc()
routine works well and posix_memalign() fails. Therefor the newest UnixAos
boot loader 'aos.linux' maps posix_memalign() to valloc(). If you can't wait
for the next release of UnixAos you can fetch the new boot loader from the
A2 repository:

   https://www.ocp.inf.ethz.ch/svn/aos/trunk/UnixAos/boot/aos.linux

-- Günter

[adamss937]

No problem - I can wait for the next release.  Thanks.

[Bernhard T.]

With Rev. 5221 Felix switched the default floating point code generation mode from FPU to SSE2.

What kind of CPU do you have? Does it have full SSE2 support?

I had the same problems (recursive traps) with an older Pentium III and WinAOS.

According to Felix it should be possible to force FPU code, but I preferred to move to newer CPUs.

regards
--
  Bernhard

[adamss937]

Pentium III.  Running in one of ThinkPad T22 or T23

[Bernhard T.]

Pentium III.  Running in one of ThinkPad T22 or T23

this is the reason for the problems.

I do not (yet) understand the build process in depth, so I can neither give any advice, which MODULEs should be compiled with the --useFPU flag nor how to incorporate that into the build process.

Felix Friedrich wrote in German something like: "Background: We switched the floating point implementation completely from FPU to SSE registers.  But there is a compiler-flag --useFPU, which might be used for building a Release with FPU-support."

In the following small discussion, it became obvious that some codes use SSE2 instructions, which are not available on the PIII.

Building the complete release on a P4 (2.8GHz/1GB memory) takes less than five minutes, so that should not pose a problem.

regards
--
  Bernhard

[fld]

To create a new system which uses FPU instead of SSE the following
two modifications in file "Release.Tool" should be sufficient:

<LinuxAos {
<      INCLUDE "UNIX LINUX"
<      COMPILER "Compiler.Compile"
<      COMPILEOPTIONS ""
      
>LinuxAos {
>      INCLUDE "UNIX LINUX"
>      COMPILER "Compiler.Compile"
>      COMPILEOPTIONS "--useFPU"

   

<      # Runtime support for math oberon (Move to runtime package? *)
<      I386, WIN, UNIX { XMM.I386.Math.Mod XMM.I386.MathL.Mod }

>     # Runtime support for math oberon (Move to runtime package? *)
>   I386, WIN, UNIX { I386.Math.Mod I386.MathL.Mod }

-- Günter

[adamss937]

I thought that the 3 Jul 2013 release would correct the issue with the system not running on older PCs.  However, it has the same problem as before.

[fld]

Hi,

I now added an additional tar file 'LinuxAos_oldHW.tgz'. It has been compiled
with option --useFPU and modules I386.Math*.Mod instead of XMM.I386.Math*.Mod.

Don't forget to use the --useFPU compiler option when compiling your own software
as the new compiler emits SSE instructions by default.

-- Guenter

[adamss937]

That worked great, thanks.

[peasthope]

Unfortunately on some recent Linux distributions only the obsoleted valloc()
routine works well and posix_memalign() fails.

Suppose the SSE version is used on an older CPU.  Is the result always a complete freeze of UnixAOS?  Can UnixAOS have most functionality while more subtle failures exist?

With at least one earlier installation, the Mail.Panel in the Oberon subsystem retrieved messages by POP3.  An installation also sent messages.  Not sure both sending and receiving worked in one system.  Now with 5348 only one blank message is ever retrieved, regardless of what is waiting on the server.  I've checked configurations several times in recent days.  Still wonder whether I have a blunder or FPU/SSE is involved or a new bug has surfaced.  cpuinfor is here.
http://carnot.yi.org/cpuinfo.dalton.txt

Thanks for any answer or suggestion,             ... Peter E.