http://bugzilla.kernel.org/show_bug.cgi?id=11898 ------- Comment #27 from yanmin_zhang@xxxxxxxxxxxxxxx 2008-11-06 17:04 ------- (In reply to comment #26) > Reply-To: James.Bottomley@xxxxxxxxxxxxxxxxxxxxx > > On Wed, 2008-11-05 at 18:19 -0800, bugme-daemon@xxxxxxxxxxxxxxxxxxx > wrote: > > ------- Comment #25 from yanmin_zhang@xxxxxxxxxxxxxxx 2008-11-05 18:19 ------- > > Created an attachment (id=18697) --> (http://bugzilla.kernel.org/attachment.cgi?id=18697&action=view) [details] > > --> (http://bugzilla.kernel.org/attachment.cgi?id=18697&action=view) > > Here is the patch to fix it against 2.6.28-rc3. > > > > I tested the patch on my 2 machines and it does fix the issue. > > The problem is that it doesn't fix the theoretical tight loop, so What's the theoretical tight loop the patch doesn't fix? Would you like to elaborate it? I know there is a scenario that scsi_target_is_busy might returns true in scsi_run_queue, but my patch also fixes it. > someone else will run into the issue under more trying circumstances. > > The only reason a patch which conditionally NULLs starved_head works > over one that does it absolutely should be that there's some other loop > that requires it being set to effect a break out. I can't understand what you said. What are the other 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
