Subject: Re: DQ656 fix
To: None <port-vax@NetBSD.ORG>
From: John Wilson <wilson@dbit.dbit.com>
List: port-vax
Date: 12/07/1997 00:27:43
>As mentioned on the web page, the DQ656 hard drive controller doesn't
>quite work due to buggy hardware. The problem seems to be that it
>reports the sectors per cylinder to be 0. The MSCP code currently
>checks for this case, but sets ra_isafloppy. From line 516 of mscp_disk.c:
> if (dl->d_secpercyl != 0)
> dl->d_ncylinders = dl->d_secperunit/dl->d_secpercyl;
> else
> ra->ra_isafloppy = 1;
>
>As a test, I changed the last line to:
> if (dl->d_secperunit <= 4096) ra->ra_isafloppy = 1;
>
>In other words, if this disk is less than 4096 sectors (2MB), call it a
>floppy, else assume it is (buggy) hard drive. This seems to work
>just fine, although it doesn't really seem to be the best solution...
>Is there perhaps some other way to determine if it is a floppy?
I'm sure someone will correct me, but it seems reasonable to expect that
floppies have no RCT (i.e. RCT size=0 and/or # RCTs=0) and everything else
does (the spec actually says that *all* devices must have at least the first
block of the RCT, but DEC seems to violate this for floppies).
The UDA50 doc's description of the track, group, and cylinder size fields
(in the GET UNIT STATUS end message) all say they should be 0 "if the concept
of a track is inappropriate to this unit". Which sounds to me like zero
is the right value to use for a generic SCSI device which is just a vector
of blocks (in reality it may not be "square" anyway, or may be a RAM disk),
but I got burned by 2BSD UNIX requiring non-zero values in these fields for
the disk labeling scheme if nothing else (easily satisfied with bogus values)
so I guess it's a UNIX tradition to depend on the real geometry. None of
the DEC PDP-11 OSes I tried cared, don't know about VMS.
John Wilson
D Bit