On Thu, 2008-12-11 at 01:05 -0800, bugme-daemon@xxxxxxxxxxxxxxxxxxx wrote: > I instrumented kernel. below is some finding. > 1) The disk isn't stable. If we run dd in a loop, sometimes the disk doesn't > work, so block request will expire to start a scsi error handling; > 2) fussion driver has its own periodic (1 sec) checking in > mpt_fault_reset_work. If something is wrong, it will do a hardware reset and > flush all pending requests; > 3) Step 1) and 2) have a race that a request might be flushed in step 2), but > step 1) releases the request firstly. Later on, when SOFTIRQ tries to release > the scsi_cmnd, kernel panic. OK, so to rule out the block timer problems which we think are fixed, could you reproduce on 2.6.28-rc8. Also, the routine > [<a000000100391cf0>] scsi_softirq_done+0x50/0x2e0 > sp=e000000008a97e10 bsp=e000000008a90d70 Is hard to diagnose. Could you ask gdb or addr2line which actual source line this is? Thanks, James -- 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
