>
> 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.