570 release feedback & discussion

Oh, now I’m finally getting a reaction :)
I would have preferred the professional way and getting response to my emails, but if I have to make a lot noise in the public eye, so shall be it :p

I know, and you’re lucky that this still works as you expect it. (until module loader will be rewritten …)

As already mentioned long ago, that is the actual problem.
This whole idea is very fragile and causing a lot of extra work to prevent this evaporating in free fall.
A slight change in some struct or function prototype makes the whole thing explode. And we do have those changes across ABI major versions.

Do you really expect us to carry tons of technical debt for all eternity just because you don’t want to compile your driver properly ?

Come one, it’s so simple: just compile the driver against the several ABI versions separately. It’s just two .so’s that have to be shipped in several per-ABI builds.
For all practical purpose, you only need 23.x, 24.x and upcoming 25.x. Three different CI jobs really can’t be such a big deal.
And once you’re already there, you could also set some more jobs that are building actual distro packages instead of this weird “installer”.
This is just a few days of work. If I had access to the source code, I already would have done this long ago.

You’d do everybody a huge favor. 90% of the hassles people have with it on daily basis would be just gone.
Do you need an DevOps coaching ? Feel free to call me ;-)

15 years ago. And the DevPrivateKeyRec changed back then, so you must recompile anyways - otherwise you’ll end up with out-of-bounds writes.
Crazy.
Those kind of changes happen over and over.

Are you really reviewing all commits for such issues and take specific actions in your driver ? Seriously ?

Oh, and didn’t you want to clean up this old stuff anyways ?

And why didn’t you just copy over the obsolete mi-overlay code that I had to reintroduce just for you in the latest driver release ?
Do you really expect us unpaid volunteers to do your work ?
Do you really think that is fair ?

NVidia made 44 BILLIONS (!) net profit this year. Don’t tell me there’s no room for hiring some experts for few month to clean up all that mess once and for all.

I really hope so !
But still this causes trouble for us, upstream: we just have now idea what you really need.

