[gelöst] kein Touchpad nach Suspend2RAM

Debian auf Notebooks und speziellen Geräten wie eingebetteten Systemen, Routern, Set-Top-Boxen, ...
Antworten
Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

[gelöst] kein Touchpad nach Suspend2RAM

Beitrag von hikaru » 22.07.2018 16:50:16

Hallo,

ich habe hier ein altes Core2Duo-Notebook, genauer ein Fujitsu Siemens Amilo Si 1520 auf dem Stretch/Xfce/amd64 läuft.
Das Gerät läuft problemlos, abgesehen davon, dass nach einem Suspend2RAM das Touchpad nicht mehr funktioniert. Ob das mit früheren Debian-Releases mal funktioniet hat weiß ich nicht.
Eine per USB angeschlossene Maus funktioniert auch nach dem Suspend-Zyklus.

ich hatte gelesen, dass es helfen soll, das Modul psmouse vor dem Suspend zu entladen und danach wieder zu laden.
Wenn ich das Modul vor dem Suspend entlade, dann hört das Touchpad auf zu funktionieren und wenn ich es testweise ohne Suspend wieder lade, dann funktioniert das Touchpad wieder. Es scheint also prinzipiell die/eine richtige Baustelle zu sein.
Wenn ich das Modul stattdessen aber nach dem Suspend lade, dann wird zwar das Modul erfolgreich geladen, aber das Touchpad funktioniert trotzdem nicht. Das ändert sich auch nicht, wenn ich das Modul nach dem Suspend sowohl lade als auch entlade.

Hat jemand eine Idee für einen Fix? Unter [1] wird ein Kernel-Patch für Elantech-Touchpads erwähnt, aber nach Überfliegen des Codes scheint mir das für mein Synaptics-Touchpad nicht weiterzuhelfen und ehrlich gesagt wäre ich dafür auf Dauer eh zu faul.

Leider taucht das Touchpad nicht in lspci*, lshw oder lsusb auf. Alles was ich dazu liefern kann ist das hier:

Code: Alles auswählen

# cat /sys/class/input/mouse0/device/uevent 
PRODUCT=11/2/7/25b1
NAME="SynPS/2 Synaptics TouchPad"
PHYS="isa0060/serio1/input0"
PROP=1
EV=b
KEY=6420 30000 0 0 0 0
ABS=11000003
MODALIAS=input:b0011v0002p0007e25B1-e0,1,3,k110,111,145,14A,14D,14E,ra0,1,18,1C,mlsfw
Nach dem Suspend verschwindet das ganze mouse0-Verzeichnis.

In lsmod (NoPaste-Eintrag40386) sehe ich neben psmouse kein verdächtiges Modul. Ein diff vor und nach dem Suspend liefert kein Ergebnis.


[1] https://askubuntu.com/questions/671910/ ... 617#827617

*)

Code: Alles auswählen

# lspci
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
00:1b.0 Audio device: Intel Corporation NM10/ICH7 Family High Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 2 (rev 02)
00:1c.2 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 3 (rev 02)
00:1d.0 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #1 (rev 02)
00:1d.1 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #2 (rev 02)
00:1d.2 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #3 (rev 02)
00:1d.3 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #4 (rev 02)
00:1d.7 USB controller: Intel Corporation NM10/ICH7 Family USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7-M Family) SATA Controller [AHCI mode] (rev 02)
00:1f.3 SMBus: Intel Corporation NM10/ICH7 Family SMBus Controller (rev 02)
01:00.0 Network controller: Ralink corp. RT2790 Wireless 802.11n 1T/2R PCIe
07:08.0 Ethernet controller: Intel Corporation PRO/100 VE Network Connection (rev 02)
07:09.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller
07:09.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 19)
07:09.2 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 0a)
07:09.3 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 05)
Zuletzt geändert von hikaru am 25.07.2018 00:09:54, insgesamt 1-mal geändert.

