Hi,
The following patch does, indeed, fix the ide_release_lock imbalance. No
more warnings.
--- drivers/ide/ide-io.c.orig 2008-06-27 20:11:42.000000000 +1200
+++ drivers/ide/ide-io.c 2008-06-27 20:32:50.000000000 +1200
@@ -1075,14 +1075,13 @@
ide_startstop_t startstop;
int loops = 0;
- /* for atari only: POSSIBLY BROKEN HERE(?) */
- ide_get_lock(ide_intr, hwgroup);
-
/* caller must own ide_lock */
BUG_ON(!irqs_disabled());
while (!hwgroup->busy) {
hwgroup->busy = 1;
+ /* for atari only */
+ ide_get_lock(ide_intr, hwgroup);
drive = choose_drive(hwgroup);
if (drive == NULL) {
int sleeping = 0;
Signed-off-by: <schmitz@xxxxxxxxxxxxxxxxxxxxxxxxxx>
Please apply.
Michael
(going to find a brown paper bag now ... I should really have spotted this
| ide_release_lock: bug
What would it take to get it fixed?
Just comment out the warning message in asm-m68k/ide.h - I've tried to keep
track of the lock depth but it appeared to get imbalanced rather quick with
multiple IDE requests being queued by the IDE disk driver.
What you can try is to move the ide_get_lock() call from here:
/* for atari only: POSSIBLY BROKEN HERE(?) */
ide_get_lock(ide_intr, hwgroup);
/* caller must own ide_lock */
BUG_ON(!irqs_disabled());
while (!hwgroup->busy) {
hwgroup->busy = 1;
to here:
/* caller must own ide_lock */
BUG_ON(!irqs_disabled());
while (!hwgroup->busy) {
hwgroup->busy = 1;
ide_get_lock(ide_intr, hwgroup);
drive = choose_drive(hwgroup);
in ide-io.c (around line 1180 in the copy I'm looking at right now, which is
of Dec, 2006 vintage).
We release the lock just before hwgroup->busy is cleared, so it should be
logical to get hold of the lock just after hwgroup->busy was set, no?
Thanks for reminding me to look into this again :-)
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
--
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