If you just would look through the MRs that are already laying around for long time.
I’ve spent so much time for making those changes like unexporting symbols or dropping dead code in small and
easily digestable commits, to make it easy for you, so you can just look the subject list. It still didn’t help :( :( :(

I’m on the brink of killing all support for NVidia and announcing people shouldn’t stop buying Nvidia,
because I’m really sick of making workarounds for your mess - for free.
I’m just sick of having a mega corporation with 44 Billions profit, that’s probably spending more for toilet paper
than for driver development, shifting work on unpaid volunteers.

Frankly, I cannot understand these crazy corporate politics at all. NVidia is the most hated corporation (even more than Microsoft)
in FOSS community - because their drivers are so bad, always have been. Torvalds once told it loud and clearly.
Keeping source code secret is bad and expensive enough. But then there at least should be some professional cooperation
with the community, so we can make the products actually work, reliably, for professional/industrial environments.

What is the most powerful GPU practically worth, when one just cannot use it reliably ?

Quite my only reason for caring about Nvidia at all is the multi-port cards, because my clients having huge
screen walls. Maybe I just should tell them to use a bunch of cheap chinese cards and revive Xinerama.

That’s still more than 10 years old.

I happen to be one of the folks who’re called for maintaining really old legacy stuff (sometimes even reviving or fixing
ancient PL/M code), but I haven’t seen such ancient Xserver, running on non-ancient Nvidia hardware in the field.
Don’t get me wrong, I really honor anybody maintaining old tech - there should be more of this.
BUT: those installations are frozen, they don’t get upgrades ever, just - if necessary - minor bug fixes.
They obvious solution is branches.

Which version exactly ?
(Do you meanwhile have nightly build against master and incubate branches ?)

And then how do you even get those old symbols that aren’t even existing anymore ?
You must have your own prototypes somewhere, that’s how C works.

I’m now making a last attempt to get into active cooperation. Please respond to my mails, and let’s get the stuff fixed together.
Next release is scheduled for summer solstice. I really wish to have the nvidia driver bugs fixed here, but I can’t do that
without your cooperation. If I don’t get it, there can’t be any Nvidia support anymore.

Let’s cooperate instead of working against each other.

3 Likes

Dont be sorry, this is amazing feedback and superb questions. I appreciate your help a lot. I need to finish a project between this week and next and then I can format the computer and here is what I will do:

  1. Install Ubuntu 24.04 (I am in 25.04 on both computers).
  2. On the 4090 PC I will install 565 only. On the 5090 I will install 570 or if 575 is available at that moment then 575.
  3. I will test the games you mentioned and if by chance Indiana Jones is on sale then that one as well
  4. Report my findings here to see where the issue lies.

@metux while what you are saying makes perfect sense (as far as I can tell), I don’t think @aplattner deserves to be attacked personally. Almost everyone on this forum is sick and tired with Nvidia’s policies and general attitude towards its customers (especially desktop Linux ones), but I don’t think any of the few engineers active here has a power to do anything about it. Let’s all try to keep a friendly tone towards each other, so it’s easier to achieve solutions to technical problems: Nvidia’s corporate behavior makes it difficult enough already.

@aplattner @amrits lack of communication is something that has been mentioned several times by several ppl on this forum as well as elsewhere on the internet. I understand that you folks are probably extremely understaffed (again courtesy of Nvidia), but if there’s one thing you could prioritize more, that should be communication. Especially if a core Xorg engineer is trying to reach you to fix stuff together ;-)

Thank you all for your work!!

4 Likes

Sorry if this has been misunderstood. I’m not attacking him personally.
Instead his superiors. I’m assuming they’ve got some weird policy of prohibiting engineers to talk to outside people.

Probably not. But I’d assume driver maintainer has at least the power to fix some really weird things, especially if they’re easy and don’t take much time. If not, who else does ?

3 Likes

If you want to test pure VK games, then there is Wolfenstein II New Colossus, Baldur’s Gate 3 (you need to specify VK in launcher), Sniper Elite 5 and Doom Eternal. Beign older games they are often available cheap during sales. Indiana Jones is of course the hardest on the GPU, due to the textures.

Note that for all of them (except Sniper Elite 5) you need to add __GL_13ebad=0x1 to your %command% (otherwise there is yet another bug that crushes performance).

Let’s not forget that in big companies/organisation, direct communication with external people may be restricted/regulated. They may not be free to disclose everything regarding fixes, schedules, etc due to liabilities.

That said I notice much more communication than a few months ago.

6 Likes

With what app I get the overhead display in Ubuntu?

Thank you.

Hi @vrachatte , thanks for reaching out, and sorry for the late reply. Yes, I’m still facing it, but I advanced a little further on the investigation. What actually happens is: if I boot up on battery, the Acer and Fedora logos appear on the internal display and the spinner goes on for a short while, but then it freezes; however, if I plug in an external monitor to the HDMI port (which is wired to the GTX 1650 dGPU), I can see that the system is actually up and running, but only on the external display. If I login and open GNOME display settings, I can see that the internal display isn’t even recognized.

BTW I just tested this on latest driver 575.57.08, and it is reproducible.

This is how internal display stays:

I’m attaching below the nvidia-bug-report output for this last attempt, let me know if I can provide any additional info.
nvidia-bug-report.log.gz (739.4 KB)

Thanks a lot for these data points, I have created internal bug 5176385 to track this issue, we shall keep you posted on progress.

3 Likes

You’re welcome! Keep in mind that this odd behavior only happens when booting on battery (which has already put me in some difficult situations – I simply cannot boot the laptopt if the charger is not around). However, unplugging the charger and/or the external monitor after the system booted successfully (charging) works as expected, so it is something specific to the boot process.

On a positive note: my suspend problems seem to be gone! 🎉🙏 Many times it takes a “long” time (15-20s) to suspend, which is slightly annoying, but still infinitely better than not being able to suspend most of the times.

Thank you. Do note, I noticed that the GPU usage was stuck around with 50% during the recording (You can see it at the top right corner using MangoHUD). So take that into account but it could be a Proton issue, Steam issue or an Nvidia driver issue. Just to be objective.

Hi @andre.ocosta ,

Given that your internal display is controlled by the AMD iGPU, could you try uninstalling the NVIDIA driver and see if the issue with the internal display persists?

Hi @metux,

First, I want to apologize for not being responsive to your freedesktop.org merge requests lately. I’ll do my best to provide quicker responses in the future.

It might help if I clarify exactly how we build nvidia_drv.so and how it handles supporting different versions of Xorg in a single binary:

  • The core code that interfaces with the rest of the graphics driver components doesn’t use any Xorg headers at all. This includes stuff like initializing and tearing down GPUs, translating rendering requests into GPU commands, and handling synchronization of direct-rendering clients such as GLX and Vulkan.

  • The rest of the code that talks to the Xorg server is built multiple times, once for each supported ABI version. This includes anything that accesses a pScreen or pScrnInfo or plugs function pointers into the wrapping chain. Each time this code is built, it includes a different snapshot of the /usr/include/xorg header directory, and uses compile-time flags to handle anything that changed at an API level. That’s why I’m confident that, for example, the driver will never try to call dixLookupPrivate on an X server where it doesn’t exist: the headers it compiled against don’t include it and it would have failed to compile if it tried.

  • All of these support modules get linked together into a single nvidia_drv.so module.

  • When the driver is loaded, the first thing it does is call LoaderGetABIVersion and find a suitable support module to load. All communication with the X server goes through that module for the lifetime of the server.

  • During the Xorg release process, we generally declare the ABI frozen somewhere during the RC phase of the release. This doesn’t mean no ABI changes are allowed, it just means the version number needs to be bumped if the ABI changes. At the freeze point, I take a snapshot of the headers in /usr/include/xorg and that becomes the official set of headers for that ABI version. The freeze process during RC releases allows me to enable support for the new version in the next driver release so it can get into the hands of users before distributions pick up the new version of Xorg.

We have enterprise customers who use very old software and expect it to remain stable. That’s why our support timeframes are so long for things like old X ABI versions. Yes, the updated minimum for the release 580 series is still very old, but it shouldn’t affect your work at all: that ABI is frozen and it doesn’t affect the version of the code that is built for ABI 27.

We considered shipping multiple different versions of nvidia_drv.so, but that creates a big hassle for distribution packagers and users when upgrading the X server causes the driver to break. For users that use the .run package, we’d also have to identify the Xorg version at install time and users would be left with a broken driver if they upgrade Xorg without reinstalling the driver. A similar problem for the kernel modules is generally solved by DKMS, but we don’t have anything like that for Xorg modules.

You’d do everybody a huge favor. 90% of the hassles people have with it on daily basis would be just gone.

Can you clarify exactly what hassles you’re referring to? I haven’t been able to skim all of the forum traffic, but problems with installing or loading nvidia_drv.so don’t really show up on the radar as far as I’ve seen. This method for supporting Xorg has worked reliably for a very long time.

– Aaron

4 Likes

Hi @agoins , that’s a pretty valid question. I had already tested it a while ago, but it surely deserved a fresh test. I removed all nvidia packages (dnf remove \*nvidia\*) and did some further testing.

First of all, I went through BIOS settings looking for something that could influence boot behavior. Couldn’t find any entry explicitly related to iGPU x dGPU, but I did turn off fastboot, which was enabled (not sure if it was related, but wouldn’t hurt to try).

Here’s what I found out while running on nouveau:

  1. I can boot on battery. However, I had to set GSK_RENDERER=ngl on /etc/environment in order to be able to run GNOME apps (I use it set to vulkan with the Nvidia driver)
  2. whenever I boot on battery, GNOME shows internal display with its refresh rate fixed to 60Hz. If I plug an external monitor, internal display is labeled ‘unknown 23"’; If I boot while charging, it is properly recognized and listed as “Built-in display”, and it offers all refresh rates way up to its max 144Hz.

I then reinstalled nvidia drivers from Negativo17.org, and tried to repeat the process. I still cannot boot on battery without an external monitor plugged. When I boot on battery with an external display plugged, it also is unable to properly detect the internal display, showing the same ‘unknown 23"’ label and fixing the refresh rate to 60Hz.

On both cases (nouveau and nvidia), booting on battery with an external monitor plugged sets it as primary (login fields are shown on it). Once I log in, though, GNOME preferences are applied and the internal display appears as primary. On the other hand, booting while charging sets the built-in display as primary right from the start.

This is all pretty messed up, I can’t seem to make any sense out of it. Since both nvidia and nouveau share this same weird behavior, I’m wondering if this couldn’t be a kernel (or hardware) issue. If anyone has any clue or suggestion on additional tests I could make, it will be much welcome…

It’s okay. It just would have been nice to hear at least something (and a reply to my mail), perhaps something like “please give me some more time”.

I’ll do my best to provide quicker responses in the future.

Great. But you can forget my MRs on Xorg now, because Redhat has now hard-blocked me. (I’ll yet have to see whether I’m also hard-blocked from xorg mailing lists) - because I’m forking.
(release coming in about two weeks).

Current release preparation branch is here:

(first well known distros already coming on board :))

We’re still ironing out some regression w/ Nvidia driver (segfaulting) – seems to have something to do with
devPrivate’s (introduced a new private type for Xnamespace), but don’t really know why exactly it happens,
somehow the driver seems to get the wrong private pointer.
Maybe you’d like to have a look at it ?

  • The core code that interfaces with the rest of the graphics driver components doesn’t use any Xorg headers at all. This includes stuff like initializing and tearing down GPUs, translating rendering requests into GPU commands, and handling synchronization of direct-rendering clients such as GLX and Vulkan.

Ok. Why not just putting this into a separate library - and making the Xserver specific code open ?
That would save us all from a lot of trouble.

Can’t speak for others, but I really don’t care what deep black magic it’s doing to actually drive the gpu, but it’s really vital that it really works. The situation isn’t much different from the Linux kernel: there is no really fixed internal ABI.

This includes anything that accesses a pScreen or pScrnInfo or plugs function pointers into the wrapping chain.

This indeed must be recompiled for each ABI. And please don’t do proc wrapping, that’s fragile.
And really take care that when calling back into the daisy that you could reach some NULLs.
Optimally, drivers should just fill out the proc vectors and the leave them alone.
See my patches for replacing proc wrapping by callbacks.

By the way, getting reports of latest Nvidia driver segfaulting, because it’s trying to access the wrong devPrivates entry … grrrrr

Each time this code is built, it includes a different snapshot of the /usr/include/xorg header directory, and uses compile-time flags to handle anything that changed at an API level.

But you still link everything into one shared object. I’m not daring to ask how you actually keep these separate … :o

That’s why I’m confident that, for example, the driver will never try to call dixLookupPrivate on an X server where it doesn’t exist: the headers it compiled against don’t include it and it would have failed to compile if it tried.

Ok, if you say so.

But here we are, we have really now idea which of the many symbols you’re actually using, and how.
So if anything breaks, not my fault :p

  • During the Xorg release process, we generally declare the ABI frozen somewhere during the RC phase of the release. This doesn’t mean no ABI changes are allowed, it just means the version number needs to be bumped if the ABI changes.

Sure. Already increased it.

We have enterprise customers who use very old software and expect it to remain stable. That’s why our support timeframes are so long for things like old X ABI versions.

Sure. But do those old relics ever need any new features (or new HW) ? I doubt so.
Happen to be one of those folks keeping such old machinery alive in the field. And I never seen the need for any actual upgrades here - just occasional bugfixes.

We considered shipping multiple different versions of nvidia_drv.so, but that creates a big hassle for distribution packagers and users when upgrading the X server causes the driver to break.

No, not if you cooperate with the distros.
That monstreaus installer shell script is one of the major problems to begin with.
Cooperate with the distros and provide package repos, then everything’s fine.
Distros have their machineries for dealing with such things (and also already doing it with libGL.so links, etc)

Next Xlibre release is splitting module pathes per Xserver ABI (= major release number … we’re phasing out individual version numbers, it’s inaccurate anyways and just not worth it)

For users that use the .run package, we’d also have to identify the Xorg version at install time and users would be left with a broken driver if they upgrade Xorg without reinstalling the driver. A similar problem for the kernel modules is generally solved by DKMS, but we don’t have anything like that for Xorg modules.

Exactly. Something like dkms. Just talk to the distros, they already have such mechanisms.

Can you clarify exactly what hassles you’re referring to?

NVidia linux drivers have a long history of instability. Even back in the 90s, the proprietary Xserver for the RivaTNT … did immediate hard-lockups. I never got any Nvidia card practically working with your drivers, which means either Nouveau or plain framebuffer (that’s why I’ve stopped buying it decades ago). Forums are full with that. Ask your favorite AI chat bot ;-)
Perhaps most people just don’t file bug reports.

