blacklisting ST3500630AS as not able to do NCQ

blacklisting ST3500630AS as not able to do NCQ

[diego torres]

Hi there,

This seagate drive ST3500630AS is being recognized as NCQ capable by
hdparm, and has the default queue_depth of 31, so i think it should
work ok. But there are some problems when using smartmontools (for
example in short test mode) as seen in dmesg:

ata2.00: exception Emask 0x2 SAct 0x9 SErr 0x0 action 0x2 frozen
ata2.00: (spurious completions during NCQ issue=0x0 SAct=0x9 FIS=004040a1:00000004)
ata2.00: cmd 61/08:00:f4:28:4e/00:00:00:00:00/40 tag 0 cdb 0x0 data 4096 out
         res 40/00:00:f4:28:4e/00:00:00:00:00/40 Emask 0x2 (HSM violation)
ata2.00: cmd 61/08:18:dc:c8:d7/00:00:00:00:00/40 tag 3 cdb 0x0 data 4096 out
         res 40/00:00:f4:28:4e/00:00:00:00:00/40 Emask 0x2 (HSM violation)
ata2: soft resetting port
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: configured for UDMA/133
ata2: EH complete
sd 1:0:0:0: [sdb] 976773168 512-byte hardware sectors (500108 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

All this problems dissapear when setting queue_depth to 1.

After cheking the seagate website, there is no mention to NCQ in the
spec sheet of this drive, although there are models tagged as using
NCQ interface, for example ST3500620AS

630AS
http://www.seagate.com/ww/v/index.jsp?vgnextoid=b9df99f4fa74c010VgnVCM100000dd04090aRCRD&locale=en-US
620AS
http://www.seagate.com/ww/v/index.jsp?locale=en-US&name=barracuda-7200-11-sata-3-0-gb/s-500-gb-hard-drive-st3500620as&vgnextoid=c58ff141e7f43110VgnVCM100000f5ee0a0aRCRD&vgnextchannel=47f281f8c0f43110VgnVCM100000f5ee0a0aRCRD&reqPage=Model

So, should this drive be blacklisted as not being able to do NCQ
properly?

Thanks in advance.

Details of my setup follow:

# lspci |grep AHCI
0000:00:1f.2 0106: Intel Corporation 82801GR/GH (ICH7 Family) Serial ATA Storage Controllers cc=AHCI (rev 01)
# uname -a
Linux anthalia 2.6.22.6 #1 SMP Sun Sep 16 16:48:12 UTC 2007 i686 GNU/Linux
# hdparm -V
hdparm v7.7
# hdparm -I /dev/sda

/dev/sda:

ATA device, with non-removable media
        Model Number:       ST3500630AS
        Serial Number:      5QG0QM7A
        Firmware Revision:  3.AAE
Standards:
        Supported: 7 6 5 4
        Likely used: 7
Configuration:
        Logical         max     current
        cylinders       16383   16383
        heads           16      16
        sectors/track   63      63
        --
        CHS current addressable sectors:   16514064
        LBA    user addressable sectors:  268435455
        LBA48  user addressable sectors:  976773168
        device size with M = 1024*1024:      476940 MBytes
        device size with M = 1000*1000:      500107 MBytes (500 GB)
Capabilities:
        LBA, IORDY(can be disabled)
        Queue depth: 32
        Standby timer values: spec'd by Standard, no device specific minimum
        R/W multiple sector transfer: Max = 16  Current = 16
        Recommended acoustic management value: 254, current value: 0
        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4
             Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
        Enabled Supported:
           *    SMART feature set
                Security Mode feature set
           *    Power Management feature set
           *    Write cache
           *    Look-ahead
           *    Host Protected Area feature set
           *    WRITE_BUFFER command
           *    READ_BUFFER command
           *    DOWNLOAD_MICROCODE
                SET_MAX security extension
           *    48-bit Address feature set
           *    Device Configuration Overlay feature set
           *    Mandatory FLUSH_CACHE
           *    FLUSH_CACHE_EXT
           *    SMART error logging
           *    SMART self-test
           *    General Purpose Logging feature set
           *    SATA-I signaling speed (1.5Gb/s)
           *    SATA-II signaling speed (3.0Gb/s)
           *    Native Command Queueing (NCQ)
           *    Phy event counters
                Device-initiated interface power management
           *    Software settings preservation
Security:
        Master password revision code = 65534
                supported
        not     enabled
        not     locked
                frozen
        not     expired: security count
        not     supported: enhanced erase
Checksum: correct



-- 
Saludos,
 diego                          mailto:dtorres@coral.dnsalias.org

Re: blacklisting ST3500630AS as not able to do NCQ

[Tejun Heo]

diego torres wrote:
> Hi there,
> 
> This seagate drive ST3500630AS is being recognized as NCQ capable by
> hdparm, and has the default queue_depth of 31, so i think it should
> work ok. But there are some problems when using smartmontools (for
> example in short test mode) as seen in dmesg:
> 
> ata2.00: exception Emask 0x2 SAct 0x9 SErr 0x0 action 0x2 frozen
> ata2.00: (spurious completions during NCQ issue=0x0 SAct=0x9 FIS=004040a1:00000004)
> ata2.00: cmd 61/08:00:f4:28:4e/00:00:00:00:00/40 tag 0 cdb 0x0 data 4096 out
>          res 40/00:00:f4:28:4e/00:00:00:00:00/40 Emask 0x2 (HSM violation)
> ata2.00: cmd 61/08:18:dc:c8:d7/00:00:00:00:00/40 tag 3 cdb 0x0 data 4096 out
>          res 40/00:00:f4:28:4e/00:00:00:00:00/40 Emask 0x2 (HSM violation)
> ata2: soft resetting port
> ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> ata2.00: configured for UDMA/133
> ata2: EH complete
> sd 1:0:0:0: [sdb] 976773168 512-byte hardware sectors (500108 MB)
> sd 1:0:0:0: [sdb] Write Protect is off
> sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
> sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> 
> All this problems dissapear when setting queue_depth to 1.
> 
> After cheking the seagate website, there is no mention to NCQ in the
> spec sheet of this drive, although there are models tagged as using
> NCQ interface, for example ST3500620AS

How reproducible is the problem?

-- 
tejun

Re[2]: blacklisting ST3500630AS as not able to do NCQ

[diego torres]

> diego torres wrote:
>> Hi there,
>> 
>> After cheking the seagate website, there is no mention to NCQ in the
>> spec sheet of this drive, although there are models tagged as using
>> NCQ interface, for example ST3500620AS

> How reproducible is the problem?

It always happens under heavy load, or when using smartmontools when
depth_queue is > 1. I've 2 drives and both of them have the same
problem (different firmware versions).

#hdparm -i /dev/sda
Model=ST3500630AS                             , FwRev=3.AAD   , SerialNo=            6QG0FMYJ
#hdparm -i /dev/sdb
Model=ST3500630AS                             , FwRev=3.AAE   , SerialNo=            5QG0QM7A

Test in a ICH7 controller that can do ncq sucessfully (tested) with
other drives (for example, Maxtor 6V250F0)

00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01)

