kern/83529: partition table corruption using wdc/wd driver

[Bruce Evans]

The following reply was made to PR kern/83529; it has been noted by GNATS.

From: Bruce Evans <bde at zeta.org.au>
To: Francis Gendreau <tech at makwa.net>
Cc: freebsd-gnats-submit at FreeBSD.org, freebsd-bugs at FreeBSD.org
Subject: Re: kern/83529: partition table corruption using wdc/wd driver
Date: Tue, 9 Aug 2005 08:24:27 +1000 (EST)

 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