From owner-freebsd-questions Sun Apr 30 21:27:35 1995 Return-Path: questions-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA13157 for questions-outgoing; Sun, 30 Apr 1995 21:27:35 -0700 Received: from galois.nscf.org (Galois.nscf.org [192.48.117.201]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id VAA13144 for ; Sun, 30 Apr 1995 21:27:28 -0700 Received: by galois.nscf.org with UUCP (5.67/1.2) id AA01454; Sun, 30 Apr 95 22:56:34 -0400 Received: by wa4phy.ASYNC.COM (5.65/Smail2.5/02-15-88) id AA11659; Sun, 30 Apr 95 23:05:23 -0400 Received: (from bao@localhost) by saigon.async.com (8.6.11/8.6.9) id XAA01172; Sun, 30 Apr 1995 23:03:40 -0400 Date: Sun, 30 Apr 1995 23:03:39 -0400 (EDT) From: Bao Chau Ha To: Terry Lambert Cc: questions@FreeBSD.org Subject: Re: 950412-SNAP Installation with ESDI (WD1007V) System In-Reply-To: <9505010021.AA04511@cs.weber.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: questions-owner@FreeBSD.org Precedence: bulk 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.