From: Dominic Curran <dominic.curran@citrix.com>
To: "linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>
Subject: Possible bug in ide_cd_queue_pc() or ide_wait_stat() ?
Date: Wed, 28 Jul 2010 11:46:26 +0100 [thread overview]
Message-ID: <4C500A82.2040805@citrix.com> (raw)
I have some TEAC DV-28E-V CDROM drives that after polling for status
starts to timeout requests (the time it takes to do this varies between
5mins and 24hrs).
I believe only an APATPI reset gets them out of this timeout behaviour.
I assume this is down to bad firmware/hardware (the latest firmware has
been applied).
I happens on multiply drives of this version.
BUT...
The problem is that even when the requests timeout the ioctl
CDROM_DRIVE_STATUS will receive a status of CDS_DISC_OK.
This is obviously not the correct status (particularly when there is no
CD disc in the drive).
I have added some instrumentation to the code and this is the general
stack flow I see:
In the interrupt handler:
do_ide_request()
ide_do_request()
start_request() returns ide_stopped
ide_wait_stat() returns -EBUSY
ide_error() returns ide_stopped + stat=0xD0 {Busy}
ide_dump_status() returns 0 (so err=0)
rq->errors = 1;
ide_end_drive_cmd(err) b/c err is 0, then sets rq->errors=0
In the ioctl:
ide_cdrom_drive_status() Returns CDS_DISC_OK
cdrom_check_status() Returns 0.
ide_cd_queue_pc() Ignores the return from blk_execute_rq(). Checks for the flag REQ_FAILED in rq->cmd_flags (which is not set). Returns 0.
blk_execute_rq() Since rq->errors==1 and then returns 0
wait_for_completion()
The problem seems to be that in ide_cd_queue_pc():
1) the error return from blk_execute_rq() is ignored
2) the REQ_FAILED in rq->cmd_flags is not set in the interrupt handler (which is what ide_cd_queue_pc() seems to be concerned about)
Anyone have any comments:
1) why in ide_dump_status() a stat of BUSY_STAT does not translate to an error return ?
2) Is setting rq->cmd_flags |= REQ_FAILED in ide_wait_stat() an acceptable way to solve issue.
Patch something like this...
Index: linux/drivers/ide/ide-iops.c
===================================================================
--- linux.orig/drivers/ide/ide-iops.c 2010-07-20 15:37:01.871300665 +0100
+++ linux/drivers/ide/ide-iops.c 2010-07-28 11:43:21.386752993 +0100
@@ -652,6 +657,9 @@ int ide_wait_stat(ide_startstop_t *start
if (err) {
char *s = (err == -EBUSY) ? "status timeout" : "status error";
*startstop = ide_error(drive, s, stat);
+
+ if (err == -EBUSY)
+ rq->cmd_flags |= REQ_FAILED;
}
return err;
I appreciate any pointers you can give
Thanks
dom
next reply other threads:[~2010-07-28 10:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-28 10:46 Dominic Curran [this message]
2010-07-28 11:51 ` Possible bug in ide_cd_queue_pc() or ide_wait_stat() ? Borislav Petkov
2010-07-28 15:23 ` Dominic Curran
2010-07-29 8:12 ` Borislav Petkov
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=4C500A82.2040805@citrix.com \
--to=dominic.curran@citrix.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.