Date: Fri, 18 Feb 2000 12:51:32 +0100 (CET) From: Andre Albsmeier <andre.albsmeier@mchp.siemens.de> To: FreeBSD-gnats-submit@freebsd.org Subject: kern/16803: Newer Adaptec controllers make system hang with slices ending 1023/255/63 Message-ID: <200002181151.MAA56021@internal>
next in thread | raw e-mail | index | archive | help
>Number: 16803
>Category: kern
>Synopsis: Newer Adaptec controllers make system hang with slices ending 1023/255/63
>Confidential: no
>Severity: critical
>Priority: medium
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: change-request
>Submitter-Id: current-users
>Arrival-Date: Fri Feb 18 04:00:01 PST 2000
>Closed-Date:
>Last-Modified:
>Originator: Andre Albsmeier
>Release: FreeBSD 3.4-STABLE i386
>Organization:
>Environment:
All FreeBSD systems using an fdisk slice entry that end's with
cyl 1023/ sector 63/ head 255 in order to shut up error messages
during verbose booting.
>Description:
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.
>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.
>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:
--- diskslice_machdep.c.ORI Fri Feb 18 12:35:21 2000
+++ diskslice_machdep.c Fri Feb 18 12:38:27 2000
@@ -121,13 +121,13 @@
+ mbr_offset;
esector1 = ssector1 + dp->dp_size - 1;
- /* Allow certain bogus C/H/S values for esector, as above. */
+ /* Allow certain bogus C/H/S values for esector, as above and 1023/254/63. */
if (esector < esector1
&& ((chs_esect == nsectors && dp->dp_ehd == ntracks - 1
&& chs_ecyl == 1023)
|| (secpercyl != 0
&& (esector1 - esector) % (1024 * secpercyl) == 0))
- || (dp->dp_ecyl == 255 && dp->dp_ehd == 255
+ || (dp->dp_ecyl == 255 && dp->dp_ehd | 1 == 255
&& dp->dp_esect == 255)) {
TRACE(("%s: C/H/S end %d/%d/%d, end %lu: allow\n",
sname, chs_ecyl, dp->dp_ehd, chs_esect, esector1));
>Release-Note:
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200002181151.MAA56021>