maxtor sata quirk

I seem to have come across a quirk for Maxtor SATA drives:

wd0 at atabus2 drive 0: <MAXTOR STM3200820AS>
wd0: drive supports 16-sector PIO transfers, LBA48
addressing
wd0: 186 GB, 387621 cyl, 16 head, 63 sec, 512 bytes/sect x
390721968 sectors
wd0: 32-bit data port
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6
(Ultra/133)
wd0(viaide1:0:0): using PIO mode 4, Ultra-DMA mode 6
(Ultra/133) (using DMA)
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)

the center command below (only) fails on two new drives.

    dd if=/dev/rwd1a of=/dev/null skip=268435391 count=1
    dd if=/dev/rwd1a of=/dev/null skip=268435392 count=1
    dd if=/dev/rwd1a of=/dev/null skip=268435393 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)

In hex that's fffffc0 which is a little different than the
Seagate
LBA 32/48 quirk that comes up now and then. I'm looking for
(hopefully) an existing quirk table that I can add my drive
id to.

If anyone knows where to go from here, please let me know.

not sure about "id not found"

// George


-- 
George Georgalis, systems architect, administrator
<IXOYE><

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.

// George


-- 
George Georgalis, systems architect, administrator
<IXOYE><

"George Georgalis" <georgegalis.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 <gdtir.bbn.com>

On Mon, Mar 05, 2007 at 03:55:25PM -0500, Greg Troxel
wrote:
> >
> > 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.

Is it about time we either:

1) Beat up the disk manufacturers and get the disk firmwares
fixed
or
2) Automatically retry these transfers as LBA48 ones

	David

-- 
David Laight: davidl8s.co.uk

On Mon, Mar 05, 2007 at 03:55:25PM -0500, Greg Troxel
wrote:
>"George Georgalis" <georgegalis.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.

okay, right.

rock# dd if=/dev/rwd1d of=/dev/null skip=268435454 count=1
bs=1b 
1+0 records in
1+0 records out
512 bytes transferred in 0.014 secs (36571 bytes/sec)
rock# dd if=/dev/rwd1d of=/dev/null skip=268435455 count=1
bs=1b 
dd: /dev/rwd1d: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 3.352 secs (0 bytes/sec)
rock# dd if=/dev/rwd1d of=/dev/null skip=268435456 count=1
bs=1b 
1+0 records in
1+0 records out
512 bytes transferred in 0.007 secs (73142 bytes/sec)

wd1d: error reading fsbn 268435455 (wd1 bn 268435455; cn
266305 tn 0 sn 15), retrying
wd1: (id not found)
wd1d: error reading fsbn 268435455 (wd1 bn 268435455; cn
266305 tn 0 sn 15), retrying
wd1: (id not found)
wd1d: error reading fsbn 268435455 (wd1 bn 268435455; cn
266305 tn 0 sn 15), retrying
wd1: (id not found)
wd1d: error reading fsbn 268435455 (wd1 bn 268435455; cn
266305 tn 0 sn 15), retrying
wd1: (id not found)
wd1d: error reading fsbn 268435455 (wd1 bn 268435455; cn
266305 tn 0 sn 15), retrying
wd1: (id not found)
wd1d: error reading fsbn 268435455 (wd1 bn 268435455; cn
266305 tn 0 sn 15)wd1: (id not found)

// George


-- 
George Georgalis, systems architect, administrator
<IXOYE><

On Mon, 5 Mar 2007, David Laight wrote:

> On Mon, Mar 05, 2007 at 03:55:25PM -0500, Greg Troxel
wrote:
>>>
>>> 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.
>
> Is it about time we either:
>
> 1) Beat up the disk manufacturers and get the disk
firmwares fixed
> or
> 2) Automatically retry these transfers as LBA48 ones

 	2), 2), and 2) again. Or better, still, on a drive over
that
 	size default to LBA48 for that sector.

-- 
 		David/absolute       -- www.NetBSD.org: No hype required
--

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:
> 
> wd0 at atabus2 drive 0: <MAXTOR STM3200820AS>
> wd0: drive supports 16-sector PIO transfers, LBA48
addressing
> wd0: 186 GB, 387621 cyl, 16 head, 63 sec, 512
bytes/sect x 390721968 sectors
> wd0: 32-bit data port
> wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA
mode 6 (Ultra/133)
> wd0(viaide1:0:0): using PIO mode 4, Ultra-DMA mode 6
(Ultra/133) (using DMA)
> 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)
> 
> the center command below (only) fails on two new
drives.
> 
>     dd if=/dev/rwd1a of=/dev/null skip=268435391
count=1
>     dd if=/dev/rwd1a of=/dev/null skip=268435392
count=1
>     dd if=/dev/rwd1a of=/dev/null skip=268435393
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)
> 
> In hex that's fffffc0 which is a little different than
the Seagate
> LBA 32/48 quirk that comes up now and then. I'm looking
for
> (hopefully) an existing quirk table that I can add my
drive id to.
> 
> If anyone knows where to go from here, please let me
know.

