IDE lockups with 2.5.28...
Quoted 11 lines · Marcin Dalecki
Quoted 3 lines · Petr Vandrovec
Well, no. Both of these loop have completely different terminating conditions. You exit when IDE hardware is busy, while SCSI exits if hardware is busy, or when there is nothing to do. Fundamental difference.
Shit - you are right. We look until the next request sets
IDE_BUSYas a side effect.... I just wanted to close the window between clear we clearIDE_BUSYinata_irq_handlerjust before recallingdo_requestto set it immediately on again.
Should be both of course.
Most of IDE code access IDE_BUSY flag when queue lock is held. So just move it inside lock everywhere... As side benefit you do not have to use atomic test_and_set then, you can use faster non-atomic (without lock prefix) equivalents.
In fact it looks to me like that only tcq's udma_tcq_start accesses IDE_BUSY without holding queue lock, and it is only read access to print some BUG()-like message.
Petr Vandrovec [email protected]