Re: [gentoo-user] Long boot time after kernel update

[William Kenworthy]

A point to keep in mind - if you can feel the drive moving it may be 
generating errors!  Depending on the drive, the errors may just be 
handled internally and I can see it slowing things down though probably 
would be barely noticeable.  I have seen it myself with random errors 
from a WD green drive disappearing when properly immobilised.  When 
investigating I ran across articles discussing the problem, one of which 
fastened the drives to a granite slab for tests!  Also see discussions 
on NAS seups and vibrations affecting co located drives.


BillK

** Interesting read 
https://www.ept.ca/features/everything-need-know-hard-drive-vibration/



On 27/12/21 22:15, Dale wrote:

Wols Lists wrote:

On 27/12/2021 13:40, Michael wrote:

On Monday, 27 December 2021 11:32:39 GMT Wols Lists wrote:

On 27/12/2021 11:07, Jacques Montier wrote:

Well, i don't know if my partitions are aligned or mis-aligned... How
could i get it ?

fdisk would have spewed a bunch of warnings. So you're okay.

I'm not sure of the details, but it's the classic "off by one"
problem -
if there's a mismatch between the kernel block size and the disk block
size any writes required doing a read-update-write cycle which of
course
knackered performance. I had that hit a while back.

But seeing as fdisk isn't moaning, that isn't the problem ...

Cheers,
Wol

I also thought of misaligned boundaries when I first saw the error,
but the
mention of Seagate by the OP pointed me to another edge case which
crept up
with zstd compression on ZFS.  I'm mentioning it here in case it is
relevant:

https://livelace.ru/posts/2021/Jul/19/unaligned-write-command/


that might be of interest to me ... I'm getting system lockups but
it's not an SSD. I've got two IronWolves and a Barracuda.

But I notice the OP has a Barra*C*uda. Note the different spelling.
That's a shingled drive I believe, which shouldn't make a lot of
difference in light usage, but you don't want to hammer it!

Cheers,
Wol



I don't recall seeing this mentioned but this may be part of the issue
unless I'm missing something that rules this out.  Could it be a drive
is a SMR drive?  I recently made a new backup after wiping out the
drive.  I know the backup drive is a SMR drive.  At first, it copied at
a fairly normal speed but after a short time frame, it started slowing
down.  At times, it would do only about 50 to 60MBs/sec.  It started out
at well over 100MBs/sec which is fairly normal for this rig.  I would
stop the copy process, let it catch up and restart just to give it some
time to process.  I can't say it was any faster that way tho.

The way I noticed my drive was SMR, I could feel the heads going back
and forth by putting my hand on the enclosure.  It had a bumpy feel to
it.  You can't really hear it tho.  If you can feel those little bumps
even when the drive isn't mounted, I'd be thinking it is a SMR drive.
There are also sites that you can look this sort of thing up on too.  If
needed, I can go dig out some links.

Just thought it worth a mention.

Dale

:-)  :-)

Re: [gentoo-user] Long boot time after kernel update

[Wols Lists]

On 28/12/2021 09:30, William Kenworthy wrote:
A point to keep in mind - if you can feel the drive moving it may be 
generating errors!  Depending on the drive, the errors may just be 
handled internally and I can see it slowing things down though probably 
would be barely noticeable.  I have seen it myself with random errors 
from a WD green drive disappearing when properly immobilised.  When 
investigating I ran across articles discussing the problem, one of which 
fastened the drives to a granite slab for tests!  Also see discussions 
on NAS seups and vibrations affecting co located drives.


BillK

** Interesting read 
https://www.ept.ca/features/everything-need-know-hard-drive-vibration/


Have you got the link to the follow-on article? I'd love to put them 
both on the linux raid wiki.


Cheers,
Wol

Re: [gentoo-user] Long boot time after kernel update

[Dale]

William Kenworthy wrote:
> A point to keep in mind - if you can feel the drive moving it may be
> generating errors!  Depending on the drive, the errors may just be
> handled internally and I can see it slowing things down though
> probably would be barely noticeable.  I have seen it myself with
> random errors from a WD green drive disappearing when properly
> immobilised.  When investigating I ran across articles discussing the
> problem, one of which fastened the drives to a granite slab for
> tests!  Also see discussions on NAS seups and vibrations affecting co
> located drives.
>
> BillK
>
> ** Interesting read
> https://www.ept.ca/features/everything-need-know-hard-drive-vibration/
>

This is just because it is a SMR drive.  It's done this ever since I
bought the drive and it has passed all tests.  There's a whole thread on
this dating back several years.  I managed to buy a SMR drive before I
even knew they existed.  Once it fills up that PMR section, it gets
really slow. 

Dale

:-)  :-) 

Re: [gentoo-user] Long boot time after kernel update

[Jacques Montier]

Le mar. 28 déc. 2021 à 13:32, Dale  a écrit :

