On Tue, Apr 24, 2007 at 09:21:35AM -0400, Salyzyn, Mark wrote: > The system BIOS sets up the card's PCI configuration and there is code > in the kernel that is capable of picking up some of the BIOS' > information from the BIOS Data Space (not sure if it is actively > collected in your configuration, you need a kernel flag to pick this > up). On kexec this BIOS Data Space information is missing (?) and if > there was any reconfiguration of the PCI space going on (I think only > the Linux BIOS project does this), kexec will inherit it. This issue > strikes me as a corrupted PCI configuration inherited in the kexec case, > such corrupted PCI configurations could be a motherboard specific issue > and can be related to the BIOS' initial setup for the initial kernel. At > least that is my thought process in questioning the motherboard BIOS or > hardware. > > Another possibility is that after you have patched over the interrupt > routing issues (a PCI configuration problem), the card has a foreign > array, and the reset and reconfiguration is taking arrays offline. Add > 'aacraid.commit=1' to force the foreign arrays to be accepted by the > card. > Hi Mark, So aacraid.commit=1 and irqpoll combination has done the trick. I can kexec/kdump into second kernel. I am using an IBM x366 series machine. There is one array and three disks behind it. Now few queries. - What is the concept of foreign arrays? - Should we pass aacraid.commit=1 all the time or this is only for some special cases? What's the point in resetting an adapter if it does not online the array it is managing? - For kexec, it calls the device shutdown routine (aac_shutdown) in this case. If this is the case for normal kexec (not kdump) adapter should not be reset? - Still needs to be found out why PCI configuration is getting corrupted and why irq routing is not proper and irqpoll is required. Thanks Vivek - 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
