linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Prarit Bhargava <prarit@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-kernel@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
	Rusty Russell <rusty@rustcorp.com.au>,
	linux-doc@vger.kernel.org
Subject: Re: [PATCH] Add kernel parameter to blacklist modules
Date: Tue, 14 Jun 2016 13:55:28 -0400	[thread overview]
Message-ID: <57604510.7050804@redhat.com> (raw)
In-Reply-To: <20160614171702.GA20693@infradead.org>



On 06/14/2016 01:17 PM, Christoph Hellwig wrote:
> On Mon, Jun 13, 2016 at 08:32:41AM -0400, Prarit Bhargava wrote:
>> Blacklisting a module in linux has long been a problem.  The process of
>> blacklisting a module has changed over time, and it seems that every OS
>> does it slightly differently and depends on the age of the init system
>> used on that OS.
> 
> And why would we care about blacklisting a module?

<rant>
I have a new system that I want to install that a customer could not install any
Linux OS on.  It's sitting on my desk right now because I finally had to get
them to send me the system.  And I *cannot* get the bloody thing to install
anything recent because the damned nouveau driver keeps blowing up in the latest
Fedora rawhide (which is pretty close to upstream), or install anyting older
because the storage isn't detected on older releases.  I have *no* way of
stopping the driver from loading so that I can at least start debugging, or
provide valuable debug information in a kernel.org bugzilla (or appropriate
mailing list).

So what I'm stuck with now is a very expensive (albeit pretty) paperweight.
</rant>

Sorry about the rant ... but I had to let it all out Christoph ... :)

Now, I am smart enough to install to a USB stick, remove the nouveau driver from
both the install image and the initramfs, play around with the myriad and random
BIOS settings on this laptop (I will note that these are different for EVERY
piece of hardware) to figure out how to get the BIOS or EFI and Secure Boot
settings to detect the USB stick, cross my fingers and stand on one leg while I
pray to $deity that the system boots.

I do NOT expect random user to follow those steps in order to install Fedora or
another other upstream-following Linux OS.  They won't, and users turn to other
OSes that "just work".  That does nothing for the community.  It does nothing to
improve bug reporting.  It does nothing to improve the kernel.

I'd much rather tell those users to add "module_blacklist=nouveau" and send me
some debug information so I can find out what the issue might be, and find
hardware similar to theirs to help them out.  I still might have to tell that
user to send me their hardware but that's always a last resort.

P.

  reply	other threads:[~2016-06-14 17:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-13 12:32 [PATCH] Add kernel parameter to blacklist modules Prarit Bhargava
2016-06-13 21:23 ` Rusty Russell
2016-06-14 17:15   ` [PATCH v2] " Prarit Bhargava
2016-06-14 21:20     ` Rusty Russell
2016-06-15 13:38       ` Prarit Bhargava
2016-06-14 17:17 ` [PATCH] " Christoph Hellwig
2016-06-14 17:55   ` Prarit Bhargava [this message]
2016-06-14 20:51   ` Henrique de Moraes Holschuh
2016-06-14 22:51     ` Prarit Bhargava

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=57604510.7050804@redhat.com \
    --to=prarit@redhat.com \
    --cc=corbet@lwn.net \
    --cc=hch@infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).