Benutzeravatar
TRex
Moderator
Beiträge: 8038
Registriert: 23.11.2006 12:23:54
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: KA

Re: kein Touchpad nach Suspend2RAM

Beitrag von TRex » 22.07.2018 19:29:32

Ich hab keine Idee für die Problemlösung, aber nachdem ich letztens auch damit rumexperimentiert hab:

https://www.kernel.org/doc/Documentatio ... ugging.txt

Du könntest mit den pm_test Optionen eingrenzen, ab wann der Fehler auftritt (ohne das Gerät tatsächlich in den Schlaf zu schicken). Ich hab in den Suchergebnissen auch ein paar Ansätze gefunden, die irgendwelche Geräte resetten sollen (ob die anwendbar sind, weiß ich nicht).
Jesus saves. Buddha does incremental backups.
Windows ist doof, Linux funktioniert nichtDon't break debian!Wie man widerspricht

Benutzeravatar
smutbert
Moderator
Beiträge: 8315
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: kein Touchpad nach Suspend2RAM

Beitrag von smutbert » 22.07.2018 23:17:22

Mich erinnert das (schmerzlich) an diesen Thread, in dem es keine Lösung gegeben hat: viewtopic.php?f=26&t=158285&start=15
(immerhin könntest du das ausprobieren was debianoli gefunden hat (psmouse zur initrd hinzufügen) und die Moduloptionen »resetafter=1« und »proto=bare« von psmouse testen – der Vollständigkeit halber vielleicht zusätzlich noch »synaptics_intertouch=1«)

Hast du den Kernel aus den Backports schon ausprobiert?
Gibt es vielleicht Kernelmeldungen von/mit i8042 oder psmouse

Code: Alles auswählen

# dmesg | grep -e i8042 -e psmouse

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: kein Touchpad nach Suspend2RAM

Beitrag von hikaru » 23.07.2018 00:34:06

TRex hat geschrieben: ↑ zum Beitrag ↑
22.07.2018 19:29:32
Ich hab keine Idee für die Problemlösung, aber nachdem ich letztens auch damit rumexperimentiert hab:

https://www.kernel.org/doc/Documentatio ... ugging.txt
Ich habe das bis zur "core"-Stufe durchexerziert, aber das Touchpad funktionierte jedes mal danach wieder und es gab auch keine erhellende Ausgabe:

Code: Alles auswählen

# echo core > /sys/power/pm_test
# cat /sys/power/pm_test
none [core] processors platform devices freezer
# systemctl suspend
# cat /sys/kernel/debug/suspend_stats 
success: 1
fail: 0
failed_freeze: 0
failed_prepare: 0
failed_suspend: 0
failed_suspend_late: 0
failed_suspend_noirq: 0
failed_resume: 0
failed_resume_early: 0
failed_resume_noirq: 0
failures:
  last_failed_dev:	
			
  last_failed_errno:	0
			0
  last_failed_step:
  

smutbert hat geschrieben: ↑ zum Beitrag ↑
22.07.2018 23:17:22
Mich erinnert das (schmerzlich) an diesen Thread, in dem es keine Lösung gegeben hat: viewtopic.php?f=26&t=158285&start=15
(immerhin könntest du das ausprobieren was debianoli gefunden hat (psmouse zur initrd hinzufügen) und die Moduloptionen »resetafter=1« und »proto=bare« von psmouse testen – der Vollständigkeit halber vielleicht zusätzlich noch »synaptics_intertouch=1«)
Das brachte leider keine Veränderung - weder das explizite Eintragen von psmouse in der initrd, noch die Moduloptionen, noch die Kombination von Beidem.
smutbert hat geschrieben: ↑ zum Beitrag ↑
22.07.2018 23:17:22
Hast du den Kernel aus den Backports schon ausprobiert?
Ja. Ohne Verhaltensänderung.
smutbert hat geschrieben: ↑ zum Beitrag ↑
22.07.2018 23:17:22
Gibt es vielleicht Kernelmeldungen von/mit i8042 oder psmouse

