[PATCH] aacraid: fails to initialize after a kexec operation
vgoyal at in.ibm.com
Mon Apr 30 05:53:34 EDT 2007
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
> 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
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.
More information about the kexec