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:
vivek, we should already have the --noio patch in the latest kexec-tools, I think this can be closed as CURRENTRELEASE.
Neil says it is already part of current release. Closing it.
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.
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
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.
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.
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, steiner and nanhai.zou to cc for discussion.
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.
added to -149.el5
kexec-tools-1.101-164.el5 included in 20070208.0 trees.