Bug 16803

During boot, /sys/i386/isa/diskslice_machdep.c tries to verify in
check_part() that the slice entries in the partition table are somehow
consistent.

If booting verbose an error message is generated if this isn't true. To
provide a possibility to shut up this message, the 1023/255/63 geometry
is always allowed.

If you have entered this 1023/255/63 geometry for the end of a slice,
newer Adaptec controller (e.g. the 2940UW with BIOS 2.20 or the 2940U2W)
will make the system freeze when it should start to load _any_ operating
system.

This is _not_ a FreeBSD problem. It is enough to have any harddisk
containing a slice ending with the above geometry attached to the bus
and have the 'Include in BIOS Scan' entry set to yes in the Adaptec
BIOS to make the system hang.

I could not observe the problem on a 2940UW running BIOS 1.34.3
or on an ASUS P2B-LS with a SCSI BIOS 2.11.

Fix: I don't know why this happens. I assume, that the various boot
codes try to read the disk where slices are ending. For the
faked slice entry, they pass 1023/255/63 to the controller and
make it hang now. Interestingly 1023/254/63 works. This maybe
due to the fact that an ending head entry of 255 means that 256
heads are used. The Adaptec controllers are normally translating
the drives to a 255/63 geometry which would require a 254/63 entry
for the end of the slice. (Who invented this f*cked up spec?!?)

Maybe we should accept the geometry 1023/254/63 as well for
the end of slice entry in /sys/i386/isa/diskslice_machdep.c?
This could be accomplished by this patch:
How-To-Repeat: 
Take a disk and make a slice ending in 1023/255/63. Attach it to
a controller as described above and set the 'Include in BIOS Scan'
entry to yes for this drive. Boot any OS.