Oberon Community Platform Forum
November 21, 2019, 07:02:56 AM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News:
 
   Home   Help Search Login Register  
Pages: [1]
  Print  
Author Topic: Problem with last two releases  (Read 8295 times)
adamss937
Newbie
*
Posts: 10


« on: April 25, 2013, 06:11:39 AM »

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)


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

Logged
fld
Newbie
*
Posts: 15


« Reply #1 on: April 25, 2013, 12:38:00 PM »

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
Logged
adamss937
Newbie
*
Posts: 10


« Reply #2 on: April 25, 2013, 10:46:51 PM »

No problem - I can wait for the next release.  Thanks.
Logged
Bernhard T.
Administrator
Full Member
*****
Posts: 164


« Reply #3 on: April 29, 2013, 02:54:02 PM »

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
« Last Edit: April 29, 2013, 03:08:07 PM by Bernhard T. » Logged
adamss937
Newbie
*
Posts: 10


« Reply #4 on: May 01, 2013, 08:24:37 PM »

Pentium III.  Running in one of ThinkPad T22 or T23
Logged
Bernhard T.
Administrator
Full Member
*****
Posts: 164


« Reply #5 on: May 02, 2013, 01:22:18 PM »

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
Logged
fld
Newbie
*
Posts: 15


« Reply #6 on: May 03, 2013, 12:54:14 PM »

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
Logged
adamss937
Newbie
*
Posts: 10


« Reply #7 on: July 12, 2013, 06:01:16 AM »

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.
Logged
fld
Newbie
*
Posts: 15


« Reply #8 on: July 12, 2013, 04:52:44 PM »

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

Logged
adamss937
Newbie
*
Posts: 10


« Reply #9 on: July 19, 2013, 07:58:06 PM »

That worked great, thanks.
Logged
peasthope
Full Member
***
Posts: 100


WWW
« Reply #10 on: September 11, 2013, 04:10:31 AM »

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.
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!