With (half)open kernel drivers it certainly became better. Now we need the same for the xf86 drivers.

And for the future I’d highly recommend cooperating with Mesa and KMS/DRI: add your pipeline driver there and leave the rest to classic standard mesa stack. xf86 then could just use generic modesetting + glamor.
That’s it. It could be so simple.

(by the way, getting reports of people successfully using them with modesetting - just loosing GLX this way, because we haven’t rewritten it ontop of glamor/EGL yet)

And again, much of this hassle could be easily prevented by just talking to each other and actively cooperating.

I really like to get the Nvidia problems ironed out before summer solstice release. But I can’t do that alone - without source code, need your help.

–mtx

Related to this post:

I have now managed uptimes of 50 hours +, 60 hours + (until I installed updates again) and still had 2 screen freezes pointing back to Nvida. I’ll post the last one from today right here.

Sometimes the browsers are obviously to blame, like Zen, Firefox or Brave. But then the references to Nvidia are usually missing in the log.

Jun 06 13:31:39 ANDROMEDA kernel: NVRM: GPU at PCI:0000:01:00: GPU-607aa084-1cf9-f43c-65b1-4be9d9db92f3
Jun 06 13:31:39 ANDROMEDA kernel: NVRM: Xid (PCI:0000:01:00): 119, pid=2081, name=Xorg, Timeout after 6s of waiting for RPC response from GPU0 GSP! Expected function 76 (GSP_RM_CONTROL) (0xc3700104 0x14).
Jun 06 13:31:39 ANDROMEDA kernel: NVRM: GPU0 GSP RPC buffer contains function 76 (GSP_RM_CONTROL) and data 0x00000000c3700104 0x0000000000000014.
Jun 06 13:31:39 ANDROMEDA kernel: NVRM: GPU0 RPC history (CPU -> GSP):
Jun 06 13:31:39 ANDROMEDA kernel: NVRM:     entry function                   data0              data1              ts_start           ts_end             duration actively_polling
Jun 06 13:31:39 ANDROMEDA kernel: NVRM:      0    76   GSP_RM_CONTROL        0x00000000c3700104 0x0000000000000014 0x000636e592781970 0x0000000000000000          y
Jun 06 13:31:39 ANDROMEDA kernel: NVRM:     -1    76   GSP_RM_CONTROL        0x000000002080852f 0x0000000000000308 0x000636e592744579 0x000636e5927446c9    336us  
Jun 06 13:31:39 ANDROMEDA kernel: NVRM:     -2    76   GSP_RM_CONTROL        0x0000000020808530 0x0000000000000390 0x000636e59274449c 0x000636e592744573    215us  
Jun 06 13:31:39 ANDROMEDA kernel: NVRM:     -3    76   GSP_RM_CONTROL        0x000000002080852f 0x0000000000000308 0x000636e5927442d6 0x000636e592744476    416us  
Jun 06 13:31:39 ANDROMEDA kernel: NVRM:     -4    76   GSP_RM_CONTROL        0x000000002080852f 0x0000000000000308 0x000636e59274410e 0x000636e5927442a1    403us  
Jun 06 13:31:39 ANDROMEDA kernel: NVRM:     -5    76   GSP_RM_CONTROL        0x0000000020808530 0x0000000000000390 0x000636e592744003 0x000636e592744108    261us  
Jun 06 13:31:39 ANDROMEDA kernel: NVRM:     -6    76   GSP_RM_CONTROL        0x000000002080852f 0x0000000000000308 0x000636e59274397e 0x000636e592743fcb   1613us  
Jun 06 13:31:39 ANDROMEDA kernel: NVRM:     -7    76   GSP_RM_CONTROL        0x000000002080a097 0x0000000000000490 0x000636e592743411 0x000636e5927438cd   1212us  
Jun 06 13:31:39 ANDROMEDA kernel: NVRM: GPU0 RPC event history (CPU <- GSP):
Jun 06 13:31:39 ANDROMEDA kernel: NVRM:     entry function                   data0              data1              ts_start           ts_end             duration during_incomplete_rpc
Jun 06 13:31:39 ANDROMEDA kernel: NVRM:      0    4128 GSP_POST_NOCAT_RECORD 0x0000000000000005 0x0000000001297258 0x000636e5828ead71 0x000636e5828ead71           
Jun 06 13:31:39 ANDROMEDA kernel: NVRM:     -1    4128 GSP_POST_NOCAT_RECORD 0x0000000000000005 0x00000000012711a4 0x000636e5828e9951 0x000636e5828e9953      2us  
Jun 06 13:31:39 ANDROMEDA kernel: NVRM:     -2    4128 GSP_POST_NOCAT_RECORD 0x0000000000000005 0x0000000001297258 0x000636e579b841ef 0x000636e579b841f0      1us  
Jun 06 13:31:39 ANDROMEDA kernel: NVRM:     -3    4128 GSP_POST_NOCAT_RECORD 0x0000000000000005 0x00000000012711a4 0x000636e579b8289b 0x000636e579b8289c      1us  
Jun 06 13:31:39 ANDROMEDA kernel: NVRM:     -4    4128 GSP_POST_NOCAT_RECORD 0x0000000000000005 0x0000000001297258 0x000636e579b28924 0x000636e579b28925      1us  
Jun 06 13:31:39 ANDROMEDA kernel: NVRM:     -5    4128 GSP_POST_NOCAT_RECORD 0x0000000000000005 0x00000000012711a4 0x000636e579b26f87 0x000636e579b26f88      1us  
Jun 06 13:31:39 ANDROMEDA kernel: NVRM:     -6    4128 GSP_POST_NOCAT_RECORD 0x0000000000000005 0x0000000001297258 0x000636e579b20172 0x000636e579b20172           
Jun 06 13:31:39 ANDROMEDA kernel: NVRM:     -7    4128 GSP_POST_NOCAT_RECORD 0x0000000000000005 0x00000000012711a4 0x000636e579b1eb16 0x000636e579b1eb19      3us  
Jun 06 13:31:39 ANDROMEDA kernel: CPU: 9 UID: 0 PID: 2081 Comm: Xorg Tainted: P           OE      6.11.0-118026-tuxedo #26~24.04.1tux1
Jun 06 13:31:39 ANDROMEDA kernel: Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
Jun 06 13:31:39 ANDROMEDA kernel: Hardware name: ASUS System Product Name/ROG STRIX X670E-A GAMING WIFI, BIOS 3003 05/05/2025
Jun 06 13:31:39 ANDROMEDA kernel: Call Trace:
Jun 06 13:31:39 ANDROMEDA kernel:  <TASK>
Jun 06 13:31:39 ANDROMEDA kernel:  dump_stack_lvl+0x76/0xa0
Jun 06 13:31:39 ANDROMEDA kernel:  dump_stack+0x10/0x20
Jun 06 13:31:39 ANDROMEDA kernel:  os_dump_stack+0xe/0x20 [nvidia]
Jun 06 13:31:39 ANDROMEDA kernel:  _nv013207rm+0x508/0x5b0 [nvidia]
Jun 06 13:31:39 ANDROMEDA kernel: WARNING: kernel stack frame pointer at 0000000050e9c24c in Xorg:2081 has bad value 000000006acb1392
Jun 06 13:31:39 ANDROMEDA kernel: unwind stack type:0 next_sp:0000000000000000 mask:0x2 graph_idx:0
Jun 06 13:31:39 ANDROMEDA kernel: 0000000062e0de72: ffffb400c1f979c8 (0xffffb400c1f979c8)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000916f0ab7: ffffffff8ca61a69 (show_trace_log_lvl+0x269/0x420)
Jun 06 13:31:39 ANDROMEDA kernel: 000000005f777dde: ffffffff8e5b259b (kallsyms_seqs_of_names+0x99bb3/0x20ca18)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000ea0e6f4c: ffff9ccc54dc2f40 (0xffff9ccc54dc2f40)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000fd644626: ffffffff8e5ddb93 (kallsyms_seqs_of_names+0xc51ab/0x20ca18)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000970b7c91: ffffb400c1f97a20 (0xffffb400c1f97a20)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000e12292c3: 00000000c1f97908 (0xc1f97908)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000201688a3: 0000000000000002 (0x2)
Jun 06 13:31:39 ANDROMEDA kernel: 000000006ae94d78: 0000000000000001 (0x1)
Jun 06 13:31:39 ANDROMEDA kernel: 000000004e071054: ffffb400c1f94000 (0xffffb400c1f94000)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000f64ebd6d: ffffb400c1f98000 (0xffffb400c1f98000)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000750516e6: 0000000000000000 ...
Jun 06 13:31:39 ANDROMEDA kernel: 00000000107ca736: ffffb400c1f94000 (0xffffb400c1f94000)
Jun 06 13:31:39 ANDROMEDA kernel: 000000006aec5616: ffffb400c1f98000 (0xffffb400c1f98000)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000e17e8d43: 0000000000000000 ...
Jun 06 13:31:39 ANDROMEDA kernel: 00000000506364ed: 0000000000000002 (0x2)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000ae691896: ffff9ccc54dc2f40 (0xffff9ccc54dc2f40)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000dad6d74e: 0000000000000000 ...
Jun 06 13:31:39 ANDROMEDA kernel: 000000003646fbc9: 0000000000000001 (0x1)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000e68305dc: ffffb400c1f97a18 (0xffffb400c1f97a18)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000a84c2b0b: ffffb400c1f978c8 (0xffffb400c1f978c8)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000ec2897cf: ffffffffc1c55e78 (_nv013207rm+0x508/0x5b0 [nvidia])
Jun 06 13:31:39 ANDROMEDA kernel: 00000000365f9dae: 0000000000000000 ...
Jun 06 13:31:39 ANDROMEDA kernel: 00000000fb2b1bd1: 931d6e4f20751a00 (0x931d6e4f20751a00)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000b7c7aac2: 0000000000000246 (0x246)
Jun 06 13:31:39 ANDROMEDA kernel: 0000000008f60802: ffffffff8e5ddb93 (kallsyms_seqs_of_names+0xc51ab/0x20ca18)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000fe8ba995: ffff9ccc45e58008 (0xffff9ccc45e58008)
Jun 06 13:31:39 ANDROMEDA kernel: 0000000043cbe7f7: 000000000000004c (0x4c)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000ac5c69c8: 0000000000000006 (0x6)
Jun 06 13:31:39 ANDROMEDA kernel: 000000004cddfa6e: ffffb400c1f979d8 (0xffffb400c1f979d8)
Jun 06 13:31:39 ANDROMEDA kernel: 000000002bd77bd6: ffffffff8ca61d40 (show_stack+0x20/0x70)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000c6ac8ec1: ffffb400c1f979f8 (0xffffb400c1f979f8)
Jun 06 13:31:39 ANDROMEDA kernel: 000000002842e7a0: ffffffff8dbd2db6 (dump_stack_lvl+0x76/0xa0)
Jun 06 13:31:39 ANDROMEDA kernel: 000000008e23d945: ffff9ccc72d60008 (0xffff9ccc72d60008)
Jun 06 13:31:39 ANDROMEDA kernel: 000000009dad656c: ffff9ccc5f878008 (0xffff9ccc5f878008)
Jun 06 13:31:39 ANDROMEDA kernel: 000000005550bf00: ffffb400c1f97a08 (0xffffb400c1f97a08)
Jun 06 13:31:39 ANDROMEDA kernel: 000000004239b91a: ffffffff8dbd2e00 (dump_stack+0x10/0x20)
Jun 06 13:31:39 ANDROMEDA kernel: 000000004217156f: ffffb400c1f97a18 (0xffffb400c1f97a18)
Jun 06 13:31:39 ANDROMEDA kernel: 000000007b8aa3c1: ffffffffc158754e (os_dump_stack+0xe/0x20 [nvidia])
Jun 06 13:31:39 ANDROMEDA kernel: 0000000050e9c24c: ffff9cce7c3bab00 (0xffff9cce7c3bab00)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000b8918e43: ffffffffc1c55e78 (_nv013207rm+0x508/0x5b0 [nvidia])
Jun 06 13:31:39 ANDROMEDA kernel: 0000000027459e3b: ffff9ccc45e58008 (0xffff9ccc45e58008)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000f45220fd: 0000000000000000 ...
Jun 06 13:31:39 ANDROMEDA kernel: 00000000cf61498a: ffff9ccc5f878008 (0xffff9ccc5f878008)
Jun 06 13:31:39 ANDROMEDA kernel: 000000008366916d: 0000000000000000 ...
Jun 06 13:31:39 ANDROMEDA kernel: 00000000c57c0897: 000000000000004c (0x4c)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000043ebc3d: ffffffffc1faaab7 (_nv013118rm+0x77/0x330 [nvidia])
Jun 06 13:31:39 ANDROMEDA kernel: 000000003cdd3a4a: ffff9ccc72d81050 (0xffff9ccc72d81050)
Jun 06 13:31:39 ANDROMEDA kernel: 000000009855bcec: ffff9cce7c3bab80 (0xffff9cce7c3bab80)
Jun 06 13:31:39 ANDROMEDA kernel: 000000007eaacc9d: ffff9ccc5f878008 (0xffff9ccc5f878008)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000c2c78d12: 00000000c3700104 (0xc3700104)
Jun 06 13:31:39 ANDROMEDA kernel: 000000001322cda1: ffff9ccc45e58008 (0xffff9ccc45e58008)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000bcb79c36: ffffffffc1fc7f8f (_nv051942rm+0x49f/0x7f0 [nvidia])
Jun 06 13:31:39 ANDROMEDA kernel: 00000000ba36187d: ffff9cce7c3bad58 (0xffff9cce7c3bad58)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000185aaf55: ffff9ccc5f878008 (0xffff9ccc5f878008)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000dcbb5dec: ffffffffc2461b80 (_nv000476rm+0xaf0/0xffffffffffee3f70 [nvidia])
Jun 06 13:31:39 ANDROMEDA kernel: 00000000c7a1ef1e: ffff9ccc44737048 (0xffff9ccc44737048)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000567c6795: ffff9cce7c3bad58 (0xffff9cce7c3bad58)
Jun 06 13:31:39 ANDROMEDA kernel: 0000000064329816: ffffffffc1638241 (_nv051480rm+0xf1/0x1f0 [nvidia])
Jun 06 13:31:39 ANDROMEDA kernel: 000000004f843409: 0000000000000000 ...
Jun 06 13:31:39 ANDROMEDA kernel: 00000000fc657968: ffff9cce7c3bac60 (0xffff9cce7c3bac60)
Jun 06 13:31:39 ANDROMEDA kernel: 0000000065fbf255: ffffffffc2461b80 (_nv000476rm+0xaf0/0xffffffffffee3f70 [nvidia])
Jun 06 13:31:39 ANDROMEDA kernel: 0000000000d28c56: ffffffffc2008c99 (_nv051173rm+0xd9/0x1c0 [nvidia])
Jun 06 13:31:39 ANDROMEDA kernel: 00000000cf175137: ffff9ccc44737028 (0xffff9ccc44737028)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000fa6f2565: ffff9ccc5ec61630 (0xffff9ccc5ec61630)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000a2e7a275: ffff9cce7c3bac60 (0xffff9cce7c3bac60)
Jun 06 13:31:39 ANDROMEDA kernel: 000000009a53ada3: ffff9cce7c3bad58 (0xffff9cce7c3bad58)
Jun 06 13:31:39 ANDROMEDA kernel: 000000002ae053e0: ffff9cce7c3bad18 (0xffff9cce7c3bad18)
Jun 06 13:31:39 ANDROMEDA kernel: 0000000041f480c0: ffffffffc1847129 (_nv023884rm+0xd9/0x160 [nvidia])
Jun 06 13:31:39 ANDROMEDA kernel: 00000000b762a977: ffff9cce7c3bad18 (0xffff9cce7c3bad18)
Jun 06 13:31:39 ANDROMEDA kernel: 000000008f691556: ffff9cce7c3bac30 (0xffff9cce7c3bac30)
Jun 06 13:31:39 ANDROMEDA kernel: 000000001ef32df5: 0000000000000000 ...
Jun 06 13:31:39 ANDROMEDA kernel: 00000000eca4cb10: ffffffffc2461b80 (_nv000476rm+0xaf0/0xffffffffffee3f70 [nvidia])
Jun 06 13:31:39 ANDROMEDA kernel: 000000005c253846: ffff9cce7c3bad58 (0xffff9cce7c3bad58)
Jun 06 13:31:39 ANDROMEDA kernel: 000000008fcf8eec: ffffffffc2005d36 (_nv053312rm+0x3f6/0x500 [nvidia])
Jun 06 13:31:39 ANDROMEDA kernel: 000000001ffdec13: 0000000000000000 ...
Jun 06 13:31:39 ANDROMEDA kernel: 00000000456931ca: 00000000c3700104 (0xc3700104)
Jun 06 13:31:39 ANDROMEDA kernel: 0000000086a4c91b: 00000000c1d00001 (0xc1d00001)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000e090e163: ffff9cce7c3bad18 (0xffff9cce7c3bad18)
Jun 06 13:31:39 ANDROMEDA kernel: 0000000094bb9862: ffff9cce7c3badd0 (0xffff9cce7c3badd0)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000381873ca: ffffffffc162af54 (_nv015043rm+0x424/0x680 [nvidia])
Jun 06 13:31:39 ANDROMEDA kernel: 000000000881ca8c: 0000000000000014 (0x14)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000544ad907: 0000000000010011 (0x10011)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000f0393974: 00000000c3700104 (0xc3700104)
Jun 06 13:31:39 ANDROMEDA kernel: 0000000027bc94b8: ffffb400c1f97cdc (0xffffb400c1f97cdc)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000503f52a0: 00000000c1d00001 (0xc1d00001)
Jun 06 13:31:39 ANDROMEDA kernel: 000000002848dd68: ffffffffc162b949 (_nv051326rm+0x69/0xd0 [nvidia])
Jun 06 13:31:39 ANDROMEDA kernel: 000000006886f4a8: ffffffffc2461600 (_nv000476rm+0x570/0xffffffffffee3f70 [nvidia])
Jun 06 13:31:39 ANDROMEDA kernel: 00000000a21bb7a2: ffffb400c1f97c08 (0xffffb400c1f97c08)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000be02132e: ffffb400c1f97c88 (0xffffb400c1f97c88)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000357fb5fa: 0000000000000000 ...
Jun 06 13:31:39 ANDROMEDA kernel: 00000000296e2f2b: ffffb400c1f97d2f (0xffffb400c1f97d2f)
Jun 06 13:31:39 ANDROMEDA kernel: 000000007e2d6174: ffffb400c0b83008 (0xffffb400c0b83008)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000c37e638e: ffffffffc162ef16 (_nv013401rm+0x86/0xa0 [nvidia])
Jun 06 13:31:39 ANDROMEDA kernel: 0000000033a3361c: 0000000000000000 ...
Jun 06 13:31:39 ANDROMEDA kernel: 00000000b7bd149f: ffffb400c1f97c08 (0xffffb400c1f97c08)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000c1731f1d: ffffb400c1f97c70 (0xffffb400c1f97c70)
Jun 06 13:31:39 ANDROMEDA kernel: 000000004e84ef31: ffffb400c1f97c88 (0xffffb400c1f97c88)
Jun 06 13:31:39 ANDROMEDA kernel: 000000006ba35b16: 0000000000000000 ...
Jun 06 13:31:39 ANDROMEDA kernel: 000000003ee12fe3: ffffffffc162f51e (_nv000631rm+0x5e/0x70 [nvidia])
Jun 06 13:31:39 ANDROMEDA kernel: 00000000097950f0: 0000000100000002 (0x100000002)
Jun 06 13:31:39 ANDROMEDA kernel: 000000001bd888be: 0000000000000000 ...
Jun 06 13:31:39 ANDROMEDA kernel: 0000000063f31fe7: ffff9cce7c3b8000 (0xffff9cce7c3b8000)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000be8bed70: ffffffffc2239b27 (rm_kernel_rmapi_op+0x167/0x273 [nvidia])
Jun 06 13:31:39 ANDROMEDA kernel: 000000006ecdb5a7: ffffb400c1f97c80 (0xffffb400c1f97c80)
Jun 06 13:31:39 ANDROMEDA kernel: 0000000049f11030: ffffb400c0b83008 (0xffffb400c0b83008)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000380f750e: 0000000000000000 ...
Jun 06 13:31:39 ANDROMEDA kernel: 00000000af31ee1c: ffffffffc6d88aac (nvkms_call_rm+0x4c/0x90 [nvidia_modeset])
Jun 06 13:31:39 ANDROMEDA kernel: 000000007cb06318: ffff9cce7c3b8000 (0xffff9cce7c3b8000)
Jun 06 13:31:39 ANDROMEDA kernel: 000000005c2ae12f: 931d6e4f20751a00 (0x931d6e4f20751a00)
Jun 06 13:31:39 ANDROMEDA kernel: 000000009026fd54: ffff9ccc72381208 (0xffff9ccc72381208)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000a9c476db: ffffb400c1f97cc0 (0xffffb400c1f97cc0)
Jun 06 13:31:39 ANDROMEDA kernel: 0000000069c617c7: ffffffffc6def2a2 (_nv003116kms+0x42/0x50 [nvidia_modeset])
Jun 06 13:31:39 ANDROMEDA kernel: 000000004767b63c: 0000000000000036 (0x36)
Jun 06 13:31:39 ANDROMEDA kernel: 000000001873dace: 00010011c1d00001 (0x10011c1d00001)
Jun 06 13:31:39 ANDROMEDA kernel: 0000000037873436: 00000000c3700104 (0xc3700104)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000816124a8: ffffb400c1f97cdc (0xffffb400c1f97cdc)
Jun 06 13:31:39 ANDROMEDA kernel: 0000000074d298c6: 0000000000000014 (0x14)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000b25d52a3: 0000000000000000 ...
Jun 06 13:31:39 ANDROMEDA kernel: 00000000cb7534da: ffffb400c1f97d10 (0xffffb400c1f97d10)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000e76084a0: ffffffffc6d9f222 (_nv002787kms+0x52/0xb0 [nvidia_modeset])
Jun 06 13:31:39 ANDROMEDA kernel: 000000001b4d481d: ffffffff8ca6f7b1 (native_tss_update_io_bitmap+0x61/0xa0)
Jun 06 13:31:39 ANDROMEDA kernel: 0000000069c493dc: 0000000000400000 (0x400000)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000b7a405a5: 000000060000c67e (0x60000c67e)
Jun 06 13:31:39 ANDROMEDA kernel: 000000000f8bc813: 0000000000000000 ...
Jun 06 13:31:39 ANDROMEDA kernel: 00000000a2a4099a: 0000000000000003 (0x3)
Jun 06 13:31:39 ANDROMEDA kernel: 000000004bceebfe: 0000000000000000 ...
Jun 06 13:31:39 ANDROMEDA kernel: 0000000034297725: ffffb400c0bb3008 (0xffffb400c0bb3008)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000021c1c09: ffffb400c0b83008 (0xffffb400c0b83008)
Jun 06 13:31:39 ANDROMEDA kernel: 000000002e3166d0: ffffb400c1f97d50 (0xffffb400c1f97d50)
Jun 06 13:31:39 ANDROMEDA kernel: 000000000ec163bb: ffffffffc6dd5e83 (_nv003010kms+0xd3/0x190 [nvidia_modeset])
Jun 06 13:31:39 ANDROMEDA kernel: 00000000ba1d5c2b: ffff9ccc51bf849c (0xffff9ccc51bf849c)
Jun 06 13:31:39 ANDROMEDA kernel: 000000009656c1e6: 00ffffff8df04110 (0xffffff8df04110)
Jun 06 13:31:39 ANDROMEDA kernel: 000000005ae81365: ffffb400c0bb3008 (0xffffb400c0bb3008)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000bf792326: 0000000000000001 (0x1)
Jun 06 13:31:39 ANDROMEDA kernel: 0000000081e20d1d: ffff9ccc51bf8488 (0xffff9ccc51bf8488)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000fc415f38: 0000000000000000 ...
Jun 06 13:31:39 ANDROMEDA kernel: 00000000fe08f7ec: ffffb400c1f97dc0 (0xffffb400c1f97dc0)
Jun 06 13:31:39 ANDROMEDA kernel: 0000000088f56b2f: ffffffffc6d8b5b3 (_nv000555kms+0x1b3/0x210 [nvidia_modeset])
Jun 06 13:31:39 ANDROMEDA kernel: 000000000bc0b1fa: ffffffff8cf09a22 (__check_object_size.part.0+0x72/0x150)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000c3773c9d: ffff9ccc51bf849c (0xffff9ccc51bf849c)
Jun 06 13:31:39 ANDROMEDA kernel: 000000007c19fefd: 0000000000000000 ...
Jun 06 13:31:39 ANDROMEDA kernel: 000000007895d379: ffff9ccc51bf8488 (0xffff9ccc51bf8488)
Jun 06 13:31:39 ANDROMEDA kernel: 0000000095faf0ff: 0000000001420f10 (0x1420f10)
Jun 06 13:31:39 ANDROMEDA kernel: 0000000025d7573d: 0000000000000000 ...
Jun 06 13:31:39 ANDROMEDA kernel: 00000000b815d286: ffffffff8cf09b33 (__check_object_size+0x23/0x30)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000f4d66f67: ffff9ccc41886d08 (0xffff9ccc41886d08)
Jun 06 13:31:39 ANDROMEDA kernel: 000000002dfddc0f: ffff9ccc51bf8488 (0xffff9ccc51bf8488)
Jun 06 13:31:39 ANDROMEDA kernel: 0000000036722ed7: 0000000000000024 (0x24)
Jun 06 13:31:39 ANDROMEDA kernel: 0000000016b20bfe: 00007ffec0420f10 (0x7ffec0420f10)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000ab9c9132: ffffffffc6d8b400 (_nv000088kms+0x30/0x30 [nvidia_modeset])
Jun 06 13:31:39 ANDROMEDA kernel: 000000007b33bd4b: ffffb400c1f97e10 (0xffffb400c1f97e10)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000625c7597: ffffffffc6d8e759 (nvKmsIoctl+0xf9/0x270 [nvidia_modeset])
Jun 06 13:31:39 ANDROMEDA kernel: 00000000bb554bcc: 000000000000000d (0xd)
Jun 06 13:31:39 ANDROMEDA kernel: 000000007c0aa4b9: 000000000000000d (0xd)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000df2c9a34: ffffffff8dc931be (_raw_spin_lock_irqsave+0xe/0x20)
Jun 06 13:31:39 ANDROMEDA kernel: 0000000057801365: 0000000000000000 ...
Jun 06 13:31:39 ANDROMEDA kernel: 000000002313a9d1: ffff9ccc41691120 (0xffff9ccc41691120)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000a9022866: 0000000000000024 (0x24)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000e9544be7: 000000000000000d (0xd)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000e6a9dc58: 00007ffec0420f10 (0x7ffec0420f10)
Jun 06 13:31:39 ANDROMEDA kernel: 000000006d55abde: ffffb400c1f97e60 (0xffffb400c1f97e60)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000073754fb: ffffffffc6d877a1 (nvkms_unlocked_ioctl+0x121/0x1a0 [nvidia_modeset])
Jun 06 13:31:39 ANDROMEDA kernel: 000000003bb8bfb6: 000000240000000d (0x240000000d)
Jun 06 13:31:39 ANDROMEDA kernel: 0000000011ea4582: 00007ffec0420f10 (0x7ffec0420f10)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000888b3770: 931d6e4f20751a00 (0x931d6e4f20751a00)
Jun 06 13:31:39 ANDROMEDA kernel: 0000000000d99a47: 0000000000000016 (0x16)
Jun 06 13:31:39 ANDROMEDA kernel: 0000000088a5f9d5: ffff9ccc72e31600 (0xffff9ccc72e31600)
Jun 06 13:31:39 ANDROMEDA kernel: 0000000075bded93: 00000000c0106d00 (0xc0106d00)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000219f7ff1: 00007ffec0420ea0 (0x7ffec0420ea0)
Jun 06 13:31:39 ANDROMEDA kernel: 000000000fc166af: ffff9ccc72e31601 (0xffff9ccc72e31601)
Jun 06 13:31:39 ANDROMEDA kernel: 000000004e621076: ffffb400c1f97e98 (0xffffb400c1f97e98)
Jun 06 13:31:39 ANDROMEDA kernel: 000000003b618903: ffffffff8cf35620 (__x64_sys_ioctl+0xa0/0xf0)
Jun 06 13:31:39 ANDROMEDA kernel: 000000004d4fb538: ffffb400c1f97f48 (0xffffb400c1f97f48)
Jun 06 13:31:39 ANDROMEDA kernel: 0000000097b38e2b: 0000000000000010 (0x10)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000ebb7bfac: 0000000000000010 (0x10)
Jun 06 13:31:39 ANDROMEDA kernel: 000000008a6f9db7: 0000000000000000 ...
Jun 06 13:31:39 ANDROMEDA kernel: 000000006b2ae39f: ffffb400c1f97ea8 (0xffffb400c1f97ea8)
Jun 06 13:31:39 ANDROMEDA kernel: 000000006fd2952a: ffffffff8ca0af8d (x64_sys_call+0x11ad/0x25f0)
Jun 06 13:31:39 ANDROMEDA kernel: 000000003b4d05da: ffffb400c1f97f38 (0xffffb400c1f97f38)
Jun 06 13:31:39 ANDROMEDA kernel: 000000003de8063c: ffffffff8dc7b76e (do_syscall_64+0x7e/0x170)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000d84aa4bb: ffffffff8dc82a4f (syscall_exit_to_user_mode+0x17f/0x250)
Jun 06 13:31:39 ANDROMEDA kernel: 0000000058048c77: ffffb400c1f97f48 (0xffffb400c1f97f48)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000b0c5149f: 0000000000000010 (0x10)
Jun 06 13:31:39 ANDROMEDA kernel: 0000000030d969f4: 0000000000000010 (0x10)
Jun 06 13:31:39 ANDROMEDA kernel: 000000001d7fe558: ffffffff8df04110 (srso_alias_return_thunk+0x5/0xfbef5)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000a8c9af0f: ffffffff8dc7b77a (do_syscall_64+0x8a/0x170)
Jun 06 13:31:39 ANDROMEDA kernel: 000000004ce33f83: ffffffff8dc82a4f (syscall_exit_to_user_mode+0x17f/0x250)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000bb26604e: ffffb400c1f97f48 (0xffffb400c1f97f48)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000679f1060: 0000000000000014 (0x14)
Jun 06 13:31:39 ANDROMEDA kernel: 0000000068d46563: 0000000000000014 (0x14)
Jun 06 13:31:39 ANDROMEDA kernel: 000000003c11693f: ffffffff8df04110 (srso_alias_return_thunk+0x5/0xfbef5)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000a6e27238: ffffffff8dc7b77a (do_syscall_64+0x8a/0x170)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000d2f9338f: 0000000000000000 ...
Jun 06 13:31:39 ANDROMEDA kernel: 00000000429e0e78: ffffffff8de0012b (entry_SYSCALL_64_after_hwframe+0x76/0x7e)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000f9d060f2: 0000000000000001 (0x1)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000a8f4c958: 00007ffec0420f14 (0x7ffec0420f14)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000c311bd3c: 00006023251bab80 (0x6023251bab80)
Jun 06 13:31:39 ANDROMEDA kernel: 000000003839ca7d: 00007ffec0420ea0 (0x7ffec0420ea0)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000e308e063: 00007ffec0420e90 (0x7ffec0420e90)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000cc6037d7: 0000000000000016 (0x16)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000e48f075a: 0000000000000246 (0x246)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000c2c408d9: 0000000000000001 (0x1)
Jun 06 13:31:39 ANDROMEDA kernel: 000000001dbc621b: 0000000000000001 (0x1)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000bcd84a67: 0000000000000001 (0x1)
Jun 06 13:31:39 ANDROMEDA kernel: 000000006c96628c: ffffffffffffffda (0xffffffffffffffda)
Jun 06 13:31:39 ANDROMEDA kernel: 000000002743e25e: 00007550bc924ded (0x7550bc924ded)
Jun 06 13:31:39 ANDROMEDA kernel: 0000000005a01ed4: 00007ffec0420ea0 (0x7ffec0420ea0)
Jun 06 13:31:39 ANDROMEDA kernel: 000000004d2411ee: 00000000c0106d00 (0xc0106d00)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000ea989512: 0000000000000016 (0x16)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000c7ffd55c: 0000000000000010 (0x10)
Jun 06 13:31:39 ANDROMEDA kernel: 000000006d16e1a9: 00007550bc924ded (0x7550bc924ded)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000ac9c4fcc: 0000000000000033 (0x33)
Jun 06 13:31:39 ANDROMEDA kernel: 0000000034688df6: 0000000000000246 (0x246)
Jun 06 13:31:39 ANDROMEDA kernel: 000000003f1e7cd7: 00007ffec0420e40 (0x7ffec0420e40)
Jun 06 13:31:39 ANDROMEDA kernel: 000000002c945abf: 000000000000002b (0x2b)
Jun 06 13:31:39 ANDROMEDA kernel: 00000000fa884ea4: 0000000000000000 ...
Jun 06 13:31:39 ANDROMEDA kernel:  ? _nv013118rm+0x77/0x330 [nvidia]
Jun 06 13:31:39 ANDROMEDA kernel:  ? _nv051942rm+0x49f/0x7f0 [nvidia]
Jun 06 13:31:39 ANDROMEDA kernel:  ? _nv051480rm+0xf1/0x1f0 [nvidia]
Jun 06 13:31:39 ANDROMEDA kernel:  ? _nv051173rm+0xd9/0x1c0 [nvidia]
Jun 06 13:31:39 ANDROMEDA kernel:  ? _nv023884rm+0xd9/0x160 [nvidia]
Jun 06 13:31:39 ANDROMEDA kernel:  ? _nv053312rm+0x3f6/0x500 [nvidia]
Jun 06 13:31:39 ANDROMEDA kernel:  ? _nv015043rm+0x424/0x680 [nvidia]
Jun 06 13:31:39 ANDROMEDA kernel:  ? _nv051326rm+0x69/0xd0 [nvidia]
Jun 06 13:31:39 ANDROMEDA kernel:  ? _nv013401rm+0x86/0xa0 [nvidia]
Jun 06 13:31:39 ANDROMEDA kernel:  ? _nv000631rm+0x5e/0x70 [nvidia]
Jun 06 13:31:39 ANDROMEDA kernel:  ? rm_kernel_rmapi_op+0x167/0x273 [nvidia]
Jun 06 13:31:39 ANDROMEDA kernel:  ? nvkms_call_rm+0x4c/0x90 [nvidia_modeset]
Jun 06 13:31:39 ANDROMEDA kernel:  ? _nv003116kms+0x42/0x50 [nvidia_modeset]
Jun 06 13:31:39 ANDROMEDA kernel:  ? _nv002787kms+0x52/0xb0 [nvidia_modeset]
Jun 06 13:31:39 ANDROMEDA kernel:  ? native_tss_update_io_bitmap+0x61/0xa0
Jun 06 13:31:39 ANDROMEDA kernel:  ? _nv003010kms+0xd3/0x190 [nvidia_modeset]
Jun 06 13:31:39 ANDROMEDA kernel:  ? _nv000555kms+0x1b3/0x210 [nvidia_modeset]
Jun 06 13:31:39 ANDROMEDA kernel:  ? __check_object_size.part.0+0x72/0x150
Jun 06 13:31:39 ANDROMEDA kernel:  ? __check_object_size+0x23/0x30
Jun 06 13:31:39 ANDROMEDA kernel:  ? _nv000088kms+0x30/0x30 [nvidia_modeset]
Jun 06 13:31:39 ANDROMEDA kernel:  ? nvKmsIoctl+0xf9/0x270 [nvidia_modeset]
Jun 06 13:31:39 ANDROMEDA kernel:  ? _raw_spin_lock_irqsave+0xe/0x20
Jun 06 13:31:39 ANDROMEDA kernel:  ? nvkms_unlocked_ioctl+0x121/0x1a0 [nvidia_modeset]
Jun 06 13:31:39 ANDROMEDA kernel:  ? __x64_sys_ioctl+0xa0/0xf0
Jun 06 13:31:39 ANDROMEDA kernel:  ? x64_sys_call+0x11ad/0x25f0
Jun 06 13:31:39 ANDROMEDA kernel:  ? do_syscall_64+0x7e/0x170
Jun 06 13:31:39 ANDROMEDA kernel:  ? syscall_exit_to_user_mode+0x17f/0x250
Jun 06 13:31:39 ANDROMEDA kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
Jun 06 13:31:39 ANDROMEDA kernel:  ? do_syscall_64+0x8a/0x170
Jun 06 13:31:39 ANDROMEDA kernel:  ? syscall_exit_to_user_mode+0x17f/0x250
Jun 06 13:31:39 ANDROMEDA kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
Jun 06 13:31:39 ANDROMEDA kernel:  ? do_syscall_64+0x8a/0x170
Jun 06 13:31:39 ANDROMEDA kernel:  ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
Jun 06 13:31:39 ANDROMEDA kernel:  </TASK>
Jun 06 13:31:39 ANDROMEDA kernel: nvidia-modeset: ERROR: GPU:0: Failed to query display engine channel state: 0x0000c67e:6:0:0x00000065
Jun 06 13:31:44 ANDROMEDA systemd[1]: systemd-hostnamed.service: Deactivated successfully.
Jun 06 13:31:45 ANDROMEDA kernel: NVRM: Xid (PCI:0000:01:00): 119, pid=4327, name=nvidia-smi, Timeout after 6s of waiting for RPC response from GPU0 GSP! Expected function 76 (GSP_RM_CONTROL) (0x20800a4c 0x4).
Jun 06 13:31:51 ANDROMEDA kernel: NVRM: Xid (PCI:0000:01:00): 119, pid=4327, name=nvidia-smi, Timeout after 6s of waiting for RPC response from GPU0 GSP! Expected function 76 (GSP_RM_CONTROL) (0x20800a4c 0x4).
Jun 06 13:31:56 ANDROMEDA wpa_supplicant[1404]: wlp9s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-64 noise=9999 txrate=87800
Jun 06 13:31:57 ANDROMEDA kernel: NVRM: Rate limiting GSP RPC error prints for GPU at PCI:0000:01:00 (printing 1 of every 30).  The GPU likely needs to be reset.

nvidia-bug-report.log_2025-06-06.gz (859.1 KB)

It’s fixed in version 575. Thanks.

@andre.ocosta

What if you leave nouveau blacklisted as well? Since the internal display is controlled by the AMD iGPU, it should function without the NVIDIA GPU altogether.

@agoins it is currently blacklisted with the proprietary Nvidia driver, I am assuming you are referring to the “Nvidia-less” test, right? I guess it could work, but AFAIK I would lose the ability to plug external monitors (since the HDMI port is wired to the Nvidia dGPU), and that would be a no-go as a permanent solution. But if you’re just curious about how it will behave, I can do it, no problem.