Date: Mon, 1 May 95 11:16:38 MDT From: terry@cs.weber.edu (Terry Lambert) To: bao@saigon.async.com (Bao Chau Ha) Cc: questions@FreeBSD.org Subject: Re: 950412-SNAP Installation with ESDI (WD1007V) System Message-ID: <9505011716.AA05410@cs.weber.edu> In-Reply-To: <Pine.LNX.3.91.950430215400.643B-100000@saigon.async.com> from "Bao Chau Ha" at Apr 30, 95 11:03:39 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. OK, this unfortunately misses the point, which is that with BIOS chaining, it's impossible to reliably determine which DOS drive is which target on which controller. The closest you could come is to CRC known areas of the drive before going into protected mode, then CRC them again once you are in protected mode to find out which DOS parameters map to which drives. Since yours isn't a multiple controller situation, this rules that out, and it's not a boot misidentification problem where the BSD can't find it's own drive, but the BIOS *can* find and load it. This is one failure mode down. 8-). > 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. As long as this is done in hardware rather than in BIOS, this type of remapping will be invisible. I believe that at least some of the bad sectoring is handled by BIOS. I make this claim because the translated geometry you indicate is 636/16/63. This implies that the 0-35 number you gave for the 1222/15/35 should really have been 0-63. This implies that the spare sectors are all over the drive, except for the first cylinder and each LCF 35x64 cylinder subsequent to the first that happens to have the 0's matching up. As I've said before, I've installed several WD1007's with both the FreeBSD and NetBSD distributions, and I've used this congruency to pick DOS and BSD regions such that the first sector of the second region happens to fall on one of these blocks (the second being BSD). This works for this particular non-linear translation model because the BSD's I installed had BAD144 handling and the WD1007's particular non-linear sector/track replacement algorithm doesn't cause cylinder skips for cylinders marked bad. > 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. OK, this is pretty much irrelevent. Bruce Evans is the guy to answer this more definitively, but I believe that the geometry is only relevent during the BIOS phase of the boot process: that is, where the geometry is catually seen as the fictitious geometry anyway. There is one place where the protected mode OS needs the geometry. When the boot occurs, the BIOS reads the MBR off the first available boot device. Then it jumps to the MBR. The MBR contains a table called the DOS partition table; this contains the C/H/S offsets, and for some releases of DOS, the absolute sector offsets as well. The MBR goes to the location given by the active partition and it reads the OS specific boot track from the start of the OS specific partition. In DOS, this is typically msdos.sys; in BSD, it is the BIOS boot code that was written out when the disklabel command was run. The BSD BIOS boot code uses BIOS calls to locate the root partition by reading the disklabel. Once there, it uses BIOS calls to read the requested file off the root partition, since it has a very basic understanding of the UFS file system. By default, it will read the file "/kernel" by scanning inode 2 (the "/" directory, by definition) for the "kernel" file. Actually, I don't think it understands any subdirectories or anything -- I think it can only read a file in "/". This is the point where it (effectivly) is now in protected mode, and jumps to the kernel to begin executing. All disk I/O past this point is done using the disk driver in the kernel. And here is where the possible failure modes start to stack up. 1) If the disk was using non-linear translation, it's possible that part of the disklabel, the root inode in the 'a' slice, one of the directory blocks before the file "kernel" in the root directorythe inode for the kernel file, or one of the blocks in the kernel file itself happened to be on a "spare" block where the BIOS couldn't read it. This is because they are written by the protected mode OS and not by BIOS. 2) If the geometry is non-linear, the absolute sectoring will be different. It used to be that the protected mode OS used the fictitious geometry exactly once, to translate the C/H/S values from the disklabel to find the 'a' slice for the kernel to mount root. Now it's passed in by the boot as an absolute sector offset, but if the translation is non-linear (as it is with a WD1007 in "perfect" mode), then what will happen is the newly booted kernel will not be able to locate the BSD partitions, and therefore will not be able to locate the disklabel, and therefore will not be able to locate the 'a' slice and therefore will not be able to mount root. > 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. The BSD disk driver uses a reset command to the drive; this is likely to kill the translated geometry for the drive. This has two possible effects: 1) No effect. The geometry is only useful for turning a C/H/S value into an absolute sector offset in the BIOS to conform to the INT 21 BIOS interface which stupidly used C/H/S values instead of absolute sector offsets from the initial IBM design. Once the protected mode OS is running, then there is never a need to refer back to the geometry ever again unless you do something like mount a DOS partition (in which case, this would probably fail for non-linear translation because the FAT entries would not really point to where they ought to). A worst case scenario is that you can't mount your DOS partitions. 2) Catastrophic effect. This would happen if the translated geometry adjustments were actually made in firmware, but based on the geometry from the BIOS. A controller reset would change this -- the result being the 35/63 discrepancy discussed earlier not only "happening" to take place, but being forced on the user. The problem in determining if this is happening is that I don't know if the cylinder sparing that the WD1007 does is always based on the real geometry or not (one scholl of thought says it should be to avoid this problem and the other school of thought says that this would mean a bad sector is a bad sector, but a bad cylinder would take a hunk out of 1-2 cylinders when it went (depending on whether or not it was spanning a fictional boundry). > 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 geometries are. But as I said before, they are only ever used at boot time, since protected mode OS's don't use BIOS calls to do disk I/O, they don't use C/H/S values -- and with absolute sector offsets, the geometry is irrelevant. > 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. To the protected mode OS, the C/H/S values and the geometry, whatever it is, is only a means of locating the disklabel so it can locate the slices on its partition using absolute sector offsets. > 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. I no longer personally have any WD1007's, but I'd like to see this problem permanently solved. I'm sure the person who owns the driver and the person who owns the slice code probably feel the same way. If you want to continue to work on loading the ESDI, let me know, and I'll give whatever assistance I can. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9505011716.AA05410>