blacklisting issue, perhaps initscripts or kernel 3.0 related
 

Am 01.08.2011 09:30, schrieb Tobias Powalowski:
> To explain it a bit better:
> Arch always had the possibility to load modules in a certain order by
> using the MODULES= array in rc.conf.

Preservation of order has not been working for several initscripts releases.

blacklisting issue, perhaps initscripts or kernel 3.0 related
 

Am Mon, 01 Aug 2011 09:30:27 +0200
schrieb Tobias Powalowski <tobias.powalowski@googlemail.com>:

> In the past people had more than one soundcard in the pc, the problem
> by autoloading modules with udev, could change the order of this
> sounddevices. This is not that much a problem anymore, modern systems
> mostly have only one soundcard installed.

At least regarding soundcards this is not true. Also loading the
soundcard modules by using the MODULES array can lead to different
orders. The only way of having them loaded in a specific order is to
using the index parameter in /etc/modprobe.d/modprobe.conf.

I don't know how it is for other modules like network cards. There are
several modules which don't have an index parameter.

Heiko

blacklisting issue, perhaps initscripts or kernel 3.0 related
 

Am 01.08.2011 09:44, schrieb Thomas Bächler:
> Am 01.08.2011 09:30, schrieb Tobias Powalowski:
>> To explain it a bit better:
>> Arch always had the possibility to load modules in a certain order by
>> using the MODULES= array in rc.conf.
>
> Preservation of order has not been working for several initscripts releases.
>
Ok talked to Thomas, seems there will be no chance to get the old stuff
back.
No problem i'll remove it from archboot media and probably replace it
with udev rules.
Media 2011.08 will contain the changes.

greetings
tpowa

--
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
http://www.archlinux.org
tpowa@archlinux.org

blacklisting issue, perhaps initscripts or kernel 3.0 related
 

On Mon, Aug 1, 2011 at 2:44 AM, Thomas Bächler <thomas@archlinux.org> wrote:
> Am 01.08.2011 09:30, schrieb Tobias Powalowski:
>> To explain it a bit better:
>> Arch always had the possibility to load modules in a certain order by
>> using the MODULES= array in rc.conf.
>
> Preservation of order has not been working for several initscripts releases.


Order preservation is doable via modprobe configs. See
/etc/modprobe.d/usb-load-ehci-first.conf for an example.

blacklisting issue, perhaps initscripts or kernel 3.0 related
 

Am 01.08.2011 16:48, schrieb Aaron Griffin:
> On Mon, Aug 1, 2011 at 2:44 AM, Thomas Bächler <thomas@archlinux.org> wrote:
>> Am 01.08.2011 09:30, schrieb Tobias Powalowski:
>>> To explain it a bit better:
>>> Arch always had the possibility to load modules in a certain order by
>>> using the MODULES= array in rc.conf.
>>
>> Preservation of order has not been working for several initscripts releases.
>
>
> Order preservation is doable via modprobe configs. See
> /etc/modprobe.d/usb-load-ehci-first.conf for an example.

Indeed, but it is not pretty.

blacklisting issue, perhaps initscripts or kernel 3.0 related
 

On Mon, Aug 01, 2011 at 05:19:11PM +0200, Thomas Bächler wrote:
> Am 01.08.2011 16:48, schrieb Aaron Griffin:
> > On Mon, Aug 1, 2011 at 2:44 AM, Thomas Bächler <thomas@archlinux.org> wrote:
> >> Am 01.08.2011 09:30, schrieb Tobias Powalowski:
> >>> To explain it a bit better:
> >>> Arch always had the possibility to load modules in a certain order by
> >>> using the MODULES= array in rc.conf.
> >>
> >> Preservation of order has not been working for several initscripts releases.
> >
> >
> > Order preservation is doable via modprobe configs. See
> > /etc/modprobe.d/usb-load-ehci-first.conf for an example.
>
> Indeed, but it is not pretty.
>
>

It's also not recommended by upstream, as per modprobe.conf(5). We
shouldn't make any guarantees about module load order. What's the
problem we're trying to solve with this juggling? Is this bandaiding and
issue that should be taken upstream to the kernel folk? Or, is this some
pre-emptive attack against hardware being claimed by the wrong module,
in which case we should be leaving it up the user to figure out which
module they want to use...

dave

blacklisting issue, perhaps initscripts or kernel 3.0 related
 

Am 01.08.2011 17:23, schrieb Dave Reisner:
> It's also not recommended by upstream, as per modprobe.conf(5). We
> shouldn't make any guarantees about module load order. What's the
> problem we're trying to solve with this juggling? Is this bandaiding and
> issue that should be taken upstream to the kernel folk? Or, is this some
> pre-emptive attack against hardware being claimed by the wrong module,
> in which case we should be leaving it up the user to figure out which
> module they want to use...

Apparently, it is recommended upstream to load ehci before uhci or ohci
(which userspace cannot safely guarantee) and actual bugs are caused if
we don't. I don't like this, but we couldn't think of another solution.

blacklisting issue, perhaps initscripts or kernel 3.0 related
 

On Mon, Aug 01, 2011 at 05:37:56PM +0200, Thomas Bächler wrote:
> Am 01.08.2011 17:23, schrieb Dave Reisner:
> > It's also not recommended by upstream, as per modprobe.conf(5). We
> > shouldn't make any guarantees about module load order. What's the
> > problem we're trying to solve with this juggling? Is this bandaiding and
> > issue that should be taken upstream to the kernel folk? Or, is this some
> > pre-emptive attack against hardware being claimed by the wrong module,
> > in which case we should be leaving it up the user to figure out which
> > module they want to use...
>
> Apparently, it is recommended upstream to load ehci before uhci or ohci
> (which userspace cannot safely guarantee) and actual bugs are caused if
> we don't. I don't like this, but we couldn't think of another solution.
>

Oh, absolutely...

https://bugzilla.redhat.com/show_bug.cgi?id=464908
https://bugzilla.redhat.com/show_bug.cgi?id=154008
https://bugs.archlinux.org/task/12009

and every distro does this, similar to the way we do it. This seems like
an edge case though -- you might want ohci _and_ ehci for different
devices. On the other hand, you definitely don't want (incoming
contrived example) b43 being loaded for your wifi card that can use
brcmsmac instead. There's no use case for both being loaded. In the
case of sound modules, we shouldn't enforce order -- leave it up to the
user to order the devices via modprobe config.

dave