Bug 115406 - [patch] gpt(8) GPT MBR hangs award BIOS on boot
Summary: [patch] gpt(8) GPT MBR hangs award BIOS on boot
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 6.2-STABLE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-08-10 23:30 UTC by Kent Hauser
Modified: 2010-01-02 00:49 UTC (History)
0 users

See Also:


Attachments
file.diff (1.03 KB, patch)
2007-08-10 23:30 UTC, Kent Hauser
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kent Hauser 2007-08-10 23:30:01 UTC
When a disk is configured for GPT, a machine with AWARD BIOS hangs in
boot. Disk must be detached before BIOS will respond. Can not boot from
CD with disk attached. Machine locked up good.

The solution is to patch the "compatiblity" MBR generated by GPT. Since
the MBR is only a indicator to non-gpt aware systems that the disk is in
use, it probably makes sense to generate an MBR entry which is "standard"
in every way except filesystem type.

Note: my award bios hangs if if the "head" field in the MBR is set to
255. Obviously a bug in BIOS, but also head=255 is never used in MBR
applications.

The following patch set start & end cyl/head/sector to more standard values:

How-To-Repeat: On a system with AWARD BIOS (eg eMACHINES T3410)

dd if=/dev/zero of=/dev/ad1 copy=100
gpt create -f /dev/ad1
reboot

