Bug 218052 - SGI SN platform requires kexec to specify "--noio" option
SGI SN platform requires kexec to specify "--noio" option
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kexec-tools (Show other bugs)
5.0
ia64 Linux
medium Severity medium
: ---
: ---
Assigned To: Neil Horman
Red Hat Kernel QE team
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-01 11:07 EST by George Beshers
Modified: 2009-09-09 01:07 EDT (History)
7 users (show)

See Also:
Fixed In Version: 5.0.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-02-13 12:05:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description George Beshers 2006-12-01 11:07:58 EST
Description of problem:

SN platform requires kexec to specify "--noio" option in order to boot a
kexec'ed kernel properly. This can be specified in /etc/sysconfig/kdump.

Note that this "--noio" option may not be needed in other IA64 platforms.

---------------------------

SN platform support PIO in a different way to generic IA64 platform. It
does not support most of the legacy I/O ports.

Give an --noio option to kexec-tools to disable I/O in purgatory code.
Without this option the kexec would send interrupt to the I/O ports and
hang on waiting response which would never come.

Nan-hai submitted a patch for us to provide this option. This PV is about
setting this option in configuration file for SN users.

BTW, the --noio kexec patch from Nan-hai contains a serious bug. I submitted
a patch to fix that bug. The bug fixing patch was what Neil and me talked
about in the mailing list. Not this configuration issue. I will open
another PV to cover the bug fixing patch and two other kexec-tools patches
we need Redhat to include in rhel5 later today.


Version-Release number of selected component (if applicable):


How reproducible:



Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Neil Horman 2006-12-01 11:23:59 EST
vivek, we should already have the --noio patch in the latest kexec-tools, I
think this can be closed as CURRENTRELEASE.
Comment 2 Vivek Goyal 2006-12-01 11:51:18 EST
Neil says it is already part of current release. Closing it.
Comment 3 Jay Lan 2006-12-07 14:52:49 EST
Neil, this bugzilla is about adding "--noio" option to /etc/sysconfig/kdump
file.  Maybe you were thinking about the --noio patch that provides this 
feature in the kexec binary?

Since the latest source i can access to is beta2, i can not verify
whether that option has been added to the latest kexec-tools configuration
file.
Comment 4 Neil Horman 2006-12-07 15:48:09 EST
ahh, well in that case, its still appropriately closed.  As I understand it,
I've got bz 218667 open to add some %post script logic to the spec file for
kexec-tools to only add machvec=dig to the command line if we detect certain HP
machines, and we can add to that to support add --noio to the kexec args as well
for SGI machiens if we absolutely have to, but its my understanding that work is
progressing at the moment to make the SGI machines behave properly so that
--noio isn't needed in the kexec-args
Comment 5 Jay Lan 2006-12-15 21:46:03 EST
I just tested -snap3 bits. The crashdump kernel boot would hang at
    machine_kexec: trying to start crashkernel
without --noio kexec command line argument.

I think your idea of doing it at %post script to add --noio should work for
SGI machines. Please do so. Without it, the boot would hang.

I am not aware of any other way to solve this problem.
Comment 6 Neil Horman 2006-12-16 12:58:34 EST
Ok, but you're going to have to give me a good way to detect affected SGI
machines in the %post script, so that I know when to appropriately add this.

Also, I expect you will continue to pursue fixes for this, correct?   There must
be a way to detect a boot into a new kernel via kdump and preform the same
features that --noio does. The solution you are requesting here is really an
unscalable hack.
Comment 7 Jay Lan 2006-12-16 15:09:54 EST
A good way of detecting a SGI SN boxes is the existence of /proc/sgi_sn/
directory.

As to the question of supporting --noio in a different way in the future,
to my understanding SN platform supports PIO in a different way. It does
not support most of the legatory I/O ports. That was why we need the --noio
option to disable I/O in purgatory code and the reason prompted Nan-Hai to
provide the patch. What would be a better way to handle it?

I added jes@sgi.com, steiner@sgi.com and nanhai.zou@intel.com to cc for
discussion.
Comment 8 Neil Horman 2006-12-18 10:46:08 EST
I don't know what a better way would be...yet.  But I do know that writing in
%post tests isn't really scalable if the number of systems that require special
options grows.  It was my understanding that we would make this change with the
understanding that HP and SGI were taking on the responsibility to research
alternate methods of fixing this problem so we didn't need to carry these spec
file tests long term.
Comment 9 Neil Horman 2006-12-18 11:04:33 EST
added to -149.el5
Comment 10 Jay Turner 2007-02-13 12:05:07 EST
kexec-tools-1.101-164.el5 included in 20070208.0 trees.

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