Bug 235608

Created attachment 151921 [details]
kexec-tools-1.101-ppc-boots-ppc64.patch

--- kexec-tools.spec    26 Mar 2007 13:22:11 -0000      1.79
+++ kexec-tools.spec    7 Apr 2007 21:44:29 -0000
@@ -23,8 +23,7 @@
 Requires: busybox >= 1.2.0
 BuildRequires: zlib-devel elfutils-libelf-devel glib2-devel pkgconfig
 BuildRequires: elfutils-libelf-devel elfutils-devel-static gettext
-ExcludeArch: ppc
-%ifarch %{ix86} x86_64 ppc64 ia64
+%ifarch %{ix86} x86_64 ppc64 ia64 ppc
 Obsoletes: diskdumputils netdump
 %endif
 
@@ -65,6 +64,7 @@
 Patch304: kexec-tools-1.101-ppc64-platform-fix.patch
 Patch305: kexec-tools-1.101-ppc64-64k-pages.patch
 Patch306: kexec-tools-1.101-ppc64-memory_regions.patch
+Patch307: kexec-tools-1.101-ppc-boots-ppc64.patch
 
 #
 # Patches 401 through 500 are meant for s390 kexec-tools enablement
@@ -118,6 +118,9 @@
 %patch304 -p1
 %patch305 -p1
 %patch306 -p1
+%ifarch ppc
+%patch307 -p1
+%endif
 %patch401 -p1
 %patch501 -p1
 %patch601 -p1
@@ -133,6 +136,10 @@
 
 tar -z -x -v -f %{SOURCE13}
 
+%ifarch ppc
+%define archdef ARCH=ppc64
+%endif
+
 %build
 %configure \
 %ifarch ppc64
@@ -142,15 +149,15 @@
     --sbindir=/sbin
 rm -f kexec-tools.spec.in
 cp %{SOURCE10} . 
-make
-%ifarch %{ix86} x86_64 ia64 ppc64
+make %{?archdef}
+%ifarch %{ix86} x86_64 ia64 ppc64 ppc
 make -C makedumpfile
 %endif
 make -C po
 
 %install
 rm -rf $RPM_BUILD_ROOT
-make install DESTDIR=$RPM_BUILD_ROOT
+make install %{?archdef} DESTDIR=$RPM_BUILD_ROOT
 make -C po install DESTDIR=$RPM_BUILD_ROOT
 mkdir -p -m755 $RPM_BUILD_ROOT%{_sysconfdir}/rc.d/init.d
 mkdir -p -m755 $RPM_BUILD_ROOT%{_sysconfdir}/sysconfig
@@ -169,7 +176,7 @@
 install -m 644 kexec/kexec.8 $RPM_BUILD_ROOT%{_mandir}/man8/kexec.8
 install -m 755 %{SOURCE11} $RPM_BUILD_ROOT%{_datadir}/kdump/firstboot_kdump.py
 install -m 644 %{SOURCE12} $RPM_BUILD_ROOT%{_mandir}/man8/mkdumprd.8
-%ifarch %{ix86} x86_64 ia64 ppc64
+%ifarch %{ix86} x86_64 ia64 ppc64 ppc
 install -m 755 makedumpfile/makedumpfile $RPM_BUILD_ROOT/sbin/makedumpfile
 install -m 755 makedumpfile/makedumpfile-R.pl
$RPM_BUILD_ROOT/sbin/makedumpfile-reasm
 %endif

Created attachment 152118 [details]
somewhat cleaner patch

Since we've ripped out the platform determination code (since its not overly
reliable), I'm just going to reduce the max rmo_top value to 0x7c000000UL for
now.  Being rawhide, If that has any adverse affects on anything else, we'll
catch it early and be able to come up with something better.

sorry, wrong bug, please disregard comment #4

David, I'm a little concerned about this change.  We initially removed 32 bit
ppc from the build because (prior to PS3) we had no need for it.  Now that we
do, I want to be extra sure that that we don't bust any of the ppc64 systems
with this.  What testing have you done to ensure that this works with ppc64 systems?

You're thinking of RHEL. We _can't_ bust ppc64 kexec in Fedora because we aren't
even _shipping_ kexec-tools in Fedora -- which in fact is because there is no
32-bit version of the package and this is one of the places where the "does it
have a -devel subpackage?" heuristic for choosing which packages to ship 64-bit
gets the answer wrong (cf. bug #235758)

We removed the 32-bit kexec package because kexec of 32-bit machines isn't
functional. That remains the case; this patch makes the 32-bit userspace package
capable of booting 64-bit machines. I'll get to 32-bit machines eventually
(probably after Fedora 7), and then I'll make the 32-bit package capable of _both_.

For the time being, this patch is _only_ about kexec of 64-bit machines. It's
been tested on Mac G5 and PlayStation 3. I haven't just done empirical testing
by booting into new kernels; I also hacked the debug output to print a crc32 of
each memory section passed to kexec, and compared with the native 64-bit userspace.

Wait, one more concern...I've got this checked in against -67.fc7, but I'm
concerned about this:
+%ifarch ppc
+%patch307 -p1
+%endif

this is a mess to maintain for me, and I can't see any reason why the changes
you made to kexec-ppc64.c warrant this conditional application.  Can you explain
to me why you did this?  Thanks!

That was done because my _original_ patch was an evil hack -- it didn't just
change ppc64-specific things; it did things like unconditionally adding '-m64
-mcall-aixdesc' to CFLAGS when building purgatory. That wasn't really something
you wanted to do elsewhere.

The _new_ patch I filed last night doesn't have those problems. The only
remaining change to generic code is making the fields in struct sha256_region
into uint64_t, and building sha256.c using purgatory's CFLAGS instead of
building it once in the util_lib/ directory and using the same object in both
kexec and purgatory. Those changes should be perfectly OK on all platforms. So
it's OK to drop the %ifarch ppc. I haven't tested on non-ppc64 though.

Note that although I think I enabled makedumpfile on ppc in my specfile patch, I
haven't actually checked that it's 64-bit clean. I don't even know what it does,
further the the obvious inferences from the name.

(In reply to comment #4)
> Since we've ripped out the platform determination code (since its not overly
> reliable), I'm just going to reduce the max rmo_top value to 0x7c000000UL for
> now.  

That would be an increase. Hopefully you mean 0x07c00000 :)

in reply to comment #10:
yes, bad eyes :)

This is checked in as -67.fc7.  Thanks!