Bug 235608 - No kexec-tools on PowerPC
No kexec-tools on PowerPC
Product: Fedora
Classification: Fedora
Component: kexec-tools (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Neil Horman
Depends On:
Blocks: 235611
  Show dependency treegraph
Reported: 2007-04-07 17:44 EDT by David Woodhouse
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-04-14 15:56:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
kexec-tools-1.101-ppc-boots-ppc64.patch (16.50 KB, patch)
2007-04-07 17:44 EDT, David Woodhouse
no flags Details | Diff
somewhat cleaner patch (9.96 KB, patch)
2007-04-10 03:41 EDT, David Woodhouse
no flags Details | Diff

  None (edit)
Description David Woodhouse 2007-04-07 17:44:06 EDT
There's no kexec-tools in rawhide. This is because we have crappy heuristics
about which ppc64 packages should be shipped in the biarch PowerPC repo, and
kexec-tools doesn't match them. Since there's no 32-bit kexec-tools package, it
doesn't get shipped at all.

We can make 32-bit kexec userspace actually work for 64-bit kernels. Then it'll
get shipped -- and it'll be a lot smaller when we put it into an initrd for the
PlayStation 3 bootloader too.

Attaching a _really_ ugly patch which I'll hopefully get round to cleaning up
some time next week.
Comment 1 David Woodhouse 2007-04-07 17:44:06 EDT
Created attachment 151921 [details]
Comment 2 David Woodhouse 2007-04-07 17:45:09 EDT
--- 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
@@ -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
 %patch401 -p1
 %patch501 -p1
 %patch601 -p1
@@ -133,6 +136,10 @@
 tar -z -x -v -f %{SOURCE13}
+%ifarch ppc
+%define archdef ARCH=ppc64
 %configure \
 %ifarch ppc64
@@ -142,15 +149,15 @@
 rm -f kexec-tools.spec.in
 cp %{SOURCE10} . 
-%ifarch %{ix86} x86_64 ia64 ppc64
+make %{?archdef}
+%ifarch %{ix86} x86_64 ia64 ppc64 ppc
 make -C makedumpfile
 make -C po
+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
Comment 3 David Woodhouse 2007-04-10 03:41:37 EDT
Created attachment 152118 [details]
somewhat cleaner patch
Comment 4 Neil Horman 2007-04-10 10:56:26 EDT
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.
Comment 5 Neil Horman 2007-04-10 11:11:51 EDT
sorry, wrong bug, please disregard comment #4
Comment 6 Neil Horman 2007-04-10 12:02:47 EDT
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?
Comment 7 David Woodhouse 2007-04-10 12:38:08 EDT
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.
Comment 8 Neil Horman 2007-04-10 14:10:47 EDT
Wait, one more concern...I've got this checked in against -67.fc7, but I'm
concerned about this:
+%ifarch ppc
+%patch307 -p1

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!
Comment 9 David Woodhouse 2007-04-10 14:34:46 EDT
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.
Comment 10 David Woodhouse 2007-04-10 14:36:12 EDT
(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 :)
Comment 11 Neil Horman 2007-04-10 15:52:29 EDT
in reply to comment #10:
yes, bad eyes :)

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

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