Code: Alles auswählen

# dmesg | grep -e i8042 -e psmouse
Ich sehe nichts Verdächtiges:

Code: Alles auswählen

# dmesg | grep -e i8042 -e psmouse
[    0.604543] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2F] at 0x60,0x64 irq 1,12
[    0.607093] serio: i8042 KBD port at 0x60,0x64 irq 1
[    0.607099] serio: i8042 AUX port at 0x60,0x64 irq 12
[    0.639642] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0
[    1.345172] psmouse serio1: synaptics: Touchpad model: 1, fw: 5.10, id: 0x258eb1, caps: 0xa04713/0x0/0x0/0x0, board id: 0, fw id: 32050
[    1.377597] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input2
[   39.742771] psmouse: unknown parameter 'synaptics_intertouch' ignored
[   40.097136] input: PS/2 Generic Mouse as /devices/platform/i8042/serio1/input/input13
Insbesondere ändert sich der Output nicht nach einem Suspend.

Benutzeravatar
smutbert
Moderator
Beiträge: 8315
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: kein Touchpad nach Suspend2RAM

Beitrag von smutbert » 23.07.2018 11:57:36

Im Netz findet man ziemlich viel zu solchen Problemen und mir fällt dazu nichts besseres als Trial & Error ein. Das hier

Code: Alles auswählen

psmouse: unknown parameter 'synaptics_intertouch' ignored
kommt allerdings unerwartet. Passiert das auch mit dem backports-Kernel, denn zumindest bei mir behauptet modinfo bzw. das psmouse-Modul die Option zu kennen. Sonst lautet die Option eventuell synaptics_touchpad und als Wert könntest du bei beiden sowohl 0 und 1 ausprobieren – ich habe zu beiden Werten Erfolgsmeldungen gefunden.
(Soweit ich das verstanden habe bestimmt der Parameter ob zusätzlich oder statt PS/2 auch I²C/smbus verwendet wird und letzteres verursacht beim suspend offensichtlich gerne Probleme.)

In dieselbe Richtung geht die Empfehlung nach dem Resume das Modul i2c-hid neu zu laden, aber bei dir ist das gar nicht geladen. (Ändert sich das mit dem Kernel aus den backports? Bei dem älteren Kernel käme mir vom Namen her das Modul i2c-i801 ähnlich verdächtig vor.)
Kann ein weiterer Suspend-/Resume-Zyklus mit einer sehr kurzen Schlafphase das Problem vorübergehend beheben?

Außerdem habe ich noch den Hinweis gefunden, dass es beim Entladen und Neuladen von psmouse und vielleicht auch i2c-hid notwendig ist zuerst auf ein Text-VT zu wechseln dort die Befehle einzugeben und erst dann wieder auf das VT von X zu wechseln, damit es hilft.

Das ist das, was mir von gestern in Erinnerung geblieben ist. (Ich habe noch ein bisschen mit meinem Tablet zu dem Thema gesucht, aber nun ist der Akku leer, deshalb kann ich Links zu Bugreports und Forenbeiträgen erst später nachliefern :wink: )


Optionen vom Treiber des Controllers wären vielleicht ein weiterer Ansatzpunkt. In anderen Fällen hat gelegentlich die Kombination von

Code: Alles auswählen

i8042.reset i8042.nomux i8042.nopnp i8042.noloop
(als Kernelparameter) geholfen (allerdings nicht hier viewtopic.php?t=166754).


Kann es sein, dass das Touchpad nur in X nicht mehr funktioniert und synclient es nach wie vor als aktiv erkennt (und es möglicherweise im Textmodus mit Debiangpm sogar noch funktionieren würde)?
Vielleicht steht im Log von Xorg irgendetwas brauchbares (nach dem Resume)?

Benutzeravatar
TRex
Moderator
Beiträge: 8038
Registriert: 23.11.2006 12:23:54
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: KA

