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