From owner-freebsd-bugs@FreeBSD.ORG Mon Aug 8 22:17:44 2005 Return-Path: X-Original-To: freebsd-bugs@FreeBSD.org Delivered-To: freebsd-bugs@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4DF616A41F; Mon, 8 Aug 2005 22:17:44 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1843743D45; Mon, 8 Aug 2005 22:17:43 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j78MHgsP026174; Tue, 9 Aug 2005 08:17:42 +1000 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j78MHeQ8023839; Tue, 9 Aug 2005 08:17:41 +1000 Date: Tue, 9 Aug 2005 08:24:27 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Francis Gendreau In-Reply-To: <200507152302.j6FN2iGr059633@www.freebsd.org> Message-ID: <20050809050637.N644@epsplex.bde.org> References: <200507152302.j6FN2iGr059633@www.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-bugs@FreeBSD.org, freebsd-gnats-submit@FreeBSD.org Subject: Re: kern/83529: partition table corruption using wdc/wd driver X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2005 22:17:44 -0000 On Fri, 15 Jul 2005, Francis Gendreau wrote: > I am building a system with two slice on a single drive, since a single slice does not provides me enough partitions for my filesystem design. In order to optimise the operating system, I've compiled the wdc and wd driver, from which I access my partition. Please use lines shorter than 256 characters. > Using the 'ad' driver, I was able to access every partition created of every slices of every drives. The problem here reside in the two commented partitions of the wd0s2 slice. > > N.B. I uses the STABLE release onyl because the Robert Watson's ACL patch is included with it. I do ignore if the 4.11-RELEASE also have the problem. You shouldn't use the wdc/wd driver, since it is not maintained and the ata/ad driver works well enough for most hardware. However, the wdc/wd driver still seems to work well enough for disks smaller than 137GB (1GB = 10^9 bytes). On my test system, there were similar but not identical problems accessing partitions until I configured the wd driver to use the "LBA addressing" flag 0x1000 (see wd(4)). Try using this flag. It shouldn't be needed, but is needed for all disks larger than 33GB due to driver bugs. Some disks have a hard limit of 8GB, and the driver gets the test for this mostly wrong and ends up intentionally breaking CHS above 33GB where it might work, without intentionally breaking CHS between 8-33GB where it might not work (the intentional breakage is just to truncate disks to a limit above which the driver fears that they might not work). On my test system (a not very old one with an nForce2 motherboard and a 120GB drive), the problems were that a slice which crossed the 33GB boundary became partly inaccessible and a slice beyond the 33GB boundary became completely inaccessible. The problem is show by boot messages: %%% Aug 9 04:55:12 epsplex kernel: wdc0 at port 0x1f0-0x1f7 irq 14 flags 0xa0ffa0ff on isa0 Aug 9 04:55:12 epsplex kernel: wd0: cannot handle 234441648 total sectors; truncating to 66060288 ... Aug 9 04:55:12 epsplex kernel: wd0s2: slice extends beyond end of disk: truncating from 57512700 to 49979223 sectors Aug 9 04:55:12 epsplex kernel: wd0s3: slice starts beyond end of the disk: rejecting it %%% Your second slice lies across the 33GB boundary like my first slice. Your disklabel -r output shows that the kernel didn't fix up the partition offsets within the slice. I can't explain how truncating the partition could cause this. After setting the LBA flag, the old wd driver worked perfectly on my relatively new test system. It even gave the maximum drive transfer rate of 47MB/sec despite it having no support for either nForce2 or UDMA faster than 33MHz. It apparently uses generic DMA and the BIOS sets this up right for UDMA100. Bruce