On Wed, 27 Feb 2019 07:42:39 -0800 Ben Koenig <[email protected]> wrote:
> On 2/26/19 10:13 PM, Tom wrote: > > On Tue, 26 Feb 2019 18:33:14 -0800 > > Ben Koenig <[email protected]> wrote: > > > >> On 2/26/19 7:48 AM, King Beowulf wrote: > >>> On 2/25/19 9:52 PM, Ben Koenig wrote: > >>>> Considering how long it's taken nvidia to fix, I think you are > >>>> allowed to be cranky. > >>>> > >>>> I see a bunch of new downloads on their website, did they finally > >>>> fix it? > >>>> > >>>> Or do I need to place an order for a Vega 56? > >>>> > >>>> > >>>> > >>> You are gainfully employed now. go for ot! > >>> > >>> I haven't tested the Nvidia updates yet for the new Slackware > >>> kernels. In progress. > >>> > >>> -Ed > >>> > >> Bought a core3D sound card instead. Vega will have to wait. > >> > >> > >> Nvidia + Ryzen has been resulting in some lock ups for people. My > >> uptime has been capped at 4 days with nvidia-418.30 :( > >> > >> I'll know by Saturday if 418.43 fixed anything. FWIW my laptop > >> (ryzen 2700U) has been up for 22 days. I even left it in suspend > >> for a solid week and it came back up like a champ. > >> > >> > >> This is on -current, but if my system is still running at the end > >> of the week I'm gonna call the driver "stable". > >> > >> -Ben > >> > >> _______________________________________________ > >> PLUG mailing list > >> [email protected] > >> http://lists.pdxlinux.org/mailman/listinfo/plug > > I have heard that even some time after the initial launch of AMD > > Ryzen that suspending didn't even work on Linux. If such a trivial > > feature such as power management for Linux can be overlooked at a > > CPU launch date I can only assume that CPU still has quite a few > > bugs to knit out. > > > > Regarding Nvidia, > > https://invidio.us/watch?v=IVpOyKCNZYw > > > Careful with that video on public lists. The systemd community might > try to have you banned in accordance with their rigid CoC. > > It also might behoove you to understand the difference between a > driver bug, and a hardware flaw. > > > AMD is trying to prove that the software stack DOES have an affect on > the functionality of the overall product. This affect can be observed > at both the OS and application levels. We've spent decades assuming > that a "faster Intel CPU" will "make your computer faster". This is > not true, and IMO the best way to dispel such fallacies is through > proof of concept. > > Behold: > > 1) CPU runs like shit > > 2) Software is updated > > 3) CPU runs great > > 4) STUNNING CONCLUSION: > > CPU was not shit. > > Software was shit. > > > AMD is a hardware company. They make great hardware, and this has > always resulted in driver headaches. The reason I look the other way > is because AMD is a hardware company, so I don't actually give a shit > if their software sucks. > > Application of Intel power management algorithms to an AMD processor > caused problems? Really?! > > <sarcasm>I HAD NO IDEA THAT WAS A THING</sarcasm> > > _______________________________________________ > PLUG mailing list > [email protected] > http://lists.pdxlinux.org/mailman/listinfo/plug It's _IS_ a driver issue if the machine can't enter certain power states. And there is nothing 'Intel' about S power states either. S1, S2, S3, S4 etc. I wasn't talking about software (at least not userspace) but AMD's lack of driver support in Linux for their own flagship CPUs. _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
