"George Georgalis" <george@galis.org> writes:

> On Mon, Mar 05, 2007 at 01:56:02PM -0500, George Georgalis wrote:
>>I seem to have come across a quirk for Maxtor SATA drives:
>>
>>wd1 at atabus3 drive 0: <MAXTOR STM3200820AS>
>>wd1: drive supports 16-sector PIO transfers, LBA48 addressing
>>wd1: 186 GB, 387621 cyl, 16 head, 63 sec, 512 bytes/sect x 390721968 sectors
>>wd1: 32-bit data port
>>wd1: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
>>wd1(viaide1:1:0): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133) (using DMA)
>>
>>    dd if=/dev/rwd1a of=/dev/null skip=268435392 count=1
>>
>>with kernel messages:
>>
>>wd1a: error reading fsbn 268435392 of 268435392-268435519 (wd1 bn 268435455; cn 266305 tn 0 sn 15), retrying
>>wd1: (id not found)
>
> I get the same (single) bad block on two new drives.
> that's fffffc0 and I don't see an existing quirk
> table for Maxtor SATA drives.
>
> if someone plans to make one and wants me to test, let me know
> asap, since I'll be returning the drives shortly.

Note that a range was tried, and that the failing bn was 268435455.
So, this looks like the same 0xfffffff problem as Seagate.

Try bs=1b or bs=512 so that with any luck dd reads only 1 block rather
than 64k.  I don't understand why it isn't following the documented
default of 12 bytes; I wonder if it's "optimizing" the reads.

-- 
    Greg Troxel <gdt@ir.bbn.com>