Re: kein Touchpad nach Suspend2RAM

Beitrag von TRex » 23.07.2018 19:00:42

smutbert hat geschrieben: ↑ zum Beitrag ↑
23.07.2018 11:57:36
Kann es sein, dass das Touchpad nur in X nicht mehr funktioniert und synclient es nach wie vor als aktiv erkennt (und es möglicherweise im Textmodus mit gpm sogar noch funktionieren würde)?
Würde ich nach
hikaru hat geschrieben: ↑ zum Beitrag ↑
22.07.2018 16:50:16
Nach dem Suspend verschwindet das ganze mouse0-Verzeichnis.
tendenziell ausschließen. Das Verzeichnis ist Kernel-Sache.
Jesus saves. Buddha does incremental backups.
Windows ist doof, Linux funktioniert nichtDon't break debian!Wie man widerspricht

Benutzeravatar
smutbert
Moderator
Beiträge: 8315
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: kein Touchpad nach Suspend2RAM

Beitrag von smutbert » 23.07.2018 20:54:35

Mein Frage zielte in eine Richtung, von der ich nicht weiß, ob sie bei nicht-USB-Geräten einen Sinn ergibt:
Zumindest bei USB-Eingabegeräte ist es ja so, dass ein Treiber für das eigentlich Gerät geladen wird, das dann erst an das Subsystem für Eingabegeräte „gebunden“ wird. So könnte ein Gerät vielleicht über eine eigene Schnittstelle verfügbar sein (zB ein Touchpad für synclient?), aber als Eingabegerät und damit das mouse0-Verzeichnis fehlen?
(und beim synaptics-Touchpad kommt noch dazu, dass X zwei verschiedene Treiber dafür hat, den synaptics-Treiber und den libinput-Treiber.)

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: kein Touchpad nach Suspend2RAM

Beitrag von hikaru » 23.07.2018 20:56:14

smutbert hat geschrieben: ↑ zum Beitrag ↑
23.07.2018 11:57:36
Im Netz findet man ziemlich viel zu solchen Problemen und mir fällt dazu nichts besseres als Trial & Error ein. Das hier

Code: Alles auswählen

psmouse: unknown parameter 'synaptics_intertouch' ignored
kommt allerdings unerwartet. Passiert das auch mit dem backports-Kernel, denn zumindest bei mir behauptet modinfo bzw. das psmouse-Modul die Option zu kennen. Sonst lautet die Option eventuell synaptics_touchpad und als Wert könntest du bei beiden sowohl 0 und 1 ausprobieren – ich habe zu beiden Werten Erfolgsmeldungen gefunden.
Nein, mit Backports-Kernel kommt die Meldung nicht. Das ändert aber leider das Verhalten nicht (weder mit 0 noch mit 1). Unter Kernel 4.9 ist auch synaptics_touchpad nicht bekannt.
smutbert hat geschrieben: ↑ zum Beitrag ↑
23.07.2018 11:57:36
In dieselbe Richtung geht die Empfehlung nach dem Resume das Modul i2c-hid neu zu laden, aber bei dir ist das gar nicht geladen. (Ändert sich das mit dem Kernel aus den backports?
Nein, i2c-hid ist wird auch mit Backports-Kernel nicht geladen.
smutbert hat geschrieben: ↑ zum Beitrag ↑
23.07.2018 11:57:36
Bei dem älteren Kernel käme mir vom Namen her das Modul i2c-i801 ähnlich verdächtig vor.)
Wenn ich i2c-i801 entlade, dann hängt sich der Rechner im Suspend auf. Es wird zwar noch alles runtergefahren, aber offenbar arbeitet die Aufweckroutine dannn nicht mehr. Normalerweise blinkt die Power-LED im Suspend2RAM und ein kurzes Drücken des Powerknopfes weckt den Rechner wieder auf. Ohne i2c-i801 leuchtet die Power-LED dauerhaft und bei einem kurzen Drücken passiert gar nichts. Ich muss den Rechner dann durch langes Drücken hart resetten.
smutbert hat geschrieben: ↑ zum Beitrag ↑
23.07.2018 11:57:36
Kann ein weiterer Suspend-/Resume-Zyklus mit einer sehr kurzen Schlafphase das Problem vorübergehend beheben?
Nein. (gilt für beide Kernel)
smutbert hat geschrieben: ↑ zum Beitrag ↑
23.07.2018 11:57:36
Außerdem habe ich noch den Hinweis gefunden, dass es beim Entladen und Neuladen von psmouse und vielleicht auch i2c-hid notwendig ist zuerst auf ein Text-VT zu wechseln dort die Befehle einzugeben und erst dann wieder auf das VT von X zu wechseln, damit es hilft.
Das macht hier offenbar keinen Unterschied (beide Kernel).
smutbert hat geschrieben: ↑ zum Beitrag ↑
23.07.2018 11:57:36
Optionen vom Treiber des Controllers wären vielleicht ein weiterer Ansatzpunkt. In anderen Fällen hat gelegentlich die Kombination von

