[arch-general] A little weirdness at boot time
Hi all! This email is divided in two parts: a curiosity and a problem. They are somewhat related, so I'm writing both together. The curiosity: Since I've installed Arch Linux in this notebook (in March), the time it takes to load the modules highly varies. With the current archinit scripts, it ranges from incredible 150ms to incredible 10 000ms. With the older archinit scripts, the time weren't exactly the same, but it did vary a lot, too. At first I thought a "cold boot" would take more than a reboot, but both things are completely unrelated: a cold boot can take only 150ms and a reboot 9 500ms and vice versa. I don't see this as a big problem, I'm just curious to know why. If anyone thinks I should report a bug, tell me what other kind of piece of information would be useful and I'll do it. The problem: Completely unrelated to the question above, the wireless card sometimes works, sometimes doesn't. It's unrelated because if the boot takes 150ms, the wireless may or may not work. The same applies if the boot takes 10 000ms. When I say it doesn't work, I mean that netcfg will fail and print an error: 'eth0: interface doesn't support scanning' Yes, I know it's weird, but I'm using the broadcom-wl module, and it sets eth0 as the wireless card. My cards: 09:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8040 PCI-E Fast Ethernet Controller (rev 12) 0b:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g (rev 01) and my MODULES array in /etc/rc.conf: MODULES=(!b43 lib80211_crypt_tkip wl ...) TIA, Andre
about the network card problem, have you tried adding: QUIRKS="predown" to your netcfg config file On 8/29/09, Andre Ramaciotti da Silva <andre.ramaciotti@gmail.com> wrote:
Hi all!
This email is divided in two parts: a curiosity and a problem. They are somewhat related, so I'm writing both together.
The curiosity: Since I've installed Arch Linux in this notebook (in March), the time it takes to load the modules highly varies. With the current archinit scripts, it ranges from incredible 150ms to incredible 10 000ms. With the older archinit scripts, the time weren't exactly the same, but it did vary a lot, too.
At first I thought a "cold boot" would take more than a reboot, but both things are completely unrelated: a cold boot can take only 150ms and a reboot 9 500ms and vice versa.
I don't see this as a big problem, I'm just curious to know why. If anyone thinks I should report a bug, tell me what other kind of piece of information would be useful and I'll do it.
The problem: Completely unrelated to the question above, the wireless card sometimes works, sometimes doesn't. It's unrelated because if the boot takes 150ms, the wireless may or may not work. The same applies if the boot takes 10 000ms. When I say it doesn't work, I mean that netcfg will fail and print an error: 'eth0: interface doesn't support scanning'
Yes, I know it's weird, but I'm using the broadcom-wl module, and it sets eth0 as the wireless card. My cards:
09:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8040 PCI-E Fast Ethernet Controller (rev 12) 0b:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g (rev 01)
and my MODULES array in /etc/rc.conf: MODULES=(!b43 lib80211_crypt_tkip wl ...)
TIA, Andre
At Sun, 30 Aug 2009 02:51:46 +0900, Juan Diego wrote:
about the network card problem, have you tried adding:
QUIRKS="predown"
to your netcfg config file
I'll test it, thanks.
On Sat, Aug 29, 2009 at 13:51, Juan Diego<juantascon@gmail.com> wrote:
about the network card problem, have you tried adding:
QUIRKS="predown"
to your netcfg config file I thought that quirks were removed?
On Sat, Aug 29, 2009 at 3:54 PM, Daenyth Blank <daenyth+arch@gmail.com<daenyth%2Barch@gmail.com>
wrote:
On Sat, Aug 29, 2009 at 13:51, Juan Diego<juantascon@gmail.com> wrote:
about the network card problem, have you tried adding:
QUIRKS="predown"
to your netcfg config file I thought that quirks were removed?
That's what I thought too. Anyway, it didn't work, but I found out what the real problem was. For some reason, sometimes I got: Wireless -> eth0 Ethernet -> eth1 and other times I got: Ethernet -> eth0 Wireless -> eth1 so netcfg would fail reporting that eth0 doesn't support scanning. I think I solved the problem loading both modules manually so now I always have: Ethernet -> eth0 Wireless -> eth1
On Sat, Aug 29, 2009 at 15:16, André Ramaciotti<andre.ramaciotti@gmail.com> wrote:
That's what I thought too. Anyway, it didn't work, but I found out what the real problem was. For some reason, sometimes I got: Wireless -> eth0 Ethernet -> eth1
and other times I got: Ethernet -> eth0 Wireless -> eth1
so netcfg would fail reporting that eth0 doesn't support scanning. I think I solved the problem loading both modules manually so now I always have: Ethernet -> eth0 Wireless -> eth1
A custom udev rule would probably work too... check the wiki.
I've got that network interface "random" swap for quite some time now. I wonder if there is something to do with the 2.6.31 kernel or the new udev Althoug it's rare, at first time I took a lot of time to find the cause... On Sat, 29 Aug 2009 17:13:48 -0300, Daenyth Blank <daenyth+arch@gmail.com> wrote:
On Sat, Aug 29, 2009 at 15:16, André Ramaciotti<andre.ramaciotti@gmail.com> wrote:
That's what I thought too. Anyway, it didn't work, but I found out what the real problem was. For some reason, sometimes I got: Wireless -> eth0 Ethernet -> eth1
and other times I got: Ethernet -> eth0 Wireless -> eth1
so netcfg would fail reporting that eth0 doesn't support scanning. I think I solved the problem loading both modules manually so now I always have: Ethernet -> eth0 Wireless -> eth1
A custom udev rule would probably work too... check the wiki.
--
For some reason, sometimes I got: Wireless -> eth0 Ethernet -> eth1
and other times I got: Ethernet -> eth0 Wireless -> eth1
On Sun, Aug 30, 2009 at 00:32, Adriano de Moura<adriano.lols@gmail.com> wrote:
I've got that network interface "random" swap for quite some time now. I wonder if there is something to do with the 2.6.31 kernel or the new udev
This is due to change in recent initscripts, not kernel or udev. Cannot reference the report now since bugtracker is down. This can be solved either by udev rules or specifying module options (like index=1) in modprobe config file. -- Roman Kyrylych (Роман Кирилич)
On 2009-08-29 at 16:13 -0400, Daenyth Blank wrote:
A custom udev rule would probably work too... check the wiki.
Another possibility would be ifrename(8) and iftab(5) from wireless_tools. The netcfg package provides a script (net-rename) for them which you can add to the DAEMONS array in /etc/rc.conf.
André Ramaciotti wrote:
On Sat, Aug 29, 2009 at 3:54 PM, Daenyth Blank <daenyth+arch@gmail.com<daenyth%2Barch@gmail.com>
wrote:
On Sat, Aug 29, 2009 at 13:51, Juan Diego<juantascon@gmail.com> wrote:
about the network card problem, have you tried adding:
QUIRKS="predown"
to your netcfg config file
I thought that quirks were removed?
That's what I thought too. Anyway, it didn't work, but I found out what the real problem was. For some reason, sometimes I got: Wireless -> eth0 Ethernet -> eth1
and other times I got: Ethernet -> eth0 Wireless -> eth1
so netcfg would fail reporting that eth0 doesn't support scanning. I think I solved the problem loading both modules manually so now I always have: Ethernet -> eth0 Wireless -> eth1
SImplest, most Arch-like solution is to load the modules in the required order in the rc.conf MODULES array. I hope that's what you mean by "manually". :) T.
On Mon, Aug 31, 2009 at 09:03, Tom K<tomk@runbox.com> wrote:
SImplest, most Arch-like solution is to load the modules in the required order in the rc.conf MODULES array.
I believe this no longer works. MODULES are not processed in the order now. -- Roman Kyrylych (Роман Кирилич)
At Mon, 31 Aug 2009 11:07:36 +0300, Roman Kyrylych wrote:
On Mon, Aug 31, 2009 at 09:03, Tom K<tomk@runbox.com> wrote:
SImplest, most Arch-like solution is to load the modules in the required order in the rc.conf MODULES array.
I believe this no longer works. MODULES are not processed in the order now.
-- Roman Kyrylych (Роман Кирилич)
Yes, with "manually" I meant that I put it in the MODULE arrays. It has been working for now. I'll take a look at custom udev rules later to see if it's worth the trouble.
Tom K schrieb:
SImplest, most Arch-like solution is to load the modules in the required order in the rc.conf MODULES array.
I hope that's what you mean by "manually". :)
With the asynchronous "trigger && load MODULES=() && settle", there is no way anymore to ensure module loading order! You need to fix this using persistent naming schemes, which is easy for network interfaces. It is also easy on alsa devices (index= option) and hard drives (uuid, label symlinks).
Am Mon, 31 Aug 2009 10:24:19 +0200 schrieb Thomas Bächler <thomas@archlinux.org>:
Tom K schrieb:
SImplest, most Arch-like solution is to load the modules in the required order in the rc.conf MODULES array.
I hope that's what you mean by "manually". :)
With the asynchronous "trigger && load MODULES=() && settle", there is no way anymore to ensure module loading order! You need to fix this using persistent naming schemes, which is easy for network interfaces. It is also easy on alsa devices (index= option) and hard drives (uuid, label symlinks).
But it's not that easy with evdev devices like mouse and remote control. Unfortunately flyspray is still down. But the /dev/input/eventX bug with the inconsistent device naming for the mouse and the IR remote control is back since the latest initscripts update to 2009.08-1, even if the device naming is not switching at every reboot this time. Sometimes (usually) the mouse is /dev/input/event5 and the remote control is /dev/input/event4 and sometimes it's vice versa. A device in /dev/input/by-path does only exist for the mouse, not for the remote control anymore which was inconsistent anyway because of the order in which the modules cx8800 and cx8802 were loaded. Maybe it helps if udev would be updated to 146. It would be even better if the initscripts would be reverted, so that the order in which modules are loaded can be set in the MODULES array in /etc/rc.conf. As you can see these changes in the initscripts probably make the boot process a bit faster (on fast PCs), but lead to many other serious problems (inconsistencies in ALSA modules, DVB modules, ethernet modules, etc.). And only a few modules like the ALSA modules have and index option. As I've written in flyspray, I'm not really a friend of parallel booting, because it's not really the best idea, leads to inconsistencies and makes booting slower on slow PCs. And I don't think that it's user-friendly if people have to write their own udev rules for every device to get udev consistent. And this is definitively not KISS like. Heiko
Heiko Baums wrote:
But it's not that easy with evdev devices like mouse and remote control. Unfortunately flyspray is still down. But the /dev/input/eventX bug with the inconsistent device naming for the mouse and the IR remote control is back since the latest initscripts update to 2009.08-1, even if the device naming is not switching at every reboot this time.
Sometimes (usually) the mouse is /dev/input/event5 and the remote control is /dev/input/event4 and sometimes it's vice versa.
Here is my /etc/conf.d/lircd - maybe it helps in your case too (: ## Configuration for Technisat USB remote TTS35AI LIRC_DRIVER="devinput" ## Using dev/input device by name (description) ## because event device node my change. ## To get the 'name' for your USB device ## look at dmesg|tail after pluging it in for a line like: ## input: USB IR Receiver USB IR Receiver as ## /devices/pci0000:00/0000:00:10.0/usb1/1-2/1-2:1.0/input/input8 ## or use cat /proc/bus/input/devices ## Make shure you have -d "$LIRC_DEVICE" (with quotes !) in your ## init script because of blanks! LIRC_DEVICE="name=USB IR Receiver USB IR Receiver" LIRC_EXTRAOPTS="" LIRC_CONFIGFILE=""
Thomas Bächler wrote:
Tom K schrieb:
SImplest, most Arch-like solution is to load the modules in the required order in the rc.conf MODULES array.
I hope that's what you mean by "manually". :)
With the asynchronous "trigger && load MODULES=() && settle", there is no way anymore to ensure module loading order! You need to fix this using persistent naming schemes, which is easy for network interfaces. It is also easy on alsa devices (index= option) and hard drives (uuid, label symlinks).
OK... guess I'll dig through arch-dev-public to find the upside to that. :P
On Sat, Aug 29, 2009 at 9:16 PM, André Ramaciotti<andre.ramaciotti@gmail.com> wrote:
That's what I thought too. Anyway, it didn't work, but I found out what the real problem was. For some reason, sometimes I got: Wireless -> eth0 Ethernet -> eth1
and other times I got: Ethernet -> eth0 Wireless -> eth1
There appears to be an optional udev rule to sort this out (/etc/udev/rules.d/75-persistent-net-generator.rules.optional). Since I removed the ".optional" from the filename I am no longer experiencing this issue. However, this file is not described in the wiki and no one at #archlinux could explain to me what it does. Seems to work, though. Hope it helps, JM
JM schrieb:
There appears to be an optional udev rule to sort this out (/etc/udev/rules.d/75-persistent-net-generator.rules.optional). Since I removed the ".optional" from the filename I am no longer experiencing this issue. However, this file is not described in the wiki and no one at #archlinux could explain to me what it does. Seems to work, though.
It's an upstream udev rule file, we just rename it as it seem so un-Arch. People who want these generated rules can rename it.
participants (12)
-
Adriano de Moura
-
Andre Ramaciotti da Silva
-
André Ramaciotti
-
Daenyth Blank
-
Heiko Baums
-
JM
-
Juan Diego
-
Kurt J. Bosch
-
Roman Kyrylych
-
Sebastian Schwarz
-
Thomas Bächler
-
Tom K