Bug 106253 - elilo 3.3a-3 crashes on SGI Altix, 3.3a-2 OK
elilo 3.3a-3 crashes on SGI Altix, 3.3a-2 OK
Status: CLOSED NEXTRELEASE
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: binutils (Show other bugs)
3.0
ia64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-10-04 02:02 EDT by Erik Jacobson
Modified: 2007-11-30 17:06 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-05-10 12:26:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch from Nick Clifton to solve elilo crashing problem (940 bytes, text/plain)
2004-01-08 09:56 EST, Erik Jacobson
no flags Details

  None (edit)
Description Red Hat Bugzilla 2003-10-04 02:02:07 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; T312461; .NET 
CLR 1.1.4322)

Description of problem:
On Altix, the elilo.efi found in elilo 3.3a-3 crashes in to our power on diags 
(POD).  We can resume out of the diags and elilo will continue running.

I found that, with elilo 3.3a-2, elilo works normally on our platform.

I checked for differences between 3.3a-3 and 3.3a-2.  The only real difference 
is efibootmgr.

I installed gnu-efi 3.0-1 on the AS 3 beta Altix system, and built SRPMS for 
both 3.3a-2 and 3.3a-3.  Both crash in to POD in the same way.  In addition, I 
tried the gcc296 compiler instead.  Still  trouble.  

I tried several other things I'll omit here because they didn't
make a difference.

Finally, I built the elilo 3.3a-3 SRPM on an AS 2.1 system.
The resulting elilo.efi works fine for Altix.

I'm not sure yet why the elilo built on AS3beta chokes Altix while
working on other platforms.  If you have any suggestions, please let me know.

This issue is being tracked inside SGI as incident 901632.

Version-Release number of selected component (if applicable):
elilo-3.3a-3

How reproducible:
Always

Steps to Reproduce:
1. Boot Altix with elilo 3.3a-3 RPM elilo.efi - elilo fails.
2. Boot Altix with elilo 3.3a-2 RPM elilo.efi - elilo works.
3. Build SRPMs for both of the above on AS3beta - elilo will fail for Altix 
for both resulting rebuilt RPMs.
4. Build SRPMS for both of the above on AS2.1, elilo will work on Altix.
    

Additional info:
Comment 1 Red Hat Bugzilla 2003-10-06 01:25:54 EDT
No suggestions off of the top of my head. If you've got a continuous set of
compilers around, try and see which one breaks it. The fact that the same code
works depending on what you build it with implies something compiler-related.
Comment 2 Red Hat Bugzilla 2004-01-05 14:37:26 EST
It looks like the version of binutils (the linker specifically, but 
probably bfd in general) currently released in Red Hat AS 3.0 sets 
the VirtualSize of the EFI executable to 0.  While it appears that 
object files are supposed to have that field clear (a rule that MS 
linkers apparently ignore), executables should have it set correctly 
(from the Microsoft Portable Executable and Common Object File 
Format Specification, Revision 6.0 - February 1999, section 4). 
 
Jesse 
Comment 3 Red Hat Bugzilla 2004-01-08 09:54:39 EST
Would it be possible to get this fix in to binutils?  Here is a
message (forwarded to me by Brian Johnson here at SGI).  I'll see
about attaching the referenced patch as well as pasting it below.

>From nickc@redhat.com Thu Jan  8 08:38:26 2004
Date: Thu, 08 Jan 2004 11:34:41 +0000
From: Nick Clifton <nickc@redhat.com>
To: Brian J. Johnson <bjohnson@sgi.com>
Cc: binutils@sources.redhat.com
Subject: Re: IA64 PE/COFF (efi-app-ia64) image has bad VirtualSize
field

Hi Brian,

> Although I tried your commands above with binutils 2.14.90.0.4, and
> got a zero for VirtualSize.  So it seems to be binutils version
> related.  Do you have an older build handy you could try?

Yes - in fact I was able to use a binary chop method to locate the
exact problem.  It was this change to peicode.h:

  2003-04-03  Nick Clifton  <nickc@redhat.com>

        * peXXigen.c (_bfd_XXi_swap_scnhdr_out): Compute ps and ss
        differently for object files and executables.
        * peicode.h (coff_swap_scnhdr_in): Only set the s_size field
        for object files or for executables who have not already
        initialised the field.
        * libpei.h (bfd_pe_executable_p): New macro.  Return true if
        the PE format bfd is an executable.

which was later fixed by this patch:

  2003-08-18  Andreas Schwab  <schwab@suse.de>

        * libpei.h (bfd_pe_executable_p): Also recognize efi-app
        executables.

Hence applying the attached patch to your 2.14 sources and then
rebuilding/reinstalling should fix the problem.

Cheers
        Nick

Index: bfd/libpei.h
===================================================================
RCS file: /repositories/repositories/sourceware/src/bfd/libpei.h,v
retrieving revision 1.10
diff -c -3 -p -r1.10 libpei.h
*** bfd/libpei.h        3 Apr 2003 11:13:26 -0000       1.10
--- bfd/libpei.h        8 Jan 2004 11:32:07 -0000
*************** bfd_boolean _bfd_XX_bfd_copy_private_sec
*** 332,335 ****
    PARAMS ((bfd *, asection *, bfd *, asection *));
  
  /* Macro: Returns true if the bfd is a PE executable as opposed to a
PE object file.  */
! #define bfd_pe_executable_p(abfd)  (strncmp ((abfd)->xvec->name,
"pei-", 4) == 0)
--- 332,338 ----
    PARAMS ((bfd *, asection *, bfd *, asection *));
  
  /* Macro: Returns true if the bfd is a PE executable as opposed to a
PE object file.  */
! #define bfd_pe_executable_p(abfd) \
!   (strncmp ((abfd)->xvec->name, "pei-", 4) == 0               \
!    || strncmp ((abfd)->xvec->name, "efi-app-", 8) == 0)
! 
Comment 4 Red Hat Bugzilla 2004-01-08 09:56:10 EST
Created attachment 96828 [details]
Patch from Nick Clifton to solve elilo crashing problem

Note You need to log in before you can comment on or make changes to this bug.