Sun Managers,
On Thursday, May 11, 1995, I posted the following:
> I am puzzled by the behavior of a Seagate ST31230N disk I have installed. I
> used John DiMarco's (excellent) scsiinfo utility to generate format.dat
> information for the disk and created a partition entry which suits my needs,
> all of which looks like this:
>
> disk_type = "Seagate ST31230N" \
> : ctlr = SCSI : fmt_time = 3 \
> : trks_zone = 5 : asect = 5 : atrks = 10 \
> : ncyl = 3978 : acyl = 2 : pcyl = 3992 : nhead = 5 : nsect = 104 \
> : rpm = 5411 : bpt = 61152
>
> partition = "Seagate ST31230N" \
> : disk = "Seagate ST31230N" : ctlr = SCSI \
> : a = 0, 31200 : b = 60, 131560 : c = 0, 2068560 : g = 313, 317720 \
> : h = 924, 1588080
>
> After I labeled the disk, anything that attempts to read the label (such as
> the format utility) gets this:
>
> selecting sd1: <Seagate ST31230N>
> No sense error during read
> ASC: 0x0 ASCQ: 0x0
> No sense error during read
> ASC: 0x0 ASCQ: 0x0
> [disk formatted, no defect list found]
>
> And any attempt to rewrite the label (as with the `label' function within
> format) gets this:
>
> No sense error during write
> ASC: 0x0 ASCQ: 0x0
> Warning: error writing backup label.
> No sense error during write
> ASC: 0x0 ASCQ: 0x0
> Label failed.
>
> Coincidently, the following appears in the messages file:
>
> May 11 17:58:01 vmunix: sd1c: Vendor 'SEAGATE' error code: 0x21
> May 11 17:58:01 vmunix: sd1c: Error for command 'write'
> May 11 17:58:01 vmunix: sd1c: Error Level: Fatal
> May 11 17:58:01 vmunix: sd1c: Block 2075745, Absolute Block: 2075745
> May 11 17:58:01 vmunix: sd1c: Sense Key: Illegal Request
>
> The odd thing is, the disk formats and verifies without any errors, and I
> can build file systems on it, run fsck, and write on it, no problem. The
> machine will even boot from it. The problem appears to be that the label
> somehow contains a reference to block #2075745, which doesn't exist. This
> reference isn't evident in the output of format> partition> print>:
>
> partition> print
> Current partition table (original sd1):
> partition a - starting cyl 0, # blocks 31200 (60/0/0)
> partition b - starting cyl 60, # blocks 131560 (253/0/0)
> partition c - starting cyl 0, # blocks 2068560 (3978/0/0)
> partition d - starting cyl 0, # blocks 0 (0/0/0)
> partition e - starting cyl 0, # blocks 0 (0/0/0)
> partition f - starting cyl 0, # blocks 0 (0/0/0)
> partition g - starting cyl 313, # blocks 317720 (611/0/0)
> partition h - starting cyl 924, # blocks 1588080 (3054/0/0)
>
> Does anyone have any insight ?
I got responses from:
Paulo Licio de Geus <paulo@parana.dcc.unicamp.br>
Chris Wozniak TISC <chris@tisc.edu.au>
Sean Ward <seanw@amgen.com>
Thanks guys, for taking time to reply.
Each of the responses had the right idea in general - back critical format.dat
parameters down till the problems go away. I actually ended up increasing the
value of ncyl, and lowering nsect, asect, and bpt values from the format.dat
entry shown above. I obtained correct values for these parameters from the
specs for the disk listed in the Seagate web page (http://www.seagate.com).
Also, I had to adjust (downward) the size of the c partition until the illegal
block error (described above) went away. Here's the format.dat entry I wound
up with, which seems to work fine:
disk_type = "Seagate ST31230N" \
: ctlr = SCSI : fmt_time = 3 \
: trks_zone = 5 : atrks = 10 : asect = 1 \
: ncyl = 3992 : acyl = 2 : pcyl = 3994 : nhead = 5 : nsect = 103 \
: rpm = 5411 : bpt = 52736
partition = "Seagate ST31230N" \
: disk = "Seagate ST31230N" : ctlr = SCSI \
: a = 0, 30900 : b = 60, 130810 : c = 0, 2055880 : g = 314, 315695 \
: h = 927, 1578475
Responses are attached.
-- David Way McDonald Observatory/Astronomy Dept.- Univ. of Texas, Austin (office) RLM 16.206 (voice) 471-7439 (internet) dpw@astro.as.utexas.edu -- From: paulo@parana.dcc.unicamp.br (Paulo Licio de Geus)Lower the number of usable cylinders so that the next cylinder before the last usable does not go as far as the block number you mentioned. The label for the disk goes after the usable cylinders, and somehow scsiping got not the correct number of cylinders for the correct format.dat. It's not scsiping's fault, because all my disks I do this manually on a macintosh, whose formatting utilities tell me the exact number of blocks the disk has (OK, scsiping is supposed to that as well...); even so, sometimes I got similar problems.
I then go lowering the number of cylinders one by one till the error does not show up (usually one or two cylinders before the one I initially calculated. Mind you, my format.dat's usually get a few extra KB's, sometimes MB's, from the same disk as opposed to scsiping's findings. My entries are derived from the total number of blocks and should not, in theory, present problems. Sometimes they do, and the only reasonable explanation is the SCSI controller on the drive lying about its formatted capacity. I've seen references to this issue before. -- From: Chris Wozniak TISC <chris@tisc.edu.au>
I've recently connected the Seagate Barracuda ST32550 and had a very similar problem with making it go. You don't tell in your message what OS version you're using. I posted a couple of queries to the sun-managers and most replies told me that Seagate Fast SCSI 2 has some problems working with Sun SCSI 1 and Sun OS 4.1.x. In my case I managed to get read of the error message about the bad block by extracting the list of defects first, re-labelling and then re-formatting the disk. Originally I was told that this (ie. extracting the list and re-formatting won't be necessary, so I didn't /why waste 2 + hours :)/). I was still having occasional messages about sense key error popping up during the periods of heavy disk activity. I consulted the sun-managers again and was told that there were bugs in Seagate fast disks firmware and that Seagate replaces it free of costs, on user's request. I sent my disk to Seagate and they replaced firmware rev. 00012 with 00013 and I've had no problems since. People claimed that this replacement is non-destructive, but Seagate contacted me and said that they had to reformat the disk. You can find the firmware revision using scsiinfo -p to get something like: esp0: sd1 tgt 1 lun 0: Synchronous(5.0MB/sec) Clean CanReconnect Non-removable Disk: SEAGATE ST32550N 0013 ^^^^^^ firmware revision number
Allegedly there should be no problems on systems running Solaris 2.x -- From: seanw@amgen.com (Sean Ward)
That error looks like it's trying to reference a block that doesn't exist. I suspect you've made the "pcyl" number too large. You might try to label the disk again with the pcyl number being 3980 (ncyl+acyl).
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:25 CDT