Conference hydra::axp-developer

3601.0. "Broner Group Ltd - Point 27769" by KZIN::ASAP () Thu May 08 1997 07:05

    Company Name :  Broner Group Ltd - Point 27769
    Contact Name :  Gordon Read
    Phone        :  441923254499
    Fax          :  441923816456
    Email        :  [email protected]
    Date/Time in :   8-MAY-1997 11:05:26
    Entered by   :  John Wood
    SPE center   :  REO

    Category     :  unix
    OS Version   :  3.2c
    System H/W   :  


    Brief Description of Problem:
    -----------------------------

From:	RDGENG::MRGATE::"RDGMTS::PMDF::mail.dec.com::Omuiri"  8-MAY-1997 10:01:46.81
To:	RDGENG::ASAP
CC:	
Subj:	ESCALATION: POINT  , Company  TO ASAP READING:

From:	NAME: Ciaran OMuiri <[email protected]@PMDF@INTERNET>
To:	NAME: '[email protected]' <IMCEAX400-c=US+3Ba=+20+3Bp=DIGITAL+3Bo=SBUEURMFG+3Bdda+3ASMTP=asap+40reo+2Emts+2Edec+2Ecom+3B@mail.dec.com@PMDF@INTERNET>

Hello -

POINT Log Number 27769	
Company Name  Broner Group Ltd	
Engineers name Gordon Read	
Telephone Number  441923254499		
Fax Number		441923816456		
E-mail Address	[email protected]

Operating System, Version	
Platform			

Problem Statement		
Has:
A/S 8000/300 with OSF/1 v3.2c
console v3.7-3
VMS powercode 5.53a
OSF powercode 1.45a

his customer has:
A/S 2100 with OSF/1 v3.2c
console v4.7-143
VMS powercode 5.56-6
OSF powercode 1.45-12

has a three line program which he compiles and links on his machine, 
works fine, but when porting the exe to customer it crashes:
	"instruction fault in addtsuid"
he has heard of patch to fix this called OSF350-002 but it only works 
with the console and powercode versions he has, and not those that his 
customer has.

He asked to have this esc to REO.

told him to send email to [email protected] with all the details so 
that we can pass it on to REO. Also gave fax number, he was having 
probs with email.
Dear Mark,

Our Alpha Machine is an 8000/300 Model, OSF1 V3.2C, C++ Version 
5.1-1.

Our customers Alpha is a 2100 4/233, OSF1 V3.2C, C++ Version 5.5-004.

We have the following C++ program (addd.cxx):

int main() {
double x = 4.3;
double y = 5.2;
double z = x + y;
}

Which is compiled and linked on our Alpha using the following 
statement:

cxx addd.cxx -O0 -g -o addd -Wc,-fprm,d -Wc,-fptm,sui 
-Wc,-resumption_safe

We are using a third party software library and the flags used here 
are simply a copy of the ones which have been used to compile the 
third party library.

This executable produced runs successfully on our Alpha.

When the executable is copied to the customers Alpha machine, it fails 
with the following error:

$ ./addd
inst fault=4, status word=               8, pc=       1200012c0
Illegal instruction(coredump)
$

When it is compiled and linked on our customers Alpha using C++ 
version 5.5-004, the executable produced runs successfully on both 
machines.

Debugging the executable produced on our machine (the 8000/300) gives 
the following:

$ dbx ./addd
dbx version 3.11.8
Type 'help' for help.

