Messages in this thread |  | | Date | Thu, 13 Jun 1996 14:51:01 -0400 (EDT) | From | Tom Zerucha <> | Subject | Re: My SCSI HD has 34 heads, not 255... |
| |
On Sun, 2 Jun 1996, Leonard N. Zubkoff wrote:
> > It's unfortunate that you installed this drive with the CONFIG_SCSI_AUTO_BIOSP > option turned on. It was a badly broken idea. Most SCSI controllers implement > only a small number of cylinder/head/sector translations, and using one not > supported by the controller and driver will lead to a disk that can never be > booted by the BIOS. If the driver provides a function to provide the > translation, then the driver must be consulted not overridden as the old code > did. >
The problem (and the reason I created the AUTO_BIOSP patch) is that many low-level drivers don't implement the bios_param function correctly. For example, my laptop docking station has an aha152x chip BUT NO BIOS. The default behavior of the adaptec drivers is to remap >1Gb disks to the extended partitioning scheme if there is no bios present. The linux aha152x driver didn't follow this earlier. I would get the same fdisk confusion messages if I didn't use the AUTO_BIOSP patch.
I usually do the FDISK under DOS, and if that doesn't agree with whatever the low-level driver in the kernel implements, you get the messages from linux fdisk which gets totally confused. Has anyone bothered to check the current and historical windows, dos, and os/2 drivers for what they think the partition mapping schemes should be?
When I move my hard drive between systems, each SCSI card can implement a totally different partitioning scheme. So I will take a chance of destroying any SCSI disk when I move it across systems, which I have to do since my laptop, and various desktops have different cards. Forget using removable media (e.g. Iomega Jaz drives and large capacity optical) unless you want to take chances.
AUTO_BIOSP solved this by looking at the partition sector or determining it, and it appears scsicam is also a standard. I probably should have made the help text clearer, since it was only intended to be used if fdisk under Linux looked strange after fdisking under DOS/WIN/etc., or if you needed to move disks across systems.
Somewhere it managed to nuke someones disk when they turned it on, so Linus removed it from the kernel. More disks will be nuked if the low-level drivers are ever corrected since they will change the mapping (and the correct mapping is not always determinable from just the size).
If the fdisk was done originally with the DOS/win or bios driver, AUTO_BIOSP would correctly recognize the partitioning, and everyone would be happy. If the original fdisk was done under linux, with AUTO_BIOSP on, it would create a problem, but the same would happen if it was done on a card with a broken bios_param function, of if they ever changed controller cards.
If my idea is badly broken, what do you suggest I do since I have two systems that return the WRONG partition mapping (I used DOS to fdisk) and move the hard drive (an AV with CD writer) across several systems?
You would be correct if two things were true: 1. the low level drivers always provided the correct mapping (I carefully verified Qlogic isa/vlb/pcmcia, and the in2000.c - the aha1542 has problems when you turn the bios off and use a large disk, most others simply copied the default mapping and never verified it). 2. No one ever changed SCSI cards or moved disks across systems.
It would have been nice if the manufacturers of SCSI cards came up with a standard way of mapping partitions, but they didn't. It would have been nice if PCs partitioned using block displacement instead of HCS, but they don't. So some ugly hack is required to get around the problems created by the lack of a standard, and a bad standard.
You don't like my fix. I would like to hear your idea or if anyone else out there has a better one. I still need to move hard drives across systems with different controllers.
For now, I have the AUTO_BIOSP patch in my personal kernel patchfile, so it is still available if someone is interested, since I can't use 2.0.0 as is because it assumes whatever partition mapping scheme the current driver implements.
|  |