Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 235608 - No kexec-tools on PowerPC
Summary: No kexec-tools on PowerPC
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kexec-tools
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Neil Horman
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 235611
TreeView+ depends on / blocked
 
Reported: 2007-04-07 21:44 UTC by David Woodhouse
Modified: 2007-11-30 22:12 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-04-14 19:56:49 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
kexec-tools-1.101-ppc-boots-ppc64.patch (deleted)
2007-04-07 21:44 UTC, David Woodhouse
no flags Details | Diff
somewhat cleaner patch (deleted)
2007-04-10 07:41 UTC, David Woodhouse
no flags Details | Diff

Description David Woodhouse 2007-04-07 21:44:06 UTC
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 21:44:06 UTC
Created attachment 151921 [details]
kexec-tools-1.101-ppc-boots-ppc64.patch

Comment 2 David Woodhouse 2007-04-07 21:45:09 UTC
--- 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


Comment 3 David Woodhouse 2007-04-10 07:41:37 UTC
Created attachment 152118 [details]
somewhat cleaner patch

Comment 4 Neil Horman 2007-04-10 14:56:26 UTC
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 15:11:51 UTC
sorry, wrong bug, please disregard comment #4

Comment 6 Neil Horman 2007-04-10 16:02:47 UTC
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 16:38:08 UTC
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 18:10:47 UTC
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!


Comment 9 David Woodhouse 2007-04-10 18:34:46 UTC
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 18:36:12 UTC
(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 19:52:29 UTC
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.