From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
To: avorontsov@ru.mvista.com
Cc: Ingo Molnar <mingo@elte.hu>,
linux-ide@vger.kernel.org,
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Steven Rostedt <rostedt@goodmis.org>,
Daniel Walker <dwalker@mvista.com>
Subject: Re: [PATCH v2 -rt] ide: workaround buggy hardware issues with preemptable hardirqs
Date: Sat, 28 Jun 2008 14:30:36 +0400 [thread overview]
Message-ID: <486612CC.3060505@ru.mvista.com> (raw)
In-Reply-To: <20080628005436.GA1956@polina.dev.rtsoft.ru>
Hello.
Anton Vorontsov wrote:
> IDE interrupt handler relies on the fact that, if necessary, hardirqs
> will re-trigger on ISR exit. The assumption is valid for level sensitive
> interrupts.
>
It's valid for both edge and level triggered interrupts.
> But some hardware (namely ULi M5228 in the ULi M1575 "Super South Brige")
> behaves in a strange way: it asserts interrupts as edge sensitive. And
> because preemptable IRQ handler disables PIC's interrupt, PIC will likely
> miss it.
>
Unmasking an IRQ should re-enable an edge detector in a PIC (or that
detector should even be independent from mask). So, unless an IRQ signal
is a short pulse (which shouldn't be the case for IDE) it shouldn't be
missed.
> This patch fixes following issue:
>
> ALI15X3: IDE controller (0x10b9:0x5229 rev 0xc8) at PCI slot 0001:03:1f.0
> ALI15X3: 100% native mode on irq 18
> ide0: BM-DMA at 0x1120-0x1127, BIOS settings: hda:PIO, hdb:PIO
> ide1: BM-DMA at 0x1128-0x112f, BIOS settings: hdc:PIO, hdd:PIO
> hda: Optiarc DVD RW AD-7190A, ATAPI CD/DVD-ROM drive
> hda: UDMA/66 mode selected
> ide0 at 0x1100-0x1107,0x110a on irq 18
> ide-cd: cmd 0x5a timed out
> hda: lost interrupt
> hda: ATAPI 12X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache
> Uniform CD-ROM driver Revision: 3.20
> ide-cd: cmd 0x3 timed out
> hda: lost interrupt
> ide-cd: cmd 0x3 timed out
> hda: lost interrupt
> ...
>
> It would be great to re-configure the ULi bridge or ULi IDE controller
> to behave sanely, but no one knows how or if this is possible at all
> (no available specifications).
>
> So.. to workaround the issue IDE interrupt handler should re-check for
> any pending IRQs. This isn't bulletproof solution, but it works and this
> is the best one we can do
I remembered a pssible issue with such code: it's possible that BSY
bit will be cleared before INTRQ assertion (this is a race not spotted
for a long time by the ATA standards -- and an observed behavior, at
least of some ATAPI drives), thus a status register read won't clear the
"interrupt pending" condition within drive.
MBR, Sergei
next prev parent reply other threads:[~2008-06-28 10:30 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-23 23:40 [PATCH -rt] ide: fix interrupts processing issue with preempt-able hardirqs Anton Vorontsov
2008-06-23 23:51 ` Ingo Molnar
2008-06-24 0:00 ` Anton Vorontsov
2008-06-25 12:34 ` Anton Vorontsov
2008-06-25 12:32 ` Alan Cox
2008-06-25 14:12 ` Anton Vorontsov
2008-06-25 13:15 ` Sergei Shtylyov
2008-06-25 14:22 ` Anton Vorontsov
2008-06-25 14:32 ` Alan Cox
2008-06-25 15:26 ` Anton Vorontsov
2008-06-25 14:59 ` Anton Vorontsov
2008-06-28 0:54 ` [PATCH v2 -rt] ide: workaround buggy hardware issues with preemptable hardirqs Anton Vorontsov
2008-06-28 1:09 ` Anton Vorontsov
2008-06-28 9:15 ` Alan Cox
2008-06-28 9:14 ` Alan Cox
2008-06-28 10:43 ` Sergei Shtylyov
2008-06-29 12:49 ` Alan Cox
2008-06-29 13:17 ` Sergei Shtylyov
2008-06-29 14:23 ` Anton Vorontsov
2008-06-28 10:30 ` Sergei Shtylyov [this message]
2008-06-28 11:31 ` Anton Vorontsov
2008-06-28 11:52 ` Sergei Shtylyov
2008-06-29 23:26 ` Benjamin Herrenschmidt
2008-06-23 23:52 ` [PATCH -rt] ide: fix interrupts processing issue with preempt-able hardirqs Anton Vorontsov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=486612CC.3060505@ru.mvista.com \
--to=sshtylyov@ru.mvista.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=avorontsov@ru.mvista.com \
--cc=bzolnier@gmail.com \
--cc=dwalker@mvista.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).