On Sat, 18 Oct 2008, Michael Schmitz wrote:
While working on ide_do_request() improvements I stumbled upon
mismatched ide_get_lock() / ide_release_lock() calls.
[ It seems to be known issue:
http://marc.info/?l=linux-m68k&m=121423752829622&w=2 ]
It is a known issue, and I submitted a simple fix to Geert a month or so ago.
It involves moving the ide_get_lock call inside the request loop instead of
doing it once at the start of the function.
See http://marc.info/?l=linux-ide&m=121473433631934&w=2
In response to this patch, I wondered:
If hwgroup->busy serves a similar purpose to falconide_intr_lock, what
about
moving the setting/clearing of hwgroup->busy into
ide_{get,release}_lock()
(and possibly renaming ide_{get,release}_lock() to e.g.
ide_hwgroup_{set,clear}_busy())?
What about the other places where hwgroup->busy is set/cleared?
And Michael responsed:
Uh - that's where it gets a bit sticky again. hwgroup->busy is set and
cleared quite a lot 'preemptively' all over ide-io.c, f.e. in timeout
handling. I'm not sure
whether this would just reintroduce the bug message.
The lock must be held as long as there are any interrupts to be expected
from IDE. If the hwgroup->busy semantics reflects just that, it's worth
a try.
Bart, can you shed a light on the hwgroup->busy semantics?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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
