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.
Well, this answers preemptively what was going to be my next question!
For the record, I was going to ask if you include the nvidia module in your initrd. (I don't, I just allow the system to load it normally during boot-up.)
Given that it behaves the same with or without nvidia, I'm at a loss. I guess the only other avenue I can think of to explore would be to try to find out if other users who are experiencing the blank-screen problem are also on Ryzen hardware...
... 5.15.x kernels boot just fine but v304 (and a sketchy 340) drivers (needed for the old Quadro FX570 chip) won't build for me on 5.15.x.
Check this post for info on how I got the nvidia-legacy304 to compile on -current. (A couple of posts above that one, Mats B Tegner describes what he has been doing for legacy340.)
I poked the kernel devs with some additional information about the boot failure with 32-bit on my Thinkpad X1E... I'd found that EFI_SOFT_RESERVE y -> n allows the kernel to boot. Simply using EFI y -> n isn't an option because it causes hardware support breakage on 32-bit under UEFI, even in legacy boot mode. I started with that hatchet job, but then narrowed it down.
Seems I inadvertently discovered that the patch I'd been reverting here breaks mem= on all $ARCH.
I certainly have their attention now... should be some action on this soon. The issue would only have been noticed with a 32-bit kernel on machines that required a certain mem= setting in order to boot.
Check this post for info on how I got the nvidia-legacy304 to compile on -current. (A couple of posts above that one, Mats B Tegner describes what he has been doing for legacy340.)
Thanks JayBird. I may have to try that. I'm happy with kernel version 5.4.164 and I've got nvidia 340.108 installed and running with the only caveat that at the native resolution of T61P's TFT panel everything seems shifted off screen somewhat to the right and possibly "up". My Panel, at top screen was working yesterday but today I can't see it at all anywhere and "Add Panel" does nothing. So it is entirely possible the newer xorg server is a tad hinky with old hardware and Legacy nvidia drivers.
... So it is entirely possible the newer xorg server is a tad hinky with old hardware and Legacy nvidia drivers.
According to this, xserver 1.20 that ships with -current should be good to go...
Quote:
Support for X.Org xserver version 1.20 was added to the 340.* legacy driver series with version 340.107, and support for Linux kernels up to Linux 5.4 was added with version 340.108.
everything seems shifted off screen somewhat to the right and possibly "up".
Seen also with xf86-video-vmware - xf86-input-mouse - runlevel 4 - xdm - xinitrc.blackbox
Mouse cursor position on the display does not match the input position, so the button opens a menu lower-rigth of the input position.
I poked the kernel devs with some additional information about the boot failure with 32-bit on my Thinkpad X1E... I'd found that EFI_SOFT_RESERVE y -> n allows the kernel to boot. Simply using EFI y -> n isn't an option because it causes hardware support breakage on 32-bit under UEFI, even in legacy boot mode. I started with that hatchet job, but then narrowed it down.
Seems I inadvertently discovered that the patch I'd been reverting here breaks mem= on all $ARCH.
I certainly have their attention now... should be some action on this soon. The issue would only have been noticed with a 32-bit kernel on machines that required a certain mem= setting in order to boot.
Seen also with xf86-video-vmware - xf86-input-mouse - runlevel 4 - xdm - xinitrc.blackbox
Mouse cursor position on the display does not match the input position, so the button opens a menu lower-rigth of the input position.
FWIW my mouse position seems fine but even the splash screen is offset to the right. I normally set my panel/launchbar at the top of screen but it soon disappears. My mouse hits a hard edge at screen top but appears to travel below screen and right screen. I seem to recall that something like xrandr can resize it but until I find out what is the source cause I get by with a widget on Desktop.
This only happens on my ancient T61P laptop which I rarely use, but it is usable, if a bit annoying, (it seems backward compatibilty's days are numbered) and all my full PCs work a treat with RC2.
So... Will these patches land in 5.16.0 only or be back ported to 5.15.8 or 5.15.9?
I have Greg KH on cc:, so I guess we'll see. If they don't land in -stable soon I'll just disable EFI_SOFT_RESERVE on 32-bit since it's useless there anyway.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,139
Original Poster
Rep:
Year 2021, Round 82
Another batch of updates has been scheduled for release on Wednesday, 15 December 2021, at approximately 09:00, GMT. If no problems are found while testing the release candidates, they might be available sometime on Tuesday (depending on your time zone).
I have Greg KH on cc:, so I guess we'll see. If they don't land in -stable soon I'll just disable EFI_SOFT_RESERVE on 32-bit since it's useless there anyway.
Code:
Lemme send them out officially so they're on the list. Will queue them
this week.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
The issue would only have been noticed with a 32-bit kernel on machines that required a certain mem= setting in order to boot.
