http://bugzilla.kernel.org/show_bug.cgi?id=12195 ------- Comment #8 from anonymous@xxxxxxxxxxxxxxxxxxxx 2008-12-12 07:09 ------- Reply-To: James.Bottomley@xxxxxxxxxxxxxxxxxxxxx On Fri, 2008-12-12 at 02:22 -0800, Mike Anderson wrote: > bugme-daemon@xxxxxxxxxxxxxxxxxxx <bugme-daemon@xxxxxxxxxxxxxxxxxxx> wrote: > > http://bugzilla.kernel.org/show_bug.cgi?id=12195 > > > > > > > > > > > > ------- Comment #6 from ming.m.lin@xxxxxxxxx 2008-12-11 18:27 ------- > > 2.6.28-rc8 also panic > > The blk_mark_rq_complete check should prevent completions from occurring on > already timed out requests unless the interaction previous mentioned between > mpt_fault_reset_work and the scsi eh thread requeue alows the REQ_ATOM_COMPLETE > bit to get cleared prior to the scsi_done being called from > mptscsih_flush_running_cmds. This did not look obvious to hit. > > mpt_fault_reset_work > mpt_HardResetHandler > mpt_signal_reset > mptsas_ioc_reset > mptscsih_flush_running_cmds > mpt_do_ioc_recovery Actually, this isn't quite true. Particularly in the eh case. It looks like the block timeout isn't stopped until blk_complete_request() which is pretty late. If the timeout fires after scsi_done is called but before we complete the request, any timeout goes through the BLK_EH_HANDLED path to __blk_complete_request(). This routine unconditionally adds to the done routine without checking the mark, so there is a window where we can get double dones. James -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. -- 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
