> 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 8/16/24 11:00 PM, David King wrote:
On 8/16/24 11:32, Robert McBroom via users wrote:
Boot process f40 system stops for a long time with a problem with
smartd. Seems to access the system drives and note that they are
SMART capable. The following entries are in the journal
smartd[977]:
On 8/16/24 10:32 AM, François Patte wrote:
Bonjour,
Yesterday I updated my fc40 installation. I have an nvidia GPU with
nvidia driver from rpm-fusion.
I think that the akmod compilation of the driver went wrong and I
could not boot until the graphical login screen: the screen remains
black
On 8/16/24 11:32, Robert McBroom via users wrote:
Boot process f40 system stops for a long time with a problem with
smartd. Seems to access the system drives and note that they are SMART
capable. The following entries are in the journal
smartd[977]: Warning via /usr/libexec/smartmontools/sm
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 21:29, Andre Robatino wrote:
>
> All I know is that my two desktops have the GNOME, KDE, MATE, Cinnamon, and
> Basic DEs installed, and by updating the nemo package to the Bodhi testing
> version, sync was disabled, so there's nothing else in those DEs causing the
> prob
> On 16 Aug 2024, at 19:28, Roger Heflin wrote:
>
> It would depend on the buffer size being used.
The buffer size is not the limit., unless it's lots of GiB in size.
It's the fact that you go into a half-duplex mode that sets the limit.
This pattern slows down all sorts of algorithms, disk
Tim wrote:
> Is it just nemo with the problem? Because that file browser is on
> systems under various different program names (nemo, nautilus, caja)
> with *some* tinkering between the different forks.
All I know is that my two desktops have the GNOME, KDE, MATE, Cinnamon, and
Basic DEs install
> 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
On Fri, 2024-08-16 at 19:17 +, Andre Robatino wrote:
> In my case, I didn't have the nemo package installed on my laptop
> (the one with USB 3.0 ports) so sync was never enabled when using
> that machine. The two machines with USB 2.0 ports both have nemo
> installed (as part of the cinnamon de
On Fri, Aug 16, 2024 at 3:54 AM Frederic Muller wrote:
>
> A few questions all related: I fly FPV drones which require to use
> betaflight to configure them over the serial port. This has been working
> ok in the past and is getting more and more confusing. The timeline is
> far from accurate but
Roger Heflin wrote:
> It would depend on the buffer size being used. In Andre's case he
> reported it was ok with non-2.0 speeds, probably just luck that the
> buffer on his disk is large enough that it works ok.
In my case, I didn't have the nemo package installed on my laptop (the one with
USB
It would depend on the buffer size being used. In Andre's case he
reported it was ok with non-2.0 speeds, probably just luck that the
buffer on his disk is large enough that it works ok.
In general I have never had good luck with sync providing anything
resembling a decent speed except with raid
> On 16 Aug 2024, at 18:12, Roger Heflin wrote:
>
> So here is why sync sucks only on a usb 2.0 connection.
The report that lead to the revert of the sync change was on 3.0 connections.
The slow down was x10 or more.
So no this is not a USB 2 only issue.
Only if the user program and the USB
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
On Fri, Aug 16, 2024 at 12:12 PM Barry wrote:
>
>
>
> > On 16 Aug 2024, at 08:54, Frederic Muller wrote:
> >
> > Serial port also requires sudo ( /dev/ttyACM0 ) for betaflight to be able
> > to access it
>
> Look into adding a udev rule to set the permissions you need on the serial
> device.
>
So here is why sync sucks only on a usb 2.0 connection.
The host fills up the disks write cache some portion of
(32MB/64MB/128MB) and then the disk waits for the head get to were the
data needs to be written and writes it, as the write cache clears
space the host sends more data, but at usb2.0 the
> On 16 Aug 2024, at 08:54, Frederic Muller wrote:
>
> Serial port also requires sudo ( /dev/ttyACM0 ) for betaflight to be able to
> access it
Look into adding a udev rule to set the permissions you need on the serial
device.
Then you can avoid using sudo.
sudo became required for dmesg as
Someone seems to have added it to setup a snmp config. It is
unlikely you want an snmp config/install, its only use is for external
monitoring via the network (without ssh access) and is for the most
part not being used much anymore.
You might do a man smartd.conf and see if there is an option t
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
There are tools like
xrandr
which can help to query and setting the video
After that, you need to check the video drivers fitting your hardware.
see also cvt
Good luck
===
Patrick DUPRÉ | |
Boot process f40 system stops for a long time with a problem with
smartd. Seems to access the system drives and note that they are SMART
capable. The following entries are in the journal
smartd[977]: Warning via /usr/libexec/smartmontools/smartdnotify to root
produced>>
smartd[977]: No conf
On 8/16/24 8:32 AM, François Patte wrote:
Bonjour,
Yesterday I updated my fc40 installation. I have an nvidia GPU with nvidia
driver from rpm-fusion.
I think that the akmod compilation of the driver went wrong and I could not
boot until the graphical login screen: the screen remains black and
Bonjour,
Yesterday I updated my fc40 installation. I have an nvidia GPU with
nvidia driver from rpm-fusion.
I think that the akmod compilation of the driver went wrong and I could
not boot until the graphical login screen: the screen remains black and
nothing was possible to be done, even ac
Installing the nemo Bodhi update from
https://bodhi.fedoraproject.org/updates/FEDORA-2024-4717e54d2b does cause sync
to be eliminated from the line in /proc/mounts, and my transfer speed is back
to normal. Thanks for the replies!
--
___
users mailing
I just checked the laptop and the /proc/mounts line for the portable drive is
/dev/sdb1 /run/media/andre/Seagate btrfs
rw,seclabel,nosuid,nodev,relatime,space_cache,subvolid=5,subvol=/ 0 0
and indeed there is no sync! (Otherwise it's identical to the one posted above
from my desktop.) I realize
No, I'm using GNOME, although I do have the cinnamon desktop installed. From
looking at your link it looks like it's due to using sync, next time I boot my
laptop I intend to check if the /proc/mounts shows the portable drive using
sync there, since my transfer speed seems to be normal on that.
Hi!
A few questions all related: I fly FPV drones which require to use
betaflight to configure them over the serial port. This has been working
ok in the past and is getting more and more confusing. The timeline is
far from accurate but in short:
1. Everything used to work fine a few Fedora
> On 15 Aug 2024, at 21:29, Roger Heflin wrote:
>
> So it is only slow on the slow port? If so it kind of sounds like the
> fs may be mounted sync and/or the disks write cache is disabled.
> smartctl --xall sometimes works against usb disk and
> sometimes it does not work. if it works it w
32 matches
Mail list logo
