From: "Gustavo Guillermo Pérez" <gustavo@compunauta.com>
To: linux-kernel@vger.kernel.org
Subject: Re: SCSI trow USB-STORAGE or SBP2 Debug for buggy device Kernels 2.6.X
Date: Thu, 27 Apr 2006 20:38:06 -0500 [thread overview]
Message-ID: <200604272038.06167.gustavo@compunauta.com> (raw)
In-Reply-To: <1146001711.3529.58.camel@mulgrave.il.steeleye.com>
El Martes, 25 de Abril de 2006 16:48, James Bottomley escribió:
> OK ... My best guess has to be that this device accepted and completed
> the command but is still processing it on the medium, hence the return.
> Try the attached; I think it makes for these cases. I could be
> persuaded to drop format and reconstruction in progress, because those
> can be *very* long operations.
Let me see, the patch of course does not apply, but I can figure out how to
proceed on kernel 2.6.16.
But guess who, not Device busy as error, of course and NO BAD SECTORS With
pktcdvd UDF.
:)
Txs, do you think this modification I can use without care on Sata o other
devices going trow SCSI?, cause I be wonder if this could be into main kernel
line.
Regards!!!!
> James
>
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 7b0f9a3..764a8b3 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -1067,16 +1067,29 @@ void scsi_io_completion(struct scsi_cmnd
> break;
> case NOT_READY:
> /*
> - * If the device is in the process of becoming ready,
> - * retry.
> + * If the device is in the process of becoming
> + * ready, or has a temporary blockage, retry.
> */
> - if (sshdr.asc == 0x04 && sshdr.ascq == 0x01) {
> - scsi_requeue_command(q, cmd);
> - return;
> + if (sshdr.asc == 0x04) {
> + switch (sshdr.ascq) {
> + case 0x01: /* becoming ready */
> + case 0x04: /* format in progress */
> + case 0x05: /* rebuild in progress */
> + case 0x06: /* recalculation in progress */
> + case 0x07: /* operation in progress */
> + case 0x08: /* Long write in progress */
> + case 0x09: /* self test in progress */
> + scsi_requeue_command(q, cmd);
> + return;
> + default:
> + break;
> + }
> }
> - if (!(req->flags & REQ_QUIET))
> + if (!(req->flags & REQ_QUIET)) {
> scmd_printk(KERN_INFO, cmd,
> - "Device not ready.\n");
> + "Device not ready: ");
> + scsi_print_sense_hdr("", &sshdr);
> + }
> scsi_end_request(cmd, 0, this_count, 1);
> return;
> case VOLUME_OVERFLOW:
--
Gustavo Guillermo Pérez
Compunauta uLinux
www.compunauta.com
next prev parent reply other threads:[~2006-04-28 1:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-24 15:29 SCSI trow USB-STORAGE or SBP2 Debug for buggy device Kernels 2.6.X Gustavo Guillermo Pérez
2006-04-24 18:38 ` James Bottomley
2006-04-24 21:30 ` Gustavo Guillermo Pérez
2006-04-24 22:02 ` James Bottomley
2006-04-24 22:12 ` Gustavo Guillermo Pérez
2006-04-25 6:09 ` Stefan Richter
2006-04-25 21:41 ` Gustavo Guillermo Pérez
2006-04-25 21:48 ` James Bottomley
2006-04-27 17:40 ` Gustavo Guillermo Pérez
2006-04-28 1:38 ` Gustavo Guillermo Pérez [this message]
[not found] ` <20060730160808.d67f71bb.akpm@osdl.org>
2006-08-09 4:03 ` Gustavo Guillermo Pérez
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=200604272038.06167.gustavo@compunauta.com \
--to=gustavo@compunauta.com \
--cc=linux-kernel@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.