to recover system:
remove disk drive power
boot system, pausing boot loader
reattach disk drive power
continue boot
fdisk -I /dev/ad1
(and hope you don't fry the drive).
Comment 1 Jeff Kletsky 2009-07-09 19:55:01 UTC
Apparently still present in 7.2 -- *may* be the cause of BIOS 
"destruction" on Intel D945GCLF2 boards.

 From /usr/src/sys/geom/part/g_part_gpt.c

        le16enc(table->mbr + DOSMAGICOFFSET, DOSMAGIC);
        table->mbr[DOSPARTOFF + 1] = 0xff;              /* shd */
        table->mbr[DOSPARTOFF + 2] = 0xff;              /* ssect */
        table->mbr[DOSPARTOFF + 3] = 0xff;              /* scyl */
        table->mbr[DOSPARTOFF + 4] = 0xee;              /* typ */
        table->mbr[DOSPARTOFF + 5] = 0xff;              /* ehd */
        table->mbr[DOSPARTOFF + 6] = 0xff;              /* esect */
        table->mbr[DOSPARTOFF + 7] = 0xff;              /* ecyl */
        le32enc(table->mbr + DOSPARTOFF + 8, 1);        /* start */
        le32enc(table->mbr + DOSPARTOFF + 12, MIN(last, 0xffffffffLL));
Comment 2 Jeff Kletsky 2009-07-09 21:44:44 UTC
Based on the Intel Extensible Firmware Interface Specification, v 1.10,
the values present appear to be correct for current drives (anything 
that exceeds the 500 MB CHS limit).
It would seem that the issue is compatibility of the BIOS with the Intel 
spec (assuming that it is the definitive source), not the MBR

On all GUID Partition Table disks a Protective MBR (PMBR) in the first 
LBA of the disk precedes
the GUID Partition Table Header to maintain compatibility with existing 
tools that do not
understand GPT partition structures. The Protective MBR has the same 
format as a legacy MBR,
contains one partition entry of OS type 0xEE and reserves the entire 
space used on the disk by the
GPT partitions, including all headers. The Protective MBR that precedes 
a GUID Partition Table
Header is shown in Table 11-7. If the GPT partition is larger than a 
partition that can be
represented by a legacy MBR, values of all Fs must be used to signify 
that all space that can be
possibly reserved by the MBR is being reserved.

Source:
http://www.intel.com/technology/efi/efiagree.htm
http://download.intel.com/technology/efi/docs/EFI_110.zip -- Page 11-14 
(374/1084)

This notwithstanding, http://www.freebsd.org/cgi/query-pr.cgi?pr=133493 
may still be part of the problem for the OP's systems.
Comment 3 Jeff Kletsky 2009-07-09 22:03:11 UTC
This needs another set of eyes on it.

Re-reading the Intel spec in Table 11-7

Set to match the Starting LBA of the EFI Partition
structure. Must be set to 0xFFFFFF if it is not possible
to represent the starting LBA.

suggests that the *starting* CHS should be the beginning of the disk,
for a PMBR that protects the entire disk, as the OP indicates in the patch.
Comment 4 Marcel Moolenaar freebsd_committer freebsd_triage 2009-08-17 17:15:46 UTC
State Changed
From-To: open->patched

Fix committed to head.
Comment 5 dfilter service freebsd_committer freebsd_triage 2009-08-17 17:16:59 UTC
Author: marcel
Date: Mon Aug 17 16:16:46 2009
New Revision: 196333
URL: http://svn.freebsd.org/changeset/base/196333

Log:
  The start of the EFI GPT partition in the PMBR can always be represented
  by CHS addressing. Don't define these fields as 0xff, but rather define
  them correctly. This prevents boot problems on PCs where GPT is being
  used.
  
  PR:		115406
  Submitted by:	Kent Hauser <kent@khauser.net>
  Approved by:	re (kib)

Modified:
  head/sys/geom/part/g_part_gpt.c

Modified: head/sys/geom/part/g_part_gpt.c
==============================================================================
--- head/sys/geom/part/g_part_gpt.c	Mon Aug 17 16:12:28 2009	(r196332)
+++ head/sys/geom/part/g_part_gpt.c	Mon Aug 17 16:16:46 2009	(r196333)
@@ -409,9 +409,9 @@ g_part_gpt_create(struct g_part_table *b
 	last = (pp->mediasize / pp->sectorsize) - 1;
 
 	le16enc(table->mbr + DOSMAGICOFFSET, DOSMAGIC);
-	table->mbr[DOSPARTOFF + 1] = 0xff;		/* shd */
-	table->mbr[DOSPARTOFF + 2] = 0xff;		/* ssect */
-	table->mbr[DOSPARTOFF + 3] = 0xff;		/* scyl */
+	table->mbr[DOSPARTOFF + 1] = 0x01;		/* shd */
+	table->mbr[DOSPARTOFF + 2] = 0x01;		/* ssect */
+	table->mbr[DOSPARTOFF + 3] = 0x00;		/* scyl */
 	table->mbr[DOSPARTOFF + 4] = 0xee;		/* typ */
 	table->mbr[DOSPARTOFF + 5] = 0xff;		/* ehd */
 	table->mbr[DOSPARTOFF + 6] = 0xff;		/* esect */
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
Comment 6 dfilter service freebsd_committer freebsd_triage 2009-08-17 17:25:09 UTC
Author: marcel
Date: Mon Aug 17 16:24:50 2009
New Revision: 196335
URL: http://svn.freebsd.org/changeset/base/196335

Log:
  MFC rev 196333:
  The start of the EFI GPT partition in the PMBR can always be represented
  by CHS addressing. Don't define these fields as 0xff, but rather define
  them correctly. This prevents boot problems on PCs where GPT is being
  used.
  
  PR:             115406
  Submitted by:   Kent Hauser <kent@khauser.net>
  Approved by:    re (kib)

Modified:
  stable/8/sys/   (props changed)
  stable/8/sys/amd64/include/xen/   (props changed)
  stable/8/sys/cddl/contrib/opensolaris/   (props changed)
  stable/8/sys/contrib/dev/acpica/   (props changed)
  stable/8/sys/contrib/pf/   (props changed)
  stable/8/sys/dev/mfi/   (props changed)
  stable/8/sys/dev/xen/xenpci/   (props changed)
  stable/8/sys/geom/part/g_part_gpt.c

Modified: stable/8/sys/geom/part/g_part_gpt.c
==============================================================================
--- stable/8/sys/geom/part/g_part_gpt.c	Mon Aug 17 16:17:21 2009	(r196334)
+++ stable/8/sys/geom/part/g_part_gpt.c	Mon Aug 17 16:24:50 2009	(r196335)
@@ -409,9 +409,9 @@ g_part_gpt_create(struct g_part_table *b
 	last = (pp->mediasize / pp->sectorsize) - 1;
 
 	le16enc(table->mbr + DOSMAGICOFFSET, DOSMAGIC);
-	table->mbr[DOSPARTOFF + 1] = 0xff;		/* shd */
-	table->mbr[DOSPARTOFF + 2] = 0xff;		/* ssect */
-	table->mbr[DOSPARTOFF + 3] = 0xff;		/* scyl */
+	table->mbr[DOSPARTOFF + 1] = 0x01;		/* shd */
+	table->mbr[DOSPARTOFF + 2] = 0x01;		/* ssect */
+	table->mbr[DOSPARTOFF + 3] = 0x00;		/* scyl */
 	table->mbr[DOSPARTOFF + 4] = 0xee;		/* typ */
 	table->mbr[DOSPARTOFF + 5] = 0xff;		/* ehd */
 	table->mbr[DOSPARTOFF + 6] = 0xff;		/* esect */
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
Comment 7 Marcel Moolenaar freebsd_committer freebsd_triage 2010-01-02 00:47:31 UTC
State Changed
From-To: patched->closed

The problem has been addressed in gart(8) and gpt(8) is obsolete, so 
no follow-up is to be expected at this time. Close the PR to reflect 
this.