On Mon, Jun 26, 2006 at 11:51:52AM -0500, Miller, Mike (OS Dev) wrote: [..] > > kdump or taking crash dumps using the kexec on panic > > mechanism could be called a drivers worst nightmare. In the > > latest distros this is becoming the way crash dump style > > information is captured. > > > > Because the initial kernel is broken we do a jump into > > another kernel that is sufficient to record a crash dump. > > That second kernel initializes the hardware from whatever > > random state the first kernel left the drivers in. That > > first kernel is not permitted to do any device shutdown activities. > > > > The problem is that a command the running instance of the > > driver did not initiate completes. At least if I read Vivek > > patch 2/2 correctly. > > > > So we have three options. > > - reset the card during initialization. > > - handle the case of a command we did not initiate completing. > > - mark the driver/card as impossibly hopeless for use in a crash > > dump scenario. > > > > > > Eric > > Thanks Eric, that helps me understand. Section 8.2.2 of the open cciss > spec supports a reset message. Target 0x00 is the controller. We could > add this to the init routine to ensure the board is made sane again but > this would drastically increase init time under normal circumstances. > And I suspect this is a hard reset, also. Not sure if that would > negatively impact kdump. If there were some condition we could test > against and perform the reset when that condition is met it would not > impact 99.9% of users. That's the precise reason of introducing the "crashboot" command line parameter. Driver authors can check against this condition and reset the device and 99.9% of the users are not impacted. Thanks Vivek - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