Code: Alles auswählen

i8042.reset i8042.nomux i8042.nopnp i8042.noloop
(als Kernelparameter) geholfen (allerdings nicht hier viewtopic.php?t=166754).
Diese Kombination hat keine sichtbare Wirkung (beide Kernel). nopnp allein führt unter 4.9 dazu, dass das Touchpad von Anfang an nicht funktioniert. Jede andere Option allein zeigt auch keine Wirkung.
smutbert hat geschrieben: ↑ zum Beitrag ↑
23.07.2018 11:57:36
Kann es sein, dass das Touchpad nur in X nicht mehr funktioniert und synclient es nach wie vor als aktiv erkennt (und es möglicherweise im Textmodus mit Debiangpm sogar noch funktionieren würde)?
Ich verstehe auf Anhieb nicht wie gpm funktioniert. Meine Intuition war, es vor dem Suspend auf einem VT zu starten und danach in mc zu testen, ob irgendwas mit der Maus geht, ähnlich wie es seinerzeit mit nc unter DOS mit Maustreiber war. Da geht aber nichts.
Ich sehe die Sache aber ähnlich wie TRex.
smutbert hat geschrieben: ↑ zum Beitrag ↑
23.07.2018 11:57:36
Vielleicht steht im Log von Xorg irgendetwas brauchbares (nach dem Resume)?
Mehr oder weniger.
Xorg.0.log vor dem Suspend: NoPaste-Eintrag40390
Nach dem Resume kommen diese Zeilen hinzu:

Code: Alles auswählen

$ diff -u0 /tmp/Xorg.0.log /tmp/Xorg.0.log.2 
--- /tmp/Xorg.0.log	2018-07-23 20:17:10.896074920 +0200
+++ /tmp/Xorg.0.log.2	2018-07-23 20:17:38.600971306 +0200
@@ -306,0 +307,513 @@
+[   190.784] (EE) SynPS/2 Synaptics TouchPad: Read error 19
+[   190.784] (EE) SynPS/2 Synaptics TouchPad: Read error 19
[..]
+[   190.797] (EE) SynPS/2 Synaptics TouchPad: Read error 19
+[   190.797] (EE) SynPS/2 Synaptics TouchPad: Read error 19
+[   190.797] (II) config/udev: removing device SynPS/2 Synaptics TouchPad
+[   190.821] (II) UnloadModule: "synaptics"
Wobei die Read error in Wahrheit über 200 Zeilen sind.

Damit kann man zumindest mal eine Suchmaschine füttern und findet u.a. [1].
In xinput verschwindet das Touchpad (id=12) und nur das nach dem Resume (Ausgabe vorher):

Code: Alles auswählen

