Custom Query (1365 matches)

Since smartmontools 5.41, on our Solaris 9/10 systems when using "smartctl -a" against a Fujitsu SCSI disk, it appears smartctl is submitting invalid CDBs to the underlying drive (which rejects the command, citing ILLEGAL REQUEST). "smartctl -x" induces two rejections. smartmontools 5.40 does not cause this behaviour.

The problem with the rejection is that the Solaris kernel logs this in such a way that it appears as a disk failure to our NOC, which results tickets opened to have disks replaced when in fact there's nothing wrong with the disk at all.

Relevant details:

# iostat -E -n
c0t0d0           Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
Vendor: FUJITSU  Product: MAW3147NC        Revision: 0104 Serial No:
Size: 147.09GB <147086327296 bytes>
Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0
Illegal Request: 0 Predictive Failure Analysis: 0

# smartctl -x /dev/rdsk/c0t0d0s0
smartctl 5.42 2011-10-20 r3458 [i386-pc-solaris2.10] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

Vendor:               FUJITSU
Product:              MAW3147NC
Revision:             0104
User Capacity:        147,086,327,808 bytes [147 GB]
Logical block size:   512 bytes
Serial number:        DAA0P7B05H9C
Device type:          disk
Transport protocol:   Parallel SCSI (SPI-4)
Local Time is:        Wed Nov  9 01:49:21 2011 PST
Device supports SMART and is Enabled
Temperature Warning Enabled
SMART Health Status: OK

Current Drive Temperature:     26 C
Drive Trip Temperature:        65 C
Manufactured in week 46 of year 2007
Specified cycle count over device lifetime:  10000
Accumulated start-stop cycles:  19
Elements in grown defect list: 0

Error counter log:
           Errors Corrected by           Total   Correction     Gigabytes    Total
               ECC          rereads/    errors   algorithm      processed    uncorrected
           fast | delayed   rewrites  corrected  invocations   [10^9 bytes]  errors
read:          0        0         0         0          0       6208.306           0
write:         0        9         0         0          0      24562.295           0

Non-medium error count:       53

SMART Self-test log
Num  Test              Status                 segment  LifeTime  LBA_first_err [SK ASC ASQ]
     Description                              number   (hours)
# 1  Background long   Self test in progress ...   -     NOW                 - [-   -    -]
# 2  Background long   Self test in progress ...   -     NOW                 - [-   -    -]

Long (extended) Self Test duration: 3432 seconds [57.2 minutes]
Device does not support Background scan results logging
scsiPrintSasPhy Log Sense Failed [unsupported field in scsi command]

# iostat -E -n
c0t0d0           Soft Errors: 2 Hard Errors: 0 Transport Errors: 0
Vendor: FUJITSU  Product: MAW3147NC        Revision: 0104 Serial No:
Size: 147.09GB <147086327296 bytes>
Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0
Illegal Request: 2 Predictive Failure Analysis: 0

Errors on console, which I imagine will greatly help since they include the request CDB:

Nov  9 09:49:21 scsi: [ID 107833 kern.warning] WARNING: /pci@0,0/pci1022,7450@a/pci9005,ffff@a/sd@0,0 (sd0):       Error for Command: inquiry                 Error Level: Informational
Nov  9 09:49:21 scsi: [ID 107833 kern.notice]      Requested Block: 0                         Error Block: 0
Nov  9 09:49:21 scsi: [ID 107833 kern.notice]      Vendor: FUJITSU                            Serial Number: DAA0P7B05H9C
Nov  9 09:49:21 scsi: [ID 107833 kern.notice]      Sense Key: Illegal Request
Nov  9 09:49:21 scsi: [ID 107833 kern.notice]      ASC: 0x24 (invalid field in cdb), ASCQ: 0x0, FRU: 0x0

Nov  9 09:49:22 scsi: [ID 107833 kern.warning] WARNING: /pci@0,0/pci1022,7450@a/pci9005,ffff@a/sd@0,0 (sd0):       Error for Command: log sense(10)           Error Level: Informational
Nov  9 09:49:22 scsi: [ID 107833 kern.notice]      Requested Block: 0                         Error Block: 0
Nov  9 09:49:22 scsi: [ID 107833 kern.notice]      Vendor: FUJITSU                            Serial Number: DAA0P7B05H9C
Nov  9 09:49:22 scsi: [ID 107833 kern.notice]      Sense Key: Illegal Request
Nov  9 09:49:22 scsi: [ID 107833 kern.notice]      ASC: 0x24 (invalid field in cdb), ASCQ: 0x0, FRU: 0x0

I believe the "scsiPrintSasPhy Log Sense Failed" error can explain one of the illegal requests, but I'm not sure where the other is.

Pretty much all our Fujitsu disks behave like this -- more than just the model shown above (smaller models, etc.). If you need me to make a list of them all (for drivedb exclusions/quirks) I can do so.

Let me know how to proceed, I have lots of systems to test with. :-)

AFAIK, currently Windows versions of smartctl allow piping smart data generated by 3ware tw_cli tool to smartctl, but this feature is not available in Linux.

I would greatly appreciate if it could be possible in the future to let smartctl read from stdin the hex-representation of 3ware-generated smart data and show the contents in human-readable format under Linux too.

There are operating systems where tw_cli is available, but not smartctl. My current issue is related to VMware ESXi with a 3ware controller: with tw_cli running in that environment, I can get a hex table of smart data over ssh to Linux environment, where I would like to decode the data to human readable.

I've got a Toshiba StorE HDD Bus 001 Device 002: ID 0939:0b16 Lumberg, Inc.

it works with -d usbsunplus so it may be added to driverdb