On Sat, 2024-08-17 at 07:45 -0700, Doug Herr wrote:
> On Fri, Aug 16, 2024, at 9:17 AM, Doug H. wrote:
> > I recently noticed that `gkrellm` was not showing the temperatures
> > for
> > my drives (SATA SSD in my case).
> >
> > It turns out that the 6.10 kernel updates fixed something to spec
> > t
On Fri, Aug 16, 2024, at 9:17 AM, Doug H. wrote:
> I recently noticed that `gkrellm` was not showing the temperatures for
> my drives (SATA SSD in my case).
>
> It turns out that the 6.10 kernel updates fixed something to spec that
> thus broke some stuff that was depending on a non-spec output tha
On Fri, Aug 16, 2024, at 11:57 PM, Barry wrote:
> Try contacting the author, there is an email address at the bottom of
> the project page.
> Here http://gkrellm.srcbox.net/
I checked the source of gkrellm and they are simply doing a query to the
hddtemp daemon. I was not able to get that to wor
> On 16 Aug 2024, at 21:48, Doug Herr wrote:
>
> I can also just use `hddtemp -w` to show the temp, but again, it is `gkrellm`
> that I want to work and I don't see a way to get it to add that "-w" when it
> checks.
Try contacting the author, there is an email address at the bottom of the
p
On Fri, Aug 16, 2024, at 1:22 PM, Barry Scott wrote:
> I can get the temp for my nvme drive with smartctl:
Yes, that works for my SATA drives also. The problem for me is that I like
using `gkrellm` to keep track of drive temp and to alert at my preferred
setting of "too hot".
I can also just us
> On 16 Aug 2024, at 17:17, Doug H. wrote:
>
> It turns out that the 6.10 kernel updates fixed something to spec that
> thus broke some stuff that was depending on a non-spec output that had
> been going on for some time.
I can get the temp for my nvme drive with smartctl:
$ smartctl -A /dev/
On Fri, 2024-08-16 at 12:30 -0500, Roger Heflin wrote:
> And having a hdtemp command/smartctl command spin up a drive to ask
> its temp is a power wasting command. The drive stays spun up for
> several minutes and uses around 5w more while it is spun up. So one
> cannot argue with it returning a
This is BROKEN user space code (hdparm assumes what is being
returned). And broken userspace code is different.
He does not like to break correct userspace code.
And this code is in what I would classify as a non-critical path, this
breaks some monitoring tools/utilities but does not impact crit
Once upon a time, Roger Heflin said:
> Zero chance they back that out. It is not a regression in the
> kernel, a valid fix exposed bad code in user space.
I wouldn't say that - Linus is very adamant about not breaking existing
user space code, which this change did. Since this is long-standing
Zero chance they back that out. It is not a regression in the
kernel, a valid fix exposed bad code in user space.
The defect is in user space commands not checking what the kernel
returned. The bug is not in the kernel. The solution will be to fix
the user space programs and/or require the ext
I recently noticed that `gkrellm` was not showing the temperatures for
my drives (SATA SSD in my case).
It turns out that the 6.10 kernel updates fixed something to spec that
thus broke some stuff that was depending on a non-spec output that had
been going on for some time.
The kernel "regression
11 matches
Mail list logo
