http://bugzilla.kernel.org/show_bug.cgi?id=12195 ------- Comment #7 from anonymous@xxxxxxxxxxxxxxxxxxxx 2008-12-12 02:22 ------- Reply-To: andmike@xxxxxxxxxxxxxxxxxx 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 When scsi_times_out is called there should not be a transportt->eh_timed_out, or hostt->eh_timed_out set for mptsas which should lead to waking up the eh thread. We will then call mptscsih_abort from the eh thread and it will return success if the scsi command is not found leading to a possible requeue. If you have time for another re-create it would be good to set some scsi logging. sysctl -w dev.scsi.logging_level=4100 # mlcomplete 1 and error 4 echo "1" > /proc/sys/kernel/sysrq # If needed echo 9 > /proc/sysrq-trigger # Raise console log level Also if you have more dmesg output prior to the error from the previous failure runs that would be good to post also. -andmike -- Michael Anderson andmike@xxxxxxxxxxxxxxxxxx -- 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
