On Sun, 9 May 1999, Thilo Manske wrote:

> This may happen if the disk hasn't spun up with the hardware start,
> Most IBM drives have a jumper to control auto spin-up. If you don't
> have the jumper specs for your drive, search storage.ibm.com

It's got a pretty limited selection of jumper settings (drive 0, drive 1,
cable select).  Listening closely when powering up the Shark, it's very
obvious that the drive spins up as soon as the external power supply is
connected to the Shark.  The drive is a little odd in that the label on it
states it's a model DADA-24860, but the identity reported by NetBSD/arm32
is EAEA-25870.  In checking IBM's websites (www.storage.ibm.com and
www.ibm.com/harddrive/) I could find no reference to either of those two
model numbers.  I did find the IBM Travelstar 6GN model DBCA-204860 which
matched the drive's physical and logical description, but it's annoying to
think that this one drive might have 3 different model numbers.  This
particular one is labeled as being manufactured in Hungary during November
of 1998.

> try:
> disklabel /dev/wd0 > tempfile
> (edit tempfile, correct size etc.)
> disklabel -R -r /dev/wd0 tempfile

No luck.  The first command results in the following being output to
tempfile (I've redirected stderr as well):

---
# /dev/wd0c:
type: unknown
disk: IBM-EAEA-25870! 
label: fictitious
flags:
bytes/sector: 512
sectors/track: 319
tracks/cylinder: 271
sectors/cylinder: 86449
cylinders: 10068
total sectors: 26291476
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0		# milliseconds
track-to-track seek: 0	# milliseconds
drivedata: 0 

8 partitions:
#        size   offset     fstype   [fsize bsize   cpg]
  c: 26291476        0     unused        0     0         # (Cyl.    0 - 304*)
disklabel: boot block size 0
disklabel: super block size 0

---

I edit this to fit the drive's specs, even being careful to pick values
which match to the cylinder boundaries (just because).

---
# /dev/wd0c:
type: IDE
disk: IBM-EAEA-25870
label: fictitious
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 15
sectors/cylinder: 945
cylinders: 10068
total sectors: 9514260
rpm: 4200
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0           # milliseconds
track-to-track seek: 0  # milliseconds
drivedata: 0

6 partitions:
#        size   offset     fstype   [fsize bsize   cpg]
  a:    66150        0     4.2BSD     1024  8192     0   # (Cyl.    0 - 69)
  b:   524475    66150       swap                        # (Cyl.   70 - 624)
  c:  9514260        0     unused        0     0         # (Cyl.    0 - 10067)
  d:   131355   590625     4.2BSD     1024  8192     0   # (Cyl.  625 - 763)
  e:  1048950   721980     4.2BSD     1024  8192     0   # (Cyl.  764 - 1873)
  f:  7743330  1770930     4.2BSD     1024  8192     0   # (Cyl. 1874 - 10067)

---

Applying this to the disk with disklabel -r -R /dev/wd0 tempfile results
in what appears to be a successful labeling.  The in core copy of the
label matches the above.  Trying to read the label with disklabel -r
/dev/wd0 just results in a "no disk label" error.  

I'm not sure if this is related or not, but I've noticed that a lot of the
kvm dependent utils within the 1.4_BETA snapshot report kvm errors. Things
like dmesg, vmstat, systat, and possibly others.

-brian.
---
Brian "JARAI" Chase | http://world.std.com/~bdc/ | VAXZilla LIVES!!!