Hum, i’m not the person that has give this solution.
It was given here 
1 Like
I have read about the new kernel 7.1 RC4.
Perhaps will all the driver problems solved with it ?
Here is the link : https://www.linuxcompatible.org/story/linux-kernel-71-rc4-released/
1 Like
I tried to add the parameter initcall_blacklist=sysfb_init and the results is:
The screen stucks here. I can listen as the SSD was loading (maybe) but the screen don’t change. And is impossible open a TTY with Ctrl + Alt + Fx.
I turned to 6.19.12 and removing the initcall_blacklist=sysfb_init.
Regards
How long did you wait? The screen won’t be updated until the driver is fully loaded and your system is up. It can take a while. Are you having Disk Encryption enabled?
@Zlinux1 > Hum, i’m not the person that has give this solution.
It was given here
First person on this thread to mention it which helped a few people.
@ZlInux1: have read about the new kernel 7.1 RC4.
Perhaps will all the driver problems solved with it ?
Maybe but since this issue doesn’t seem to affect other distros quite possibly not.
But there is always hope 
1 Like
Some minutes. I don’t use encryption.
I made a susepaste ot the sudo journalctl -k -b with the initcall_blacklist=sysfb_init parameter:
https://paste.opensuse.org/pastes/672e2e2311fb
Regards
There are more than 4 minutes here
may 19 11:29:21 Linux kernel: blacklisting initcall sysfb_init
...
may 19 11:29:33 Linux kernel: BTRFS info (device nvme1n1p2): qgroup scan completed (inconsistency flag cleared)
may 19 11:33:42 Linux kernel: Ethtool ioctl interface doesn't support passing EEE linkmodes beyond bit 32
may 19 11:33:42 Linux kernel: Ethtool ioctl interface doesn't support passing EEE linkmodes beyond bit 32
may 19 11:33:43 Linux kernel: kauditd_printk_skb: 209 callbacks suppressed
may 19 11:33:43 Linux kernel: audit: type=1305 audit(1779183223.099:398): op=set audit_pid=0 old=1390 auid=4294967295 ses=4294967295 subj=unconfined res=1
may 19 11:33:43 Linux kernel: audit: type=1305 audit(1779183223.117:399): op=set audit_enabled=0 old=1 auid=4294967295 ses=4294967295 subj=unconfined res=1
may 19 11:33:43 Linux kernel: BTRFS info (device nvme0n1p1): last unmount of filesystem 487628b1-af84-4d17-952f-8f4bcdefdb03
may 19 11:33:43 Linux kernel: BTRFS info (device sdb1): last unmount of filesystem 7ee27332-f06c-43d7-8c39-ecd847a78e12
and the system has not reached [drm] activation yet, where the display should start showing what is going on again…
Cannot say if that is a BTRFS problem or a network problem (Ethtool) or whatever.
Strange suse developer do nothing to fix it! Previously such problems were solver in 1-3 days, now it is 3 weeks already.
I think it’s not a problem from suse developers.
It’s a general problem with kernel 7.0.X
I have in use Ubuntu on my machine with kernel 7.0.0.15 and Ubuntu has not given a new kernel for the moment.
On suse, we have a new kernel 7.0.7 that not work with the nvidia driver properly but … we have news !
We can only wait on a new kernel (perhaps 7.1) in the next days
@akontsevich I understand your frustrations with your hardware, however remember for some it’s the end of the school year, summer holidays etc (well here in the US), likewise other life and/or work priorities.
It for sure is a strange issue (I’m not affected with my Quadro RTX 4000), to me it’s not an Nvidia driver issue but a kernel one, also do you expect the Mainatiners to have all the same hardware etc to test on so it may take time to debug…
3 Likes
Yeah in addition to everything Malcolm said, unfortunately this problem only seems to be affecting a (reasonably) small number of people, and while there have been some worthwhile ideas and tests that people have done in the bugzilla report and some temporary fixes in this forum, I’m not sure if we’ve even managed to narrow down the true cause of it yet. And since they can’t duplicate the bug due to it only affecting a smaller number of setups, none of which seem to have any defining common trait beyond “Nvidia” it is increasingly difficult to fix compared to other issues
1 Like
Agree, feel the same, however I have not observed suse kernel maintainers even started to look into it - they just keep releasing new kernels with no corrections, configurations, or fixes.
Let me start by saying that this isn’t a criticism (or at most, it’s a constructive one, or tries to be). Although I really appreciate Tumbleweed - which I adopted a couple of years ago after quite a bit of distro-hopping - in hindsight, it might not have been the best idea to choose a distro with so few users (relatively speaking, of course) and (probably, though I don’t know for sure) maintainers, who I’m sure are doing their best and deserve nothing but thanks and credit.
After several years with Linux, I’ve come to the conclusion that it might be better to go with a mainstream distro (even if it’s not perfectly tailored to your needs) rather than more niche ones, unless you’re willing to find yourself in situations like this, not even knowing if a solution will be found (which might just happen ‘by chance’ with a future kernel and/or driver update, rather than a direct fix for that specific bug).
Honestly, if I didn’t have a system that is now perfectly tuned to my needs - including as a developer - and on which I’ve spent dozens and dozens of hours customizing, with this newfound awareness I would probably switch to something else, though it would be with regret.
3 Likes
I’m on SUSE since 2000-2003 I think: always was the most user friendly with its Yast (on Ubuntu need to do everything from CLI), reliable and stable (like Deutch cars from the 90s. ) including TW with the most recent software. Recent time only such Nvidia problems breaks this reliability impression. Probably it does make sense to buy AMD GPU next time (I used to times when Nvidia was the only choice for Linux).
So think such changes when
- developers become less responsive to user problems (why this forum was created if developers do not read and participate in it
) - refusing to use non-integrated and very strange tools like Cockpit and Myrlyn, instead of Yast.
- a lot of packages are outdated (which is very strange for TW) and need to ask to update each package version then to wait months for the update
- worse testing (is it a problem to buy 3050 or similar card )
All of these is a wrong direction, as it contradicts to what attracted users to SUSE, and in particular, to TW, previously.
1 Like
User to user support is a thing, and is primarily the purpose of this forum. You don’t always need (or want) a developer to diagnose end-user issues, and allowing developers to stay focused on development issues is important to ongoing development. The vast majority of issues discussed here do not require a developer be involved, as they are configuration issues or user education issues.
But these questions are off-topic for this particular discussion, so let’s stay focused on the topic at hand here, which is gathering information to make it easier to diagnose this particular issue.
4 Likes
The main advantage of open source always was is that you can communicate directly with developers! Otherwise, it is a closed proprietary system.
That doesn’t mean the developers are everywhere the users are. If you’ve been around the openSUSE project as long as you say, you know where to find the developers to have a discussion with them.
But again, this is not on topic for this discussion, so let’s bring this back to the actual topic here.
3 Likes
I am just an advanced user and have no (deep) knowledge of the OS itself. So how am I supposed to find possible cause for the actual problem ? The only thing I could find so fare is that it must have something to do with the kernel upgrade from 6.x to 7.x and that the issue seems only happen on systems with nVidia graphic cards. The problem seems not to be connected to the nVidia driver version as G06 (580.x.x) and G07 (595.x.x) are effected.
- What has changed in the new kernel ? Who really has an overview ?
- Who has the knowledge and the environment to test specific kernel configurations/parameters?
- Is it really such a small number of effected systems ?
- Are other distributions (e.g. Fedora 44) also facing issues ?
From my point of view only someone with a profound knowledge of the kernel is able to understand the changes in 7.x and which of them could cause the actual problem.
I think most of us are willing to help if someone can tell us (me) what should be tested or which information is needed. My main question is how to proceed ?
initcall_blacklist=sysfb_initis, at least for me, a workaround and not a fix.
Has anyone contact to the kernel maintainers of openSUSE tumbleweed ?
3 Likes