You are not logged in.
Did you perserve a backtrace of whatever crashed (X11 server or session)?
Random things crashing in relation to electron apps however sounds more like an OOM condition.
Offline
I just found this, and it doesn't fix the problems, but it reduces them.
compton needs to have vsync explicitely disabled otherwise it does it anyway.
vsync none
Like I say, it's not a complete cure, but it helps.
EDIT. I should mention, this is only for people using compton and ForceFullCompositionPipeline
Last edited by Roken (2018-03-21 21:01:34)
Ryzen 5900X 12 core/24 thread - RTX 3090 FE 24 Gb, Asus Prime B450 Plus, 32Gb Corsair DDR4, Cooler Master N300 chassis, 5 HD (1 NvME PCI, 4SSD) + 1 x optical.
Linux user #545703
Offline
Did you compare the various __GL_YIELD methods (see /usr/share/doc/nvidia/README)?
Offline
Hopefully this isn't too much of a necrobump, two weeks later, but the nvidia 390 drivers were causing me serious problems with random shutdown of the X server that had some loose connection to Electron apps. I have only been able to get it working properly by downgrading to 387. Not only that, it's not an isolated issue with just Linux. I fixed a gaming machine two days ago by downgrading to a pre-390 version, that was randomly shutting down the whole machine.
But now I am lost as to how I find the necessary accessory packages required to get Steam running.
Offline
But now I am lost as to how I find the necessary accessory packages required to get Steam running.
If you get stuck on "Pins up-to-date!" message when starting steam or steam-runtime, backup and try removing ~/.steam and ~/.local/share/Steam (except ~/.local/share/Steam/steamapps). But first, make sure nvidia-utils, nvidia-settings and lib32-nvidia-utils were all downgraded to 387.
By the way, I still have lots of problems with 390 driver on GTX 760. Very sluggish, also I get a black screen after starting XFCE session and I need to switch to TTY and back to X session again in order to see anything.
Last edited by mard (2018-03-24 14:43:40)
Offline
I encountered that problem as well, on a dual screen setup since version 390. I've tried everything from page 1 to 8 without success. I've tried 390.42-5 this morning again but it's the same.
On my dual screen setup, I use the same models (some Dells 24"). Screen 1 has trouble waking out of sleep sometimes, and when it wakes up, bad resolution is detected (it maxes at 1600x900 intead of full HD). I believe this is because of some bad EDID information reported by the nvidia driver. I did try to override the EDID info but then my second screen goes batshit as well. Using one screen at a time seem to make the screens work properly (by switching one off, the other works properly).
Offline
I encountered that problem as well, on a dual screen setup since version 390. I've tried everything from page 1 to 8 without success. I've tried 390.42-5 this morning again but it's the same.
On my dual screen setup, I use the same models (some Dells 24"). Screen 1 has trouble waking out of sleep sometimes, and when it wakes up, bad resolution is detected (it maxes at 1600x900 intead of full HD). I believe this is because of some bad EDID information reported by the nvidia driver. I did try to override the EDID info but then my second screen goes batshit as well. Using one screen at a time seem to make the screens work properly (by switching one off, the other works properly).
I've had a similar problem ever since I started using dual monitors a year or so ago. Sometimes one display will not wake from sleep after resuming the PC from suspend. It seems to be that the GPU detects connected displays before the on signal is correctly sent to the monitor. Switching to another TTY makes the monitor turn on then back to TTY1 and Xorg can see the display. Not ideal but it's better than going into display settings every single time. I'd prefer a more persistent fix but haven't found anything yet.
Offline
Looks like there's some hope on the horizon!
Please vote for all the AUR packages you're using. You can mass-vote for all of them by doing: "pacman -Qqm | xargs aurvote -v" (make sure to run "aurvote --configure" first)
Offline
Looks like there's some hope on the horizon!
Huzzah!I was beginning to think I'd be stuck on an old driver and kernel forever...
Offline
Yes, but it seems it is not just chrome/ium and his sandbox to expose 390.25 driver problems.
Help me to improve ssh-rdp !
Retroarch User? Try my koko-aio shader !
Offline
From a quick test, it looks like in addition to /dev/nvidiactl, we also stat() /dev/nvidia[0-9]+, /dev/nvidia-modeset (for display-related stuff) and $HOME/.nv and its subdirectories for the shader cache. In some cases we apparently will also stat() /dev/zero, although it doesn't look like that should be needed for Chrome.
That's probably not an exhaustive list, so I'd recommend `strace`ing with the sandbox disabled to see what else the driver is trying to do.
Nvidia can not provide an exhaustive list for their own driver or document what additions have been made with the 390 series and want chromium developers to do the tracing for an issue with the nvidia driver.
@kokoko3k there is also https://devtalk.nvidia.com/default/topi … 4/#5245514
Offline
Yes, but it seems it is not just chrome/ium and his sandbox to expose 390.25 driver problems.
It's definitely not just a Chrome/ium problem this issue is affecting Steam and various games as well.
Offline
The latest update (390.48) appears to have fixed the regression for me.
Offline
The latest update (390.48) appears to have fixed the regression for me.
Are you sure? It didn't for me. See if you can reproduce the slowdown as described in this post. I still can.
Offline
There have to be also upstream fix on the google-chrome side according to devtalk.nvidia, apparently they are working on it.
But there is still major fps drop on 3D games on .25 and .48. comparing to Windows. Which never occurred in the past.
Offline
paraita wrote:I encountered that problem as well, on a dual screen setup since version 390. I've tried everything from page 1 to 8 without success. I've tried 390.42-5 this morning again but it's the same.
On my dual screen setup, I use the same models (some Dells 24"). Screen 1 has trouble waking out of sleep sometimes, and when it wakes up, bad resolution is detected (it maxes at 1600x900 intead of full HD). I believe this is because of some bad EDID information reported by the nvidia driver. I did try to override the EDID info but then my second screen goes batshit as well. Using one screen at a time seem to make the screens work properly (by switching one off, the other works properly).I've had a similar problem ever since I started using dual monitors a year or so ago. Sometimes one display will not wake from sleep after resuming the PC from suspend. It seems to be that the GPU detects connected displays before the on signal is correctly sent to the monitor. Switching to another TTY makes the monitor turn on then back to TTY1 and Xorg can see the display. Not ideal but it's better than going into display settings every single time. I'd prefer a more persistent fix but haven't found anything yet.
I can totally relate ! Thanks for the TTY switching tips, it helps
Offline
The latest update (390.48) appears to have fixed the regression for me.
Good for you, on my computer though, regression is still there...
Offline
Can those affected test if chromium 65.0.3325.181-5 which has a patch for the sandbox interaction with the nvidia driver resolves that issue?
Offline
Are you sure? It didn't for me. See if you can reproduce the slowdown as described in this post. I still can.
Chromium 65.0.3325.181-5 has fixed this issue for me.
Offline
Can those affected test if chromium 65.0.3325.181-5 which has a patch for the sandbox interaction with the nvidia driver resolves that issue?
Seems to have fixed the issue for me.
Offline
Can those affected test if chromium 65.0.3325.181-5 which has a patch for the sandbox interaction with the nvidia driver resolves that issue?
The issue is gone for me as well.
Offline
Can those affected test if chromium 65.0.3325.181-5 which has a patch for the sandbox interaction with the nvidia driver resolves that issue?
I'm no longer experiencing the same ridiculous stuttering from just having one Youtube video open. Redraw issues I saw are also fixed. System utilization seems higher but I might just be imagining it, I didn't do any comparison tests.
Thanks for sharing, I'm glad this is finally fixed. I'm a little concerned now about how little Nvidia did to comment on or resolve the issue and how long it took.
Offline
I'm a little concerned now about how little Nvidia did to comment on or resolve the issue and how long it took.
You can already see the next issue if you try the linux 4.16 package from staging and nvidia 390.48-4 which will fail to load the module and work around that to find it exposes kernel memory to userspace.
https://bugs.archlinux.org/task/58074
Offline
The previous nvidia driver are almost never compatibility with a next major kernel release due to changes in it.
Offline
I finally updated everything and everything seems to be working fine. Chromium is fast again.
ArchM wrote:I'm a little concerned now about how little Nvidia did to comment on or resolve the issue and how long it took.
You can already see the next issue if you try the linux 4.16 package from staging and nvidia 390.48-4 which will fail to load the module and work around that to find it exposes kernel memory to userspace.
https://bugs.archlinux.org/task/58074
Ugh, even this Chromium perf fix was due to Chromium team. Nvidia made a lot of changes with their pipeline and notified no one and just pushed it onto everyone.
I hope Arch team doesn't just package Nvidia's stuff without doing lots of checks. You just can't trust them.
Please vote for all the AUR packages you're using. You can mass-vote for all of them by doing: "pacman -Qqm | xargs aurvote -v" (make sure to run "aurvote --configure" first)
Offline