$ cat /mnt/tmp/xinput
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ USB Mouse                               	id=10	[slave  pointer  (2)]
⎜   ↳ SynPS/2 Synaptics TouchPad              	id=12	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Power Button                            	id=6	[slave  keyboard (3)]
    ↳ Video Bus                               	id=7	[slave  keyboard (3)]
    ↳ Power Button                            	id=8	[slave  keyboard (3)]
    ↳ Sleep Button                            	id=9	[slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard            	id=11	[slave  keyboard (3)]
Diese beiden Befehle bleiben fruchtlos ...

Code: Alles auswählen

xinput float "SynPS/2 Synaptics TouchPad"
xinput reattach "SynPS/2 Synaptics TouchPad" "Virtual core pointer"
... weil schon der erste kein Touchpad findet:

Code: Alles auswählen

# xinput float "SynPS/2 Synaptics TouchPad"
unable to find device 'SynPS/2 Synaptics TouchPad'
Man findet auch [2], was wiederum zu [3] führt. Das hätte allerdings mit dem Backports-Kernel (4.16) funktionieren müssen, wenn hier die Lösung läge.


[1] http://forums.debian.net/viewtopic.php?f=7&t=122385
[2] https://bbs.archlinux.org/viewtopic.php?id=228492
[3] https://bugzilla.kernel.org/show_bug.cgi?id=195471

Gunman1982
Beiträge: 923
Registriert: 09.07.2008 11:50:57
Lizenz eigener Beiträge: MIT Lizenz

Re: kein Touchpad nach Suspend2RAM

Beitrag von Gunman1982 » 24.07.2018 10:46:02

Vielleicht ein Versuch wert: kernel parameter: "atkbd.reset"

https://bugs.launchpad.net/ubuntu/+sour ... +bug/59867

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: kein Touchpad nach Suspend2RAM

Beitrag von hikaru » 24.07.2018 23:28:37

Gunman1982 hat geschrieben: ↑ zum Beitrag ↑
24.07.2018 10:46:02
Vielleicht ein Versuch wert: kernel parameter: "atkbd.reset"

https://bugs.launchpad.net/ubuntu/+sour ... +bug/59867
Danke! Das löst im Prinzip das Problem. Das Touchpad funktioniert nach dem Resume wieder.

Allerdings hängt sich das Notebook mit dem Parameter etwa bei jedem 3. oder 4. Suspend auf. Das Display geht aus, aber die Power-LED leuchtet weiter und soweit sie vorher liefen, laufen auch HDD und Lüfter weiter.
Beim pm_test-Debugging ist auch hier nichts zu erkennen. Ebensowenig bringt eine Kombination von atkbd.reset mit einer oder allen von smutbert vorgeschlagenen i8042-Optionen Erfolg.

Im syslog sehe ich einen Unterschied zwischen einem erfolgreichen (NoPaste-Eintrag40391) und einem erfolglosen (NoPaste-Eintrag40392) Suspend-Zyklus. Auch längere Pausen von teils mehreren Minuten zwischen zwei Zyklen lösen das Problem nicht. In seltenen Fällen ist auch der allererste Zyklus erfolglos.
Ich vermute, dass mir das Ralink-WLAN-Modul bzw. dessen Treiber dazwischenpfuscht, das ich hier mal eingebaut hatte, weil ich das originale Intel-Modul in meinem Netbook nötiger brauchte. Bei einem Test mit per Hardwareschalter abgeschaltetem WLAN hatte ich jedenfalls 10 oder 12 erfolgreiche Suspend-Zyklen in Folge. Ich werde die Module mal zurücktauschen und dann weitersehen.

Edit:
Ich habe noch ein Broadcom-Modul gefunden, und damit klappte ein Dutzend Suspend-Zyklen problemlos. Ich kann also das Thema Suspend/Touchpad abhaken. Das Intel-Modul werde ich trotzdem nochmal testen, denn das Broadcom-Modul braucht deutlich länger um sich an meinem AP zu authentifizieren.

Edit2:
Auch mit dem Intel-Modul gibt es offenbar keine Probleme beim Suspend.

Antworten