Vivek wrote: > > I think this is not the right usage of reset_devices > parameter. This parameter instructs the driver to reset the > device before going ahead with rest of the initialization > before as underlying device might not be in a sane state. > kexec/kdump is one of the usages and this can also be useful > in the case of BIOS not doing its job. > > When I had proposed crash_boot parameter for kexec/kdump > purposes, that time andrew had suggested that he is afraid > that driver authors will use this parameter to solve all kind > of problems. > > I think we should stick to the theme of the parameter and > implement the reset routine for cciss driver instead of > simply returning back. Consider the case of hypothetical > scenario where somebody booted the kernel with reset_device > parameter (because of unreliable bios) and if there is a > problem on kernel side that after it issues the command it > lost track of that (because of kernel bug) then driver will > never catch that bug as upon receiving the response it will > simply ignore that. > > Mike, you know most about this device. Can you please help > out with implementing a reset routing for it? > Vivek I think I finally have an idea that will work. (`bout time!) We actually have 2 different issues. One is that there may outstanding commands on the controller when the kdump kernel initializes. Our SAS controllers support the reset message defined in the open CISS spec which will (hopefully) resolve this issue. The second problem is that I cannot allocate my MSI-X vectors because I couldn't free the vectors then disable MSI. So the cciss driver would most likely panic at that time. My idea for this is to put the card into INTx mode rather than MSI or MSI-X. That should the 2nd issue. I haven't tested the 64xx series to see if they support the reset message. I should to write the code today, maybe test by tomorrow and then send something upstream. mikem - To unsubscribe from this list: 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
