[opensuse-kernel] Compiling KMP that depends on another KMP (was: Re: [opensuse-factory] [Resolved] Leap 42.3 kernel 4.4.71x and problem installing the Nvidia driver)
Of course, nothing is "resolved" by removing package that is part of distribution. It just helps to diagnose it. 19.06.2017 02:32, Roman Bysh пишет:
Hi everybody,
If you have a problem in Leap 42.3 installing your Nvidia driver you must remove the "drm-knp-default" package.
Oh! So, how does one compile KMP that depends on another KMP, which itself overrides in-tree kernel driver? We somehow need to pickup correct symbol versions, otherwise we get [ 202.462673] nvidia_drm: disagrees about version of symbol drm_atomic_get_connector_state [ 202.462674] nvidia_drm: Unknown symbol drm_atomic_get_connector_state (err -22) [ 202.462679] nvidia_drm: disagrees about version of symbol drm_gem_prime_export [ 202.462680] nvidia_drm: Unknown symbol drm_gem_prime_export (err -22) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Mon, 19 Jun 2017 05:20:06 +0200, Andrei Borzenkov wrote:
Of course, nothing is "resolved" by removing package that is part of distribution. It just helps to diagnose it.
19.06.2017 02:32, Roman Bysh пишет:
Hi everybody,
If you have a problem in Leap 42.3 installing your Nvidia driver you must remove the "drm-knp-default" package.
Oh! So, how does one compile KMP that depends on another KMP, which itself overrides in-tree kernel driver?
Depends, and it's note quite easy.
We somehow need to pickup correct symbol versions, otherwise we get
[ 202.462673] nvidia_drm: disagrees about version of symbol drm_atomic_get_connector_state [ 202.462674] nvidia_drm: Unknown symbol drm_atomic_get_connector_state (err -22) [ 202.462679] nvidia_drm: disagrees about version of symbol drm_gem_prime_export [ 202.462680] nvidia_drm: Unknown symbol drm_gem_prime_export (err -22)
This case is unfortunately very hard to resolve. The changes in the drm are so large, thus we can't keep symbols to be compatible. (It's possible to hack so that symbols appear same, but it doesn't help unless the call functionality is aligned as well -- i.e. you may change the struct fields identical with two kernel versions, but if the usage of the struct is different, it shall crash.) It'd be possible to export include/drm/*.h and include/uapi/drm/*.h as another *-devel package, but then still you'd need to hack nvidia build system to refer to these include files as well. So it can't work as is, either. The simplest and probably best option is to uninstall the DRM stack update if you're using Nvidia driver, after all... Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
19.06.2017 10:36, Takashi Iwai пишет:
[ 202.462673] nvidia_drm: disagrees about version of symbol drm_atomic_get_connector_state [ 202.462674] nvidia_drm: Unknown symbol drm_atomic_get_connector_state (err -22) [ 202.462679] nvidia_drm: disagrees about version of symbol drm_gem_prime_export [ 202.462680] nvidia_drm: Unknown symbol drm_gem_prime_export (err -22)
This case is unfortunately very hard to resolve. The changes in the drm are so large, thus we can't keep symbols to be compatible. (It's possible to hack so that symbols appear same, but it doesn't help unless the call functionality is aligned as well -- i.e. you may change the struct fields identical with two kernel versions, but if the usage of the struct is different, it shall crash.)
Which is why I find this solution rather questionable. It breaks kABI for one of kernel subsystems, so I'd really expect it to be part of different kernel flavor.
It'd be possible to export include/drm/*.h and include/uapi/drm/*.h as another *-devel package, but then still you'd need to hack nvidia build system to refer to these include files as well. So it can't work as is, either.
The simplest and probably best option is to uninstall the DRM stack update if you're using Nvidia driver, after all...
What about hybrid systems that need this patch for Intel part? -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Mon, 19 Jun 2017 18:59:57 +0200, Andrei Borzenkov wrote:
19.06.2017 10:36, Takashi Iwai пишет:
[ 202.462673] nvidia_drm: disagrees about version of symbol drm_atomic_get_connector_state [ 202.462674] nvidia_drm: Unknown symbol drm_atomic_get_connector_state (err -22) [ 202.462679] nvidia_drm: disagrees about version of symbol drm_gem_prime_export [ 202.462680] nvidia_drm: Unknown symbol drm_gem_prime_export (err -22)
This case is unfortunately very hard to resolve. The changes in the drm are so large, thus we can't keep symbols to be compatible. (It's possible to hack so that symbols appear same, but it doesn't help unless the call functionality is aligned as well -- i.e. you may change the struct fields identical with two kernel versions, but if the usage of the struct is different, it shall crash.)
Which is why I find this solution rather questionable. It breaks kABI for one of kernel subsystems, so I'd really expect it to be part of different kernel flavor.
Well, it's natural that something crashes when you update two things in the same region :) The drm-kmp solution was decided because of two reasons: - This opt-in style can be much easier and manageable than error-prone backports of thousands patches; i915 is especially notorious about the difficulty of backports. - User can still opt-out it in case something got broken; the graphics support state will be equivalent with the former, Leap 42.2 kernel.
It'd be possible to export include/drm/*.h and include/uapi/drm/*.h as another *-devel package, but then still you'd need to hack nvidia build system to refer to these include files as well. So it can't work as is, either.
The simplest and probably best option is to uninstall the DRM stack update if you're using Nvidia driver, after all...
What about hybrid systems that need this patch for Intel part?
It should still work in the level of Leap 42.2. That is, if it's Intel Kabylake and Nvidia combination, it can't, and user would need to use the later upstream kernel instead. The Skylake and older should work -- but maybe with some known bugs unfixed. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
19.06.2017 20:16, Takashi Iwai пишет: ...
The simplest and probably best option is to uninstall the DRM stack update if you're using Nvidia driver, after all...
What about hybrid systems that need this patch for Intel part?
It should still work in the level of Leap 42.2. That is, if it's Intel Kabylake and Nvidia combination, it can't, and user would need to use the later upstream kernel instead. The Skylake and older should work -- but maybe with some known bugs unfixed.
OK, so the remaining question is - how to limit install of this KMP to systems that actually need it. Currently it looks like users unconditionally get it (at least, multiple users are having the same issue). -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Mon, 19 Jun 2017 19:31:34 +0200, Andrei Borzenkov wrote:
19.06.2017 20:16, Takashi Iwai пишет: ...
The simplest and probably best option is to uninstall the DRM stack update if you're using Nvidia driver, after all...
What about hybrid systems that need this patch for Intel part?
It should still work in the level of Leap 42.2. That is, if it's Intel Kabylake and Nvidia combination, it can't, and user would need to use the later upstream kernel instead. The Skylake and older should work -- but maybe with some known bugs unfixed.
OK, so the remaining question is - how to limit install of this KMP to systems that actually need it. Currently it looks like users unconditionally get it (at least, multiple users are having the same issue).
All users that don't need Nvidia binary or AMDGPU-pro should install drm-kmp. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
participants (2)
-
Andrei Borzenkov -
Takashi Iwai