NVIDIA's Binary Driver Doesn't Yet Play Nicely With Linux 4.15

[DanL]

I'm sure we're all now safer and more secure from the sleeper cells conspiring in caves. I wouldn't ask Linus for his opinion on such matters though...
http://lkml.iu.edu/hypermail/linux/k...1.2/01701.html

And this is relevant to the topic... how? Also, would it be too much to ask for you to make a comment without referring to sleeper cells (or is that too tightly integrated into your InsideJob shtick)?

[reavertm]

You didn't get what he sounds like and intend to imply.

" Nvidia's problem is there all the time , not specific to 4.15. That is why i'm suffering even on 4.12 too. "

Proposal : Use 4.14 instead of it cause it works and that is not an ongoing , continued problem like you meant.

https://i.hizliresim.com/qJa9DD.png

Calm down folks, I didn't want to start flamewar over my graphics card :P
(which might be actually failing hardware wise, after six years, Asus GTX 570 DirectCUII, problems now also observed under Windows with more demanding games)

[ElectricPrism]

If I could trade out all Nvidia GPU's in all my 15 workstations and laptops I would instantly.

Thank god some of the laptops have Intel graphics to fall back on.

Nvidia on Linux is just a bad choice if you care about stability at all.

[VikingGe]

Wasn't the latest vega cards this year not working several kernel releases?

We can only hope that AMD have learned from their DC/DAL fiasco and can provide proper Day One support for future GPUs. Then again, there are ways to make them work properly with the OSS drivers, it's just not particularly user friendly.

[zoomblab]

We can only hope that AMD have learned from their DC/DAL fiasco and can provide proper Day One support for future GPUs. Then again, there are ways to make them work properly with the OSS drivers, it's just not particularly user friendly.

This model, where a driver for a piece of hardware must be included in the kernel, does not scale. It is common sense. Even if linux was the most successful OS on the planet, it would be unreasonable to expect any hardware manufacturers to have to align their product releases such as that drivers to exist in the kernel. And even if someone managed to accomplish this there would always be the problem of having to support users that run older kernels. So common sense says that there has to be a way for manufacturers to provide drivers independently of the kernel tree and schedule. That requires stable kernel interfaces or - since such thing does not exist - this someone needs to invent the wheel (kernel abstractions) in their driver package. And because that is common sense, people should be tolerant with the implications of such strategy.

[Guest]

This model, where a driver for a piece of hardware must be included in the kernel, does not scale. It is common sense. Even if linux was the most successful OS on the planet, it would be unreasonable to expect any hardware manufacturers to have to align their product releases such as that drivers to exist in the kernel. And even if someone managed to accomplish this there would always be the problem of having to support users that run older kernels. So common sense says that there has to be a way for manufacturers to provide drivers independently of the kernel tree and schedule. That requires stable kernel interfaces or - since such thing does not exist - this someone needs to invent the wheel (kernel abstractions) in their driver package. And because that is common sense, people should be tolerant with the implications of such strategy.

There is one counter argument here, Intel. They have experimental drivers in kernel MONTHS before HARDWARE release. GKH complained as a joke that they had to delete some code from linux because the chip they added support for was never released. That is the kind of tier1 support you don't really get with AMD.
Also, stable interfaces don't matter if you actively contribute to the kernel and shape it's development. It's cheaper to lag behind and fix things on the fly though (case in point - AMD/Nvidia).

[andre30correia]

If I could trade out all Nvidia GPU's in all my 15 workstations and laptops I would instantly.

Thank god some of the laptops have Intel graphics to fall back on.

Nvidia on Linux is just a bad choice if you care about stability at all.

no stable? kidding right?, probaly you don't have a single nvidia gpu and you are a troll

[andre30correia]

I doesn't play with 4.12.12 either. Sporadic X11 server hangs (magic SysRq 'sync' 'umount' 'reboot' sequence needed), errors in games like

[ 639.737134] NVRM: GPU at PCI:0000:01:00: GPU-0a3fe00d-d4cf-7c08-c7a9-99bb6a5222aa
[ 639.737138] NVRM: Xid (PCI:0000:01:00): 13, Graphics Exception on GPC 0: 3D-C MEMLAYOUT Violation. Coordinates: (0x30, 0x0)
[ 639.737140] NVRM: Xid (PCI:0000:01:00): 13, Graphics Exception: ESR 0x500420=0x80000400 0x500434=0x30 0x500438=0x2a00 0x50043c=0x10000
[ 639.737150] NVRM: Xid (PCI:0000:01:00): 13, Graphics Exception on GPC 1: 3D-C MEMLAYOUT Violation. Coordinates: (0x0, 0x0)
[ 639.737152] NVRM: Xid (PCI:0000:01:00): 13, Graphics Exception: ESR 0x508420=0x80000400 0x508434=0x0 0x508438=0x2a00 0x50843c=0x10000
..
Behold the magic of blob.

I install nvidia driver , the last one and it works with kernel 4.12.14, the problem is in your OS or machine

[starshipeleven]

We can only hope that AMD have learned from their DC/DAL fiasco and can provide proper Day One support for future GPUs.

There is nothing to learn and it's not a "fiasco", everyone knows that upstreaming shit takes a long time.

Now that DC is mainlined they can add new GPUs to it without much drama.

[bridgman]

We can only hope that AMD have learned from their DC/DAL fiasco and can provide proper Day One support for future GPUs. Then again, there are ways to make them work properly with the OSS drivers, it's just not particularly user friendly.

For previous GPUs we had to double-implement the display code each time - DC-based code for AMDGPU-PRO and OEM / embedded customers (using AMDGPU-PRO kernel plus open source userspace), plus a simpler non-DC version for upstream.

Vega10 was the first GPU where we felt that DC was sufficiently close to going upstream that we did not implement a duplicate display code base and instead focused on getting DC upstream more quickly. We did have DC-based code in public repos at launch as you mentioned - the only thing missing was getting DC upstream.

I suppose you could call that a fiasco but we felt it was a reasonable decision given the timing.