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

Bruce Evans bde at
Mon Aug 8 22:17:44 GMT 2005

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.


More information about the freebsd-bugs mailing list