-- 
Saludos,
 diego                            mailto:dtorres@coral.dnsalias.org

Re: blacklisting ST3500630AS as not able to do NCQ

[Michael Tokarev]

Tejun Heo wrote:
> diego torres wrote:
>> Hi there,
>>
>> This seagate drive ST3500630AS is being recognized as NCQ capable by
>> hdparm, and has the default queue_depth of 31, so i think it should
>> work ok. But there are some problems when using smartmontools (for
>> example in short test mode) as seen in dmesg:
>>
>> ata2.00: exception Emask 0x2 SAct 0x9 SErr 0x0 action 0x2 frozen
>> ata2.00: (spurious completions during NCQ issue=0x0 SAct=0x9 FIS=004040a1:00000004)
>> ata2.00: cmd 61/08:00:f4:28:4e/00:00:00:00:00/40 tag 0 cdb 0x0 data 4096 out
>>          res 40/00:00:f4:28:4e/00:00:00:00:00/40 Emask 0x2 (HSM violation)
>> ata2.00: cmd 61/08:18:dc:c8:d7/00:00:00:00:00/40 tag 3 cdb 0x0 data 4096 out
>>          res 40/00:00:f4:28:4e/00:00:00:00:00/40 Emask 0x2 (HSM violation)
>> ata2: soft resetting port
>> ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
>> ata2.00: configured for UDMA/133
>> ata2: EH complete
>> sd 1:0:0:0: [sdb] 976773168 512-byte hardware sectors (500108 MB)
>> sd 1:0:0:0: [sdb] Write Protect is off
>> sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
>> sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
>>
>> All this problems dissapear when setting queue_depth to 1.
>>
>> After cheking the seagate website, there is no mention to NCQ in the
>> spec sheet of this drive, although there are models tagged as using
>> NCQ interface, for example ST3500620AS
> 
> How reproducible is the problem?

A good question.

We too has - not the same but similar - drives here, which shows pretty
similar behavior.

ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: ATA-7: ST3250620NS, 3.AEG, max UDMA/133
ata1.00: 488397168 sectors, multi 16: LBA48 NCQ (depth 31/32)
ata1.00: configured for UDMA/133
sd 0:0:0:0: [sda] 488397168 512-byte hardware sectors (250059 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] 488397168 512-byte hardware sectors (250059 MB)

(those are 250Gb drives, not 500Gb as Diego have, but they're
from the same model line).  Later on:

ata1.00: exception Emask 0x2 SAct 0x8 SErr 0x0 action 0x2 frozen
ata1.00: (spurious completions during NCQ issue=0x0 SAct=0x8 FIS=004040a1:00000004)
ata1.00: cmd 61/08:18:02:98:d8/00:00:00:00:00/40 tag 3 cdb 0x0 data 4096 out
         res 40/00:20:6a:72:d8/00:00:00:00:00/40 Emask 0x2 (HSM violation)
ata1: soft resetting port
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: configured for UDMA/133
ata1: EH complete
sd 0:0:0:0: [sda] 488397168 512-byte hardware sectors (250059 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

and so on and so on.

The thing is that I haven't seen this behavior with previous kernel.
I upgraded from 2.6.20-i686 to 2.6.22-x86-64 (from kernel.org), and
started seeing those messages.  I'm not sure if it's new kernel
version or 32 vs 64 bits issue.

The machine is our main production server, so I can't test it right
now - have to wait till some spare evening...

/mjt