Gentoo Archives: gentoo-user

From: Mick <michaelkintzios@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Re: Having Trouble with Wireless Interface
Date: Wed, 21 May 2014 19:30:15
Message-Id: 201405212030.00925.michaelkintzios@gmail.com
In Reply to: Re: [gentoo-user] Re: Having Trouble with Wireless Interface by Alexander Kapshuk
1 On Wednesday 21 May 2014 18:56:49 Alexander Kapshuk wrote:
2 > On 05/18/2014 04:05 AM, Jonathan Callen wrote:
3 > > On 05/15/2014 03:50 PM, Mick wrote:
4 > > > On Thursday 15 May 2014 14:24:57 Alexander Kapshuk wrote:
5 > > >> On 05/15/2014 11:39 AM, Stroller wrote:
6 > > >>> On Wed, 14 May 2014, at 12:36 pm, Alexander Kapshuk
7 > > >
8 > > > <alexander.kapshuk@×××××.com> wrote:
9 > > >>>>>> ?
10 > > >>>>>> If you like to check if RTL8192CE is enabled in your kernel's
11 > >
12 > > .config
13 > >
14 > > >>>>>> file. If it isn't, you probably want to compile it as a module,
15 > > >>>>>> and then add rtl8192ce to /etc/conf.d/modules as well.
16 > > >>>>>
17 > > >>>>> Am pretty sure there's no need to add this one to
18 > >
19 > > /etc/conf.d/modules -
20 > >
21 > > >>>>> IME it'll just be found and loaded automagically by the kernel.
22 > > >>>>
23 > > >>>> Thanks for pointing that out. I wasn't aware of that. As I
24 > >
25 > > mentioned in
26 > >
27 > > >>>> my previous post, I do not use genkernel myself.
28 > > >>>
29 > > >>> Neither do I - for this reason I found it a little frustrating
30 > >
31 > > trying to
32 > >
33 > > >>> help in a recent thread, myself.
34 > > >>>
35 > > >>> However, I'm pretty sure that loadable kernel modules behave the same
36 > > >>> whether your kernel is built "by hand" or by genkernel - if you have
37 > > >>> modules listed in /etc/conf.d/modules then I have to wonder if you
38 > > >>> really need them there.
39 > > >>>
40 > > >>> I haven't used that file for years, and I prefer to compile
41 > >
42 > > everything as
43 > >
44 > > >>> a module, too.
45 > > >>>
46 > > >>> Stroller.
47 > > >>
48 > > >> That's interesting. I wasn't aware of that either.
49 > > >>
50 > > >> So far, I've just been following the instructions given in the
51 > >
52 > > handbook,
53 > >
54 > > >> section 7.d, which do recommend explicitly specifying the kernel
55 > >
56 > > modules
57 > >
58 > > >> to be loaded at boot time in /etc/conf.d/modules.
59 > > >>
60 > > >> How does the kernel know then what modules to load at boot time, if it
61 > > >> doesn't rely on /etc/conf.d/modules to supply the list of modules to
62 > > >> be loaded?
63 > > >>
64 > > >> Does it use udev, or some other mechanism for that?
65 > > >>
66 > > >> Thanks.
67 > > >
68 > > > I understand it is udev magic which probes the hardware and it
69 > >
70 > > fetches the
71 > >
72 > > > corresponding module from the kernel, as long as it has been compiled.
73 > > > Incidentally, I noticed that I now have this running on my system:
74 > > >
75 > > > /lib/systemd/systemd-udevd --daemon
76 > >
77 > > The actual udev magic in question is this line from
78 > > /lib/udev/rules.d/80-drivers.rules:
79 > >
80 > > ENV{MODALIAS}=="?*", RUN{builtin}+="kmod load $env{MODALIAS}"
81 > >
82 > > When a new device is seen by the kernel (which includes cold-plug on
83 > > boot), udev calls the equivalent of `modprobe ${MODALIAS}` (in reality,
84 > > the actual command is now just a call to libkmod, which is linked into
85 > > udev itself), where ${MODALIAS} is the contents of the file "modalias"
86 > > under the /sys directory describing that device. This file may look
87 > > something like this (actual example from my machine):
88 > >
89 > > pci:v00008086d00000416sv00001558sd00007104bc03sc00i00
90 > >
91 > > This information (following the the initial "pci:", indicating that this
92 > > is a PCI device), can be split into multiple identifier/number pairs,
93 > > like so:
94 > >
95 > > v 00008086
96 > > d 00000416
97 > > sv 00001558
98 > > sd 00007104
99 > > bc 03
100 > > sc 00
101 > > i 00
102 > >
103 > > In this case I have vendor "00008086" (Intel Corporation), device
104 > > "00000416" (4th Gen Core Processor Integrated Graphics Controller),
105 > > subsystem vendor "00001558" (CLEVO/KAPOK Computer), subsystem device
106 > > "00007104" (not listed in pci.ids, sorry), base class "03" (Display
107 > > controller), sub class "00" (VGA compatible controller), and programming
108 > > interface "00" (VGA controller).
109 > >
110 > > This information is then used to look up the module in
111 > > /lib/modules/$(uname -r)/modules.alias (actually, modules.alias.bin is
112 > > used if present to speed up the lookup). This lookup finds the line:
113 > >
114 > > alias pci:v00008086d00000416sv*sd*bc03sc*i* i915
115 > >
116 > > As my card matches the glob in the second field in that line, the module
117 > > listed in the third field is loaded to handle the card. The actual
118 > > modules.alias file is generated by depmod when the module is installed
119 > > by reading the information from the module itself.
120 >
121 > Thanks for the explanation.
122 >
123 > Just to double check I understood it correctly, there's no need to put
124 > the list of kernel modules into /etc/conf.d/modules any longer, because
125 > udev is aware of the modules that have been built and will load them by
126 > consulting /lib/modules/$(uname -r)/modules.alias. Is that correct?
127 >
128 > Thanks.
129
130 No, it is incorrect, or I better say incomplete. There are some modules
131 (netfilter, virtualbox, et al.) which will not be autoloaded. You will need
132 to add those in your /etc/conf.d/modules and make sure the syntax is correct
133 for the kernel version that you intend to boot with.
134 --
135 Regards,
136 Mick

Attachments

File name MIME type
signature.asc application/pgp-signature