> William Kenworthy wrote:
> > A point to keep in mind - if you can feel the drive moving it may be
> > generating errors!  Depending on the drive, the errors may just be
> > handled internally and I can see it slowing things down though
> > probably would be barely noticeable.  I have seen it myself with
> > random errors from a WD green drive disappearing when properly
> > immobilised.  When investigating I ran across articles discussing the
> > problem, one of which fastened the drives to a granite slab for
> > tests!  Also see discussions on NAS seups and vibrations affecting co
> > located drives.
> >
> > BillK
> >
> > ** Interesting read
> > https://www.ept.ca/features/everything-need-know-hard-drive-vibration/
> >
>
> This is just because it is a SMR drive.  It's done this ever since I
> bought the drive and it has passed all tests.  There's a whole thread on
> this dating back several years.  I managed to buy a SMR drive before I
> even knew they existed.  Once it fills up that PMR section, it gets
> really slow.
>
> Dale
>
> :-)  :-)
>
>
Hello all,

Thanks a lot for all your responses !
I think this issue is kernel related.
No problem with 5.10.76-gentoo-r1, but the issue appears
with 5.15.11-gentoo.

I read on the net that it could be possible to desactivate the sata
protocol NCQ (Native Command Queuing)
So, in the grub file, i added the
ligne GRUB_CMDLINE_LINUX=libata.force=noncq
Now, all the errors messages are gone and the booting time gets down to 24s
with the two kernel versions.
BUT : do you think it could damage or slow down my SSD and HDD disks ?

Thanks again,

Regards,

--
Jacques

Re: [gentoo-user] Long boot time after kernel update

[Jacques Montier]

Le mar. 28 déc. 2021 à 14:03, Jacques Montier  a écrit :

>
>
>
> Le mar. 28 déc. 2021 à 13:32, Dale  a écrit :
>
>> William Kenworthy wrote:
>> > A point to keep in mind - if you can feel the drive moving it may be
>> > generating errors!  Depending on the drive, the errors may just be
>> > handled internally and I can see it slowing things down though
>> > probably would be barely noticeable.  I have seen it myself with
>> > random errors from a WD green drive disappearing when properly
>> > immobilised.  When investigating I ran across articles discussing the
>> > problem, one of which fastened the drives to a granite slab for
>> > tests!  Also see discussions on NAS seups and vibrations affecting co
>> > located drives.
>> >
>> > BillK
>> >
>> > ** Interesting read
>> > https://www.ept.ca/features/everything-need-know-hard-drive-vibration/
>> >
>>
>> This is just because it is a SMR drive.  It's done this ever since I
>> bought the drive and it has passed all tests.  There's a whole thread on
>> this dating back several years.  I managed to buy a SMR drive before I
>> even knew they existed.  Once it fills up that PMR section, it gets
>> really slow.
>>
>> Dale
>>
>> :-)  :-)
>>
>>
> Hello all,
>
> Thanks a lot for all your responses !
> I think this issue is kernel related.
> No problem with 5.10.76-gentoo-r1, but the issue appears
> with 5.15.11-gentoo.
>
> I read on the net that it could be possible to desactivate the sata
> protocol NCQ (Native Command Queuing)
> So, in the grub file, i added the
> ligne GRUB_CMDLINE_LINUX=libata.force=noncq
> Now, all the errors messages are gone and the booting time gets down to
> 24s with the two kernel versions.
> BUT : do you think it could damage or slow down my SSD and HDD disks ?
>
> Thanks again,
>
> Regards,
>
> --
> Jacques
>
>
>
> Me again !

Well, il cleaned my dusty mobo, unplugged and plugged again the sata cables.
Now, with or without NCQ, boot time is rather short (~28s).
So it seems it was a connection problem.

I still have some errors as :


[   24.708377] ata6.00: exception Emask 0x10 SAct 0x5041 SErr 0x401
action 0xe frozen
[   24.708385] ata6.00: irq_stat 0x00400040, connection status changed
[   24.708387] ata6: SError: { PHYRdyChg DevExch }
[   24.708390] ata6.00: failed command: READ FPDMA QUEUED
[   24.708391] ata6.00: cmd 60/08:00:78:08:c0/00:00:31:00:00/40 tag 0 ncq
dma 4096 in
res 40/00:00:78:08:c0/00:00:31:00:00/40 Emask 0x10
(ATA bus error)
[   24.708397] ata6.00: status: { DRDY }
..

To be sure, i'll buy some news sata cables.

Sorry for the noise and thanks again for having helped me.

Regards,

--
Jacques





>
>

[gentoo-user] Kernel 5.15.11 won't boot

[Neil Bothwick]

I recently upgraded several systems from gentoo-sources-5.10.76-r1 to
5.15.11, using my usual approach

copy current config to new sources
make oldconfig
all modules_install install
run dracut
reboot

All worked well except my desktop, which just sits there showing 

EFI stub: Loaded initrd from command line option

So the bootloader has loaded the kernel but then there is absolutely
nothing. I tried removing the initrd option, but then it went straight to
a blank screen without the above message. I left it for a while, in case
it was just a case of no output, but nothing happened, not disk or
network activity, nothing.

I tried using make olddefconfig instead, but it made no difference. The
old kernel still boots normally. With nothing, literally, to go on, I am
stumped here.

This is my working /proc/cmdline, the only change is in in the version
numbers

initrd=\amd-uc.img initrd=\initramfs-5.10.76-gentoo-r1.img root=LABEL=loon 
rootfstype=btrfs rootflags=rw,noatime,ssd,space_cache rd.shell net.ifnames=0 
nopti init=/lib/systemd/systemd


-- 
Neil Bothwick

Experience is what you get when you didn't get what you wanted.


pgp1fpXTfDWll.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Long boot time after kernel update

