Custom Query (1359 matches)
Results (7 - 9 of 1359)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #13 | fixed | Autodetection doesn't work with -d sat | ||
| Description |
Hi, with: DEVICESCAN -d sat -n standby -m root -M exec /usr/share/smartmontools/smartd-runner -M test I got: # smartd -d smartd 5.39 2009-08-29 r2879 [i686-pc-linux-gnu] (local build) Copyright (C) 2002-9 by Bruce Allen, http://smartmontools.sourceforge.net Opened configuration file /etc/smartd.conf Drive: DEVICESCAN, implied '-a' Directive on line 23 of file /etc/smartd.conf Configuration file /etc/smartd.conf was parsed, found DEVICESCAN, scanning devices In the system's table of devices NO devices found to scan Unable to monitor any SMART enabled devices. Try debug (-d) option. Exiting... But with: DEVICESCAN -n standby -m root -M exec /usr/share/smartmontools/smartd-runner -M test autodetection works: # smartd -d smartd 5.39 2009-08-29 r2879 [i686-pc-linux-gnu] (local build) Copyright (C) 2002-9 by Bruce Allen, http://smartmontools.sourceforge.net Opened configuration file /etc/smartd.conf Drive: DEVICESCAN, implied '-a' Directive on line 23 of file /etc/smartd.conf Configuration file /etc/smartd.conf was parsed, found DEVICESCAN, scanning devices Device: /dev/hda, opened Device: /dev/hda, packet devices [this device CD/DVD] not SMART capable Unable to register ATA device /dev/hda at line 23 of file /etc/smartd.conf Device: /dev/hdc, opened Device: /dev/hdc, packet devices [this device CD/DVD] not SMART capable Unable to register ATA device /dev/hdc at line 23 of file /etc/smartd.conf Device: /dev/sda, type changed from 'scsi' to 'sat' Device: /dev/sda [SAT], opened Device: /dev/sda [SAT], found in smartd database. Device: /dev/sda [SAT], is SMART capable. Adding to "monitor" list. Device: /dev/sdb, type changed from 'scsi' to 'sat' Device: /dev/sdb [SAT], opened Device: /dev/sdb [SAT], found in smartd database. Device: /dev/sdb [SAT], is SMART capable. Adding to "monitor" list. Monitoring 2 ATA and 0 SCSI devices Original bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=546566 |
|||
| #17 | fixed | add descriptions of attributes 188 and 184 | ||
| Description |
This article says that attribute 188 is "Command Timeout": http://en.wikipedia.org/wiki/S.M.A.R.T. "A number of aborted operations due to HDD timeout. Normally this attribute value should be equal to zero and if you have values far above zero, then most likely you have some serious problems with your power supply or you have an oxidized data cable." It also described attribute 184 "End-to-End error" These attributes are reported for Seagate 7200.12 disks: START OF INFORMATION SECTIONDevice Model: ST3500410AS Serial Number: 5VM0NB43 Firmware Version: CC34 User Capacity: 500,107,862,016 bytes Device is: Not in smartctl database [for details use: -P showall] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 4 Local Time is: Mon Sep 21 15:29:24 2009 EEST SMART support is: Available - device has SMART capability. SMART support is: Enabled ... 184 Unknown_Attribute 0x0032 100 100 099 Old_age Always - 0 ... 188 Unknown_Attribute 0x0032 100 098 000 Old_age Always -
... |
|||
| #20 | fixed | weird byte order of "Head Flying Hours" | ||
| Description |
I've bought a brand new 1T Seagate drive yesterday. kotik tmp # dmesg | grep ST31 [ 0.834822] ata1.00: ATA-8: ST31000528AS, CC35, max UDMA/133 [ 0.847168] scsi 0:0:0:0: Direct-Access ATA ST31000528AS CC35 PQ: 0 ANSI: 5 I was quite surprised to see its Head_Flying_Hours to be some n-teen digit number when I first run smartctl on it, however, Power_On_Hours value was sane. To be sure that everything is ok with my eyes I ran smrtctl again. This time the value was completely different although of the same order of magnitude. After quick investigation it became quite obvious that there is something wrong with the byte order of the raw value kotik tmp # smartctl -d ata -A /dev/sda | grep ^240 240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offline - 102838696935451 kotik tmp # printf "%x\n" 102838696935451 5d880000001b When I read the values with my programme (see attachment) I found that one of the bytes of the value is stored in the reserv field of the ata_smart_attribute structure. The right order to read the value seems to be raw[3], raw[2], raw[1], raw[0], reserv, raw[5], raw[4] However, I am not sure about more significant bytes (raw[1-3]). The value itself is almost for sure number of milliseconds. |
|||
