On Friday, July 19, 2019 3:09:17 AM CDT, Hans-Peter Jansen wrote:

What does it buy you to live one or two weeks ahead, especially in the major kernel release version gap, other than dealing with yet another NVidia fallout, Virtualbox hassles, ... Check the change logs for reverts. They're done for a reason. I don't want to be my systems *that* reason.

All of this would not even be an issue if we didn't use KMP and used dkms as most distributions do. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

On Friday, July 19, 2019 8:44:54 AM CDT, Takashi Iwai wrote:

On Fri, 19 Jul 2019 15:03:46 +0200, simonizor wrote:

...

On Friday, July 19, 2019 3:09:17 AM CDT, Hans-Peter Jansen wrote: ...

It's mostly a matter of kernel API changes the downstream doesn't follow. If API changes, it breaks -- no matter whether DKMS or KMP.

Takashi

Sure, but KMP makes it so people can't even use kernel-vanilla of the same version as kernel-default in the default repos without their modules breaking. They have one choice: use the default kernel. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

On Friday, July 19, 2019 9:06:16 AM CDT, Takashi Iwai wrote:

On Fri, 19 Jul 2019 15:58:10 +0200, simonizor wrote:

...

On Friday, July 19, 2019 8:44:54 AM CDT, Takashi Iwai wrote: ...

It's pretty much irrelevant from DKMS vs KMP argument.

Technically seen a KMP can be built even for vanilla. We don't provide the vanilla-kmp as default, just because vanilla is vanilla.

Takashi

With dkms, you wouldn't have to provide separate things at all. One package works for all kernels. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

On Friday, July 19, 2019 9:14:14 AM CDT, Takashi Iwai wrote:

On Fri, 19 Jul 2019 16:09:15 +0200, simonizor wrote:

...

On Friday, July 19, 2019 9:06:16 AM CDT, Takashi Iwai wrote: ...

Basically that's same for KMP; it just a matter of configuration you may set in the spec file (or the rpm macro provided in the project).

Admittedly DKMS has many advantages, yes. But it's no silver bullet for all problems at all, either.

Takashi

Yes, but the user needs to know how to do all of these things. With DKMS, it's a pretty much "just works" solution. KMP is not at all user friendly for anyone who doesn't want to use the default kernel. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

On Fri, 19 Jul 2019 16:15:33 +0200, simonizor wrote:

On Friday, July 19, 2019 9:14:14 AM CDT, Takashi Iwai wrote:

...

On Fri, 19 Jul 2019 16:09:15 +0200, simonizor wrote:

...

On Friday, July 19, 2019 9:06:16 AM CDT, Takashi Iwai wrote: ...

Basically that's same for KMP; it just a matter of configuration you may set in the spec file (or the rpm macro provided in the project).

Admittedly DKMS has many advantages, yes. But it's no silver bullet for all problems at all, either.

Takashi

Yes, but the user needs to know how to do all of these things. With DKMS, it's a pretty much "just works" solution. KMP is not at all user friendly for anyone who doesn't want to use the default kernel.

DKMS is "just works" only because you know about DKMS, too. I suppose that DKMS is often easier to manage, too, but my point is that DKMS is no solution for the problems of Nvidia or VirtualBox breakages that have been suggested in this thread. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

PGNet Dev composed on 2019-07-19 08:08 (UTC-0700):

nvidia's proprietary drivers continue to be a preferable solution here to nouveau.

You write as if the competent choices are two, when in fact, there are three. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

PGNet Dev composed on 2019-07-19 10:40 (UTC-0700):

Felix Miata wrote:

...

You write as if the competent choices are two, when in fact, there are three.

No idea what that's supposed to mean.

I've simply stated the choice I've made from the 2 options I consider.

