Bug 106253 - elilo 3.3a-3 crashes on SGI Altix, 3.3a-2 OK
Summary: elilo 3.3a-3 crashes on SGI Altix, 3.3a-2 OK
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: binutils   
(Show other bugs)
Version: 3.0
Hardware: ia64 Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2003-10-04 06:02 UTC by erikj
Modified: 2007-11-30 22:06 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-05-10 16:26:25 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
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 14:56 UTC, erikj
no flags Details

Description Red Hat Bugzilla 2003-10-04 06:02:07 UTC
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):

How reproducible:

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 05:25:54 UTC
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 19:37:26 UTC
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). 

Comment 3 Red Hat Bugzilla 2004-01-08 14:54:39 UTC
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

Hi Brian,

> Although I tried your commands above with binutils, 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

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


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 14:56:10 UTC
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.