Date: Sun, 30 Apr 95 18:21:05 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: <9505010021.AA04511@cs.weber.edu> In-Reply-To: <Pine.LNX.3.91.950430100745.110B-100000@saigon.async.com> from "Bao Chau Ha" at Apr 30, 95 10:33:53 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Not really, Linux is running happily on the second drive. I > don't think I need the OS/2-style real-mode INT-13 driver. > The WD1007V is running under the OS/2 ST506 driver. OS/2 > does know the real geometries, but it uses the fictitous > geometries. > > Anyway, I think we may have miscommunicated somewhere. What > I am complaining is that the disk driver did not use the BIOS > geometries, which is used by DOS, Linux, and OS/2 sharing the > disk system. I may be naive, but all it is needed is a BIOS > call to get the fictitous drive geometries during the boot up > process prior to switching to the protected mode. The WD1007V > can then be treated just like a ST506/ST412 interface. All of > the geometry translation and spare sector mapping are done by > the controller firmware. I think the problem is that the disk > device driver is too smart for its own good, since the WD1007V > is a hybrid between the old MFM/RLL interface and the new IDE. > The WD1007V predated the current IDE standard, I think. I have installed FreeBSD and NetBSD on several WD1007's. 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. The practical problem will still be there: the code can't be written to universally recognize these devices unless you make the boot time something unreasonable and regcognize the drives via a checksum/CRC of some early sectors on the drive that will be the same translated and untranslated. No, Linux doesn't do this either. You just got lucky. Linux doesn't give up as easily, and that just means you are in terrible danger of losing random sectors from Linux as you hit bas blocks running DOS. > 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. Linux and BSD and any other protected mode OS that doesn't use the BIOS uses sector addressing for the drive. That is, they use the first sector on the drive, the 535th sector on the drive, or whatever... the sector is a linear offset from the start of the drive. When a controller uses BIOS to pretend the drive is perfect, there's two ways to do it. The first is to pile all the replacement sectors at the end of the drive. The second is to take every nth sector from the start of the drive and "reserve" it as a "spare". Obviously, when you are not using BIOS based I/O, unless this is done in hardware, the BIOS geometry will include gaps that are hidden from the BIOS using OS. These gaps will be painfully visible in a protected mode OS not using the BIOS. Basically, what this means is that the sector umber you get by adding up the C/H/S values and multiplying them by the real or fictitious or whatever geometry that was used to write them will result in a sector offset that is at the wrong place in protected mode. In fact, the protected mode geometry will be off by however many "reserve"sectors were hidden between the start of the disk and the offset you arrive at. So sector 0 is o, sector 1 is 1, and sector 49 is actually sector 52, for instance. The further into the disk you go, the worse it is. This is what is called "non-linear" translation. This is what the WD1007 uses to get "perfect media". Generally, if you have your controller set this way, you can only use a whole disk for a protected mode OS -- or the protected mode OS must start at the front of the disk before there are any "spare" sectors so that the protected mode code can find the disk. No what happens if you use a protected mode OS this way, and you put a BIOS using OS on the same disk? Well, the first bad sector that you hit in the BIOS area of the disk is going to be remapped to one of the "spare sectors" on the disk. This could easily be some important binary on your protected mode OS's disk area, although it probably won't be because of it being statistically unlikely that it will get a hit. Of course, some day it will, and then you'll be screwed. My personally suggestion would be to turn off "perfect media" mode on the WD1007 after backing up the data you want to keep and then reinstalling the OS's on the drive. If if you stay using Linux, be aware that Linux itself is just "cheating" to find the start of it's partition, and you are going to be screwed anyway sooner or later because of this. > I do have a DOS partition on the first drive. I tried a lot of > other things and make the wd1 error about changing d partition > size ... going away. I still have the same panic error about > cannot mount the root partition, right after the message about > npx0: INT 16 ... I still think it is an incompatible problem, > but not knowing how to deal with it. The WD1007 is listed as > supported in the FAQ. The controller *is* supported. The problem is in the use BIOS code to present "perfect media" in a way that can't be predicted by a protected mode OS. Even if the WD1007 algorithm was hard coded in BSD ED driver, it will not save people who have other controllers that have use non-linear reanslation, or people with WD1007's that have the mode turned off. I don't expect this to happen in the next release because of this. Regards, 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?9505010021.AA04511>