Befrager
(Themenstarter)
Anmeldungsdatum: 4. Februar 2014
Beiträge: 332
|
Hallo Vej, Vej schrieb: Befrager schrieb: Ok, aber die Frage, ob sie verantwortlich sind, stellt sich ja eigentlich für mich nicht mehr. Ich hab ja ausprobiert, was dort empfohlen wurde, und habe die Datei /etc/pm/config.d/00sleep_module angelegt. Etwas geändert hat sich dadurch nicht.
Welches Modul hattest du denn eingetragen?
Ehrlich gesagt weiß ich das gar nicht, ich habe einfach den Text aus dem Link 1:1 übernommen und das eingetragen: # USB-Kernelmodule und forcedeth (Netzwerkkarte) machen Aerger bei SUSPEND & RESUME mit pm-utils
# daher sollen sie automatisch ent- und geladen werden
SUSPEND_MODULES="$SUSPEND_MODULES ehci-hcd uhci-hcd usbcore forcedeth"
Die genannten Module sind mögliche (und häufige) Kandidaten, es gibt aber noch massenweise weitere Module, die für das Problem verantwortlich sein könnten. Du musst halt schauen, was auf deinem Rechner konkret läuft.
Konkret laufen laut des Befehls lsmod | grep -iE '802|ndiswr|forced|8139|hci|usb|1394|hid|..tv' auf einem Rechner diese Module: michael@michael-Rechner:~$ lsmod | grep -iE '802|ndiswr|forced|8139|hci|usb|1394|hid|..tv'
mac80211 630669 1 iwldvm
sparse_keymap 13948 1 dell_wmi
btusb 32412 0
bluetooth 391136 22 bnep,btusb,rfcomm
cfg80211 484040 3 iwlwifi,mac80211,iwldvm
mac_hid 13205 0
hid_logitech_dj 18581 0
usbhid 52659 0
hid 106148 3 usbhid,hid_logitech_dj
firewire_ohci 40409 0
ahci 29915 3
firewire_core 68769 1 firewire_ohci
libahci 32716 1 ahci
sdhci_pci 23172 0
sdhci 43015 1 sdhci_pci
Nun hast Du ja gesagt, ich solle prüfen, welches Modul für den Fehler verantwortlich sein könnte. Prüfe ich zum Beispiel mit modinfo das Modul hci, so erhalte ich folgende Ausgabe: michael@michael-Rechner:~$ modinfo hci
filename: /lib/modules/3.13.0-49-generic/kernel/net/nfc/hci/hci.ko
description: NFC HCI Core
license: GPL
srcversion: 27B19AC2872D424175C52F6
depends: nfc
intree: Y
vermagic: 3.13.0-49-generic SMP mod_unload modversions
signer: Magrathea: Glacier signing key
sig_key: 6F:CA:28:7C:25:73:D0:9C:A3:2C:19:80:C0:D7:63:77:7A:63:D4:F5
sig_hashalgo: sha512
Woran soll ich anhand dieser Daten erkennen, ob das Modul für den Fehler verantwortlich ist? Beste Grüße Befrager
|
Vej
Moderator, Supporter
Anmeldungsdatum: 7. März 2013
Beiträge: 3390
|
Hallo Befrager, ich dachte eigentlich du könntest die Beschreibungen nach den "üblichen Verdächtigen" durchsuchen:
WLAN-Karten und USB-WLAN-Sticks: *802*, ndiswrapper, ... LAN-Karten: forcedeth, *8139*, ... USB- und Firewire-Module: ehci-hcd, uhci-hcd, *usb*, *1394, ... Bluetooth- und TV-Karten: ivtv, bttv, btusb, ...
(Zitat aus dem Wikiartikel pm-utils (Abschnitt „Module-vor-SUSPEND-entladen-nach-RESUME-wieder-laden“)) Wenn die allerdings alle so inhaltsleer sind, wie die von hci wird das in der Tat schwierig. Dann bleibt noch alle von dir geposteten Module in die Datei zu kopieren und zu testen, ob das Problem dadurch behoben wird. Theoretisch kannst du danach natürlich durch systematisches Testen einzelner Module herausfinden an welchem Modul es lag um den Bereitscaftszustand wieder zu beschleunigen. Das hängt davon ab, wie viel Lust du noch hast. Viele Grüße Vej PS.: Wenn du ein Modul eingrenzen kannst, sag bitte Bescheid, dann kommt es ins Wiki (du darfst es natürlich auch selber eintragen).
|
Befrager
(Themenstarter)
Anmeldungsdatum: 4. Februar 2014
Beiträge: 332
|
Hallo Vej
Wenn die allerdings alle so inhaltsleer sind, wie die von hci wird das in der Tat schwierig.
Ja, also die sehen alle mehr oder weniger ähnlich aus. Ich versteh da eh nur Bahnhof, aber hier ist noch ein weiteres Beispiel: michael@michael-Rechner:~$ modinfo libahci
filename: /lib/modules/3.13.0-49-generic/kernel/drivers/ata/libahci.ko
license: GPL
description: Common AHCI SATA low-level routines
author: Jeff Garzik
srcversion: BFD212F5399F9F1CBBA7983
depends:
intree: Y
vermagic: 3.13.0-49-generic SMP mod_unload modversions
signer: Magrathea: Glacier signing key
sig_key: 6F:CA:28:7C:25:73:D0:9C:A3:2C:19:80:C0:D7:63:77:7A:63:D4:F5
sig_hashalgo: sha512
parm: skip_host_reset:skip global host reset (0=don't skip, 1=skip) (int)
parm: ignore_sss:Ignore staggered spinup flag (0=don't ignore, 1=ignore) (int)
parm: ahci_em_messages:AHCI Enclosure Management Message control (0 = off, 1 = on) (bool)
parm: devslp_idle_timeout:device sleep idle timeout (int)
PS.: Wenn du ein Modul eingrenzen kannst, sag bitte Bescheid, dann kommt es ins Wiki (du darfst es natürlich auch selber eintragen).
Das kann ich gerne mal probieren! Jetzt muss ich nur noch wissen: wie genau muss das konkret aussehen? Wo in diesem Text trage ich dasjenige Modul (oder mehrere) ein (also z.B. hid, hci), das ich abschalten möchte? # USB-Kernelmodule und forcedeth (Netzwerkkarte) machen Aerger bei SUSPEND & RESUME mit pm-utils
# daher sollen sie automatisch ent- und geladen werden
SUSPEND_MODULES="$SUSPEND_MODULES ehci-hcd uhci-hcd usbcore forcedeth" Beste Grüße, Befrager
|
Vej
Moderator, Supporter
Anmeldungsdatum: 7. März 2013
Beiträge: 3390
|
Hallo Befrager. Befrager schrieb:
Das kann ich gerne mal probieren! Jetzt muss ich nur noch wissen: wie genau muss das konkret aussehen? Wo in diesem Text trage ich dasjenige Modul (oder mehrere) ein (also z.B. hid, hci), das ich abschalten möchte? # USB-Kernelmodule und forcedeth (Netzwerkkarte) machen Aerger bei SUSPEND & RESUME mit pm-utils
# daher sollen sie automatisch ent- und geladen werden
SUSPEND_MODULES="$SUSPEND_MODULES ehci-hcd uhci-hcd usbcore forcedeth"
Die Markierung sind die Modulnamen (mit Leerzeichen getrennt). Hier kannst du stattdessen die Module eintragen, die du testen willst.
Sinnvollerweise testet man erst viele Module auf einmal, da ja durchaus auch mehrere Module zusammen das Problem verursachen können.
Hat man eine Variante gefunden, bei der der Neustart Aufwachen funktioniert, entfernt man einzelne Module, bis der Neustart Aufwachen nicht mehr funktioniert. Das zuletzt entfernte Modul bleibt dann stehen, weil es (mit) verantwortlich für das Problem war. Das ganze geht so lange, bis nur noch "verantwortliche" Module in der Liste stehen. Viele Grüße Vej EDIT: Wie bin ich den auf Neustart gekommen *kopfschüttel*.
|
Befrager
(Themenstarter)
Anmeldungsdatum: 4. Februar 2014
Beiträge: 332
|
Hallo Vej,
Das kann ich gerne mal probieren! Jetzt muss ich nur noch wissen: wie genau muss das konkret aussehen? Wo in diesem Text trage ich dasjenige Modul (oder mehrere) ein (also z.B. hid, hci), das ich abschalten möchte? # USB-Kernelmodule und forcedeth (Netzwerkkarte) machen Aerger bei SUSPEND & RESUME mit pm-utils
# daher sollen sie automatisch ent- und geladen werden
SUSPEND_MODULES="$SUSPEND_MODULES ehci-hcd uhci-hcd usbcore forcedeth"
Die Markierung sind die Modulnamen (mit Leerzeichen getrennt). Hier kannst du stattdessen die Module eintragen, die du testen willst.
Sinnvollerweise testet man erst viele Module auf einmal, da ja durchaus auch mehrere Module zusammen das Problem verursachen können.
Hat man eine Variante gefunden, bei der der Neustart Aufwachen funktioniert, entfernt man einzelne Module, bis der Neustart Aufwachen nicht mehr funktioniert. Das zuletzt entfernte Modul bleibt dann stehen, weil es (mit) verantwortlich für das Problem war. Das ganze geht so lange, bis nur noch "verantwortliche" Module in der Liste stehen.
Das mit dem Ausschlussverfahren hat sich vermutlich erübrigt. Der Bereitschaftsmodus funktioniert anscheinend selbst dann nicht, wenn alle Module abgeschaltet werden. Die Datei /etc/pm/config.d/00sleep_module sieht nun so aus: # USB-Kernelmodule und forcedeth (Netzwerkkarte) machen Aerger bei SUSPEND & RESUME mit pm-utils
# daher sollen sie automatisch ent- und geladen werden
SUSPEND_MODULES="$SUSPEND_MODULES mac80211 sparse_keymap btusb bluetooth cfg80211 mac_hid hid_logitech_dj usbhid hid firewire_ohci ahci firewire_core libahci sdhci_pci sdhci" Wenn mich nicht alles täuscht, habe ich darin alle Module eingetragen, die mir über lsmod | grep -iE '802|ndiswr|forced|8139|hci|usb|1394|hid|..tv' ausgegeben werden: michael@michael-Rechner:~$ lsmod | grep -iE '802|ndiswr|forced|8139|hci|usb|1394|hid|..tv'
mac80211 630669 1 iwldvm
sparse_keymap 13948 1 dell_wmi
btusb 32412 0
bluetooth 391136 22 bnep,btusb,rfcomm
cfg80211 484040 3 iwlwifi,mac80211,iwldvm
mac_hid 13205 0
hid_logitech_dj 18581 0
usbhid 52659 0
hid 106148 3 usbhid,hid_logitech_dj
firewire_ohci 40409 0
ahci 29915 3
firewire_core 68769 1 firewire_ohci
sdhci_pci 23172 0
libahci 32716 1 ahci
sdhci 43015 1 sdhci_pci Ist das Problem nun ein Fall für die Akte XY ungelöst? Beste Grüße, Befrager
|
Vej
Moderator, Supporter
Anmeldungsdatum: 7. März 2013
Beiträge: 3390
|
Hallo Befrager. Befrager schrieb: Ist das Problem nun ein Fall für die Akte XY ungelöst?
Das kommt auf deine Motivation an 😉. Der Befehl den du zum Anzeigen der Module verwendet hast, schränkt die angezeigten Module auf diejenigen ein, die als Teil ihres Namens Zeichenkombinationen enthalten, die häufig in problematischen Modulen vorkommen (vgl. grep). Du kannst auch mal versuchen alle Module einzutragen, die dir dieser Befehl hier ausspuckt:
Viel Glück Vej
|
Befrager
(Themenstarter)
Anmeldungsdatum: 4. Februar 2014
Beiträge: 332
|
Hallo Vej, nicht einmal das Eintragen aller Module von lsmod behebt das Problem... ☹ Ausgabe von lsmod: michael@michael-Rechner:~$ lsmod
Module Size Used by
ctr 13049 1
ccm 17773 1
rfcomm 69160 8
bnep 19624 2
nouveau 1097199 3
mxm_wmi 13021 1 nouveau
snd_hda_codec_hdmi 46368 4
arc4 12608 2
iwldvm 232285 0
mac80211 630669 1 iwldvm
dell_wmi 12761 0
sparse_keymap 13948 1 dell_wmi
dell_laptop 18168 0
dcdbas 14928 1 dell_laptop
snd_hda_codec_idt 54762 1
intel_powerclamp 14705 0
coretemp 13435 0
kvm_intel 143187 0
kvm 455835 1 kvm_intel
crct10dif_pclmul 14289 0
crc32_pclmul 13113 0
ghash_clmulni_intel 13216 0
aesni_intel 55624 2
aes_x86_64 17131 1 aesni_intel
lrw 13286 1 aesni_intel
gf128mul 14951 1 lrw
glue_helper 13990 1 aesni_intel
ablk_helper 13597 1 aesni_intel
cryptd 20359 3 ghash_clmulni_intel,aesni_intel,ablk_helper
snd_hda_intel 56531 5
snd_hda_codec 192906 3 snd_hda_codec_hdmi,snd_hda_codec_idt,snd_hda_intel
snd_hwdep 13602 1 snd_hda_codec
snd_pcm 102099 3 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel
joydev 17381 0
snd_page_alloc 18710 2 snd_pcm,snd_hda_intel
serio_raw 13462 0
snd_seq_midi 13324 0
snd_seq_midi_event 14899 1 snd_seq_midi
intel_ips 18664 0
snd_rawmidi 30144 1 snd_seq_midi
snd_seq 61560 2 snd_seq_midi_event,snd_seq_midi
btusb 32412 0
iwlwifi 169932 1 iwldvm
bluetooth 391136 22 bnep,btusb,rfcomm
snd_seq_device 14497 3 snd_seq,snd_rawmidi,snd_seq_midi
snd_timer 29482 2 snd_pcm,snd_seq
lpc_ich 21080 0
snd 69322 21 snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_hda_codec_idt,snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec,snd_hda_intel,snd_seq_device,snd_seq_midi
ttm 93424 1 nouveau
cfg80211 484040 3 iwlwifi,mac80211,iwldvm
drm_kms_helper 55071 1 nouveau
drm 303102 5 ttm,drm_kms_helper,nouveau
soundcore 12680 1 snd
i2c_algo_bit 13413 1 nouveau
wmi 19177 3 dell_wmi,mxm_wmi,nouveau
mac_hid 13205 0
video 19476 1 nouveau
shpchp 37032 0
parport_pc 32701 0
ppdev 17671 0
lp 17759 0
parport 42348 3 lp,ppdev,parport_pc
hid_logitech_dj 18581 0
usbhid 52659 0
hid 106148 3 usbhid,hid_logitech_dj
psmouse 106714 0
e1000e 254433 0
firewire_ohci 40409 0
ahci 29915 3
firewire_core 68769 1 firewire_ohci
sdhci_pci 23172 0
libahci 32716 1 ahci
sdhci 43015 1 sdhci_pci
ptp 18933 1 e1000e
crc_itu_t 12707 1 firewire_core
pps_core 19382 1 ptp
Ich hoffe, die Datei enthält nicht irgendwelche "Rechtschreibfehler" (siehe Foto im Anhang)? Beste Grüße Befrager
- Bilder
|
Vej
Moderator, Supporter
Anmeldungsdatum: 7. März 2013
Beiträge: 3390
|
Hallo Befrager. Befrager schrieb: nicht einmal das Eintragen aller Module von lsmod behebt das Problem... ☹
Damit liegt es an etwas Anderem. Ich hoffe, die Datei enthält nicht irgendwelche "Rechtschreibfehler" (siehe Foto im Anhang)?
Ich habe beim einfachen Durchlesen keine gefunden. Im Moment habe ich leider keine weiteren Ideen. Viele Grüße und vielen Dank für deine Ausdauer Vej
|
Befrager
(Themenstarter)
Anmeldungsdatum: 4. Februar 2014
Beiträge: 332
|
Hallo Vej Vej schrieb: Viele Grüße und vielen Dank für deine Ausdauer
Ich habe zu danken! ☺ Beste Grüße Befrager
|