Bug 239658 - Fedora 7 Test 4 (6.93) provided netboot image doesn't boot Power5 machines
Fedora 7 Test 4 (6.93) provided netboot image doesn't boot Power5 machines
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: yaboot (Show other bugs)
9
powerpc Linux
medium Severity high
: ---
: ---
Assigned To: Paul Nasrat
Brian Brock
: Reopened
Depends On:
Blocks: FC7Target
  Show dependency treegraph
 
Reported: 2007-05-10 07:44 EDT by IBM Bug Proxy
Modified: 2011-10-13 11:31 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 13:14:57 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)
Link zImage at 64Mb rather than 4Mb. Move real-base from 12Mb to 32Mb (3.25 KB, text/plain)
2008-05-26 02:24 EDT, IBM Bug Proxy
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
IBM Linux Technology Center 34545 None None None Never

  None (edit)
Description IBM Bug Proxy 2007-05-10 07:44:54 EDT
LTC Owner is: amitarora@in.ibm.com
LTC Originator is: joseferr@br.ibm.com


Problem description:

When trying to install F7-test4 using a netboot image at Power5 and Power5+
machines, the kernel doesn't boot.

This is reproducible, and the steps to reproduce are:
1) Enter the HMC for the machine which will be installed
2) Reboot the desired machine using chsysstate.
3) Enter the desired machine using vtmenu.
4) Configure the netboot options using SMS menu.
5) Boot from the image server.

At this point, the machine will request the image using tftp, and by time it
tries to boot, it fails. This is the output:

BOOTP: chosen-network-type = ethernet,auto,rj45,auto
BOOTP: server   IP =        x.x.xxx.xx
BOOTP: requested filename =
BOOTP: client   IP =        x.x.xxx.xxx
BOOTP: client   HW addr =   0 d 60 f4 1f d2
BOOTP: gateway  IP =        x.x.xxx.x
BOOTP: device    /pci@800000020000001/pci@2,2/ethernet@1
BOOTP: loc-code  U787D.001.1234567-P1-T1


icmp 5 : redirect
BOOTP R = 1 BOOTP S = 2
FILE: ppc64.img
FINAL Packet Count = 18562
FINAL File Size = 9503484 bytes.
load-base=0x4000
real-base=0xc00000
CLAIM failed
Call History
------------
throw  - c3903c
$call-method  - c46cc8
(poplocals)  - c3a710
(init-program)  - c7da28
boot  - c7e66c
evaluate  - c4a5b8
create-single-mem-node  - da4140
invalid pointer - 4
invalid pointer - 4
quit  - c4ac78
quit  - c4aa60

My Fix Pt Regs:
 00 0000000000000000 0000000000000000 00000000deadbeef 0000000000c46cc4
 04 0000000000c3fda0 0000000000000004 0000000000c11f60 0000000000c03010
 08 0000000010000000 0000000000000004 000000001000000f 80000000001c3b80
 0c 0000000000004000 0000000000c17100 0000000000c18000 00000000000e85e0
 10 0000000000f48393 0000000000f4812b 0000000000c46cc0 0000000000c46cc8
 14 fffffffffffffffe 0000000000004000 0000000000000000 0000000000000000
 18 0000000000c13000 0000000000c38000 0000000000c14fc0 0000000000c16fc0
 1c 0000000000c20000 0000000000c3fda8 0000000000c11fa8 0000000000c10ff8
Special Regs:
    %IV: 00000900     %CR: 22808000    %XER: 20000001  %DSISR: 00000000
  %SRR0: 0000000000c3eaa8   %SRR1: 800000000000b002
    %LR: 0000000000c3ad44    %CTR: 80000000001af404
   %DAR: 0000000000000000
PFW: Unable to send error log!
 ok
0 >

The " 0 > " is the SLOF prompt, returning the control to the open firmware.

This problem is found when using both ppc32 and ppc64 images, found at
images/netboot/ directory of the ISO.

This machines can boot F7-test3 and F6 netboot images from the same server.

 -Jose Otavio
---------------------------------------------------------------------------------