[Dale]

Jacques Montier wrote:
> /
> /
>
>
> Le mar. 28 déc. 2021 à 14:03, Jacques Montier  > a écrit :
>
> /
> /
>
>
> Le mar. 28 déc. 2021 à 13:32, Dale  > a écrit :
>
> William Kenworthy wrote:
> > A point to keep in mind - if you can feel the drive moving
> it may be
> > generating errors!  Depending on the drive, the errors may
> just be
> > handled internally and I can see it slowing things down though
> > probably would be barely noticeable.  I have seen it myself with
> > random errors from a WD green drive disappearing when properly
> > immobilised.  When investigating I ran across articles
> discussing the
> > problem, one of which fastened the drives to a granite slab for
> > tests!  Also see discussions on NAS seups and vibrations
> affecting co
> > located drives.
> >
> > BillK
> >
> > ** Interesting read
> >
> https://www.ept.ca/features/everything-need-know-hard-drive-vibration/
> >
>
> This is just because it is a SMR drive.  It's done this ever
> since I
> bought the drive and it has passed all tests.  There's a whole
> thread on
> this dating back several years.  I managed to buy a SMR drive
> before I
> even knew they existed.  Once it fills up that PMR section, it
> gets
> really slow. 
>
> Dale
>
> :-)  :-) 
>
>
> Hello all,
>
> Thanks a lot for all your responses !
> I think this issue is kernel related.
> No problem with 5.10.76-gentoo-r1, but the issue appears
> with 5.15.11-gentoo.
>
> I read on the net that it could be possible to desactivate the
> sata protocol NCQ (Native Command Queuing)
> So, in the grub file, i added the
> ligne GRUB_CMDLINE_LINUX=libata.force=noncq
> Now, all the errors messages are gone and the booting time gets
> down to 24s with the two kernel versions.
> BUT : do you think it could damage or slow down my SSD and HDD disks ?
>
> Thanks again,
>
> Regards,
>
> --
> Jacques
>
>
>
> Me again !
>
> Well, il cleaned my dusty mobo, unplugged and plugged again the sata
> cables.
> Now, with or without NCQ, boot time is rather short (~28s).
> So it seems it was a connection problem.
>
> I still have some errors as :
>
> 
> [   24.708377] ata6.00: exception Emask 0x10 SAct 0x5041 SErr
> 0x401 action 0xe frozen
> [   24.708385] ata6.00: irq_stat 0x00400040, connection status changed
> [   24.708387] ata6: SError: { PHYRdyChg DevExch }
> [   24.708390] ata6.00: failed command: READ FPDMA QUEUED
> [   24.708391] ata6.00: cmd 60/08:00:78:08:c0/00:00:31:00:00/40 tag 0
> ncq dma 4096 in
>                         res 40/00:00:78:08:c0/00:00:31:00:00/40 Emask
> 0x10 (ATA bus error)
> [   24.708397] ata6.00: status: { DRDY }
> ..
>
> To be sure, i'll buy some news sata cables.
>
> Sorry for the noise and thanks again for having helped me.
>
> Regards,
>
> --
> Jacques

It could be that the cable itself is good but just had a dust bunny or
something in the connection.  Once you reseated the cable, it moved the
dust bunny out of the way.  I've done this sort of thing with lots of
connections and not had any trouble afterwards.  I'd suggest unplugging
things, blowing them out with compressed air to remove all the dust and
such and then reconnecting everything and seeing how that works.  No
need throwing out what could very well be perfectly good cables. 

Just a thought.  ;-)

Dale

:-)  :-) 

Re: [gentoo-user] Long boot time after kernel update

[Rich Freeman]

On Tue, Dec 28, 2021 at 8:32 AM Jacques Montier  wrote:
>
> Well, il cleaned my dusty mobo, unplugged and plugged again the sata cables.
> Now, with or without NCQ, boot time is rather short (~28s).
> So it seems it was a connection problem.

Yeah, I've suspected my cables for some of these ATA errors.  I do
feel like SATA is probably a bit lacking in error management, but I
haven't looked into the gory details.

That said, without NCQ the drive should work completely normally but
you may get degraded performance.  The idea of NCQ is that the kernel
can feed the drive multiple instructions at a time, and then the drive
firmware can optimize order of execution to reduce seek time.  The
kernel doesn't know the physical layout of the disk and so if the
commands are executed in strict order the drive may end up seeking in
a non-optimal way, and of course with mechanical drives being what
they are that is very costly.  A bit of controller CPU spent solving
the travelling salesman problem can save a LOT of time waiting for the
disk and heads to move.

One of the bigger changes in NVMe is making the queue vastly larger so
that more operations can be done in parallel.  Obviously there are no
seek times in flash, but I'm not familiar with how the actual
addressing works so there may still be cases where the order of access
matters, or where dispatching instructions in parallel keeps the
pipeline more full.

-- 
Rich

RE: [gentoo-user] Synchronous writes over the network.

[Laurence Perkins]

