On Tue, Apr 03, 2018 at 03:47:57PM +0200, Michel Dänzer wrote: > On 2018-04-03 03:39 PM, Ilia Mirkin wrote: > > On Tue, Apr 3, 2018 at 9:32 AM, Michel Dänzer <michel@xxxxxxxxxxx> wrote: > >> On 2018-04-03 03:26 PM, Ilia Mirkin wrote: > >>> On Tue, Apr 3, 2018 at 5:29 AM, Daniel Vetter <daniel@xxxxxxxx> wrote: > >>>> On Sun, Apr 01, 2018 at 10:12:10PM +0200, Christian König wrote: > >>>>> Am 01.04.2018 um 20:21 schrieb Takashi Iwai: > >>>>>> On Sun, 01 Apr 2018 19:58:11 +0200, > >>>>>> Christian K6nig wrote: > >>>>>>> Am 01.04.2018 um 19:45 schrieb Ilia Mirkin: > >>>>>>>> On Sun, Apr 1, 2018 at 1:39 PM, Christian König > >>>>>>>> <christian.koenig@xxxxxxx> wrote: > >>>>>>>>> Am 30.03.2018 um 22:45 schrieb Takashi Iwai: > >>>>>>>>>> amdgpu driver lacks of modeset module option other drm drivers provide > >>>>>>>>>> for enforcing or disabling the driver load. Interestingly, the > >>>>>>>>>> amdgpu_mode variable declaration is already found in the header file, > >>>>>>>>>> but the actual implementation seems to have been forgotten. > >>>>>>>>>> > >>>>>>>>>> This patch adds the missing piece. > >>>>>>>>> NAK, modesetting is mandatory for amdgpu and we should probably remove the > >>>>>>>>> option to disable it from other DRM drivers without UMS support as well > >>>>>>>>> (pretty much all of them now). > >>>>>>>>> > >>>>>>>>> If you want to prevent a driver from loading I think the correct way to do > >>>>>>>>> so is to give modprobe.blacklist=amdgpu on the kernel commandline. > >>>>>>>>> > >>>>>>>>> That would remove the possibility to prevent the driver from loading when it > >>>>>>>>> is compiled in, but I don't see much of a problem with that. > >>>>>>>> Having a way to kill the graphics driver is a very useful debugging > >>>>>>>> tool, and also a quick and easy way to get out of an unpleasant > >>>>>>>> situation where graphics are messed up / system hangs / etc. The > >>>>>>>> modprobe blacklist kernel arg only works in certain environments (and > >>>>>>>> only if it's a module). > >>>>>>>> > >>>>>>>> Every other DRM driver has this and this is a well-documented > >>>>>>>> workaround for "graphics are messed up when I install linux", why not > >>>>>>>> allow a uniform experience for the end users who are just trying to > >>>>>>>> get their systems up and running? > >>>>>>> Because it is not well documented and repeated over and over again in > >>>>>>> drivers. > >>>>>>> > >>>>>>> The problem is that people don't realized that the driver isn't loaded > >>>>>>> at all without the modeset=0 module option and demand fixing the > >>>>>>> resulting bad performance without modesetting. > >>>>>> Hm, I don't get it. What this options has to do with performance for > >>>>>> a KMS-only driver...? > >>>>> > >>>>> Well exactly that's the point, nothing. > >>>>> > >>>>> The problem is that the option name is confusing to the end user because the > >>>>> expectation is that "nomodeset" just means that they only can't change the > >>>>> display mode. > >>>>> > >>>>> Some (unfortunately quite a lot) people don't realize that for KMS drivers > >>>>> this means that the driver isn't even loaded and they also don't get any > >>>>> acceleration. > >>>>> > >>>>> We had to explain that numerous times now. I think it would be best to give > >>>>> the option a more meaningful name. > >>>> > >>>> Yeah, agreed with Christian. If we want a generic "pls disable all gfx > >>>> accel" knob then probably best to put that into the drm core. And just > >>>> outright fail loading the drm core if that happens, which will prevent all > >>>> gfx drivers from loading. > >>>> > >>>> That likely means a hole bunch of stuff won't work (usually sound keels > >>>> over too), but that's what you get for this. Only disabling modesetting > >>>> without disabling the entire driver doesn't work (never has, except for > >>>> this UMS+GEM combo only i915 support, and not for long). > >>>> > >>>> And once we have that knob, probably best to phase out all the per-driver > >>>> options. > >>> > >>> Another use-case that the per-driver disables enable is "i915 works > >>> but nouveau is broken due to crazy ACPI / PCIe PM / whatever". It > >>> seems likely this could happen with amdgpu as well. > >> > >> modprobe.blacklist=amdgpu > >> > >> works as well as the modeset parameter for this. > > > > People who build their own kernels run into trouble too. > > There have always been various more or less serious issues with building > amdgpu (and radeon) into the kernel. People who do so get to keep all > pieces when it breaks. > > > > Also does this work uniformly across all systems where it is a module? > > AFAIK yes. Sadly modprobe.blacklist doesn't prevent X/whatever from loading the module anyway. I use modprobe.blacklist myself all the time for i915 development, but I also have all GUI junk disabled as well so that I can load the module myself when I'm actually ready for it (typically after I've enabled netconsole). -- Ville Syrjälä Intel OTC _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