I included this bug at "ship issue" level, because we don't know if this problem
would show up for a install based on a burned CD or DVD. We've seen this problem
using the netboot images. That's the reason why this isn't a "block".
In case someone else has seen similar problems with the other install
possibilities, this would change.

It is interesting to notice that the same ppc64.img has been used to sucessfully
install QS20 (Cell) machines, from the same image server. 

 -Jose Otavio
Comment 1 IBM Bug Proxy 2007-05-11 13:50:25 EDT
----- Additional Comments From joseferr@br.ibm.com  2007-05-11 13:46 EDT -------
Amit, 

I was able to normally boot a Fedora 6.93 burned CD at one of the machines.
Everything works as it should, using the ISO CD approach. No changes to the
netboot image tho, so I'm leaving this as a ship issue. 
Comment 2 Will Woods 2007-05-11 20:38:49 EDT
At this point in the boot process, I'm not sure if control has transferred to
the kernel image yet... David, are you aware of changes between f7t3 and f7t4
that could cause a problem with netbooting?
Comment 3 David Woodhouse 2007-05-12 01:09:31 EDT
Not unless it's just a problem with the size of the image -- which is actually
not unheard-of.
Comment 4 IBM Bug Proxy 2007-05-17 06:30:45 EDT
----- Additional Comments From amitarora@in.ibm.com  2007-05-17 06:24 EDT -------
RedHat Team,