>> 
>> -Original Message-
>> From: Wols Lists  
>> Sent: Thursday, December 23, 2021 2:29 PM
>> To: gentoo-user@lists.gentoo.org
>> Subject: Re: [gentoo-user] Synchronous writes over the network.
>> 
>> On 23/12/2021 21:50, Mark Knecht wrote:
>> > In the case of astrophotography I will have multiple copies of the 
>> > original photos. The process of stacking the individual photos can 
>> > create gigabytes of intermediate files but as long as the originals 
>> > are safe then it's just a matter of starting over. In my 
>> > astrophotography setup I create about 50Mbyte per minute and take 
>> > pictures for hours so a set of photos coming in at 1-2GB and up to 
>> > maybe 10GB isn't uncommon. I might create 30-50GB of intermediate 
>> > files which eventually get deleted but they can reside on the server 
>> > while I'm working. None of that has to be terribly fast.
>> 
>> :-)
>> 
>> Seeing as I run lvm, that sounds a perfect use case. Create an LV, dump the 
>> files on it, when you're done unmount and delete the LV.
>> 
>> I'm thinking of pulling the same stunt with wherever gentoo dumps its build 
>> files etc. Let it build up til I think I need a clearout, then create a new 
>> lv and scrap the old one.
>> 
>> Cheers,
>> Wol
>> 
>> 

The locations where Portage drops build files, package files, and source 
archives are set in make.conf if you really want to do this.
But the build files get deleted automatically when finished unless there was an 
error or you specifically told Portage not to, and the "eclean" tool will clean 
up the stale things in the other locations without deleting stuff that's 
actually still useful.

LMP

RE: [gentoo-user] Synchronous writes over the network.

[Laurence Perkins]

>> -Original Message-
>> From: Wols Lists  
>> Sent: Thursday, December 23, 2021 9:54 AM
>> To: gentoo-user@lists.gentoo.org
>> Subject: Re: [gentoo-user] Synchronous writes over the network.
>> 
>> > As always I'm interested in your comments about what works or 
>> > doesn't work about this sort of setup.
>> > 
>> My main desktop/server currently has two 4TB drives split 1TB/3TB. The two 
>> 3TB partitions are raid-5'd with a 3TB drive to give me 6TB of /home space.
>> 
>> I'm planning to buy an 8TB drive as a backup. The plan is it will go into a 
>> test-bed machine, that will be used for all sorts of stuff, but it will at 
>> least keep a copy of my data off my main machine.
>> 
>> But you get the idea. If you get two spare drives you can back up on to 
>> them. I don't know what facilities ZFS offers for sync'ing filesystems, but 
>> if you're go somewhere regularly, where you can stash a hard disk (even a 
>> shed down the bottom of the garden :-), you back up onto disk 1, swap it for 
>> disk 2, back up on to disk 1, swap it for disk 2 ...
>> 
>> AND YOUR BACKUP IS OFF SITE!
>> 
>> Cheers,
>> Wol

Data does not exist unless it exists in at least three places.  Assume your 
most recent backup will also have a problem and plan accordingly with regard to 
time and number of copies.

Back in the day the rule of thumb was that whatever losing the data would cost 
you, you should probably spend about a third of that on redundancy.

LMP

RE: [gentoo-user] Synchronous writes over the network.

[Laurence Perkins]

>> -Original Message-
>> From: Rich Freeman  
>> Sent: Thursday, December 23, 2021 9:50 AM
>> To: gentoo-user@lists.gentoo.org
>> Subject: Re: [gentoo-user] Synchronous writes over the network.
>> 
>> On Thu, Dec 23, 2021 at 12:39 PM Mark Knecht  wrote:
>> >
>> > I'll respond to Rich's points in a bit but on this point I think 
>> > you're both right - new SSDs are very very reliable and I'm not overly 
>> > worried, but it seems a given that forcing more and more writes to an 
>> > SSD has to up the probability of a failure at some point. Zero writes 
>> > is almost no chance of failure, trillions of writes eventually wears 
>> > something out.
>> >
>> 
>> Every SSD has a rating for total writes.  This varies and the ones that cost 
>> more will get more writes (often significantly more), and wear pattern 
>> matters a great deal.  Chia fortunately seems to have died off pretty 
>> quickly but there is still a ton of data from those who were speculating on 
>> it, and they were buying high end SSDs and treating them as expendable 
>> resources - and plotting Chia is actually a fairly ideal use case as you 
>> write a few hundred GB and then you trim it all when you're done, so the 
>> entirety of the drive is getting turned over regularly.  People plotting 
>> Chia were literally going through cases of high-end SSDs due to write wear, 
>> running them until failure in a matter of weeks.
>> 
>> Obviously if you just write something and read it back constantly then wear 
>> isn't an issue.
>> 
>> Just googled the Samsung Evo 870 and they're rated to 600x their capacity in 
>> writes, for example.  If you write 600TB to the 1TB version of the drive, 
>> then it is likely to fail on you not too long after.
>> 
>> Sure, it is a lot better than it used to be, and for typical use cases I 
>> agree that they last longer than spinning disks.  However, a ZIL is not a 
>> "typical use case" as such things are measured.
>> 
>> --
>> Rich
>> 
>> 

This is also why the video surveillance industry still uses spinning rust for 
anything beyond a very minimal capacity.  

Rotating drives wear out primarily based on time run as long as you're not 
thrashing the heads all the time by running Windows (Windows 10 seems to have 
given up even trying to optimize read and write on non-SSD media.)

SSD wears out primarily based on write throughput, and anything with a large 
turnover can easily wear one out in a matter of months.

LMP

