Custom Query (1414 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (31 - 33 of 1414)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Ticket Resolution Summary Owner Reporter
#1851 fixed Error when downloading from https://builds.smartmontools.org/ Alex Samorukov EugenAM
Description

For example, I'm trying to download https://builds.smartmontools.org/ #1927 builds/smartmontools-linux-x86_64-static-7.5-r5613.tar.gz today.


ash-4.4# curl https://output.circle-artifacts.com/output/job/a270debf-d10c-4990-add4-eddeef0bfc0e/artifacts/0/builds/smartmontools-linux-x86_64-static-7.5-r5613.tar.gz
{"message":"not found"}
#1850 fixed Ignore individual NVME temperature sensors Christian Franke Matalonder
Description

I have a Kingston Fury Renegade NVMe SSD, SFYRDK4000G. It reports two temperature sensors:

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        62 Celsius
...
Temperature Sensor 2:               67 Celsius

and as sensors output:

nvme-pci-0100
Adapter: PCI adapter
Composite:    +61.9°C  (low  = -20.1°C, high = +83.8°C)
                       (crit = +88.8°C)
Sensor 2:     +66.8°C  

The problem is, only Composite is an actual temperature sensor. Sensor 2 seems to be just a "Highest temperature ever seen" tracking value. It's always 66.8, even when Composite is, like, 25.

I track this drive with -W 5,55,65, because I want to get desktop notifications when it goes over 65, and I figured out that passing the notification-creating script to -M works well enough.

This, however, now causes me to get the notification on every boot, because Sensor 2 is stuck at the highest-ever-seen 66.8 and smartd always uses its value:

Jun 30 15:38:29 hostname smartd[18016]: Device: /dev/disk/by-id/nvme-KINGSTON_SFYRDK4000G_..., Temperature 67 Celsius reached critical limit of 65 Celsius (Min/Max 67/67)

Effectively making the whole -W flag useless.

So it seems like this behaviour, described in the man page, is messing with me:

For NVMe devices, smartd checks the maximum of the Composite Temperature value and all Temperature Sensor values reported by SMART/Health Information log.

Is there a way to instruct smartd to ignore certain temperature sensor values, or use only the Composite one?

If there isn't, could you consider this enhancement? It seems like a valid use case with no other solution. For now I'll have to pass -W 0,0,0 for this SSD to avoid useless notifications and monitor it manually.

#1847 fixed Seagate Barracuda 7200.12, FW:HP34, invalid warning about new firmware Christian Franke Jaroslav
Description

Device: /dev/sdb [SAT], ST3500418AS, S/N:CENSORED, WWN:CENSORED, FW:HP34, 500 GB Device: /dev/sdb [SAT], found in smartd database 7.3/5610: Seagate Barracuda 7200.12 Device: /dev/sdb [SAT], WARNING: A firmware update for this drive may be available, see the following Seagate web pages: http://knowledge.seagate.com/articles/en_US/FAQ/207931en http://knowledge.seagate.com/articles/en_US/FAQ/213891en

The HP34 is customized HP firmware which cannot be officially reflashed with the Seagate FW update tool and is explicitly rejected by the tool. It seems HP doesn't have firmware update for linux machines using this drive, they have only HP40 version for Windows machines which seems to only resolves problem with the response time of the cold drive, i.e. nothing SMART related.

Nevertheless, the above warning is misleading and can even result that some brave people would brick their drives if they try to force flash the Seagate firmware because mixing the Seagate chip firmware with incompatible modules on the service area of the drive can lead to catastrophical results - invalid SMART attributes reported by the crippled firmware is one of the better results from the force flash.

drivedb.h 7.3/5610

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.