udev problem

[besto]

Hallo,

seit ein paar Wochen habe ich ein Problem mit dem udev daemon bzw. udev insgesamt. Ich nutze ein Labtop mit einem debian squeeze. Im Moment als:
Linux 2.6.30-2-686 #1 SMP Sat Sep 26 01:16:22 UTC 2009 i686 GNU/Linux
wobei das Problem zum Teil auch beim 2.6.26-2 kernel auftritt.
Es gibt dabei zwei Varianten die nach einem mir nicht nachvollziehbaren Muster auftreten:
1. udev wird beim booten gar nicht geladen. Es erfolgt dann irgendwann

Nov 27 23:20:08 client4 laptop-mode: Querying /dev/hdc media type using udevinfo:
Nov 27 23:20:08 client4 laptop-mode: failed - udev not active?
Nov 27 23:20:08 client4 laptop-mode: Querying /dev/hdc media type using device name:
Nov 27 23:20:08 client4 laptop-mode: failed - unknown name
Nov 27 23:20:08 client4 laptop-mode: Querying /dev/hdc type using hdparm:
Nov 27 23:20:08 client4 laptop-mode: type 'disk' on bus 'ata' detected
Nov 27 23:20:08 client4 laptop-mode: Querying /dev/hdc media type using udevinfo:
Nov 27 23:20:08 client4 laptop-mode: failed - udev not active?
Nov 27 23:20:08 client4 laptop-mode: Querying /dev/hdc media type using device name:
Nov 27 23:20:08 client4 laptop-mode: failed - unknown name
Nov 27 23:20:08 client4 laptop-mode: Querying /dev/hdc type using hdparm:
Nov 27 23:20:08 client4 laptop-mode: type 'disk' on bus 'ata' detected
Nov 27 23:20:08 client4 laptop-mode: Executing: hdparm -S 244 /dev/hdc
Nov 27 23:20:08 client4 laptop-mode: /dev/hdc: No such device or address

Als Nachricht und das für alle möglichen Platten, die das System halt nicht findet (oder die es nicht gibt).
Danach wird gdm gestartet und dann kann ich nur noch den "Aus" Knopf drücken, weil dann auch Maus und Keyboard nicht mehr gehen.

2. udev wird gefunden. Es gibt dann die Fehlermeldung:

modprobe: Error running install command for dev snd_hda_codec_si3054

sowie das Ganze noch mal für snd_hda_...realtec.
Wenn ich dann mit ctrl-c abbreche, fährt das System hoch und es funktioniert alles. Nur habe ich dann udev ungefähr 25 mal laufen und ein Prozess brauch dann ca. 25% cpu Kapazität. Ich kill dann udev immer und wenn ich was neues einhängen will, dann starte ich udevd wieder. Interessanter Weise läuft der Sound trotzdem.

lsmod|grep snd
snd_hda_codec_si3054 4024 1
snd_hda_codec_realtek 178564 1
snd_hda_intel 22192 1
snd_hda_codec 63580 3 snd_hda_codec_si3054,snd_hda_codec_realtek,snd_hda_intel
snd_hwdep 6120 1 snd_hda_codec
snd_pcm_oss 32228 0
snd_mixer_oss 12368 1 snd_pcm_oss
snd_pcm 62396 4 snd_hda_codec_si3054,snd_hda_intel,snd_hda_codec,snd_pcm_oss
snd_timer 17436 1 snd_pcm
snd 49060 11 snd_hda_codec_si3054,snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer
soundcore 6184 1 snd
snd_page_alloc 8180 2 snd_hda_intel,snd_pcm

Hat jemand eine Idee dazu? Irgendwie ist das komisch und eher nervig.

B.

[storm]