main:   2  double x = 4.3;
(dbx) stop in main
[2] stop in main
(dbx) run
[2] stopped at   [main:2 ,0x12000129c]  double x = 4.3;
(dbx) nexti
>*[main:2, 0x1200012a0]         ldt     $f10, -32768(r28)
(dbx) nexti
>*[main:2, 0x1200012a4]         stt     $f10, 16(sp)
(dbx) nexti
>*[main:3, 0x1200012a8]         ldq     r28, -32744(gp)
(dbx) nexti
>*[main:3, 0x1200012ac]         ldt     $f11, -32760(r28)
(dbx) nexti
>*[main:3, 0x1200012b0]         stt     $f11, 8(sp)
(dbx) nexti
>*[main:4, 0x1200012b4]         ldt     $f12, 16(sp)
(dbx) nexti
>*[main:4, 0x1200012b8]         ldt     $f13, 8(sp)
(dbx) nexti
>*[main:4, 0x1200012bc]         addtsuid        $f12,$f13,$f14
(dbx) nexti
>*[main:4, 0x1200012c0]         trapb
(dbx) nexti
>*[main:4, 0x1200012c4]         stt     $f14, 0(sp)
(dbx) nexti
>*[main:5, 0x1200012c8]         bis     r1, r1, r0
(dbx) quit
$

As can be seen, the executable produced by the version 5.1 compiler on 
our machine has generated an instruction 'addtsuid' at address 
0x1200012bc, it contains the modifiers passed via the -Wc compiler 
options (suid).

The program core dumps on our customers machine with an 'inst fault' 
trap error at the 'trapb' instruction at address 0x1200012c0. This is 
caused since the processor does not recognise the 'addtsuid' 
instruction at the previous addresss.

Debugging the executable produced on our customers machine (compiled 
using version 5.5-004 of the executable) gives the following:

$ dbx ./addd
dbx version 3.11.8
Type 'help' for help.

main:   2  double x = 4.3;
(dbx) stop in main
[2] stop in main
(dbx) run
[2] stopped at   [main:2 ,0x120001988]  double x = 4.3;
(dbx) nexti
>*[main:2, 0x12000198c]         ldt     $f10, 8(r28)
(dbx) nexti
>*[main:3, 0x120001990]         ldq     r28, -32728(gp)
(dbx) nexti
>*[main:3, 0x120001994]         ldt     $f1, 0(r28)
(dbx) nexti
>*[main:4, 0x120001998]         addt    $f10,$f1,$f0
(dbx) nexti
>*[main:5, 0x12000199c]         bis     r31, r31, r0
(dbx) nexti
>*[main:5, 0x1200019a0]         ret     r31, (r26), 1
(dbx) nexti
>*[__start, 0x1200017c0]        ldah    gp, 8192(r26)
(dbx) quit
$

The addition instruction at address 0x120001998 (addt) does not 
contain the modifiers passed to the compiler by the -Wc options.

We are aware that the 5.5-004 compiler may not be able to pass the s, 
u, i and d modifiers to the addt instruction using the -Wc option, but 
we have no documentation to that effect.

The 'real' question here is the following:

Why does the instruction 'addtsuid' cause the instruction fault error 
on our customers machine?

We have been made aware that there is a known problem of this nature 
with console version 3.7-3, VMS PALCode version V5.53A, OSF PALCode 
version V1.45A which requires firmware patch number OSF 350-202 
(specific to the Alpha 2100 and OSF1 V3.2C).

If our customers shuts down the machine and enters 'show config' at 
the '>>>' prompt, they obtain the following information:

Console version V4.7-143, VMS PALCode version V5.56-6 and OSF PALCode 
version X1.45-12

Is there also a similar problem with these versions, and, if so, is a 
patch available to fix this.

I have been asked to request that this problem be 'escalated' to The 
Software Partner Engineering Group at Reading.

Thanking you in advance.


yours sincerely

Gordon Read








In replying, please use [email protected]




