On Fri, Jan 05, 2007 at 08:20:41AM +0900, Horms wrote: > On Thu, Jan 04, 2007 at 10:51:57AM -0500, Don Zickus wrote: > > On Thu, Jan 04, 2007 at 08:59:10AM -0500, Neil Horman wrote: > > > > Hi Neil, > > > > > > > > That solution would be very specific to RedHat. If a user on non RHEL5 > > > > distro tries to use kdump then how would he handle it? > > > > > > > I understand that, but the point I'm trying to make is that this seems > > > like it > > > would be better to do in an initscript in general. We've seen the need > > > to add > > > specific commandline parameters for specific systems several times now. > > > Instead > > > of updating the kexec code to detect and add appropriate parameters for > > > every > > > system out there, wouldn't it be better if each distro provided a way > > > for a > > > user to configure any needed additional parameters that an initscript > > > could then > > > just pass along to the kernel using the --command-line option? > > > > I have to agree with Neil here. I think part of the problem is > > kexec-tools is bursting at its britches here. It is starting to turn into > > a real application that needs config files and init scripts. I can see > > the maintainers and developers are trying hard to avoid it by adding in > > hacks like this. But the bottom line is, if kexec-tools is to be done > > right you guys are going to have to create an infrastructure for it. > > > > I know it's the last thing a bunch of kernel developers want to do, but I > > think its the right way. You can probably even follow the kernel model of > > of creating a directory in the git repo called scripts/ and put the init > > and config scripts in there. Also you could probably add some rpm > > packaging to a Makefile to bundle it up and install it correctly. > > > > Just some thoughts. > > > > > > > > > Another option can be that we specify this thing in kdump documentation > > > > so > > > > that a user can add this parameter additionally along with maxcpus=1 and > > > > irqpoll. Then respective distros can choose to automate this whole > > > > process > > > > and add append reset_devices through init scripts. > > > > > > > I absolutely agree. I think this is the way to go forward. It keeps us > > > from > > > having to update kexec binaries when someone wants/needs new command line > > > parameters (for which there may be countless combinations of out in the > > > field). > > > Make the distros provide a method for leveraging the already existing > > > functionality of kexec instead (in this case --command-line). Its less > > > confusing and more flexible IMO. > > > > I agree. > > Taking a step back, when exactly is reset_devices needed? >
Hi Horms, Sometimes we encounter a device re-initialization failure in second kernel because second kernel is booting in special circumstances. (BIOS has been skipped and underlying device might very well be operational). This command line option is a hint to the device driver that kernel is booting in a special environment and reset the underlying device before going ahead with rest of the initialization. I am not sure how many devices do provide the capability to reset the devices from software, but this atleast gives driver a chance to bring the underlying device to a known state and reducing the chances of initialization failure. So far there are no users of this option. But I am hoping down the line there will be. One possible candidate seems to be cciss driver. That driver was the trigger point for this command line parameter. Hence we need to pass this parameter to second kernel as command line option. This should be an arch independent command line parameter as it deals with devices. This is not an essential parameter. Adding this parameter increases the chances of success of booting second kernel. Hence looks like hardcoding it in kexec-tools might not be a very good idea and passing it through init scripts might make more sense. Thanks Vivek _______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
