[SCSI] kdump: mpt fusion driver initialization failure fix
MPT fusion driver initialization fails while second kernel is booting, after a system crash (if kdump kernel is configured). Oops message is pasted below. ***************************************************************************** Fusion MPT base driver 3.03.08 Copyright (c) 1999-2005 LSI Logic Corporation Fusion MPT SAS Host driver 3.03.08 ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKA] -> GSI 5 (level, low) -> IRQ 5 mptbase: Initiating ioc0 bringup BUG: unable to handle kernel paging request at virtual address 00002608 printing eip: c11782fd *pde = 00000000 Oops: 0000 [#1] Modules linked in: CPU: 0 EIP: 0060:[<c11782fd>] Not tainted VLI EFLAGS: 00010046 (2.6.17-rc1-16M #2) EIP is at mptscsih_io_done+0x27/0x3a3 eax: c4fed000 ebx: c4fed000 ecx: 00002600 edx: 00000298 esi: c11782d6 edi: 00002600 ebp: 00000000 esp: c1332f74 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=c1332000 task=c128f9c0) Stack: <0>0000006c 00000020 00000298 00002600 c4fed000 c4fed000 c11782d6 0000260 0 00000000 c1172c49 c4fed000 c1305b40 00000005 00000000 c1172d75 c48877e0 c1029687 00000000 c1307fb8 00000000 c1305a00 00000001 00000000 c1307fb8 Call Trace: <c11782d6> mptscsih_io_done+0x0/0x3a3 <c1172c49> mpt_turbo_reply+0xbb/0xd3 <c1172d75> mpt_interrupt+0x22/0x2b <c1029687> misrouted_irq+0x63/0xcb <c10297b3> note_interrupt+0x43/0x98 <c10292f9> __do_IRQ+0x68/0x8f <c1003fac> do_IRQ+0x36/0x4e ======================= <c1002aa6> common_interrupt+0x1a/0x20 <c1001150> mwait_idle+0x1a/0x2a <c10010bf> cpu_idle+0x40/0x5c <c1308610> start_kernel+0x17a/0x17c Code: 5e 5f 5d c3 55 89 cd 57 56 53 83 ec 14 89 54 24 0c 89 44 24 10 8b 90 cc 00 00 00 8b 4c 24 0c 81 c2 98 02 00 00 85 ed 89 54 24 08 <0f> b7 79 08 89 fe 74 04 0f b7 75 08 66 39 f7 75 0d 8b 44 24 0c ******************************************************************************* o Kdump capture kernel boot fails during initialization of MPT fusion driver. (LSI Logic / Symbios Logic SAS1064E PCI-Express Fusion-MPT SAS (rev 01)) o Problem is easily reproducible, if system crashed while some disk activity like cp operation was going on. o After a system crash, devices are not shutdown and capture kernel starts booting while skipping BIOS. Hence underlying device is left in operational state. In this case scsi contoller was left with interrupt line asserted reply FIFO was not empty. When driver starts initializing in the second kernel, it receives the interrupt the moment request_irq() is called. Interrupt handler, reads the message from reply FIFO and tries to access the associated message frame and panics, as in the new kernel's context that message frame is not valid at all. o In this scenario, probably we should delay the request_irq() call. First bring up the IOC, reset it if needed and then should register for irq. o I have tested the patch with SAS1064E and 53c1030 controllers. Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Acked-by: "Moore, Eric Dean" <Eric.Moore@lsil.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Showing
Please register or sign in to comment