From: Albert Lee <albertcc@tw.ibm.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Jeff Garzik <jeff@garzik.org>, Tejun Heo <htejun@gmail.com>,
Linux IDE <linux-ide@vger.kernel.org>,
Doug Maxey <dwm@maxeymade.com>,
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>,
Mark Lord <liml@rtr.ca>
Subject: Re: [PATCH 8/8] libata: ack more unsolicited INTRQ
Date: Thu, 17 May 2007 16:59:30 +0800 [thread overview]
Message-ID: <464C1972.6050205@tw.ibm.com> (raw)
In-Reply-To: <20070516140201.29d0f6f0@the-village.bc.nu>
Alan Cox wrote:
>>As previously discussed, the possible issue with this patch is:
>>Some ATA/ATAPI devices might be unhappy if the STATUS register
>>is read during data transfer (not sure if this is true or not).
>>(Patch 5/8 doesn't have such issue.)
>
>
> Some older intel eats your disk if you do that.
Ah, too bad. Thanks for the advice.
>
> Neither of these approaches quite work. Much as I dislike the "old IDE"
> disable/enable irq approach it does look like that is the only safe
> answer for some controllers.
>
Agreed reading the status register during data transfer looks bad.
Please disregard this patch.
Back to the problem that the patch was trying to solve,
i.e. unsolicited interrupt when HSM doing data transfer in the wq,
is there any experience about how often such situation occurs?
IMHO, it seems not something that happens often. If the cable/devices
are well configured, the intrq would mostly occur when it should.
Even if the unsolicited irq happens, maybe the current code has
good chance to handle it?
e.g. ata_irq_task() already reads the status before data transfer,
thus possibly clearing some of unsolicited irqs.
e.g. maybe the data transfer in the workqueue is quick enough?
If yes, hopefully the ATA_PFLAG_HSM_WQ is soon cleared, and
then the interrupt handler can come in ack the irq. (Much the same
way when the irq handler encounters "early irq" by bad devices.)
--
albert
next prev parent reply other threads:[~2007-05-17 9:00 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-16 7:03 [PATCH/RFC 0/8] libata: delegate irq driven pio to workqueue (take 2) Albert Lee
2007-05-16 7:09 ` [PATCH 1/8] libata: fix the ata_altstatus() in ata_hsm_qc_complete() Albert Lee
2007-05-16 7:11 ` [PATCH 2/8] libata: move ata_altstatus() out from ata_hsm_move() to the pio data xfer functions Albert Lee
2007-05-16 7:13 ` [PATCH 3/8] libata: change the state after "PIO data-in" to HSM_ST_IDLE instead of HSM_ST_LAST Albert Lee
2007-05-16 7:18 ` [PATCH 4/8] libata: move and reduce locking to the pio data xfer functions Albert Lee
2007-05-16 7:20 ` [PATCH 5/8] libata: ack unsolicited INTRQ when polling Albert Lee
2007-05-16 7:23 ` [PATCH 6/8] libata: delegate irq driven pio to workqueue Albert Lee
2007-05-16 7:24 ` [PATCH 7/8] libata: fix ata_port_flush_task() for irq pio delegation Albert Lee
2007-05-16 7:29 ` [PATCH 8/8] libata: ack more unsolicited INTRQ Albert Lee
2007-05-16 13:02 ` Alan Cox
2007-05-17 8:59 ` Albert Lee [this message]
2007-05-17 9:25 ` Tejun Heo
2007-05-17 15:42 ` Mark Lord
2007-05-17 15:50 ` Tejun Heo
2007-05-17 16:00 ` Alan Cox
2007-05-17 9:28 ` Alan Cox
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=464C1972.6050205@tw.ibm.com \
--to=albertcc@tw.ibm.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=albertl@mail.com \
--cc=bzolnier@gmail.com \
--cc=dwm@maxeymade.com \
--cc=htejun@gmail.com \
--cc=jeff@garzik.org \
--cc=liml@rtr.ca \
--cc=linux-ide@vger.kernel.org \
/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).