Could you try the attached patch against current ? This
should fix the
issue for the most common cases, and hopefully it won't
break any working
setups.

-- 
Manuel Bouyer <bouyerantioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la
difference
--

On Wed, Mar 07, 2007 at 10:37:54PM +0100, Manuel Bouyer
wrote:
>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:
>> 
>> wd0 at atabus2 drive 0: <MAXTOR
STM3200820AS>
>> wd0: drive supports 16-sector PIO transfers, LBA48
addressing
>> wd0: 186 GB, 387621 cyl, 16 head, 63 sec, 512
bytes/sect x 390721968 sectors
>> wd0: 32-bit data port
>> wd0: drive supports PIO mode 4, DMA mode 2,
Ultra-DMA mode 6 (Ultra/133)
>> wd0(viaide1:0:0): using PIO mode 4, Ultra-DMA mode
6 (Ultra/133) (using DMA)
>> 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)
>> 
>> the center command below (only) fails on two new
drives.
>> 
>>     dd if=/dev/rwd1a of=/dev/null skip=268435391
count=1
>>     dd if=/dev/rwd1a of=/dev/null skip=268435392
count=1
>>     dd if=/dev/rwd1a of=/dev/null skip=268435393
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)
>> 
>> In hex that's fffffc0 which is a little different
than the Seagate
>> LBA 32/48 quirk that comes up now and then. I'm
looking for
>> (hopefully) an existing quirk table that I can add
my drive id to.
>> 
>> If anyone knows where to go from here, please let
me know.
>
>Could you try the attached patch against current ? This
should fix the
>issue for the most common cases, and hopefully it won't
break any working
>setups.

thanks, nice patch.

ATM the drives are partitioned < LBA48_THRESHOLD and
committed
to an important operation. We've already decided to return
them
but I'll try to test your patch when they have finished
their
moment of fame.

// George


-- 
George Georgalis, systems architect, administrator
<IXOYE><

On Wed, Mar 07, 2007 at 10:37:54PM +0100, Manuel Bouyer
wrote:
> 
> Could you try the attached patch against current ? This
should fix the
> issue for the most common cases, and hopefully it won't
break any working
> setups.
> 
> Manuel Bouyer <bouyerantioche.eu.org>
>      NetBSD: 26 ans d'experience feront toujours la
difference

> -	if (wd->sc_flags & WDF_LBA48 &&
> -	    (wd->sc_wdc_bio.blkno > LBA48_THRESHOLD ||
> -	    (wd->sc_quirks & WD_QUIRK_FORCE_LBA48) !=
0))
> +	if (wd->sc_flags & WDF_LBA48)
>  		wd->sc_wdc_bio.flags |= ATA_LBA48;
>  	if (wd->sc_flags & WDF_LBA)
>  		wd->sc_wdc_bio.flags |= ATA_LBA;

Doesn't that have the effect of always trying to do LBA48
transfers
on disks that appear to support LBA48 ?

There are two problems:
1) The controller may not support LBA48 (even though the
disk does)
2) There is a performance penalty for using LBA48
transfers.
IIRC that is why 28 bit transfers are done whenever
possible.

	David

-- 
David Laight: davidl8s.co.uk

On Thu, Mar 08, 2007 at 04:46:41PM +0000, David Laight
wrote:
> On Wed, Mar 07, 2007 at 10:37:54PM +0100, Manuel Bouyer
wrote:
> > 
> > Could you try the attached patch against current ?
This should fix the
> > issue for the most common cases, and hopefully it
won't break any working
> > setups.
> > 
> > Manuel Bouyer <bouyerantioche.eu.org>
> >      NetBSD: 26 ans d'experience feront toujours
la difference
> 
> > -	if (wd->sc_flags & WDF_LBA48 &&
> > -	    (wd->sc_wdc_bio.blkno >
LBA48_THRESHOLD ||
> > -	    (wd->sc_quirks &
WD_QUIRK_FORCE_LBA48) != 0))
> > +	if (wd->sc_flags & WDF_LBA48)
> >  		wd->sc_wdc_bio.flags |= ATA_LBA48;
> >  	if (wd->sc_flags & WDF_LBA)
> >  		wd->sc_wdc_bio.flags |= ATA_LBA;
> 
> Doesn't that have the effect of always trying to do
LBA48 transfers
> on disks that appear to support LBA48 ?

only if they are strictly larger than 128GB.

> 
> There are two problems:
> 1) The controller may not support LBA48 (even though
the disk does)

Agreed. In such a case a workaround is to use the disk's
jumper to clamp dowm
the size to 128GB.

> 2) There is a performance penalty for using LBA48
transfers.
> IIRC that is why 28 bit transfers are done whenever
possible.

Long term I think we want to alway use LBA48 anyway, to have
single transfers
larger than 128k. Right now we're limited to 64k because of
MAXPHYS but this
is something that has to die. The performance penalty of
such small
transfers is much highter than LBA48 ...

-- 
Manuel Bouyer, LIP6, Universite Paris VI.          
Manuel.Bouyerlip6.fr
     NetBSD: 26 ans d'experience feront toujours la
difference
--