On Wed, Jun 25, 2008 at 06:22:49PM +0400, Anton Vorontsov wrote:
> On Wed, Jun 25, 2008 at 05:15:43PM +0400, Sergei Shtylyov wrote:
> > Hello.
> >
> > Anton Vorontsov wrote:
> >
> >>>>> IDE interrupt handler relies on the fact that, if necessary,
> >>>>> hardirqs will re-trigger on ISR exit. With fully preemtable IRQs
> >>>>> this seems to be not true, since if hardirq thread is currently
> >>>>> running, and the same IRQ raised again, then this IRQ will be
> >>>>> simply lost.
> >
> >>>> actually no, that should not happen - if -rt loses an IRQ then
> >>>> something broke in the threaded IRQ code. It's supposed to be a
> >>>> drop-in, compatible IRQ flow with no driver changes needed.
> >
> >>> ..just as I thought, the bug somewhere deeper... heh.
> >
> >> Ok, a bit more investigation showed that this is indeed not RT specific
> >> per see, but issue emerges only on RT-style IRQ handlers + alim15x3 IDE
> >> controller (for example, PDC20269 works ok).
> >
> > Does it happen only with ATAPI devices also or with ATA disks too?
>
> So far I own two ATAPI devices, IDE disks are quire rare nowadays,
> should find one. ;-)
[...]
> >> Also, further testing showed that this issue isn't drive-specific, i.e.
> >> with a delay inserted before the unmask_irq(), the bug shows with any
> >> drive I have.
> >
> > So, "shit happens" even with the ATA drives?
>
> Will try as soon as I'll get one.
Thanks for the drive, and the result is:
hda: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
ide: failed opcode was: unknown
--
Anton Vorontsov
email: cbouatmailru@xxxxxxxxx
irc://irc.freenode.net/bd2
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