What stops you from considering the upstream default option? It doesn't scare you asking you to acknowledge its limitations when you install or upgrade. # inxi -Gxx Graphics: Device-1: NVIDIA GF119 [NVS 310] vendor: Hewlett-Packard driver: nouveau v: kernel bus ID: 01:00.0 chip ID: 10de:107d Fermi based Display: tty server: X.Org 1.20.4 driver: modesetting unloaded: fbdev,vesa alternate: nouveau,nv,nvidia compositor: kwin_x11 resolution: 2560x1440~60Hz, 1920x1200~60Hz OpenGL: renderer: llvmpipe (LLVM 7.0 128 bits) v: 3.3 Mesa 19.0.5 compat-v: 3.1 direct render: Yes -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

PGNet Dev composed on 2019-07-19 10:59 (UTC-0700):

i have no idea what you're talking about, or what point you're attempting to make.

How can you know which driver suits you best if you haven't even tried the (upstream default) DDX, aka /modesetting/, provided by xorg-x11-server rpm? # rpm -qa | egrep -i 'xf86-video|nvidia|modeset' xf86-video-fbdev-0.5.0-1.7.x86_64 xf86-video-vesa-2.4.0-1.7.x86_64 # xrandr | egrep 'onnect|creen|\*' | grep -v disconn | sort -r Screen 0: minimum 320 x 200, current 2560 x 2640, maximum 16384 x 16384 DP-2 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 519mm x 324mm DP-1 connected primary 2560x1440+0+1200 (normal left inverted right x axis y axis) 598mm x 336mm 2560x1440 59.95*+ 74.92 1920x1200 59.95*+ # xdpyinfo | grep dimen dimensions: 2560x2640 pixels (541x558 millimeters) # inxi -GxxS System: Host: p5bse Kernel: 5.1.16-1-default x86_64 bits: 64 compiler: gcc v: 9.1.1 Desktop: KDE Plasma 5.16.2 tk: Qt 5.13.0 wm: kwin_x11 dm: startx Distro: openSUSE Tumbleweed 20190717 Graphics: Device-1: NVIDIA GF119 [NVS 310] vendor: Hewlett-Packard driver: nouveau v: kernel bus ID: 01:00.0 chip ID: 10de:107d Display: tty server: X.Org 1.20.5 driver: modesetting unloaded: fbdev,vesa alternate: nouveau,nv,nvidia compositor: kwin_x11 resolution: 2560x1440~60Hz, 1920x1200~60Hz OpenGL: renderer: llvmpipe (LLVM 8.0 128 bits) v: 3.3 Mesa 19.1.2 compat-v: 3.1 direct render: Yes # egrep -i 't\(0\)|modeset|connect' /var/log/Xorg.0.log | grep -v 'not conn' | head -n6 [ 679.616] (==) Matched modesetting as autoconfigured driver 3 [ 679.617] (II) LoadModule: "modesetting" [ 679.617] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so [ 679.617] (II) Module modesetting: vendor="X.Org Foundation" [ 679.617] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [ 679.617] (II) modeset(0): using drv /dev/dri/card0 # grep -i unload /var/log/Xorg.0.log [ 681.372] (II) UnloadModule: "fbdev" [ 681.372] (II) Unloading fbdev [ 681.372] (II) UnloadSubModule: "fbdevhw" [ 681.372] (II) Unloading fbdevhw [ 681.372] (II) UnloadModule: "vesa" [ 681.372] (II) Unloading vesa -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

Andrei Borzenkov composed on 2019-07-20 07:19 (UTC+0300):

Felix Miata composed:

...

PGNet Dev composed on 2019-07-19 10:40 (UTC-0700):

...

...

Felix Miata wrote:

...

...

...

You write as if the competent choices are two, when in fact, there are three.

...

...

No idea what that's supposed to mean.

...

...

I've simply stated the choice I've made from the 2 options I consider.

...

What stops you from considering the upstream default option?

That's option 2. What is the third option you were talking about?

Option 1, apparently most popular: non-FOSS (proprietary) NVidia Option 2, openSUSE default: FOSS nouveau DDX, provided by (upstream optional) rpm xf86-video-nouveau Option 3, upstream default: FOSS modesetting DDX, provided by xorg-x11-server rpm -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

Andrei Borzenkov composed on 2019-07-20 09:16 (UTC+0300):

