Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 30 Apr 1995 23:03:39 -0400 (EDT)
From:      Bao Chau Ha <bao@saigon.async.com>
To:        Terry Lambert <terry@cs.weber.edu>
Cc:        questions@FreeBSD.org
Subject:   Re: 950412-SNAP Installation with ESDI (WD1007V) System
Message-ID:  <Pine.LNX.3.91.950430215400.643B-100000@saigon.async.com>
In-Reply-To: <9505010021.AA04511@cs.weber.edu>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Sun, 30 Apr 1995, Terry Lambert wrote:

> These controllers have some intrinsic problems with using a
> translated "perfect" geometry.
> 
> 
> The first problem is that the geometry is not available to BSD
> at all.  You have to ask for geometries in real mode because you
> have to do an int 13 AH-8 to get them.
> 
> That leads us to the second problem, which is that the BIOS chaining
> order for a controller is not going to necessarily be the same as
> the BSD (or Linux or whatever) controller recognition order.
> 
> That means that given an INT 13 AH=8, an AL of 0x80, 0x81, 0x82, etc.
> will represent drives "C:", "D:", "E:", etc., but there's no way
> to map these drive numbers to the corresponding protected mode
> device.  If this works for you, it's an accident, and if you change
> the device build order in the kernel or the chaining order of the
> controllers, you may just find the other protected mode OS's not
> working, or you can change the device order by building a new BSD
> kernel.
>
I think "C:" drive is the first drive and "D:" drive is the
second drive at this level.  Upon return, ES:DI points to the
parameter table of the drive.  This table contains the
ficticous geometry of the drive which is used by DOS, OS/2, and
Linux fdisk programs.

For example, the drive I am having problems is a Maxtor XT4380E.
Its real geometry is 1224 tracks by 15 heads by 36 sectors/track.
The WD1007V reserved the last two tracks so there are only 1222
tracks available.  Since I use spare sectors, the 36 sectors per
tracks are indexed from 0-35.  Sector 0 is invisible (ST506/412
standard I think) and used to remapped a bad sector on the 
particular track.  If there are more than 1 bad sector, the 
whole track will be marked bad.  So, in reality, my disk drive 
now has only 1222 tracks by 15 heads by 35 sectors/tracks.  To 
bypass the INT 13 limitation of 1024 cylinders, the drive was 
mapped into 636 tracks by 16 heads by 63 sectors/track.

Unfortunately, since the WD1007V predated the IDE, it responds to
a READ_PARAMTER command by returning the true geometry, instead
of the usable geometry of 1222 cyl. x 15 hd. x 35 s/cyl.  I think
this is what confuses the device driver.

Also, all of this is done by the firmware, without the disk BIOS.
The ficticous geometry is actually stored on a space within the
last two tracks.  Once it is set, the controller BIOS can be
disabled.  The drive will still behave correctly if the CMOS
disk parameters are set the same as the "ficticous" parameters.

I think the bios geometries can be obtained early during the
boot up process before switching to the protected mode.  These
parameters once initialized do not need to be accessed in the
real mode again.  They should also be used rather than the real
geometries so that the drives can be shared between DOS or any
other OSes that can recognize the ficticous geometries.

> > The disk is perfect, since all of the bad spots have been remapped
> > to the spare sectors.  This is a controller firmware feature, just
> > like the current IDE or SCSI drives.
> 
> OK, this is a *drive* firmare feature for SCSI and IDE.
> 
> The problem with this being controller firmware in the WD1007 is a
> two level problem.  The first level is that the "perfection" of the
> drive only exists if you access the drive through the BIOS.  This
> was the gist of my previous posting about VM86() based drivers.
> This ordinarily wouldn't be a bad thing if the replacement sectors
> were put all in one spot at the end of the drive.  Now we come to
> our second problem.
> 
As I explained before, the feature is provided by the firmware,
not the controller BIOS.  It is hidden away from the operating
system.  Any accesses within the preset ficticous geometries
will be silently remapped to the real geometry by the drive
controller, a lowly Intel 80188 CPU.  To a protected mode OS, 
the controller is nothing more than a set of I/O registers.

Anyway, thanks for the comments.  I will be trying to load
FreeBSD on a different system with a SCSI disk system.  When I
have chance to look at the source code and to compare it against
Linux, I may understand what has gone wrong with the WD1007V.
I am still waiting for the ESDI disk system to go south so I
can upgrade to a modern system.  Watching the free fall of
disk drive price during the last year or so has also been fun.

Bao

--
Bao Chau Ha (bao@saigon.async.com)
Nuclear chemical engineer by day, Linux hacker by night and weekends.




Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.91.950430215400.643B-100000>