From owner-freebsd-i386@FreeBSD.ORG Wed Apr 26 10:50:12 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8887F16A402 for ; Wed, 26 Apr 2006 10:50:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D15A343D48 for ; Wed, 26 Apr 2006 10:50:11 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k3QAoBmg041768 for ; Wed, 26 Apr 2006 10:50:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k3QAoBMq041766; Wed, 26 Apr 2006 10:50:11 GMT (envelope-from gnats) Resent-Date: Wed, 26 Apr 2006 10:50:11 GMT Resent-Message-Id: <200604261050.k3QAoBMq041766@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-i386@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Leo Shum Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 88CA616A409 for ; Wed, 26 Apr 2006 10:49:44 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46CB143D6D for ; Wed, 26 Apr 2006 10:49:44 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k3QAnikI069833 for ; Wed, 26 Apr 2006 10:49:44 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id k3QAnh6m069832; Wed, 26 Apr 2006 10:49:43 GMT (envelope-from nobody) Message-Id: <200604261049.k3QAnh6m069832@www.freebsd.org> Date: Wed, 26 Apr 2006 10:49:43 GMT From: Leo Shum To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: i386/96357: FreeBSD cannot recognize all the logical partitions X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2006 10:50:12 -0000 >Number: 96357 >Category: i386 >Synopsis: FreeBSD cannot recognize all the logical partitions >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-i386 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Apr 26 10:50:11 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Leo Shum >Release: FreeBSD 6.0 >Organization: >Environment: FreeBSD 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Thu Nov 3 09:36:13 UTC 2005 root@x64.samsco.home:/usr/obj/usr/src/sys/GENERIC i386 >Description: The interpretation of dp_start in an extended partition is incorrect. According to wikipedia http://en.wikipedia.org/wiki/Extended_Master_Boot_Record, the 2nd entry of the EMBR, if not empty, points to the next EMBR in the chain. The starting sector is relative address of the next EMBR within the extended partition. However, in boot/i386/libi386/biosdisk.c, in function bd_checkextended, dp_start of the next chained partition is added to the start address of the current logical partition, but not the address of the extended partition. (line 677 and 687) The end result is that when iterating through the logical paritions (slices), the function fails to recognize other slices past the 7th or 8th, and bombs with "no magic in extended table" because by that time the start address of the slice is all messed up. >How-To-Repeat: On a disk, create a few logical paritions (>10). Invoke /boot/loader and check for available slices. With enough debugging turned on, /boot/loader will complain "no magic in extended table" when looking at slicenum 7. >Fix: I have a brute force hack to make dp_start calculate the correct address, then /boot/loader can find all available slices. But at the boot prompt, the slice start and end addresses as shown by lsdev -v are incorrect. Looks like there are other parts of the code that calculate the values incorrectly as well, not just bd_checkextended >Release-Note: >Audit-Trail: >Unformatted: