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
Summary: | No kexec-tools on PowerPC | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | David Woodhouse <dwmw2> | ||||||
Component: | kexec-tools | Assignee: | Neil Horman <nhorman> | ||||||
Status: | CLOSED RAWHIDE | QA Contact: | |||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | rawhide | ||||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2007-04-14 19:56:49 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 235611 | ||||||||
Attachments: |
|
Description
David Woodhouse
2007-04-07 21:44:06 UTC
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! |