From owner-freebsd-i386@FreeBSD.ORG Sun Jan 31 01:40:08 2010 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1E71106568B for ; Sun, 31 Jan 2010 01:40:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7C6B58FC1D for ; Sun, 31 Jan 2010 01:40:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o0V1e8M8046021 for ; Sun, 31 Jan 2010 01:40:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0V1e8P7046020; Sun, 31 Jan 2010 01:40:08 GMT (envelope-from gnats) Resent-Date: Sun, 31 Jan 2010 01:40:08 GMT Resent-Message-Id: <201001310140.o0V1e8P7046020@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, Daisuke Aoyama Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35C2C106566B for ; Sun, 31 Jan 2010 01:35:02 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from moon.peach.ne.jp (unknown [IPv6:2001:380:e06:127::53]) by mx1.freebsd.org (Postfix) with ESMTP id C75A58FC0A for ; Sun, 31 Jan 2010 01:35:01 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id 4E4AD78C4B for ; Sun, 31 Jan 2010 10:34:51 +0900 (JST) Received: from hera.peach.ne.jp.private (unknown [192.168.2.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTP id 097CE78C3B for ; Sun, 31 Jan 2010 10:34:50 +0900 (JST) Received: from hera.peach.ne.jp.private (localhost [127.0.0.1]) by hera.peach.ne.jp.private (8.14.3/8.14.3) with ESMTP id o0V1YZG4041031 for ; Sun, 31 Jan 2010 10:34:35 +0900 (JST) (envelope-from aoyama@peach.ne.jp) Received: (from aoyama@localhost) by hera.peach.ne.jp.private (8.14.3/8.14.3/Submit) id o0V1YZDI041030; Sun, 31 Jan 2010 10:34:35 +0900 (JST) (envelope-from aoyama) Message-Id: <201001310134.o0V1YZDI041030@hera.peach.ne.jp.private> Date: Sun, 31 Jan 2010 10:34:35 +0900 (JST) From: Daisuke Aoyama To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: i386/143389: fdisk(8) cannot handle above 1TB under i386 system. X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daisuke Aoyama List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2010 01:40:08 -0000 >Number: 143389 >Category: i386 >Synopsis: fdisk(8) cannot handle above 1TB under i386 system. >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-i386 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Jan 31 01:40:08 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Daisuke Aoyama >Release: FreeBSD 7.1-RELEASE-p10 i386 >Organization: >Environment: System: FreeBSD hera.peach.ne.jp.private 7.1-RELEASE-p10 FreeBSD 7.1-RELEASE-p10 #0: Wed Jan 13 13:18:46 JST 2010 aoyama@hera.peach.ne.jp.private:/usr/src/sys/i386/compile/ISCSI i386 >Description: I first noticed at the post of FreeNAS forum below. http://sourceforge.net/apps/phpbb/freenas/viewtopic.php?f=78&t=5558&start=0 The reason is /sbin/fdisk reads config value by strtol(3) as signed long which is 32 bits on i386. At least, this bug still exists in HEAD. structure definition: >How-To-Repeat: /sbin/fdisk -f on 2TB disk. >Fix: use unsigned long/int or more wide type. (strtoul, etc) >Release-Note: >Audit-Trail: >Unformatted: >>typedef struct cmd { >> char cmd; >> int n_args; >> struct arg { >> char argtype; >> int arg_val; //signed int (32bit) >> } args[MAX_ARGS]; >>} CMD; in function parse_config_line(): >> command->args[command->n_args].arg_val = strtol(cp, &end, 0); // return as signed long strtol(3) is overflow if the value > LONG_MAX(0x7fffffffL on i386). As a result, the partition have wrong size and boundary. Once wrong partition is created, writing to it will cause data loss of next/previous partition. I tested following config on 2TB disk. g c261083 h255 s63 p 1 165 1 2097152 p 2 165 2097154 4175429632 p 3 165 4177526787 16777216 p 4 0 0 0 a 1 Please see above the link for more detail. I am not checking other utilities.