http://bugzilla.kernel.org/show_bug.cgi?id=11898 ------- Comment #23 from yanmin_zhang@xxxxxxxxxxxxxxx 2008-11-05 17:59 ------- Let me clarify the scenario again why my machine hangs with pure 2.6.28-rc[123]. In function scsi_run_queue, before enter the while loop, there are 2 sdev on shost->starved_list. 1) When scsi_run_queue checks the first sdev, scsi_run_queue is set to point to the first sdev. 2) scsi_run_queue => __blk_run_queue ... =>scsi_request_fn to succeed in processing the first sdev. 3) scsi_run_queue goes to next loop in while to pick up the second sdev. the 2nd sdev is deleted from starved_list; 4) scsi_run_queue => __blk_run_queue ... =>scsi_request_fn to succeed in processing the 2nd sdev. Unfortunately, in function scsi_request_fn, "if (blk_queue_tagged(q) && !blk_rq_tagged(req))" is true this time, so the 2nd sdev is added back to starved_list. See below codes: if (blk_queue_tagged(q) && !blk_rq_tagged(req)) { if (list_empty(&sdev->starved_entry)) ========> list_add_tail(&sdev->starved_entry, &shost->starved_list); goto not_ready; } 5) scsi_run_queue goes to next loop in while to repeat step from 3) to 5). So it enters a dead loop. James' patch doesn't break the dead loop, and even couldn't break it when starved_list just has a sdev initially. So the checking should be in the tail of the while loop. -- 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