Felix Miata composed:

...

Option 2, openSUSE default: FOSS nouveau DDX, provided by (upstream optional) rpm xf86-video-nouveau

...

Option 3, upstream default: FOSS modesetting DDX, provided by xorg-x11-server rpm

This is opensuse-kernel, not opensuse-xorg list. There are two kernel drivers - nouveau or nvidia.

The language initially replied to was: nvidia's proprietary drivers Yes, NVidia's drivers are of two types, kernel, and X. However, just because a post is on a kernel list doesn't necessarily mean only the former type can be inferred as the subject matter. For X there are (the) three types I listed. Thus the post replied to was unclear and my intent was in no small part to elicit clarification on the subject of video "drivers" generally. Of the X type it seems few have any idea there are more than two to choose from, much less a need to be specific whether the kernel or X type, or both, is the subject matter. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

On Fri, 19 Jul 2019 19:21:25 +0200, simonizor wrote:

On Friday, July 19, 2019 9:25:32 AM CDT, Takashi Iwai wrote:

...

DKMS is "just works" only because you know about DKMS, too.

Actually, I know next to nothing about it other than it allows me to use drivers such as NVIDIA with pretty much any kernel version without having to worry. I used Ubuntu's nvidia-dkms driver package for quite some time on many different kernel versions without ever having to do anything myself. This is not ever the case for KMP.

Well, that's the difference by how to look at the whole process. You've got positive results, but it's just merely because someone already worked on it to make things working before you try. That's not DKMS that fixes the build issues by the kernel API changes automagically. You haven't seen the people behind the scene, hence you'd believe it being DKMS as an exposed result. That said, pushing DKMS into Tumbleweed or Kernel:stable *alone* won't help much as advertised. Someone still needs to step in and resolve the issues quickly. It's irrelevant whether DKMS or KMP. Unfortunately, on openSUSE, a fix for Nvidia or such is often behind Ubuntu simply because fewer developers are interested in it. And, if the problem is about pure packaging, it should be reported as quickly as possible to Bugzilla, and we're going to address it in timely manner. Switching to DKMS should be discussed only after it's confirmed that this kind of feedback cycle doesn't work well. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

On Fri, 19 Jul 2019 16:06:16 +0200, Takashi Iwai wrote:

On Fri, 19 Jul 2019 15:58:10 +0200, simonizor wrote:

...

On Friday, July 19, 2019 8:44:54 AM CDT, Takashi Iwai wrote:

...

On Fri, 19 Jul 2019 15:03:46 +0200, simonizor wrote:

...

On Friday, July 19, 2019 3:09:17 AM CDT, Hans-Peter Jansen wrote: ...

It's mostly a matter of kernel API changes the downstream doesn't follow. If API changes, it breaks -- no matter whether DKMS or KMP.

Takashi

Sure, but KMP makes it so people can't even use kernel-vanilla of the same version as kernel-default in the default repos without their modules breaking. They have one choice: use the default kernel.

It's pretty much irrelevant from DKMS vs KMP argument.

Technically seen a KMP can be built even for vanilla. We don't provide the vanilla-kmp as default, just because vanilla is vanilla.

... and to be more noted: the difference between vanilla and default on TW is fairly minimalistic, hence there won't be much benefit to provide extra resources for building a vanilla-kmp. Maybe Leap is a different story; but I'm not going further to that direction, as it'll be a discussion about how to manage Leap kernels in general :) Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

On Fri, 19 Jul 2019 16:14:03 +0200, simonizor wrote:

On Friday, July 19, 2019 9:10:32 AM CDT, Takashi Iwai wrote:

...

On Fri, 19 Jul 2019 16:06:16 +0200, Takashi Iwai wrote:

...

On Fri, 19 Jul 2019 15:58:10 +0200, simonizor wrote: ...

... and to be more noted: the difference between vanilla and default on TW is fairly minimalistic, hence there won't be much benefit to provide extra resources for building a vanilla-kmp.