Re: [gentoo-user] Kernel 5.15.11 won't boot

[Peter Humphrey]

On Tuesday, 28 December 2021 13:40:44 GMT Neil Bothwick wrote:
> I recently upgraded several systems from gentoo-sources-5.10.76-r1 to
> 5.15.11, using my usual approach
> 
> copy current config to new sources
> make oldconfig
> all modules_install install
> run dracut
> reboot
> 
> All worked well except my desktop, which just sits there showing
> 
> EFI stub: Loaded initrd from command line option
> 
> So the bootloader has loaded the kernel but then there is absolutely
> nothing. I tried removing the initrd option, but then it went straight to
> a blank screen without the above message. I left it for a while, in case
> it was just a case of no output, but nothing happened, not disk or
> network activity, nothing.

Did you touch the new frame-buffer settings? I did at first and got something 
like your experience, but then after a distclean and oldconfig, making sure to  
leave the new frame buffer at their defaults, everything now works.

I'll look into how it's supposed to work when I get back home.

-- 
Regards,
Peter.

Re: [gentoo-user] Kernel 5.15.11 won't boot

[Michael]

On Tuesday, 28 December 2021 16:09:09 GMT Peter Humphrey wrote:
> On Tuesday, 28 December 2021 13:40:44 GMT Neil Bothwick wrote:
> > I recently upgraded several systems from gentoo-sources-5.10.76-r1 to
> > 5.15.11, using my usual approach
> > 
> > copy current config to new sources
> > make oldconfig
> > all modules_install install
> > run dracut
> > reboot
> > 
> > All worked well except my desktop, which just sits there showing
> > 
> > EFI stub: Loaded initrd from command line option
> > 
> > So the bootloader has loaded the kernel but then there is absolutely
> > nothing. I tried removing the initrd option, but then it went straight to
> > a blank screen without the above message. I left it for a while, in case
> > it was just a case of no output, but nothing happened, not disk or
> > network activity, nothing.
> 
> Did you touch the new frame-buffer settings? I did at first and got
> something like your experience, but then after a distclean and oldconfig,
> making sure to leave the new frame buffer at their defaults, everything now
> works.
> 
> I'll look into how it's supposed to work when I get back home.

I also ended up with a blank screen followed by a reboot, which showed some 
partitions were not unmounted cleanly, followed by repeated reboots in the 
same fashion, until I interfered to stop this madness.  I then booted with the 
previous kernel and as my first task I disabled some framebuffer setting, which 
I now fail to recall!  LOL!

I think it is this one:
===
CONFIG_DRM_SIMPLEDRM:

DRM driver for simple platform-provided framebuffers.

This driver assumes that the display hardware has been initialized
by the firmware or bootloader before the kernel boots. Scanout
buffer, size, and display format must be provided via device tree,
UEFI, VESA, etc.

On x86 BIOS or UEFI systems, you should also select SYSFB_SIMPLEFB
to use UEFI and VESA framebuffers.

Symbol: DRM_SIMPLEDRM [=n]
Type  : tristate
Defined at drivers/gpu/drm/tiny/Kconfig:54
  Prompt: Simple framebuffer driver
  Depends on: HAS_IOMEM [=y] && DRM [=y]
  Location:
-> Device Drivers
  -> Graphics support
Selects: DRM_GEM_SHMEM_HELPER [=y] && DRM_KMS_HELPER [=y]

Simple framebuffer driver (DRM_SIMPLEDRM) [N/m/y/?] (NEW) 
==


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Kernel 5.15.11 won't boot

[Neil Bothwick]

On Tue, 28 Dec 2021 18:14:51 +, Michael wrote:

> On Tuesday, 28 December 2021 16:09:09 GMT Peter Humphrey wrote:
> > On Tuesday, 28 December 2021 13:40:44 GMT Neil Bothwick wrote:  
> > > I recently upgraded several systems from gentoo-sources-5.10.76-r1
> > > to 5.15.11, using my usual approach
> > > 
> > > copy current config to new sources
> > > make oldconfig
> > > all modules_install install
> > > run dracut
> > > reboot
> > > 
> > > All worked well except my desktop, which just sits there showing
> > > 
> > > EFI stub: Loaded initrd from command line option
> > > 
> > > So the bootloader has loaded the kernel but then there is absolutely
> > > nothing. I tried removing the initrd option, but then it went
> > > straight to a blank screen without the above message. I left it for
> > > a while, in case it was just a case of no output, but nothing
> > > happened, not disk or network activity, nothing.  
> > 
> > Did you touch the new frame-buffer settings? I did at first and got
> > something like your experience, but then after a distclean and
> > oldconfig, making sure to leave the new frame buffer at their
> > defaults, everything now works.
> > 
> > I'll look into how it's supposed to work when I get back home.  
> 
> I also ended up with a blank screen followed by a reboot, which showed
> some partitions were not unmounted cleanly, followed by repeated
> reboots in the same fashion, until I interfered to stop this madness.
> I then booted with the previous kernel and as my first task I disabled
> some framebuffer setting, which I now fail to recall!  LOL!
> 
> I think it is this one:
> ===
> CONFIG_DRM_SIMPLEDRM:

I don't have that one set. About the only framebuffer I have set is
CONFIG_FB_EFI and changing that makes no difference.

I'm not convinced it is display related as I do get the initial message
from the bootloader displayed as normal.

> 
> DRM driver for simple platform-provided framebuffers.
> 
> This driver assumes that the display hardware has been initialized
> by the firmware or bootloader before the kernel boots. Scanout
> buffer, size, and display format must be provided via device tree,
> UEFI, VESA, etc.
> 
> On x86 BIOS or UEFI systems, you should also select SYSFB_SIMPLEFB
> to use UEFI and VESA framebuffers.
> 
> Symbol: DRM_SIMPLEDRM [=n]
> Type  : tristate
> Defined at drivers/gpu/drm/tiny/Kconfig:54
>   Prompt: Simple framebuffer driver
>   Depends on: HAS_IOMEM [=y] && DRM [=y]
>   Location:
> -> Device Drivers
>   -> Graphics support  
> Selects: DRM_GEM_SHMEM_HELPER [=y] && DRM_KMS_HELPER [=y]
> 
> Simple framebuffer driver (DRM_SIMPLEDRM) [N/m/y/?] (NEW) 
> ==


-- 
Neil Bothwick

I wonder how much deeper would the ocean be without sponges.


pgpM291kQNfwv.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Kernel 5.15.11 won't boot

[Michael]

On Tuesday, 28 December 2021 19:23:31 GMT Neil Bothwick wrote:
> On Tue, 28 Dec 2021 18:14:51 +, Michael wrote:
> > On Tuesday, 28 December 2021 16:09:09 GMT Peter Humphrey wrote:
> > > On Tuesday, 28 December 2021 13:40:44 GMT Neil Bothwick wrote:
> > > > I recently upgraded several systems from gentoo-sources-5.10.76-r1
> > > > to 5.15.11, using my usual approach
> > > > 
> > > > copy current config to new sources
> > > > make oldconfig
> > > > all modules_install install
> > > > run dracut
> > > > reboot
> > > > 
> > > > All worked well except my desktop, which just sits there showing
> > > > 
> > > > EFI stub: Loaded initrd from command line option
> > > > 
> > > > So the bootloader has loaded the kernel but then there is absolutely
> > > > nothing. I tried removing the initrd option, but then it went
> > > > straight to a blank screen without the above message. I left it for
> > > > a while, in case it was just a case of no output, but nothing
> > > > happened, not disk or network activity, nothing.
> > > 
> > > Did you touch the new frame-buffer settings? I did at first and got
> > > something like your experience, but then after a distclean and
> > > oldconfig, making sure to leave the new frame buffer at their
> > > defaults, everything now works.
> > > 
> > > I'll look into how it's supposed to work when I get back home.
> > 
> > I also ended up with a blank screen followed by a reboot, which showed
> > some partitions were not unmounted cleanly, followed by repeated
> > reboots in the same fashion, until I interfered to stop this madness.
> > I then booted with the previous kernel and as my first task I disabled
> > some framebuffer setting, which I now fail to recall!  LOL!
> > 
> > I think it is this one:
> > ===
> 
> > CONFIG_DRM_SIMPLEDRM:
> 
> I don't have that one set. About the only framebuffer I have set is
> CONFIG_FB_EFI and changing that makes no difference.
> 
> I'm not convinced it is display related as I do get the initial message
> from the bootloader displayed as normal.

Mine was going blank and then crashing/rebooting at the point when the sddm DM 
was meant to launch.  The openrc boot scripts scrolled by without any problem.  
:-/

This is what I have configured here in case it helps.  Otherwise you could diff 
old/new kernel configs to see if something is standing out.

$ grep 'FB|DRM' /usr/src/linux/.config
# CONFIG_NET_SCH_SFB is not set
CONFIG_SYSFB=y
CONFIG_SYSFB_SIMPLEFB=y
# CONFIG_IFB is not set
CONFIG_DRM=y
# CONFIG_DRM_DP_AUX_CHARDEV is not set
# CONFIG_DRM_DEBUG_MM is not set
CONFIG_DRM_KMS_HELPER=y
CONFIG_DRM_FBDEV_EMULATION=y
CONFIG_DRM_FBDEV_OVERALLOC=100
# CONFIG_DRM_LOAD_EDID_FIRMWARE is not set
# CONFIG_DRM_DP_CEC is not set
CONFIG_DRM_TTM=y
CONFIG_DRM_TTM_HELPER=y
# CONFIG_DRM_I2C_CH7006 is not set
# CONFIG_DRM_I2C_SIL164 is not set
# CONFIG_DRM_I2C_NXP_TDA998X is not set
# CONFIG_DRM_I2C_NXP_TDA9950 is not set
CONFIG_DRM_RADEON=y
CONFIG_DRM_RADEON_USERPTR=y
# CONFIG_DRM_AMDGPU is not set
# CONFIG_DRM_NOUVEAU is not set
# CONFIG_DRM_I915 is not set
CONFIG_DRM_VGEM=m
# CONFIG_DRM_VKMS is not set
# CONFIG_DRM_VMWGFX is not set
# CONFIG_DRM_GMA500 is not set
# CONFIG_DRM_UDL is not set
# CONFIG_DRM_AST is not set
# CONFIG_DRM_MGAG200 is not set
# CONFIG_DRM_QXL is not set
# CONFIG_DRM_VIRTIO_GPU is not set
CONFIG_DRM_PANEL=y
CONFIG_DRM_BRIDGE=y
CONFIG_DRM_PANEL_BRIDGE=y
# CONFIG_DRM_ANALOGIX_ANX78XX is not set
# CONFIG_DRM_ETNAVIV is not set
# CONFIG_DRM_BOCHS is not set
# CONFIG_DRM_CIRRUS_QEMU is not set
# CONFIG_DRM_GM12U320 is not set
# CONFIG_DRM_SIMPLEDRM is not set
# CONFIG_DRM_VBOXVIDEO is not set
# CONFIG_DRM_GUD is not set
# CONFIG_DRM_LEGACY is not set
CONFIG_DRM_PANEL_ORIENTATION_QUIRKS=y
CONFIG_FB_CMDLINE=y
CONFIG_FB_NOTIFY=y
CONFIG_FB=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
CONFIG_FB_SYS_FILLRECT=y
CONFIG_FB_SYS_COPYAREA=y
CONFIG_FB_SYS_IMAGEBLIT=y
# CONFIG_FB_FOREIGN_ENDIAN is not set
CONFIG_FB_SYS_FOPS=y
CONFIG_FB_DEFERRED_IO=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
# CONFIG_FB_UVESA is not set
# CONFIG_FB_VESA is not set
CONFIG_FB_EFI=y
# CONFIG_FB_N411 is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_OPENCORES is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_I740 is not set
# CONFIG_FB_LE80578 is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CO

[gentoo-user] SD memory card not erasing, even with dd.

[Dale]

Howdy,

As some may recall, I have quite a few deer trail cameras that use SD
memory cards.  On occasion some of the cards start acting weird.  I've
got one that is really weird.  Usually I just replace them but this one
is a bit of a puzzle I'd like to solve.  When it stopped working, it had
a dozen or so short videos on it that are about 30MBs on average.  Some
color and large, some black and white night vision and fairly small. 
When it stopped working, I tried to reformat the thing.  The files
remained even after that.  I then ran dd and zeroed the thing, files
still there even tho dd reported no problems.  I then used this GUI disk
program that tests memory cards and it claims the card is fine.  It
writes files to it, reads them back.  I also used it to reformat the
card.  The original videos are still there.  Today I decided to play
with it again.  I ran this dd command on the stick. 


root@fireball / # dd if=/dev/zero of=/dev/sdh bs=4K conv=notrunc
oflag=direct status=progress
31907364864 bytes (32 GB, 30 GiB) copied, 3956 s, 8.1 MB/s
dd: error writing '/dev/sdh': No space left on device
7791745+0 records in
7791744+0 records out
31914983424 bytes (32 GB, 30 GiB) copied, 3956.94 s, 8.1 MB/s
root@fireball / #


As you can see, no errors. It wrote zeros until it ran out of space. 
Guess what, the original videos are still on the card.  File listing:


root@fireball / # ls -al /run/media/dale/2140-2E00/DCIM/100MEDIA/*
-rw-r--r-- 1 dale users    0 May  6  2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/.AAA
-rw-r--r-- 1 dale users    0 May  6  2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/.BBB
-rw-r--r-- 1 dale users 14335272 May  2  2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0823.AVI
-rw-r--r-- 1 dale users 50843576 May  6  2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0824.AVI
-rw-r--r-- 1 dale users 53137560 May  6  2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0825.AVI
-rw-r--r-- 1 dale users 18398504 May  6  2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0826.AVI
-rw-r--r-- 1 dale users 18922808 May  6  2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0827.AVI
-rw-r--r-- 1 dale users 18332888 May  6  2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0828.AVI
-rw-r--r-- 1 dale users 18726200 May  6  2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0829.AVI
-rw-r--r-- 1 dale users 18332920 May  6  2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0830.AVI
-rw-r--r-- 1 dale users 18005288 May  6  2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0831.AVI
-rw-r--r-- 1 dale users 17612088 May  6  2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0832.AVI
-rw-r--r-- 1 dale users 17153336 May  6  2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0833.AVI
-rw-r--r-- 1 dale users 16694584 May  6  2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0834.AVI
-rw-r--r-- 1 dale users    0 May  6  2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0835.AVI
root@fireball / #



The zero byte files are broken, my first clue way back that the card
needed replacing.  I see no errors in dmesg or messages.  Usually the
cards produce errors and it remounts read only.  Not in this case tho. 
Mount info:


root@fireball / # mount | grep sdh
/dev/sdh1 on /run/media/dale/2140-2E00 type vfat
(rw,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
root@fireball / #



In the past, I've at times been able to copy the files off other cards
going bad but it stays read only.  Reformating fails etc etc. 
Sometimes, it just plain doesn't work.  Almost always tho I get a error
of some kind in messages or dmesg if not both.  This one tho, it's just
plain weird.  No errors but nothing removes the files either.  Oh, I've
checked the lock button.  It's not locked.  It is shown that way in
dmesg as well. 


[2592841.808336] sd 10:0:0:2: [sdh] Write Protect is off



Obviously I'm not going to trust this thing.  It will end up in the
trash but, does this make sense to anyone else?  Of all the ones I've
worn out, this is the only one that behaves this way.  I'd at least
expect the format to fail or it only mount read only.  At least some
sort of error anyway. 

Thoughts?

Dale

:-)  :-) 

Re: [gentoo-user] Ktorrent using a lot of memory recently

[Dale]

computers with nikita nikita wrote:
> I dont use Ktorrent, While what you are describing sounds like a
> memory leak,
> have you considered it could be the active downloads connecting to a
> large number of peers? Or it could be it building a very large dht
> index (not sure what the proper terminology for this is)
>
> You should double check your settings and make sure everything has
> sane limits
>

I've been playing with this a bit before replying.  There's not many
options with ktorrent.  I did find a older version of libtorrent tho.  I
downgraded to that.  It still increases at times but then seems to
return a more normal amount.  It does act strange still but not as bad
as it was.  I think you have the right idea tho.  It does seem to be a
memory leak somewhere. 

I'll keep playing with this some more and post if I come up with anything. 

Thanks for the help.

Dale

:-)  :-) 

[gentoo-user] Re: Kernel 5.15.11 won't boot

[Remy Blank]

Neil Bothwick wrote on 28/12/2021 14:40:
> So the bootloader has loaded the kernel but then there is absolutely
> nothing. I tried removing the initrd option, but then it went straight to
> a blank screen without the above message. I left it for a while, in case
> it was just a case of no output, but nothing happened, not disk or
> network activity, nothing.

You could try adding the following to the kernel command-line:

earlyprintk=efi,keep earlycon=efifb

It allows seeing the early kernel output on the EFI framebuffer. It's 
exceedingly slow, but at
least you might see what's going wrong.

-- Remy

Re: [gentoo-user] Ktorrent using a lot of memory recently

[ny6p01]

If a tool is not working the way it should I chuck it and find one that
does. There are many good torrent apps out there.


Lee 😎

On Dec 28, 2021 at 12:28 PM, Dale  wrote:

computers with nikita nikita wrote:
> I dont use Ktorrent, While what you are describing sounds like a
> memory leak,
> have you considered it could be the active downloads connecting to a
> large number of peers? Or it could be it building a very large dht
> index (not sure what the proper terminology for this is)
>
> You should double check your settings and make sure everything has
> sane limits
>

I've been playing with this a bit before replying.  There's not many
options with ktorrent.  I did find a older version of libtorrent tho.  I
downgraded to that.  It still increases at times but then seems to
return a more normal amount.  It does act strange still but not as bad
as it was.  I think you have the right idea tho.  It does seem to be a
memory leak somewhere.

I'll keep playing with this some more and post if I come up with anything.

Thanks for the help.

Dale

:-)  :-)

Re: [gentoo-user] Ktorrent using a lot of memory recently

[computers with nikita nikita]

I recommend qbittorrent (its qt so it should theme nicely with kde), it
works really well IMO

On Tue, Dec 28, 2021 at 2:09 PM ny6p01  wrote:

> If a tool is not working the way it should I chuck it and find one that
> does. There are many good torrent apps out there.
>

Re: [gentoo-user] Ktorrent using a lot of memory recently

[Dale]

computers with nikita nikita wrote:
> I recommend qbittorrent (its qt so it should theme nicely with kde),
> it works really well IMO
>
> On Tue, Dec 28, 2021 at 2:09 PM ny6p01  > wrote:
>
> If a tool is not working the way it should I chuck it and find one
> that does. There are many good torrent apps out there.
>


I'm happy with Ktorrent.  I just want to figure out why it is using so
much memory.  I did look at qbittorrent tho, screenshots anyway.  It
seems to work the same way and even looks the same as Ktorrent.  Given I
have Ktorrent already set up and a lengthy list of files for it to
download, I'm not really wanting to switch.  If I can't figure out the
memory leak or it gets worse, I may have to switch later on. 

Question just in case I do have to switch.  I click on links in Firefox
to download torrents.  Right now it opens the files/imports/whatever to
Ktorrent.  Can I do the same with qbittorrent?  From the looks of it, I
suspect it works that way, and suspect other GUI software does as well. 

Thanks.

Dale

:-)  :-) 

Re: [gentoo-user] Ktorrent using a lot of memory recently

[computers with nikita nikita]

Yes, you can open magnet links directly from your browser using qbittorrent,

I hope you'll be able to solve the memory leak though, good luck

On Tue, Dec 28, 2021, 5:40 PM Dale  wrote:

> computers with nikita nikita wrote:
> > I recommend qbittorrent (its qt so it should theme nicely with kde),
> > it works really well IMO
> >
> > On Tue, Dec 28, 2021 at 2:09 PM ny6p01  > > wrote:
> >
> > If a tool is not working the way it should I chuck it and find one
> > that does. There are many good torrent apps out there.
> >
>
>
> I'm happy with Ktorrent.  I just want to figure out why it is using so
> much memory.  I did look at qbittorrent tho, screenshots anyway.  It
> seems to work the same way and even looks the same as Ktorrent.  Given I
> have Ktorrent already set up and a lengthy list of files for it to
> download, I'm not really wanting to switch.  If I can't figure out the
> memory leak or it gets worse, I may have to switch later on.
>
> Question just in case I do have to switch.  I click on links in Firefox
> to download torrents.  Right now it opens the files/imports/whatever to
> Ktorrent.  Can I do the same with qbittorrent?  From the looks of it, I
> suspect it works that way, and suspect other GUI software does as well.
>
> Thanks.
>
> Dale
>
> :-)  :-)
>
>