lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <646765f40909142257t560b314dt74d4158a497f0460@mail.gmail.com>
Date:	Tue, 15 Sep 2009 15:57:39 +1000
From:	Julian Calaby <julian.calaby@...il.com>
To:	James Bottomley <James.Bottomley@...e.de>
Cc:	Constantin Baranov <const@...as.ru>, linux-kernel@...r.kernel.org,
	linux-scsi@...r.kernel.org
Subject: Re: [PATCH] hwmon: Driver for SCSI/ATA temperature sensors

On Mon, Sep 14, 2009 at 00:00, James Bottomley <James.Bottomley@...e.de> wrote:
> On Sun, 2009-09-13 at 04:01 +0500, Constantin Baranov wrote:
>> The scsitemp module attaches a device to each SCSI device
>> and registers it in hwmon. Currently the only method of
>> reading temperature is ATA SMART. Adding support of the
>> pure SCSI methods is provided.
>
> The code, as you wrote it looks fine.
>
> The basic problem are the effects.  Right at the moment it tries to send
> an ATA_16 encapsulated SMART command to every SCSI device in the system.
> We simply can't allow this.  A huge number of SCSI presenting USB
> devices are known to lock up when they see either ATA_X encapsulation or
> SMART commands.  It's not really even safe to send ATA_X to SCSI
> devices.  The modern ones should all error out fine, but the older ones
> are likely to be less tolerant.
>
> Finally, this:
>
>> +               if (attr[2] == 194) {
>> +                       *temp = attr[7] * 1000;
>> +                       err = 0;
>> +                       break;
>
> Smart attribute 194 is highly vendor specific ... for instance my new
> SATA drive doesn't implement it (it does implement 190 instead).
>
> So really, given the complexity of just obtaining the data and the
> problem of matching which data to obtain to which device you have, why
> not just use smartctl from userspace for monitoring?  you could even
> just plug into smartd, it seems to have most of the necessary heuristics
> built in already.

There's even a util called hddtemp which handles all this and has a
database of smart attributes to use for most drives.

Thanks,

-- 

Julian Calaby

Email: julian.calaby@...il.com
.Plan: http://sites.google.com/site/juliancalaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