Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 14 Jan 1999 02:02:30 -0500 (EST)
From:      "Mark W. Krentel" <krentel@dreamscape.com>
To:        freebsd-stable@FreeBSD.ORG
Subject:   scsiformat timeout
Message-ID:  <199901140702.CAA00951@dreamscape.com>

next in thread | raw e-mail | index | archive | help
I'm having a problem with scsiformat in 2.2.8-release.
/sbin/scsiformat is an sh script that issues the command: 

    scsi -s 28800 -f $RAW -c "4 0 0 0 0 0"

where $RAW is something like /dev/rsd1.ctl.  The problem seems to be
that 28800 seconds (8 hours) is too long.  Between 2.2.7 and 2.2.8,
this number was bumped up from 14400 in response to PR 7803 which
complained that 14400 was too small and cited an example disk that
takes >4 hours to format. 

Anyway, when I run scsiformat on a zip100 disk (scsi drive), the
command returns immediately with this message:

    # scsiformat -q -w sd1 
    IOMEGA 
    ZIP 100 
    E.11 

    This will destroy all data on this drive!
    Hit return to continue, or INTR (^C) to abort: 
    Formatting... this may take a while.
    SCIOCCOMMAND ioctl: Command accepted.
    return status 1 (Command Timeout) after 28800000 msCommand out (6 of 6):
    04 00 00 00 00 00 

    No sense sent.
    # 

And this appears on the console (when I get out of X windows):

    sd1(ahc0:3:0): SCB 0x0 - timed out in command phase,
        SCSISIGI == 0x84  SEQADDR = 0x48  SCSISEQ = 0x12
        SSTAT0 = 0x7  SSTAT1 = 0x2
    sd1(ahc0:3:0): abort message in message buffer
    sd1(ahc0:3:0): SCB 0 - Abort completed
    sd1(ahc0:3:0): no longer in timeout

I tried running scsi directly and fiddled with the -s (timeout) parameter.
Turns out that any number greater than 22000 produces the above error
and anything smaller than 21000 works fine (takes about 9 min to format).

Now, this is no tragedy because I can always run scsi directly or edit
the scsiformat script on my system.  But I am wondering just what is
the problem.

Is 28800 really too large, or does it work on some systems?
Does this vary by controller or disk?  Don't blame the zip disk; I get 
the same error with my old Seagate ST31200N (1 gig, from June 94).

I have a PPro 166, ASUS 440FX mobo and Adaptec 2940-UW controller
(about 2 years old).  Nothing special in the kernel:

    controller      ahc0
    controller      scbus0
    device          sd0
    device          cd0
    options         SCSI_DELAY=3

--Mark Krentel

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901140702.CAA00951>