Hmm, ohne genauere Hinweise lässt sich da schwer etwas rauslesen. Versionsmäßig ist alles aktuell? Auf der Konsole ist während des Startens (mal nur in's runlevel 2 oder vllt. gleich in den single user mode) auch keine Fehlermeldung zu sehen?

wobei das Problem zum Teil auch beim 2.6.26-2 kernel auftritt

Wie nur zum Teil?

ciao, storm

[besto]

O.k. ich versuch das mal mit Single user mode.
Ansonsten ist das komische, dass der Fehler eben in verschiedener Form auftritt. Beim Kernel 2.6.26-2 ist es so, dass der Fehler nach dem gar nichts mehr geht eher selten ist (kommt aber auch vor). Im Moment hab ich ihn geladen, weil das laden von 2.6.30-2 drei Mal fehlgeschlagen ist (d.h. keine Tastatur - keine Maus nach gdm start). Was aber bei 2.6.26-2 auftritt, ist eine lange boot-Pause kurz nach dem udev-start.
Da ist laut /var/log/messages der Ablauf wie folgt (ungekürzt):

Nov 29 16:36:16 client4 kernel: [ 23.684480] ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 22 (level, low) -> IRQ 22
Nov 29 16:36:16 client4 kernel: [ 23.786442] ACPI: PCI interrupt for device 0000:05:00.0 disabled
Nov 29 16:36:16 client4 kernel: [ 23.786442] udev: renamed network interface wmaster0 to eth3
Nov 29 16:36:16 client4 kernel: [ 24.288132] cs: IO port probe 0x100-0x3af: clean.
Nov 29 16:36:16 client4 kernel: [ 24.290369] cs: IO port probe 0x3e0-0x4ff: excluding 0x4d0-0x4d7
Nov 29 16:36:16 client4 kernel: [ 24.291533] cs: IO port probe 0x820-0x8ff: clean.
Nov 29 16:36:16 client4 kernel: [ 24.292402] cs: IO port probe 0xc00-0xcf7: clean.
Nov 29 16:36:16 client4 kernel: [ 24.292894] cs: IO port probe 0xa00-0xaff: clean.
Nov 29 16:36:16 client4 kernel: [ 150.864343] EXT3 FS on sda10, internal journal

D.h. da sind irgendwo 2 Minuten Pause und ich tippe im Moment auf udev als Ursache.
Wie gesagt, das System verhält sich merkwürdig. Ich versuche mal den Single user mode.

[besto]

O.k. hier ist nun, das Ergebnis, wenn ich auf "Single-user" (recovery mode) starte:

Dann startet udev bzw. udevd nicht. Wenn ich von dort weiter hochfahre zum runtime more 5 (ist das glaube ich), dann wird udevd auch nicht mehr geladen und ich kann den Rechner getrost wieder ausschalten.
Wenn ich udev aus /etc/init.d/ starte, bekomme ich den typischen Output, den ich auch sonst bekomme beim hochfahren, inklusive dessen, dass am Ende der Prozess hängen bleibt und nach 3 Minuten abbricht. Leider ist es mir nicht gelungen die Bildschirm Ausgabe mit > outfile.txt in eine Datei umzuleiten (vielleicht weiß jemand, wie ich das dann mache, wenn > nicht geht??).
Ich habe auch nicht ganz verstanden, welcher Prozess eigentlich /etc/init.d/udev aufruft, weil es keinen expliziten Start-Aufruf in den rcX.d Directories gibt.
Was ich feststelle ist, dass ich, wenn es mir gelingt komplett zu booten, mit /etc/init.d/udev restart das Problem beheben kann. Nur muss ich das dann immer erst per Hand machen. Irgendwie ist das noch nicht optimal - zumal der Fehler bleibt.

[storm]

Zuerst mal: irgendwie erscheint mir dein Setup etwas seltsam. Du sagst, du hast squeeze, aber in squeeze ist kein kernel 2.6.26.y zu finden. Da kann schon eine Ursache für dein Problem liegen. In /etc/init.d/udev für sid(unstable) steht als Mindestanforderung für udev ein Kernel >= 2.6.27. Hast du mal deine Software auf den neusten Stand gebracht? udev ist auch die aktuellste Version?
Was auch noch in Betracht kommt, ist das neulich eingeführte dependency based booting. D.h., die Skripte des jeweiligen runlevels (/etc/rcX.d/) werden nicht mehr nacheinander entsprechend der Nummer in ihrem Namen ausgeführt, sondern es wird ein Abhängigkeitsbaum aufgestellt und entsprechend diesem die Skripte ausgeführt. Wenn da udev irgendwo hängt oder nicht richtig ausgeführt wird, kann das Auswirkungen auf alle folgenden haben.

Wenn ich udev aus /etc/init.d/ starte, bekomme ich den typischen Output, den ich auch sonst bekomme beim hochfahren, inklusive dessen, dass am Ende der Prozess hängen bleibt und nach 3 Minuten abbricht. Leider ist es mir nicht gelungen die Bildschirm Ausgabe mit > outfile.txt in eine Datei umzuleiten (vielleicht weiß jemand, wie ich das dann mache, wenn > nicht geht??).

Wahrscheinlich musst du nur stderr miteinbeziehen. Ausgabe > datei bedeutet, du lenkst nur die Standardausgabe in die Datei. Fehler werden aber meistens auf stderr, der Fehlerausgabe, ausgegeben. Damit du die mit umlenkst, musst du den Befehl wie folgt gestalten:

Code: Alles auswählen

Befehl 2>&1 > datei

Es kommt natürlich auch darauf an, woher die Fehlermeldung kommt. Ist es ein Skript, kannst du die Ausgabe wie oben umlenken. Kommt sie statt dessen vom Kernel, kannst du sie nicht einfach umlenken -- musst du aber in dem Fall auch nicht, da sie dann im Ringpuffer des Kernels zu finden ist (dmesg) bzw. in /var/log/syslog.

Ich habe auch nicht ganz verstanden, welcher Prozess eigentlich /etc/init.d/udev aufruft, weil es keinen expliziten Start-Aufruf in den rcX.d Directories gibt.

Hehe, Linux, 1. Klasse, "Reihenfolge beim booten": kernel -> init -> /etc/rcX.d/*

Und sonst hast du nicht irgend etwas, was als Ursache gemeldet wird? Deine Beschreibung des Fehlers (machmal geht es, manchmal nicht) deutet (für mich) in Richtung Hardware. Aber das müsstest du irgendwo beim booten auch sehen.

ciao, storm

[besto]

Ah, danke, sehr schöner Tip. In den syslog finde ich nun endlich, was zwischen den Boot-Vorgängen unterschiedlich war:

[ 0.000000] Fast TSC calibration failed
[ 0.000000] TSC: PIT calibration matches PMTIMER. 1 loops

findet sich in dem, wo udev gar nicht geladen wird. Im anderen Fall hießt das:

[ 0.000000] Fast TSC calibration using PIT

Keine Ahnung, was das ist.

Hm, dann werden einige Dinge manchmal in umgekehrter Reihenfolge aufgerufen, aber es scheint eine Weile alles da zu sein. Nur dann wird eben in dem einen Fall udev nicht aufgerufen, was dann so aussieht:

[ 2.073270] sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray
[ 2.073273] Uniform CD-ROM driver Revision: 3.20
[ 2.073358] sr 1:0:0:0: Attached scsi CD-ROM sr0
[ 2.084273] sda1 sda2 sda3 < sda5 sda6 sda7 sda8 sda9 sda10 > sda4
[ 2.171779] sd 0:0:0:0: [sda] Attached SCSI disk
[ 2.176967] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 2.177010] sr 1:0:0:0: Attached scsi generic sg1 type 5
[ 2.875790] PM: Starting manual resume from disk
[ 2.938751] kjournald starting. Commit interval 5 seconds
[ 2.938763] EXT3-fs: mounted filesystem with ordered data mode.
[ 5.445771] loop: AES key scrubbing enabled
[ 5.446129] loop: loaded (max 8 devices)
[ 5.668229] Adding 3413768k swap on /dev/loop1. Priority:-1 extents:1 across:3413768k
[ 5.904859] EXT3 FS on sda10, internal journal
[ 6.276119] device-mapper: uevent: version 1.0.3
[ 6.276205] device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised: dm-devel@redhat.com
[ 7.659835] fuse init (API version 7.11)
[ 7.741404] kjournald starting. Commit interval 5 seconds
[ 7.746697] EXT3 FS on sda2, internal journal
[ 7.746702] EXT3-fs: mounted filesystem with ordered data mode.

Wenn aber udev mit aufgerufen wird, kommt folgende Ausgabe bei syslog (ich glaube die oben schon beschriebene Fehlermeldung fehlt hier):

[ 3.343767] kjournald starting. Commit interval 5 seconds
[ 3.343780] EXT3-fs: recovery complete.
[ 3.344343] EXT3-fs: mounted filesystem with ordered data mode.
[ 5.054129] udev: starting version 146
[ 5.164258] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2
[ 5.164266] ACPI: Power Button [PWRF]
[ 5.164338] input: Lid Switch as /devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input3
[ 5.164423] ACPI: Lid Switch [LID]
[ 5.164481] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input4
[ 5.164485] ACPI: Power Button [PWRB]
[ 5.333453] ACPI: SSDT 7fe7e9a0 001A8 (v01 PmRef Cpu0Ist 00003000 INTL 20050624)
[ 5.333770] ACPI: SSDT 7fe7e73f 001DC (v01 PmRef Cpu0Cst 00003001 INTL 20050624)
[ 5.334110] Marking TSC unstable due to TSC halts in idle
[ 5.334158] ACPI: CPU0 (power states: C1[C1] C2[C2])
[ 5.334186] processor ACPI_CPU:00: registered as cooling_device1
[ 5.334191] ACPI: Processor [CPU0] (supports 8 throttling states)
[ 5.334532] ACPI: SSDT 7fe7eb48 00089 (v01 PmRef Cpu1Ist 00003000 INTL 20050624)
[ 5.334819] ACPI: SSDT 7fe7e91b 00085 (v01 PmRef Cpu1Cst 00003000 INTL 20050624)
[ 5.335267] ACPI: CPU1 (power states: C1[C1] C2[C2])
[ 5.335291] processor ACPI_CPU:01: registered as cooling_device2
[ 5.335296] ACPI: Processor [CPU1] (supports 8 throttling states)
[ 5.336587] ACPI: EC: non-query interrupt received, switching to interrupt mode
[ 5.353377] ACPI: AC Adapter [ADP0] (on-line)
[ 5.362796] ACPI: Battery Slot [BAT0] (battery present)
[ 5.648096] cfg80211: Using static regulatory domain info
[ 5.648101] cfg80211: Regulatory domain: US
[ 5.648104] ^I(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 5.648110] ^I(2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
[ 5.648116] ^I(5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 5.648121] ^I(5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 5.648126] ^I(5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 5.648130] ^I(5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 5.648135] ^I(5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
[ 5.648147] cfg80211: Calling CRDA for country: US
[ 5.712762] input: PC Speaker as /devices/platform/pcspkr/input/input5
[ 5.945256] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.2.26ks
[ 5.945259] iwl3945: Copyright(c) 2003-2009 Intel Corporation
[ 5.945370] iwl3945 0000:05:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[ 5.945384] iwl3945 0000:05:00.0: setting latency timer to 64
[ 5.999276] iwl3945 0000:05:00.0: Tunable channels: 13 802.11bg, 23 802.11a channels
[ 5.999279] iwl3945 0000:05:00.0: Detected Intel Wireless WiFi Link 3945ABG
[ 5.999451] iwl3945 0000:05:00.0: irq 28 for MSI/MSI-X
[ 6.112791] yenta_cardbus 0000:07:06.0: CardBus bridge found [1179:ff10]
[ 6.112813] yenta_cardbus 0000:07:06.0: Enabling burst memory read transactions
[ 6.112819] yenta_cardbus 0000:07:06.0: Using CSCINT to route CSC interrupts to PCI
[ 6.112821] yenta_cardbus 0000:07:06.0: Routing CardBus interrupts to PCI
[ 6.112829] yenta_cardbus 0000:07:06.0: TI: mfunc 0x01a01b22, devctl 0x66
[ 6.123825] i801_smbus 0000:00:1f.3: PCI INT B -> GSI 19 (level, low) -> IRQ 19
[ 6.125175] intel_rng: FWH not detected
[ 6.157069] Synaptics Touchpad, model: 1, fw: 6.2, id: 0x25a0b1, caps: 0xa04713/0x0
[ 6.157079] synaptics: Toshiba Satellite A100 detected, limiting rate to 40pps.
[ 6.192097] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio4/input/input6
[ 6.345114] yenta_cardbus 0000:07:06.0: ISA IRQ mask 0x0cf8, PCI irq 18
[ 6.345119] yenta_cardbus 0000:07:06.0: Socket status: 30000006
[ 6.345124] pci_bus 0000:07: Raising subordinate bus# of parent bus (#07) from #07 to #0b
[ 6.345133] yenta_cardbus 0000:07:06.0: pcmcia: parent PCI bridge I/O window: 0x5000 - 0x5fff
[ 6.345136] pcmcia_socket pcmcia_socket0: cs: IO port probe 0x5000-0x5fff: clean.
[ 6.345380] yenta_cardbus 0000:07:06.0: pcmcia: parent PCI bridge Memory window: 0xde000000 - 0xde0fffff
[ 6.345383] yenta_cardbus 0000:07:06.0: pcmcia: parent PCI bridge Memory window: 0x88000000 - 0x8bffffff
[ 6.428507] tifm_7xx1 0000:07:06.2: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[ 6.961916] pcmcia_socket pcmcia_socket0: cs: IO port probe 0x100-0x3af: clean.
[ 6.963916] pcmcia_socket pcmcia_socket0: cs: IO port probe 0x3e0-0x4ff: excluding 0x4d0-0x4d7
[ 6.964802] pcmcia_socket pcmcia_socket0: cs: IO port probe 0x820-0x8ff: clean.
[ 6.967264] pcmcia_socket pcmcia_socket0: cs: IO port probe 0xc00-0xcf7: clean.
[ 6.968130] pcmcia_socket pcmcia_socket0: cs: IO port probe 0xa00-0xaff: clean.
[ 7.076618] HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
[ 7.076657] HDA Intel 0000:00:1b.0: setting latency timer to 64
[ 7.159640] phy0: Selected rate control algorithm 'iwl-3945-rs'
[ 7.186142] udev: renamed network interface wlan0 to eth3
[ 7.187152] input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/input/input7
[ 9.161072] iwl3945 0000:05:00.0: Radio Frequency Kill Switch is On:
[ 9.161075] Kill switch must be turned off for wireless networking to work.
[ 14.239476] EXT3 FS on sda10, internal journal
[ 14.455050] loop: AES key scrubbing enabled
[ 14.455408] loop: loaded (max 8 devices)

Die ersten und letzten Zeilen sind identisch. Ich hab sie drin gelassen, um deutlich zu machen, was wohl zu udev gehört. Die Ausgabe von udev, die sich auch beim Einzelaufruf wiederfindet, hab ich dazu noch fett gemacht.
Ja, und nun? Daraus kann ich zumindest noch nicht erkennen, warum udev beim einen Mal startet, beim anderen aber nicht. Und es leuchtet mir auch noch nicht ein, warum ich anschließend udev über 20 Mal im System laufen habe, wobei der Prozess dann wirklich 25% Leistung beansprucht.

Zum System: Die source-list sieht so aus:

deb http://ftp.de.debian.org/debian/ testing main contrib non-free
deb http://ftp2.de.debian.org/debian/ testing main contrib non-free
deb http://ftp2.de.debian.org/debian/ testing-proposed-updates main contrib non-free
deb http://http.us.debian.org/debian/ squeeze contrib non-free main
deb http://ftp.de.debian.org/debian/ squeeze non-free contrib main
deb http://www.debian-multimedia.org testing main
/quote]
Das sollte nach meiner Meinung auf ein Squeeze System heraus laufen - oder liege ich da vollkommen falsch??

[storm]

Ah, danke, sehr schöner Tip. In den syslog finde ich nun endlich, was zwischen den Boot-Vorgängen unterschiedlich war:

[ 0.000000] Fast TSC calibration failed
[ 0.000000] TSC: PIT calibration matches PMTIMER. 1 loops

findet sich in dem, wo udev gar nicht geladen wird. Im anderen Fall hießt das:

[ 0.000000] Fast TSC calibration using PIT

Keine Ahnung, was das ist.

Nix weiter. TSC ist der time stamp counter (ein timer der CPU), welcher beim booten kalibiriert werden muss. Dafür gibt es unterschiedliche Quellen (=andere timer). Zwischen 2.6.26 und .30 gab es im TSC-code einige (wichtige) Änderungen und die Ausgaben hier sind eine Auswirkung.

Hm, dann werden einige Dinge manchmal in umgekehrter Reihenfolge aufgerufen, aber es scheint eine Weile alles da zu sein. Nur dann wird eben in dem einen Fall udev nicht aufgerufen, was dann so aussieht:
...
Wenn aber udev mit aufgerufen wird, kommt folgende Ausgabe bei syslog (ich glaube die oben schon beschriebene Fehlermeldung fehlt hier):
...
Die ersten und letzten Zeilen sind identisch. Ich hab sie drin gelassen, um deutlich zu machen, was wohl zu udev gehört. Die Ausgabe von udev, die sich auch beim Einzelaufruf wiederfindet, hab ich dazu noch fett gemacht.
Ja, und nun? Daraus kann ich zumindest noch nicht erkennen, warum udev beim einen Mal startet, beim anderen aber nicht. Und es leuchtet mir auch noch nicht ein, warum ich anschließend udev über 20 Mal im System laufen habe, wobei der Prozess dann wirklich 25% Leistung beansprucht.

Da ist auch von meiner Seite aus nix ungewöhnliches zu sehen. Völlig normale Ausgaben. Einzig das Fehlen der im unteren Abschnitt auftauchenden Angaben könnten ein Hinweis sein, allerdings kann man die Ausgaben von zwei zeitlich doch recht weit auseinander liegenden Kernen nicht so einfach vergleichen.
Du hattest eigentlich noch nicht auf meine Frage geantwortet, ob die Software auf deinem System wirklich aktuell ist. Gerade bei udev gab es vor nicht all zu langer Zeit einen Fix, der sich auch auf das Auftauchen von vielen udev-Prozessen mit starker CPU-Last bezog.
Du solltest evtl. auch mal versuchen, ohne laptop-mode zu booten, also das Paket mal deinstallieren.

Zum System: Die source-list sieht so aus:

deb http://ftp.de.debian.org/debian/ testing main contrib non-free
deb http://ftp2.de.debian.org/debian/ testing main contrib non-free
deb http://ftp2.de.debian.org/debian/ testing-proposed-updates main contrib non-free
deb http://http.us.debian.org/debian/ squeeze contrib non-free main
deb http://ftp.de.debian.org/debian/ squeeze non-free contrib main
deb http://www.debian-multimedia.org testing main

Das sollte nach meiner Meinung auf ein Squeeze System heraus laufen - oder liege ich da vollkommen falsch??

Nee, sieht korrekt aus.

ciao, storm

edith meint: wenn du dich noch etwas geduldest, löst sich das Problem eventuell von selbst. Mit 2.6.32 wird udev überflüssig werden. Also fällt auch der ganze Kram mit den rules-files weg und keiner (maintainer, user, falsche shells) kann dann mehr da drin rumpfuschen. *g

[guennid]

Mit 2.6.32 wird udev überflüssig werden.

Jubilate!!! Frohlocken!!! Hosiannah!!!

keiner (maintainer, user, falsche shells) kann dann mehr da drin rumpfuschen.

Etwa so wie bei xorg? Hoffentlich übernimmt sich da niemand!

Grüße, Günther

[Duff]

Mit 2.6.32 wird udev überflüssig werden.

Jubilate!!! Frohlocken!!! Hosiannah!!!

Das dauert aber noch ein wenig

[besto]

Ja, hm. Die Aussicht "es wird irgendwann besser" ist ja schon mal nicht schlecht. Das System ist an sich Aktuell (im Moment hab ich nur libsnmp nicht aktualisiert, weil mir dann wireshark deinstalliert werden soll, aber das dürfte damit nix zu tun haben. Sonst ist alles da.
Also mal abwarten. Vielen Dank auf jeden Fall für die Unterstützung. Immerhin hab ich jetzt herausgefunden, dass ich das Problem mit

/etc/init.d/udev restart

in den Griff bekomme. Ist zwar nervig aber funktioniert.

[Clio]

Mit 2.6.32 wird udev überflüssig werden.

Jubilate!!! Frohlocken!!! Hosiannah!!!

Günther, noch solltest Du leise jubilieren......
Ich habe mittlerweile 2.6.32-rc8 im Einsatz und kann nicht erkennen, daß udev überflüssig wäre.
@storm
Oder muß da was beim Kompilieren explizit angegeben werden?

[storm]

So wie ich das bisher verstanden hab, wird udev nicht wirklich überflüssig, der Einsatz ist dann aber unter verschiedenen Bedingung nicht mehr notwendig. D.h. zum Beispiel für Distri-Kernel mit initrd, dass die schneller starten können, da die eh in /sys vorliegenden Informationen in einem schnellen (weil im RAM) devtmpfs nicht mehr von udev ausgwertet werden müssen. Also kein user-space support abgewartet werden muss. Das geht in Richtung eines statischen Gerätebaums. Wie die genaue Implementierung nun aussieht, keine Ahnung. Ich will mir das auch gerade erst ansehen. *g

Auf der einen Seite find ich das natürlich toll, wenn schnellere boot-Zeiten daraus resultieren. Auch hatte ich immer leichte Bauchschmerzen bei dem Gedanken, dass mit udev bei jedem boot die Geräte dynamisch ermittelt werden, obwohl sich für den überwiegenden Anteil der user die Hardware nur selten ändert. Andererseits versteh ich die kernel-devs nicht: erst raus mit dem Zeug in den user-space, weg mit dem alten Krücken und jetzt mehr oder weniger wieder zurück. Und wer zu Laufzeit Geräte (USB anyone?) ansteckt, wird den Komfort von udev (zB. eigene Namen vergeben zu können) nicht mehr missen wollen.

Lesefutter: http://lwn.net/Articles/331818/

ciao, storm

[storm]

Also: für 'normale' Kernel wird es wohl kein großer Unterschied sein, nur dass udev halt später zum Zuge kommt:

The lifetime rules of objects in devtmpfs are simple: the nodes are
created by the kernel, and that's all. It's just a bunch of automatic
mknod()s. Everything else is handled by udev, as now.

Und wer es ausprobieren will:

Create a kernel maintained /dev tmpfs (EXPERIMENTAL) (DEVTMPFS) [N/y/?] (NEW)

ciao, storm

[Clio]

Hallo storm,
Danke für Deine Information.
Zwischenzeitlich habe ich den freigegebenen 2.6.32 kompiliert und eher keine Änderung bemerkt.
Schnell hat mein System schon immer gestartet, da ich den Kernel ohne initrd auf meine Hardware abgestimmt habe.
In den rules.d habe ich nur noch persistent-cd, persistent-net und permissions. Ob das vorher auch so war, kann ich gar nicht sagen, da ich da schon länger nicht mehr reingeguckt habe.
Also, alles wie gehabt, ganz ohne geht es doch noch nicht.

[storm]

So, ich hab auch grad mal den Neuen gebaut und gestartet. Ohne das devtmpfs, da mir die boot-Zeit eher unwichtig ist. So wie es aussieht, war das nur wieder etwas viel Rummel um ein eher kleines Feature.

Zwischenzeitlich habe ich den freigegebenen 2.6.32 kompiliert und eher keine Änderung bemerkt.

Ich schon. Da ich bis zum release einen git-kernel mit drm-next sowie BFS laufen hatte, fällt diese compiler-Orgie erstmal wieder weg. Und dank der Diskussion um CFS vs. BFS hat sich beim ersteren doch einiges getan. Der Eindruck kurz nach dem Starten ist wirklich gut, so wie beim BFS auch. Aber der Knackpunkt war immer der Eindruck nach wenigstens 24h Laufzeit.

Also, alles wie gehabt, ganz ohne geht es doch noch nicht.

Warum "noch"? Mittlerweile tendier ich dazu, dass devtmpfs (und ähnliche Ansätze) doch nur Rückschritte sind. Ein wirkliche Bewegung in Richtung vollständig dynamische Geräteliste wäre mir lieber, eben konsequenter als mit udev.
Und für die Leute, die immer noch auf den daemon schimpfen sei gesagt: der Kernel kann nach wie vor mit rein statischem /dev arbeiten. Einfach Liste kopieren und udev abschalten.

ciao, storm

[cosmac]

hi,

Mit 2.6.32 wird udev überflüssig werden.

Jubilate!!! Frohlocken!!! Hosiannah!!!

Günther, noch solltest Du leise jubilieren......
Ich habe mittlerweile 2.6.32-rc8 im Einsatz und kann nicht erkennen, daß udev überflüssig wäre.

Jedenfalls bootet ein System jetzt auch ohne udev und ohne statisches /dev. Allein das wäre ein riesiger Fortschritt, selbst wenn es nicht schneller ginge. Außerdem werden die Device-Namen jetzt nur noch im Kernel verwaltet, dafür war udev eigentlich schon immer überflüssig.

Das einzige, was udev jetzt noch in /dev zu tun hat, ist die Rechte einiger Dateien anzupassen. Weil es keinen Standard gibt, legt sie der Kernel mit "root.root, 0600" an. Deswegen ist es mit devtmpfs sogar schwieriger ein udev-loses System zu betreiben. Wie man an /dev/null sieht, ist aber schon ein Mechanismus eingebaut, womit jeder Treiber die Rechte selbst gleich richtig setzen kann. Da müsste man (Debian) nur die Debian-spezifischen Rechte rein patchen.

Abgesehen davon ist udev für manche Sachen natürlich immer noch nützlich, z.B. Firmware laden. Aber mit devtmpfs braucht man nur noch wenige, ganz spezielle udev-Regeln weil udev nicht mehr pauschal alles kontrolliert. Debian könnte sogar das udev-Paket aufspalten in ein Grundpaket und ein udev-rules Paket. Im Grundpaket wären alle Regeln auskommentiert und nur als Beispiele gedacht. Nur rundum-sorglos-Desktop-Pakete würden die udev-rules mit installieren.

Mittlerweile tendier ich dazu, dass devtmpfs (und ähnliche Ansätze) doch nur Rückschritte sind. Ein wirkliche Bewegung in Richtung vollständig dynamische Geräteliste wäre mir lieber, eben konsequenter als mit udev.

Der Kernel entfernt die Device Nodes doch auch wieder, wenn das Gerät ausgesteckt wird oder auf ein rmmod hin. Damit bildet /dev immer genau den Hardware-Zustand ab. Dynamischer geht's doch kaum?

Und für die Leute, die immer noch auf den daemon schimpfen sei gesagt: der Kernel kann nach wie vor mit rein statischem /dev arbeiten. Einfach Liste kopieren und udev abschalten.

Und mit devtmpfs muss ich als militanter udev-Gegner nichtmal mehr die Liste kopieren