lkml.org 
[lkml]   [2000]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: scsi init problem in 2.4.0-test10? [PATCH]
Date
> 

Yes, I know that is in the spec, but truly,
some scsi devices do act this way....
Maybe they need to read the spec :>

I have included the START_STOP for Matthew, but
I never see it execute with the ATLAS disks...
A diff follows for those that want to try it..

cheers,

Elizabeth

> The SCSI spec says that INQUIRY and not
> TUR + INQUIRY is the way to go, but maybe we
> should make it a compile time option for buggy
> drives.

-------------------------cut here ----------------------
*** scsi_scan.c.orig Tue Oct 24 14:01:54 2000
--- scsi_scan.c Thu Nov 2 18:59:30 2000
***************
*** 471,476 ****
--- 471,479 ----
Scsi_Request * SRpnt;
int bflags, type = -1;
extern devfs_handle_t scsi_devfs_handle;
+ int spintime = 0;
+ int retries = 0;
+ unsigned long spintime_value = 0;

SDpnt->host = shpnt;
SDpnt->id = dev;
***************
*** 499,504 ****
--- 502,574 ----
* not really necessary. Spec recommends using INQUIRY to scan for
* devices (and TEST_UNIT_READY to poll for media change). - Paul G.
*/
+ /* Add TUR back in to sync up the disk --
+ mostly borrowed from 2.2 kernel -- eamb */
+
+ do
+ {
+ retries = 0;
+
+ while (retries < 3)
+ {
+ scsi_cmd[0] = TEST_UNIT_READY;
+ scsi_cmd[1] = (lun << 5) & 0xe0;
+ memset((void *) &scsi_cmd[2], 0, 8);
+ SRpnt->sr_cmd_len = 0;
+ SRpnt->sr_sense_buffer[0] = 0;
+ SRpnt->sr_sense_buffer[2] = 0;
+ SRpnt->sr_data_direction = SCSI_DATA_READ;
+
+ scsi_wait_req (SRpnt, (void *) scsi_cmd,
+ (void *) scsi_result,
+ 256, SCSI_TIMEOUT+4*HZ, 3);
+
+ retries++;
+ if (SRpnt->sr_result == 0
+ || SRpnt->sr_sense_buffer[2] != UNIT_ATTENTION)
+ break;
+ }
+
+ if( SRpnt->sr_result != 0
+ && ((driver_byte(SRpnt->sr_result) & DRIVER_SENSE) != 0)
+ && SRpnt->sr_sense_buffer[2] == UNIT_ATTENTION)
+ {
+ break;
+ }
+
+ /* Look for devices that are NOT_READY.
+ * Issue command to spin up drive for these cases. */
+ if(SRpnt->sr_sense_buffer[2] == NOT_READY)
+ {
+ unsigned long time1;
+ if (!spintime)
+ {
+ scsi_cmd[0] = START_STOP;
+ scsi_cmd[1] = (lun << 5) & 0xe0;
+ scsi_cmd[1] |= 1; /* Return immediately */
+ memset((void *) &scsi_cmd[2], 0, 8);
+ scsi_cmd[4] = 1; /* Start spin cycle */
+ SRpnt->sr_cmd_len = 0;
+ SRpnt->sr_sense_buffer[0] = 0;
+ SRpnt->sr_sense_buffer[2] = 0;
+
+ SRpnt->sr_data_direction = SCSI_DATA_READ;
+ scsi_wait_req (SRpnt, (void *) scsi_cmd,
+ (void *) scsi_result,
+ 256, SCSI_TIMEOUT+4*HZ, 3);
+ }
+ spintime = 1;
+ spintime_value = jiffies;
+ time1 = HZ;
+ /* Wait 1 second for next try */
+ do
+ {
+ current->state = TASK_UNINTERRUPTIBLE;
+ time1 = schedule_timeout(time1);
+ } while(time1);
+ }
+ } while (SRpnt->sr_result && spintime && (retries < 3) &&
+ time_after(spintime_value + 100 * HZ, jiffies));

SCSI_LOG_SCAN_BUS(3, printk("scsi: performing INQUIRY\n"));
/*
-------------------------cut here ----------------------
>
>
> On Thu, Nov 02 2000, Elizabeth Morris-Baker wrote:
> > >
> >
> > You need to send the TUR first, but yes,
> > START_STOP will guarantee that you are
> > ready to rock and roll.
> > The first fix I wrote did a TUR, then
> > 3 tries at a START_STOP, till it worked.
> >
> > cheers,
> >
> > Elizabeth
> >
>
> [deleted]
>
> --
> Torben Mathiasen <tmm@kernel.dk>
> Linux ThunderLAN maintainer
> http://tlan.kernel.dk
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:45    [W:0.045 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site