RFC-822-headers:
Received: from reoexc1.reo.dec.com by rg71rw.reo.dec.com (PMDF V5.0-7 #15552)
 id <[email protected]> for [email protected]; Thu,
 08 May 1997 09:58:10 +0100
Received: by reoexc1.reo.dec.com with SMTP
 (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63)
 id <[email protected]>; Thu, 08 May 1997 10:00:02 +0100
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63

Date:	 8-MAY-1997 12:26:21.75
From:	DEC:.REO.REOVTX::WOOD_J       "[email protected]"
Subj:	Digital ASAP #27769: floating-point illegal instructions
To:	smtp%"[email protected]"

Hello Gordon,

I think we met at Broner several years ago...

Re. 

> $ ./addd
> inst fault=4, status word=               8, pc=       1200012c0
> Illegal instruction(coredump)
> $

Thankyou for your comprehensive problem report.

Further to your comment about the Digital UNIX OSF350-202 patch I attach a
description of this patch. The problem is not just specific to the Alphaserver
2100. Note also the comment about "When executing with OSF PALcode revision 
1.45, or GREATER, ...".

I found reference to several problem reports like yours; the solution to
these was to apply the patch OSF350-202. The patch comes as part of a patch-kit
known as DUV32CAS00001-19961217.tar.

Thus I recommend that you customer contacts their local Digital Customer
Support Centre and requests this patch, using the OSF350-202 and 
DUV32CAS00001-19961217.tar. reference numbers, and applies it.

Let me know how you get on.

Note I will be out next week, thus if the patch does not solve the problem
please e-mail my colleague [email protected] (and copy me), and
Nick will try to help.

Regards,
  John Wood		[email protected]
  Software Partner Engineering (UK)
  Digital Equipment Co
------------------------


PROBLEM:  ( QAR 40124 )         (Patch ID: OSF350-202)
********
When executing with OSF PALcode revision 1.45, or greater, with Digital UNIX
V3.2, V3.2B, V3.2C, V3.2D-1, V3.2E-1, V3.2D-2, or V3.2E-2 some floating point
instructions fail.

Some floating point instructions fail and cause the message on the console:
       "unknown OPDEC from ieee emulation"
There may also be user output instruction fault messages such as:
       "inst fault=4, status word=               8, pc=     3ff80128e50"
       "Illegal instruction (core dumped)"

The following table identifies the machines that may have this
problem.

      Platform                Firmware Minimum Rev
      --------                --------------------
      DECpc AXP 150           SRM Console V2.2
      DEC 2000 AXP            SRM Console V2.2
      DEC 3000 AXP            Console V6.5
      DEC 4000 AXP            Console V3.7
      AlphaStation 2x0/400    SRM Console V6.0
      AlphaServer 400         SRM Console X4.4
      AlphaStation 255        SRM Console V6.0
      AlphaServer 1000/1000A  SRM Console V3.1-21
      AlphaServer 2000/2100   SRM Console V4.4
      DEC 7000/10000 AXP      LFU V11
      Digital AXPvme          Console V15.0
      DECAXPPC133             SRM Console X4.3-3114

To determine the revision of the OSF PALcode, do one of the following:
 
  1)  Look for the following line in the output from Digital UNIX as it boots.
             PALcode: OSF version 1.45
  2)  At the console prompt prior to booting Digital UNIX, type "show config".
        >>>show config
             Console V3.7-3                    VMS PALcode V5.53A, 
                                               OSF PALcode V1.45A
                                          Note: V1.45A is the same as V1.45.
                                                       
Common floating point operations will reproduce the problem.  For example:

floor.c
-------

#include <math.h>

main()
{
   double dd = (double)0.019999999552965164;
   double int_dd;

   int_dd = floor(dd);

   printf("dd = %f    int_dd = %f\n", dd, int_dd);
}

Compiling with:
---------------


  cc   floor.c  -o floor

Executing:
---------

  floor

inst fault=4, status word=               8, pc=     3ff80128e50
Illegal instruction (core dumped)

Date:	30-MAY-1997 11:52:50.99
From:	RDGENG::MRGATE::"RDGMTS::VBEMDF::PMDF::broner.co.uk::dmallett"
Subj:	Digital ASAP #27769

From:	NAME: David Mallett <[email protected]@PMDF@INTERNET>
To:	NAME: 'John Wood' <John.Wood@reo>

Hello John. 

Our customers have now added patch number OSF350-290 which, apparently,
supersedes the patch number you gave us (OSF350-202).

All now appears to be working correctly. 

Many thanks for your time.

Gordon Read
[email protected]