Maybe Leap is a different story; but I'm not going further to that direction, as it'll be a discussion about how to manage Leap kernels in general :)

Takashi

I don't think you get my point... with the KMP setup, someone who has modules that use KMP cannot even use kernel-vanilla. With dkms, they can use whatever kernel they want. Someone on Ubuntu isn't limited to the default kernel in their repos; they can use the latest kernel without doing anything to something like their NVIDIA packages.

Of course, it's a drawback of KMP. The build is done in outside. But this is also an advantage. You don't need any toolchain for installing a KMP in general. (Nvidia package is an exception in this regard because it is Nvidia, who always needs avoid GPL-thingies :) Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

On Friday, July 19, 2019 9:12:41 AM CDT, Michal Kubecek wrote:

KMPs are built for a particular flavor. You just need foo-kmp-vanilla instead of foo-kmp-default if you want to switch to kernel-vanilla.

Michal Kubecek

Are you sure that's even a thing? I know broadcom-wl has no broadcom-wl-kmp-vanilla, and 'zypper se kmp-vanilla' gives 'No matching items found.'... -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

On Friday, July 19, 2019 2:26:33 PM CDT, Takashi Iwai wrote:

On Fri, 19 Jul 2019 19:11:56 +0200, simonizor wrote:

...

On Friday, July 19, 2019 9:12:41 AM CDT, Michal Kubecek wrote: ...

Usually it's not built for vanilla. A part of reasons is thatit'd be a bit trickier to build from two different source trees (vanilla and default have different sources in the end). And, as already mentioned, it makes little sense to build a vanilla KMP for TW, as the difference between vanilla and default is pretty small, so no one ever tried toward that direction. But technically seen, there is nothing to stop building vanilla KMP by yourself if you inevitably need it.

Takashi

I have no interest in touching KMP lol... I would just use dkms like everyone else does. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

On Fri, 19 Jul 2019 10:10:52 +0200, Jiri Slaby wrote:

I usually don't mind (or care) as I personally use Kernel:stable anyway (*). But due to this, recently, the TCP SACK CVE fixes landed to Tumbleweed long after the EMBARGO was dropped and long after many other distributions already had a fixed kernel. Given users like you are complaining staging managers might consider a change :).

There is Tumbleweed:Update for a faster update path, IIRC, so if the fix is urgently requested, we can push to there, too. thanks, Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

On Fri, Jul 19, 2019 at 10:50:17AM +0200, Richard Brown wrote:

On Fri, 19 Jul 2019 at 10:43, Jiri Slaby wrote:

...

I usually don't mind (or care) as I personally use Kernel:stable anyway (*). But due to this, recently, the TCP SACK CVE fixes landed to Tumbleweed long after the EMBARGO was dropped and long after many other distributions already had a fixed kernel. Given users like you are complaining staging managers might consider a change :).

Yup, that seems suboptimal. I would imagine the staging managers had no idea there was anything special about this kernel submission.

Did anyone notify the staging managers regarding the CVE sensitivity of the submission?

I've found that a note in an SR, an email or a ping in IRC to any of the staging managers is universally met with my request being handled in the way I wish. I would be shocked if they couldn't have shoved the kernel in its own staging and got it through quickly.

I'm having to do that right now given I've got half a dozen submissions that absolutely need the opposite treatment - they need to be clumped together and care taken to ensure we only merge them as one unified blob :)

We occasionaly ping dimstar on critical security issues. AFAIR for SACK fixes these also had problems with overlayfs at the same time, where openqa used overlayfs incorrectly. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

hi, Am 19.07.19 um 10:10 schrieb Jiri Slaby:

On 19. 07. 19, 5:38, simonizor wrote:

...

Is there a reason for this?  I personally have not had a single issue with the kernels from the kernel:stable repo (I'm using 5.2.1 right now without a single hiccup), so the quality of the kernels does not seem to be the issue. I, as a maintainer of that kernel, can only say, that the process from

THANK YOU for that. i use it since years now! -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales *DI Rainer Klier* DevOps, Research & Development -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org