Originally posted by partcyborg
View Post
Announcement
Collapse
No announcement yet.
NVIDIA 470.74 Linux Driver Released With Several Fixes
Collapse
X
-
Originally posted by mdedetrich View Post
And then you can bring in regressions or unknown changes from a future Kernel. The point is that with the Nvidia blob you can change the driver independently from everything else.
Comment
-
Comment
-
Looking forward to trying this once it hits the Ubuntu repos... But it sounds like it has only fixed one issue with the new /proc/driver/nvidia/suspend interface. What a trainwreck this new interface has been. Sometimes resuming from hibernate works all the time, sometimes it only works once, sometimes it works never. Seems to depend on the alignment of the planets, the day of the week, and the mood the GPU is in. For now, I've set my laptop to only use the Intel iGPU and now resuming from hibernate works 100% of the time.
You can still use the older approach (this can be controlled with the NVreg_PreserveVideoMemoryAllocations module parameter)... But it works terribly. For me, the old approach consistently lets me resume from hibernate once, and after that I get a hang on resume until X finally crashes, restarts, and I'm at the login screen.
Fortunately, it looks like we might finally might be starting to see gaming laptops with high powered AMD GPU's. At least I could dig into the issue with AMD hardware and possibly submit my own patch if no one else was willing to dig into it (I did this recently to add speaker output for several Lenovo laptops).
Sorry for the rant but these resume from hibernate issues with Nvidia have really frustrated me over the last 1.5 months.
Comment
-
Originally posted by partcyborg View Post
Is this some kind of trolling attempt?
Oh well, I'll bite. Please show me examples of said "basic googling" that reveals your supposed major kernel version releases full of regressions
And yeah if the kernel had zero regressions than the main business case of redhat would be meaningless (they deliberately postpone updating to new kernels because of potential regressions, rather they backport fixes from future kernels as needed)
Comment
-
Originally posted by mdedetrich View Post
This took me 10 seconds to find https://www.phoronix.com/scan.php?pa...fairness&num=1
And yeah if the kernel had zero regressions than the main business case of redhat would be meaningless (they deliberately postpone updating to new kernels because of potential regressions, rather they backport fixes from future kernels as needed)
While phoronix has plenty of articles covering prerelease issues, they are all always ironed out well before a stable release.
So I'll ask again. Show me examples of kernel RELEASES (as in, NOT development versions) with regressions.
Comment
-
Originally posted by partcyborg View Post
If you would have spent another 10 seconds on reading comprehension you would have seen that this article is for an UNRELEASED version of 5.9. Nowhere did I, or anyone for that matter suggest building a kernel from a deveopment branch.
While phoronix has plenty of articles covering prerelease issues, they are all always ironed out well before a stable release.
So I'll ask again. Show me examples of kernel RELEASES (as in, NOT development versions) with regressions.
The kernel having regressions is rare but not impossible and if you see how the kernel is "tested" you will see why, tl;dr the Kernel almost completely relies on the community during RC's to see if there regressions, although there are kunit/kselftest that is part of the kernel the coverage is incredibly small.
Comment
Comment