[Dev] Kernel modules parameters and blacklists Was: What I belive a Linux-libre bug (intel wifi constant nag)

Denis 'GNUtoo' Carikli GNUtoo at no-log.org
Mon Nov 23 20:53:41 GMT 2015


On Fri, 30 Oct 2015 07:31:07 +0200
Mikko Viinamäki <t8mf4nu6lizp at canaglie.net> wrote:

> Hi there! Looks like there is a problem with intel wifi that causes 
> constant error messages about missing firmware. This makes the
> machine slow and fills disks up when it gets logged. I believe the
> kernel in Trisquel 7 is Linux-libre 3.13.
I've the feeling that more could be done to support more hardware in
Trisquel.
In /etc/ you can:
-> Blacklist modules such as the intel wifi modules
-> Change modules options to make some wifi work reliably

At the end of the day such simple modifications make the hardware work.
Examples:
* Before attempting to make recent radeon cards work, I
  could make that card work again with the radeon driver:
  01:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
  [AMD/ATI] RV350/M10 [Mobility Radeon 9600 PRO Turbo]
  with options radeon dpm=0

* On some laptops with Intel wifi cards, Network manager gets confused,
  blacklisting the intel wifi driver makes the external USB card works
  fine.

* I also had to change kernel options to make a b43 card work well with
  the free firmware. I've still that card but the laptop that used it
  died.

On Trisquel expecting the user to do such work is not a good option, on
parabola it's more acceptable but still not great (users are power
users knowing how to configure their systems, but they probably don't
know that the openfwwf firmware for b43 required this or that kernel
option to work well).

I really wonder how to address that globally, I just notice that stuff
while trying to make Trisquel work on other people's laptop.

I've no idea:
-> Where to talk about such issue, Maybe Trisquel and Parabola mailing
   list should not be CCed but instead the problem should be raised on
   a mailing list common to all 100% free distros?
-> I really wonder who's task is it to fix it? The distros? linux-libre?
   Since theses are kernel parameters, the drivers have defaults at
   when they are declared.
   Should linux-libre change the defaults? That would carry yet one
   more patch around.
   Should the distros do it instead? like in /etc/modprobe.d ?
   For instance I could make Trisquel work well on an old laptop by
   disabling 3D acceleration in nouveau, so here we have an issue:
   The setting is driver wide, and applies to all nouveau GPU, while
   it's probably needed for very old GPU chips.
   How to check that changing some option won't have the opposite
   effect on other hardware that is driven by the same driver?
   With the blacklists, if we blacklist modules, we might miss the fact
   that it works without the firmware on some older hardware, that was
   the case with the radeon card mentioned above.

All that is such a mess, and I really don't see how to deal with it yet.
The only idea I had was to have some central website like h-node that
would store that info, like for instance:
Hardware(card model), driver options, kernel version and distro,
firmware version if any.

But then I don't know how would linux-libre or the distros deal with
that info.

Right now, some well known free software friendly hardware is working
well, is it worth trying to improve the situation? if we do, would it
end up being worse than the current state given the issues mentioned
above?

I'm sorry that this mail raises more questions than answers, I've been
thinking a bit about it, but I cound't find good ways to fix it beside
making sure that distros only do modifications that are expected to
work for all the hardware supported by the driver.
That could work for the b43 issue for instance.

Denis.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20151123/7bdb7f55/attachment.sig>


More information about the Dev mailing list