Is there anything that we can try and help to get more information on this bug ? 
Comment 5 IBM Bug Proxy 2007-05-17 08:41:13 EDT
------- Additional Comments From joseferr@br.ibm.com  2007-05-17 08:34 EDT -------
(In reply to comment #15)
> ----- Additional Comments From dwmw2@redhat.com  2007-05-12 01:09 EST -------
> Not unless it's just a problem with the size of the image -- which is actually
> not unheard-of.
> 
> -- 

I tried to use 3 different machines as servers, which used 3 different
downloaded ISOs and they all had the sha1sum checked, without any troubles. None
of the images/netboot/ppc64.img provided by the ISOs worked.
Thinking it could be something specific for the files of the 6.93's ISO, I tried
to use 0427 and 0511 rawhide ppc64 netboot images, and they didn't work either.
The test4 ppc64.img is 9.1 MB X test3 is 9.0 MB.

I think this is what I could say about the sizes for now. Thanks. 
Comment 6 IBM Bug Proxy 2007-06-05 02:35:31 EDT
----- Additional Comments From amitarora@in.ibm.com  2007-06-05 02:33 EDT -------
Redhat Team,

Are you able to reproduce the problem at your side ? What should be the next
step here to proceed further ? 
Comment 7 IBM Bug Proxy 2007-06-05 10:00:44 EDT
------- Additional Comments From joseferr@br.ibm.com  2007-06-05 09:59 EDT -------
(In reply to comment #19)
> Redhat Team,
> 
> Are you able to reproduce the problem at your side ? What should be the next
> step here to proceed further ? 

Fedora 7 was GA'd last thursday and the new netboot images provided with the ISO
don't boot the previous mentioned machines too.
the files are $ISO/images/netboot/ppc[32|64].img
This issue had previously entered a "to do" list from Fedora to correct it. 
Comment 8 IBM Bug Proxy 2007-07-02 06:35:15 EDT
----- Additional Comments From amitarora@in.ibm.com  2007-07-02 06:32 EDT -------
Redhat,

Any update here, plz ? 
Comment 9 David Woodhouse 2007-12-03 07:16:42 EST
Apologies for the delay. Please could you try the netboot image at
http://david.woodhou.se/zImage.f8 which is a Fedora 8 installer.

This uses the zImage wrapper code from the kernel rather than an old copy which
we made some time ago. If this doesn't work, then it's an upstream issue which
we can continue to pursue.

7e2a0319a1cb48d84234350005db0d0d  zImage.f8
Comment 10 James Laska 2007-12-03 08:00:03 EST
Attempting to boot the zImage.f8 posted in comment#9, I hit the following on
several power5 systems:

0 > boot network:,\ppc\zImage.f8
BOOTP: chosen-network-type = ethernet,auto,rj45,auto
BOOTP: server   IP =        0.0.0.0
BOOTP: requested filename = \ppc\zImage.f8
BOOTP: client   IP =        0.0.0.0
BOOTP: client   HW addr =   0 11 25 7e 28 64
BOOTP: gateway  IP =        0.0.0.0
BOOTP: device    /pci@800000020000002/pci@2/ethernet@1
BOOTP: loc-code  U789F.001.AAA0060-P1-T1


BOOTP R = 1 BOOTP S = 2 
FILE: /ppc/zImage.f8
FINAL Packet Count = 21106 
FINAL File Size = 10805829 bytes.
load-base=0x4000 
real-base=0xc00000 
CLAIM failed
Call History
------------
throw  - c3903c 
$call-method  - c46d48 
(poplocals)  - c3a738 
(init-program)  - c7d728 
boot  - c7e36c 
evaluate  - c4a638 
invalid pointer - e03c1d 
invalid pointer - 7 
invalid pointer - 7 
quit  - c4acf8 
quit  - c4aae0 

My Fix Pt Regs:
 00 0000000000000000 0000000000000000 00000000deadbeef 0000000000c46d44
 04 0000000000c3fdc8 0000000000000007 0000000000c11f60 0000000000c03010
 08 0000000008000000 0000000000000004 000800001c00000f 80000000001c3b80
 0c 0000000000004000 0000000000c17100 0000000000c18000 00000000000e86b0
 10 0000000000e80574 0000000000e80298 0000000000c46d40 0000000000c46d48
 14 fffffffffffffffe 0000000000004000 0000000000000000 0000000000000000
 18 0000000000c13000 0000000000c38000 0000000000c14fc0 0000000000c16fc0
 1c 0000000000c20000 0000000000c3fdd0 0000000000c11fa8 0000000000c10ff8
Special Regs:
    %IV: 00000900     %CR: 22808000    %XER: 20000001  %DSISR: 00000000 
  %SRR0: 0000000000c3c808   %SRR1: 800000000000b002 
    %LR: 0000000000c3ad6c    %CTR: 0000000000c46d0c 
   %DAR: 0000000000000000 
PFW: Unable to send error log!
 ok
0 >
Comment 11 David Woodhouse 2007-12-03 08:18:36 EST
I believe that error is from the firmware, having failed to load the image.

Is there someone on the IBM side who knows more about the firmware limitations? 
Comment 12 David Woodhouse 2007-12-04 20:37:46 EST
Please could you also test http://david.woodhou.se/zImage.f8.16MiB and
http://david.woodhou.se/zImage.f8.32MiB
Comment 13 James Laska 2007-12-05 07:46:47 EST
(In reply to comment #12)
> http://david.woodhou.se/zImage.f8.16MiB 

0 > boot network:,\ppc\zImage.f8.16MiB 
BOOTP: chosen-network-type = ethernet,auto,none,auto
BOOTP: server   IP =        0.0.0.0
BOOTP: requested filename = \ppc\zImage.f8.16MiB
BOOTP: client   IP =        0.0.0.0
BOOTP: client   HW addr =   46 2a b0 0 70 2
BOOTP: gateway  IP =        0.0.0.0
BOOTP: device    /vdevice/l-lan@30000002
BOOTP: loc-code  U9123.710.10004CA-V7-C2-T1

BOOTP: wait 60 seconds for Spanning Tree ... 

BOOTP R = 1 BOOTP S = 2 
FILE: /ppc/zImage.f8.16MiB
FINAL Packet Count = 21106 
FINAL File Size = 10805829 bytes.
load-base=0x4000 
real-base=0xc00000 
CLAIM failed
Call History
------------
throw  - c3903c 
$call-method  - c46d48 
(poplocals)  - c3a738 
(init-program)  - c7d728 
boot  - c7e36c 
evaluate  - c4a638 

 Lœ›ߖxâM!§ë¨/¥µЪØm¹»¥ʹߓBX³Z·Ǝa6ЮÜ   Ñ6è]Ó²DmÚ÷K–8  - c17100 
invalid pointer - 83 
invalid pointer - 83 
quit  - c4acf8 
quit  - c4aae0 

My Fix Pt Regs:
 00 0000000000000000 0000000000000000 00000000deadbeef 0000000000c46d44
 04 0000000000c3fdc8 0000000000000083 0000000000c11f60 0000000000c03010
 08 0000000008000000 0000000000000000 0000000000000000 80000000000d8cb4
 0c 0000000000004000 0000000000c17100 0000000000c18000 00000000000e86b0
 10 0000000000de4f38 0000000000de4d08 0000000000c46d40 0000000000c46d48
 14 fffffffffffffffe 0000000001bfd4c0 0000000000000000 0000000000000000
 18 0000000000c13000 0000000000c38000 0000000000c14fc0 0000000000c16fc0
 1c 0000000000c20000 0000000000c3fdd0 0000000000c11fa8 0000000000c10ff8
Special Regs:
    %IV: 00000900     %CR: 42808000    %XER: 20000008  %DSISR: 00000000 
  %SRR0: 0000000000c3a43c   %SRR1: 800000000000b002 
    %LR: 0000000000d2db44    %CTR: 0000000000c3ad38 
   %DAR: 0000000000000000 
PFW: Unable to send error log!
 ok

> http://david.woodhou.se/zImage.f8.32MiB

BOOTP R = 1 BOOTP S = 2 
FILE: /ppc/zImage.f8.32MiB
FINAL Packet Count = 21106 
FINAL File Size = 10805829 bytes.
load-base=0x4000 
real-base=0xc00000 

Elapsed time since release of system processors: 11343 mins 33 secs

zImage starting: loaded at 0x02000000 (sp: 0x0199fea0)
Allocating 0x825eb0 bytes for kernel ...
OF version = 'IBM,SF240_219'
gunzipping (0x02b00000 <- 0x02007000:0x022881d5)...done 0x771000 bytes
Attached initrd image at 0x02289000-0x02a3c547
initrd head: 0x1f8b0800

Linux/PowerPC load: 
Finalizing device tree... using OF tree (promptr=00c39a48)
...
Starting Linux PPC64 #1 SMP Tue Oct 30 13:05:49 EDT 2007
-----------------------------------------------------
ppc64_pft_size                = 0x19
physicalMemorySize            = 0x40000000
ppc64_caches.dcache_line_size = 0x80
ppc64_caches.icache_line_size = 0x80
htab_address                  = 0x0000000000000000
htab_hash_mask                = 0x3ffff
-----------------------------------------------------
Linux version 2.6.23.1-42.fc8 (kojibuilder@ppc4.fedora.phx.redhat.com) (gcc
version 4.1.2 20070925 (Red Hat 4.1.2-33)) #1 SMP Tue Oct 30 13:05:49 EDT 2007
...
Welcome to Fedora for ppc

                   +---------+ Choose a Language +---------+
                   |                                       |
                   | What language would you like to use   |
                   | during the installation process?      |
                   |                                       |
                   |       Catalan                ^        |
                   |       Chinese(Simplified)    :        |
                   |       Chinese(Traditional)   #        |                    
                   |       Croatian               :        |                    
                   |       Czech                  :        |                    
                   |       Danish                 :        |                    
                   |       Dutch                  :        |                    
                   |       English                v        |
                   |                                       |
                   |                +----+                 |
                   |                | OK |                 |
                   |                +----+                 |
                   |                                       |
                   |                                       |
                   +---------------------------------------+

Comment 14 IBM Bug Proxy 2007-12-10 02:25:31 EST
------- Comment From mohd.omar@in.ibm.com 2007-12-10 02:21 EDT-------
Hi David,

Whether this BUG helps you? https://bugzilla.novell.com/show_bug.cgi?id=335580#c3
I think there is a limitation of size to be loaded via tftp on Power boxes. I
too faced this problem.

As a workaround I used suse yaboot to load ppc64.img. F8 yaboot gives me a error
"Claim error, can't allocate kernel memory".

One more workaround is to load
/ppc/ppc64/vmlinuz
/ppc/ppc64/ramdisk.image.gz
via yaboot.

--Regards
Omar
Comment 15 David Woodhouse 2007-12-10 08:51:57 EST
Assigning to yaboot then. We'll need it to handle TFTP of large files...
Comment 16 IBM Bug Proxy 2008-01-30 22:56:36 EST
------- Comment From mohd.omar@in.ibm.com 2008-01-30 22:55 EDT-------
Hi David,

F9alpha netboot image also doesn't works on Power5.

--log---
BOOTP: chosen-network-type = ethernet,auto,none,auto
BOOTP: server   IP =        0.0.0.0
BOOTP: requested filename =
BOOTP: client   IP =        0.0.0.0
BOOTP: client   HW addr =   36 cb 20 0 40 2
BOOTP: gateway  IP =        0.0.0.0
BOOTP: device    /vdevice/l-lan@30000002
BOOTP: loc-code  U9133.55A.06DF42G-V4-C2-T1

BOOTP: wait 60 seconds for Spanning Tree ...

BOOTP R = 1 BOOTP S = 2
FILE: ppc64.img
FINAL File Size = 12566528 bytes.
load-base=0x4000
real-base=0xc00000
\
Elapsed time since release of system processors: 273187 mins 25 secs

--Regards
Omar
Comment 17 Paul Nasrat 2008-01-30 23:58:53 EST
Can you try latest yaboot git (http://yaboot.ozlabs.org has instructions) a
binary is here:

http://people.fedoraproject.org/~pnasrat/yaboot


You'll have to run /usr/lib/yaboot/addnote /tmp/yaboot on it first I think, and
netboot that yaboot 
Comment 18 IBM Bug Proxy 2008-01-31 03:24:31 EST
------- Comment From mohd.omar@in.ibm.com 2008-01-31 03:16 EDT-------
Hi paul,
The latest yaboot git http://people.fedoraproject.org/~pnasrat/yaboot could pick
up the netboot image "ppc64.img" correctly. It works fine. I wonder if it can be
incorporated with F9alpha before releasing it(scheduled for 5Feb08).

--Regards
Omar
Comment 19 IBM Bug Proxy 2008-01-31 03:48:28 EST
------- Comment From mohd.omar@in.ibm.com 2008-01-31 03:42 EDT-------

Does we need 'yaboot' for netboot ? It suppose to work individually.It was a
work around that I used 'yaboot' to load "ppc64.img". Can we improve netboot
image to get loaded via tftp without using yaboot?

--Regards
Omar
Comment 20 David Woodhouse 2008-01-31 05:57:34 EST
(In reply to comment #19)
> Does we need 'yaboot' for netboot ? It suppose to work individually.It was a
> work around that I used 'yaboot' to load "ppc64.img". Can we improve netboot
> image to get loaded via tftp without using yaboot?

No, I believe the size limit is in IBM's firmware -- you'd have to fix the
firmware. Alternatively, please suggest a link address which might work...

Otherwise, I think netbooting via yaboot is the way forward... at least on boxes
with problematic firmware. The stock ppc64.img works fine on my Electra...
Comment 21 David Woodhouse 2008-01-31 05:59:42 EST
Hm. Comment #13 suggests that a link address of 32MiB should work. Can you
confirm that this will work on all versions of IBM firmware? I had a distinct
recollection that it didn't work on some machines.
Comment 22 IBM Bug Proxy 2008-01-31 07:08:36 EST
------- Comment From jwboyer@us.ibm.com 2008-01-31 07:03 EDT-------
(In reply to comment #60)
> Hi paul,
> The latest yaboot git http://people.fedoraproject.org/~pnasrat/yaboot could pick
> up the netboot image "ppc64.img" correctly. It works fine. I wonder if it can be
> incorporated with F9alpha before releasing it(scheduled for 5Feb08).

Alpha is frozen at the moment and won't be picking up updates.  Let's try to
work with the Red Hat yaboot owner to get yaboot updated and into Beta.

josh
Comment 23 IBM Bug Proxy 2008-03-26 16:16:47 EDT
------- Comment From kenblake@us.ibm.com 2008-03-26 16:08 EDT-------
(In reply to comment #64)
> Alpha is frozen at the moment and won't be picking up updates.  Let's try to
> work with the Red Hat yaboot owner to get yaboot updated and into Beta.
>
We are seeing this in our lab with F9 Beta.  I have had issues installing a
QS20, JS20 and JS24.  Any chance this will be fixed soon?
Comment 24 IBM Bug Proxy 2008-03-26 16:32:49 EDT
------- Comment From jwboyer@us.ibm.com 2008-03-26 16:30 EDT-------
From today's kernel.spec file in Fedora CVS:

* Wed Mar 26 2008 David Woodhouse <dwmw2@redhat.com>
- Link PowerPC zImage at 32MiB (#239658 on POWER5, also fixes Efika)

So it would be good to try with tomorrow's rawhide to see if that change makes a
difference.
Comment 25 Paul Nasrat 2008-03-27 03:25:50 EDT
There seems to be conflicting information on the state of the patches to fix
this on HEAD - please can you provide test information (h/w), any additional
patches on top of git HEAD and console output to yaboot-devel or yaboot-users.

See also

http://ozlabs.org/pipermail/yaboot-users/2008-February/thread.html

Even if the link address change fixes the zImage I'd like to ensure that we can
consistently netboot large images using yaboot.
Comment 26 IBM Bug Proxy 2008-04-29 07:48:43 EDT
------- Comment From IndhuDurai@in.ibm.com 2008-04-29 07:47 EDT-------
Hi,

I am finding the issue reproduced in Fedora9preview release as well. Machine is
not booting with /tftpboot/ppc64.img.

Regards,
Indhu D
Comment 27 David Woodhouse 2008-04-29 08:00:19 EDT
Gr. Which machine? What if you link the zImage at 64MiB? 
Comment 28 IBM Bug Proxy 2008-04-29 12:24:32 EDT
------- Comment From kenblake@us.ibm.com 2008-04-29 12:23 EDT-------
(In reply to comment #69)
> ------- Comment From dwmw2@redhat.com 2008-04-29 08:00 EST-------
> Gr. Which machine? What if you link the zImage at 64MiB?
I too am seeing this issue with a JS21 and F9Preview.  If you could detail the
process for booting the installer via yaboot, I will try it with this system and
see if it gets around the issue.
Comment 29 Paul Nasrat 2008-04-30 01:07:45 EDT
Assuming running tftp/dhcp on linux (if on AIX I think tftpserver runs off / so
may have to change to run in root of /tftpboot)


1) Create yaboot on my tftp server for the machine being
netbooted.  And copy in the appropriate yaboot binary

       $ mkdir /tftpboot/ppc/

       $ cp /path/to/F-9/ppc/chrp/yaboot /tftpboot/ppc/

2) Copy yaboot.conf kernel and initrd onto server

      $ mkdir /tftpboot/etc
      $ cp /path/to/F-9/etc/yaboot.conf /tftpboot/ppc
      $ mkdir -p /tftpboot/ppc/ppc64
      $ cp /path/to/F-9/ppc64/* /tftpboot/ppc/ppc64

3) Edit yaboot.conf, remove ppc32 entries and change label=linux64 to label=linux

4) Create a default 'filename' for that system in my dhcpd.conf

       host ibm-sf2b-lp1 {
           hardware ethernet 00:11:22:33:44:55;
           fixed-address ibm-sf2b-lp1.example.com;
           filename "ppc/yaboot";
       }

5) Boot into OF

       $ boot network

       [*] assumes 'network' is valid device aliases
Comment 30 David Woodhouse 2008-04-30 05:26:32 EDT
Does F-9 yaboot have all the latest TFTP-related patches? It's still 1.3.13.
Comment 31 Paul Nasrat 2008-05-08 00:44:25 EDT
No it doesn't have everything from 1.3.14/HEAD (particularly the pxelinux style
boot) but it should netboot on IBM Power machines
Comment 32 Bug Zapper 2008-05-13 22:53:20 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 33 IBM Bug Proxy 2008-05-26 02:24:44 EDT
Created attachment 306647 [details]
Link zImage at 64Mb rather than 4Mb.  Move real-base from 12Mb to 32Mb

As far as I can tell we have a couple of problems:
 1) the filesize of the zImage (vmlinux and initrd) is greater than (12Mb -
16Kb)
 2) the Default link address of the zImage is too low. (4Mb)

problem (2) is relatively simple to solve, but doesn't help with problem (1). 
Moving real-base is the only way to solve this problem (1).

For small zImages a patched kernel should boot with no visible differences, for
large zImages, real-base will bneed to be set to 32Mb (0x2000000) before the
zImage is loaded.  This works around firmware problems.

I attempted to use yaboot to workout some of these problems but as yet I can't
get PXE style tftp'ing of the config file to work :(

This patch has been boot tested on POWER3,4,5,5+, 6 and JS20.  If people don't
object I'll push it to Paulus for 2.6.27.
Comment 34 Hanns-Joachim Uhl 2008-06-03 09:56:16 EDT
reopening Red Hat bugzilla per comment #32 ...
Comment 35 IBM Bug Proxy 2008-06-26 03:48:53 EDT
------- Comment From hannsj_uhl@de.ibm.com 2008-06-26 03:40 EDT-------
fyi .. copying the following comment over from Red Hat bugzilla
254120: Netboot with ppc64.img fails booting
to this bugzilla:
"
Comment #6 From Jim Lindeman (lindj@us.ibm.com)  on 2008-06-25 14:35 EST
[reply]
The issue is because the ELF-header at the beginning of the Linux image has an
inappropriate value for the "real-base" setting, which tells where Open
Firmware
should sit in memory.  The Linux image is downloaded starting at address 0x4000
("load-base" setting also in the ELF-header), and if the "real-base" is not set
high enough for the OS image to fit, the download will fail.  In this
particular
error above, the "real-base" setting was still at 12Mb (0xC00000).  Note that
while the OS binary would still fit (was just under 11Mb), the "program image
size" (which includes the BSS section, not in the binary), would overflow above
the 12Mb threshold and that's why the "CLAIM failed".

AIX sets the "real-base" in their ELF header to 32Mb (0x2000000), so they don't
ever hit this issue.  This is a bug for Fedora to fix.
"

------- Comment From hannsj_uhl@de.ibm.com 2008-06-26 03:41 EDT-------
fyi .. a patch for this bugzilla was posted at 6/23 at
http://patchwork.ozlabs.org/linuxppc/patch?id=19122 ...
Comment 36 James Laska 2008-07-30 08:55:43 EDT
Still happening in F10-alpha ... comment#35 from IBM points to a porposed patch
to resolve the issue.
Comment 37 Hanns-Joachim Uhl 2008-07-30 10:22:43 EDT
... which is now accepted upstream into 2.6.27-rc1 as
"
commit 9b09c6d909dfd8de96b99b9b9c808b94b0a71614
Author: Tony Breeds <tony@bakeyournoodle.com>
Date:   Tue Jun 24 14:20:29 2008 +1000

    powerpc: Change the default link address for pSeries zImage kernels
    
    Currently we set the start of the .text section to be 4Mb for pSeries.
    In situations where the zImage is > 8Mb we'll fail to boot (due to
    overlapping with OF).  Move .text in a zImage from 4MB to 64MB
    (well past OF).
    
    We still will not be able to load large zImage unless we also move OF,
    to that end, add a note to the zImage ELF to move OF to 32Mb.  If this
    is the very first kernel booted then we'll need to move OF manually by
    setting real-base.
    
    Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
    Signed-off-by: Paul Mackerras <paulus@samba.org>
"
Comment 38 IBM Bug Proxy 2008-08-04 03:30:40 EDT
(In reply to comment #88)
> ------- Comment From jlaska@redhat.com 2008-07-30 08:55 EST-------
> Still happening in F10-alpha ... comment#35 from IBM points to a porposed patch
> to resolve the issue.

Silly question .... Where can I get the F10 Alpha?
Comment 39 IBM Bug Proxy 2008-12-13 09:38:58 EST
L?????b?x??M??!??????/????????m????????b?BX??Z?????a6????   ??6??]????Dm????K??8  - c17100
Comment 40 Bug Zapper 2009-06-09 18:35:54 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 41 IBM Bug Proxy 2009-06-09 18:43:04 EDT
?
?L?????b?x??M??!??????/????????m????????b?BX??Z?????a6????   ??6??]????Dm????K??8  - c17100
Comment 42 Bug Zapper 2009-07-14 13:14:57 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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