Hi,
Roman's latest CVS updates broke IDE (ST-DMA) locking on the Falcon.
Reason: calls to ide_get_lock and ide_release_lock are not guaranteed to
be balanced. I fact, the very few first IDE operations leave the driver
with a perceived imbalance of four excess lockings. Don't ask me why this
happens - the IDE driver seems to process multiple requests in one session
and only releases the lock if no more work can be done.
For that reason, falcon_intr_lock may only be incremented when the lock is
actually taken. In the alternative, the lock _must_ be released no matter
what number of times ide_get_lock was called (the lock was only taken on
the first call anyway).
This change then fixes the Falcon SCSI hang on boot I had reported on
debian-68k (tested on ARAnyM). SCSI still fails on the Falcon as soon as
the first timeout hits a connected command (tested in my tree). I have
looked at the current error handling in atari_scsi and other drivers, and
it may be as simple as using the proper return codes instead of trying to
be smart and hinting the midlevel about subtle details. I'll test that as
soon as I can get some idle time on hobbes.
Patch (implementing the former method):
--- include/asm-m68k/ide.h.rz.org 2006-12-17 17:30:41.000000000 +0100
+++ include/asm-m68k/ide.h 2006-12-22 12:40:31.000000000 +0100
@@ -114,7 +114,8 @@
{
if (MACH_IS_ATARI) {
if (falconide_intr_lock == 0) {
- printk("ide_release_lock: bug\n");
+ if (stdma_islocked())
+ printk("ide_release_lock: not held but DMA locked!\n");
return;
}
if (!--falconide_intr_lock)
@@ -130,8 +131,8 @@
if (in_interrupt() > 0)
panic( "Falcon IDE hasn't ST-DMA lock in interrupt" );
stdma_lock(handler, data);
+ falconide_intr_lock++;
}
- falconide_intr_lock++;
}
}
#endif /* CONFIG_BLK_DEV_FALCON_IDE */
Signed-Off-By: <schmitz@xxxxxxxxxx>
Please apply,
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
