From nobody@FreeBSD.org  Fri Aug 10 22:24:42 2007
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 3574E16A418
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 10 Aug 2007 22:24:42 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 0B6D313C481
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 10 Aug 2007 22:24:42 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.1/8.14.1) with ESMTP id l7AMOfXX009708
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 10 Aug 2007 22:24:41 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.1/8.14.1/Submit) id l7AMOffq009707;
	Fri, 10 Aug 2007 22:24:41 GMT
	(envelope-from nobody)
Message-Id: <200708102224.l7AMOffq009707@www.freebsd.org>
Date: Fri, 10 Aug 2007 22:24:41 GMT
From: Kent Hauser <kent@khauser.net>
To: freebsd-gnats-submit@FreeBSD.org
Subject: GPT MBR hangs award BIOS on boot
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         115406
>Category:       bin
>Synopsis:       [patch] gpt(8) GPT MBR hangs award BIOS on boot
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Aug 10 22:30:01 GMT 2007
>Closed-Date:    Sat Jan 02 00:49:43 UTC 2010
>Last-Modified:  Sat Jan 02 00:49:43 UTC 2010
>Originator:     Kent Hauser
>Release:        6.2-STABLE
>Organization:
>Environment:
FreeBSD hnl.tfd.com 6.2-STABLE FreeBSD 6.2-STABLE #1: Sat Aug  4 22:50:46 HST 2007     kent@hnl.tfd.com:/usr/obj/usr/src/sys/GENERIC  i386

>Description:
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).


>Fix:
Index: create.c
===================================================================
RCS file: /home/ncvs/src/sbin/gpt/create.c,v
retrieving revision 1.10.2.1
diff -u -r1.10.2.1 create.c
--- create.c    6 Sep 2005 23:59:01 -0000       1.10.2.1
+++ create.c    10 Aug 2007 22:08:14 -0000
@@ -93,11 +93,11 @@
                mbr = gpt_read(fd, 0LL, 1);
                bzero(mbr, sizeof(*mbr));
                mbr->mbr_sig = htole16(MBR_SIG);
-               mbr->mbr_part[0].part_shd = 0xff;
-               mbr->mbr_part[0].part_ssect = 0xff;
-               mbr->mbr_part[0].part_scyl = 0xff;
+               mbr->mbr_part[0].part_shd = 1;
+               mbr->mbr_part[0].part_ssect = 1;
+               mbr->mbr_part[0].part_scyl = 0;
                mbr->mbr_part[0].part_typ = 0xee;
-               mbr->mbr_part[0].part_ehd = 0xff;
+               mbr->mbr_part[0].part_ehd = 0xfe;
                mbr->mbr_part[0].part_esect = 0xff;
                mbr->mbr_part[0].part_ecyl = 0xff;
                mbr->mbr_part[0].part_start_lo = htole16(1);


>Release-Note:
>Audit-Trail:

From: Jeff Kletsky <jeff+freebsd@wagsky.com>
To: bug-followup@FreeBSD.org, kent@khauser.net
Cc:  
Subject: Re: bin/115406: [patch] gpt(8) GPT MBR hangs award BIOS on boot
Date: Thu, 09 Jul 2009 11:55:01 -0700

 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));
 

From: Jeff Kletsky <jeff+freebsd@wagsky.com>
To: bug-followup@FreeBSD.org, kent@khauser.net
Cc:  
Subject: Re: bin/115406: [patch] gpt(8) GPT MBR hangs award BIOS on boot
Date: Thu, 09 Jul 2009 13:44:44 -0700

 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.

From: Jeff Kletsky <jeff+freebsd@wagsky.com>
To: bug-followup@FreeBSD.org, kent@khauser.net
Cc:  
Subject: Re: bin/115406: [patch] gpt(8) GPT MBR hangs award BIOS on boot
Date: Thu, 09 Jul 2009 14:03:11 -0700

 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.
State-Changed-From-To: open->patched 
State-Changed-By: marcel 
State-Changed-When: Mon Aug 17 16:15:46 UTC 2009 
State-Changed-Why:  
Fix committed to head. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=115406 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: bin/115406: commit references a PR
Date: Mon, 17 Aug 2009 16:16:59 +0000 (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"
 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: bin/115406: commit references a PR
Date: Mon, 17 Aug 2009 16:25:09 +0000 (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"
 
State-Changed-From-To: patched->closed 
State-Changed-By: marcel 
State-Changed-When: Sat Jan 2 00:47:31 UTC 2010 
State-Changed-Why:  
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. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=115406 
>Unformatted:
