SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: Slackware64 15.0 (started with 13.37). Testing -current in a spare partition.
Posts: 935
Rep:
Quote:
Originally Posted by GazL
I've been using the "legacy" EFIFB until now, but with this option showing up in 5.15 I decided to give the simplefb a shot.
If you do set CONFIG_SYSFB_SIMPLEFB=y, make sure you also select its driver (CONFIG_DRM_SIMPLEDRM=y), otherwise you might end up without a framebuffer at all.
I haven't decided whether I'll stick with this or go back to using EFIFB. inteldrm takes over when it loads anyway, so it likely makes little difference either way.
Does "otherwise you might end up without a framebuffer at all" mean blank screen through all boot until login prompt?
That's why I had to login in the dark. X session loaded ok but crt+alt+F2 was blank too.
I will rebuild with CONFIG_DRM_SIMPLEDRM=y to see if the delay goes away.
Does "otherwise you might end up without a framebuffer at all" mean blank screen through all boot until login prompt?
Well, until something else takes over the framebuffer. So, yes. I think that's likely.
That said, I only read up on it this morning while trying to figure out what the correct setting was for this new option, so take that for what it is. I could be wrong.
Distribution: Slackware64 {15.0,-current}, FreeBSD, stuff on QEMU
Posts: 462
Rep:
Quote:
Originally Posted by GazL
I've been using the "legacy" EFIFB until now, but with this option showing up in 5.15 I decided to give the simplefb a shot.
If you do set CONFIG_SYSFB_SIMPLEFB=y, make sure you also select its driver (CONFIG_DRM_SIMPLEDRM=y), otherwise you might end up without a framebuffer at all.
I haven't decided whether I'll stick with this or go back to using EFIFB. inteldrm takes over when it loads anyway, so it likely makes little difference either way.
I had a chance to do a little testing (one computer with Intel onboard graphics, one with an AMD video card), and it seems that any one of these three solutions will get rid of the stall and/or black screen:
If SYSFB_SIMPLEFB=y and DRM_SIMPLEDRM=m, add simpledrm to initrd to load the module (working for me)
Use SYSB_SIMPLEFB=y and DRM_SIMPLEDRM=y (almost certainly OK, based on what happens when the simpledrm module is actually loaded)
Use SYSB_SIMPLEFB=n (not yet confirmed, but that's how it was in 5.14.x, so I assume it'll work)
I'll probably just turn the simple framebuffer off next time since it doesn't have any penguins.
With current moving to kernel 5.15.0 today, I see Pat has defaulted to preemption mode "voluntary". On the previous kernel 5.14.15 the default is "none". I read that "voluntary" is good for desktops and "none" is good for servers.
Is it recommended to append "preempt=none" in the kernel parameters for servers running -current or does "voluntary" do the same thing if a desktop is not in use?
Quote:
> Thu Nov 4 04:43:31 UTC 2021
...
> k/kernel-source-5.15.0_smp-noarch-1.txz: Upgraded.
> We'll be using 5.15.x in the 15.0 release, and it's working well here, so
> let's just start it right out in the main tree rather than in /testing.
> The primary differences with the previous (5.14.15) kernel:
> The default preemption mode is changed to "voluntary".
> Added CONFIG_CEC_GPIO=m (thanks to LuckyCyborg).
If latency is not a concern then preempt=none should give you slightly better overall throughput as the kernel will never interrupt itself. Whether the difference will be noticeable or not will likely depend on the characteristics of your servers workload.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,166
Original Poster
Rep:
Just installed the 5.15.0 kernel from the latest -current and it still has a blank screen for 6 to 8 seconds after the BIOS check (using lilo).
Everything else works as it should.... so far.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,166
Original Poster
Rep:
Year 2021, Round 75
Another batch of updates has been scheduled for release on Saturday, 06 November 2021, at approximately 14:00, GMT. If no problems are found while testing the release candidates, they might be available sometime on Friday (depending on your time zone).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
-> Slackware 15.5
