After I reboot I have tried checking all logs available and I cannot find anything logged right before the incident. Last entries are always different and not indicating anything.
isn’t this a unified way to present logs that also exist in var/log ? I mean if the logs are saved in var/log I’ve checked them. If there is a possibility that journalctl has more entries, then I need to check this too.
Seems you might know more than me. When I had an obscure crash related to my pc going into C-sleep state, I managed to find a pattern viewing the logs in reverse from the time of the crash.
Maybe for some logs but no, systemd logs are stored in binary format and can only be accessed with journalctl. I would definitely give that command a shot.
I don’t know if the nouveau driver supports Vulkan on this, nor the nvidia driver, but if they don’t, then yes, you’ll get better performance on Windows.
I’ve used homeshick github.com/andsens/homeshick for a few years and it’s been running fine. It can load two git repos, one common public repo and one private one for work config.
NixOS. Not going to switch away from NixOS for servers probably ever even if I decide to distro-hop on my desktop in the future. It’s essentially what “traditional server distro + docker + ansible” can only dream of being. If you don’t mind learning a very different system, that is. Also the size of its package repository is only rivaled by AUR ;)
What laptop is it exactly? I’ve got that card in my Thinkpad T580 and it sucks big time. Not because of the card itself or because of Linux but because it has some insane thermal targets more or less hardcoded in the firmware.
Technically it’s fine. It has Vulkan support. It can run Doom 2016 at 30 fps. But as soon as it starts thermal throttling (and it does so very quickly) it clocks down to the lowest value. That way it even struggles to run Quake 3 at more than 6 or so fps.
Having it on battery power can sometimes get it working for half an hour or so. But sooner or later it will get too hot and only stopping the demanding process for a few minutes will get it to cool down enough.
There were apparently 2 different MX150 chips with very different power consumption (10w vs 25w), core clocks (937mhz vs 1468mhz), and memory bandwidth (40GB/s vs 48GB/s). I don’t think either of these are going to play GTA5 well, but the 10w part is probably much worse. Can you confirm which one you’ve got?
So, here’s my final update on this issue, and a possible solution/workaround: As the problem is due to crappy audio latency when using Wine, a way to avoid it is by giving it higher priority. If anyone has the issue, you can try using Feral’s gamemode. Launch your problematic app via gamemoderun, and it will decrease stuttering very significantly. If the game is really intense on CPU or you have other stuff getting it busy, it will still stutter, but it’s way less frequent on the game I’m currently playing (Outer Worlds), which is not very resource intensive. I’ll let you know once I try harder games.
If that’s the case, the mx150 needs to copy over the framebuffer to that one when you use the internal display. Performance can improve with an external display, but don’t expect wonders.
linux
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.