On Tue, Apr 03, 2018 at 05:06:03PM +0300, Ville Syrjälä wrote: > 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 at daenzer.net> wrote: > > >> On 2018-04-03 03:26 PM, Ilia Mirkin wrote: > > >>> On Tue, Apr 3, 2018 at 5:29 AM, Daniel Vetter <daniel at ffwll.ch> 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 at amd.com> 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. fwiw, same roughly applies for i915. We try to make it work, by allowing firmware to be loaded later on and asynchronously. But if you fail to provide firmware the driver simply hangs forever. At least in certain cases, for others we simply never clock gate/shutdown the chip. Also not awesome (and we're closing all corresponding bug reports too). We don't yet need firmware for basic display support, so you'll get at least a picture to be able to look at dmesg. If you remember to start X without accel, that is :-) > > > 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. A generic "please don't bind anything to this device path" kernel property would be really nice for this. And hopefully something that could be merged into the drivers/base core code. Plus a generic and all-encompassing no_modeset^Wno_gfx_I_mean_it knob would cover everything I think. -Daniel > 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). Oh, that's why modprobe.blacklist never works for me. TIL. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
