staging.inyokaproject.org

Benno-007 schrieb:

ingo2 schrieb:

Die Module lp und parport werden trotz blacklisting geladen.

Ich hab zwar auch keinen richtigen Plan, aber liegen die vielleicht doch noch in der Initial Ramdisk rum?

Ich habe aber immer update-initramfs -u' laufen lassen. Ich vermute, da sind entweder im Kernel selbst noch Abhängigkeiten, die diese Module benötigen, oder sie werden nachträglich von CUPS geladen, da das der default ist, wenn kein Drucker gefunden wird? Aber ist ja jetzt egal, diente nur der Ursachenforschung.

Danke für die Lösung.

Ja, ich hatte zuletzt auch die GraKa im Verdacht (nVidia 7100GS), bis ich dann als letzte Idee mit nousb gebootet habe und plötzlich alles klappte. Und das schöne:

alle USB-Geräte, die dauernd angeschlossen sind, überstehen suspend problemlos ohne irgendwelche Hooks oder suspend-Scripte. Und das sind eine ganze Menge! Bei Hardy habe ich noch für den "apcupsd", der auf einem USB-Port lauscht, ein suspend-hook geschrieben, sonst ließ sich der ohci-hcd nicht entladen. Ist jetzt überflüssig.

Viel Erfolg, Ingo

alle USB-Geräte, die dauernd angeschlossen sind, überstehen suspend problemlos ohne irgendwelche Hooks oder suspend-Scripte. Und das sind eine ganze Menge!

Ich las in deinem Link:

153 Writing "-1" to power/autosuspend and writing "on" to power/control do
154 essentially the same thing -- they both prevent the device from being
155 autosuspended.  Yes, this is a redundancy in the API.

Bezüglich dem gelb markierten und dem Grund, warum nun alles gehen soll, drängt sich mir der Gedanke auf, dass USB-Geräte so gar nicht schlafen gelegt werden, sondern weiter Strom zapfen und auch die Platine hin zu USB ganz schön unter Strom bleibt - könnte das sein?

Dasdachte ich auch erst, ist aber ein Trugschluß:

1. Ich habe ein recht genaues Leistungsmeßgerät vor meinem PC hängen und da sind die Werte unter Lucid aufs Watt genau wie unter Hardy. Sowohl im Betrieb (ruhender Desktop) als auch im S3. Der Wert im S3 ist genau so hoch wie S5 (soft off), ca 3Watt.

2. Gemäß Doku-Zitat war das ab Kernel 2.6.23 (also Hardy) so, daß nur die Hub's autosuspended wurden, keine Geräte (lies mal bis zum Ende durch).

3. Das eigentliche Problem sind aber bei meiner Hardware die Hub's (im MCP55), die können offensichtlich im "autosuspended Zustrand" keinen System-Suspend korrekt überstehen. In Hardy konnte man das durch entladen+laden des ohci-hcd + ehci-hcd wieder in die Reihe bringen (ohne die kernel-Option), die sind aber unter Lucid einkompiliert.

4. Wenn ich das Zitat richtig verstehe, sind zwar alle USB-Geräte jetzt per default auf "autosuspend=off". Trotzdem können einzelne Treiber gezielt einzelne Geräte in den autrosuspend schicken. Und ein System-suspend ist der ganzen Sache übergeordnet (egal ob ein device autosuspended ist oder nicht.

Das eigentliche Problem ist also, daß es massig Geräte (und auch HUBB's) gibt, die wenn autosuspended, den System-Suspend blockieren oder nicht mehr korrekt resumen.

Viele Grüße, Ingo

👍 für die Erklärungen.

Vielleicht kann man das in die Wiki-Diskussionsseite verlinken oder gar mal einen Link auf's Forum riskieren? Zumindest unter "Links" (für weiterführende Infos)...

Bis das mal einer ausgearbeitet (oder bestätigt) hat...

2. Boot with kernel parameter "usbcore.autosuspend=-1"

Ich würde einfach das reinschreiben als Option bei den Versuchen...(ich hab die Seite jetzt nicht angesehen, wo das am besten reinpaßt).

Benno-007 schrieb:

👍 für die Erklärungen.

Vielleicht kann man das in die Wiki-Diskussionsseite verlinken oder gar mal einen Link auf's Forum riskieren? Zumindest unter "Links" (für weiterführende Infos)...

Das habe ich schon gemacht (Diskussionsseite)

Bis das mal einer ausgearbeitet (oder bestätigt) hat...

Das würde mich auch interessieren. Ich könnte zwar das Spielchen jetzt noch weiter treiben und die "Verursacher-Devices" suchen. Dazu müßte ich aber für jedes Device eine udev-Regel schreiben und für das gezielt autosuspend aktivieren. Zitat:

Setting the initial default idle-delay to -1 will prevent any
autosuspend of any USB device. This is a simple alternative to
disabling CONFIG_USB_SUSPEND and rebuilding the kernel, and it has the
added benefit of allowing you to enable autosuspend for selected
devices.

Aber das ist mir jetzt wirklich nicht der Mühe wert, außerdem braucht jeder Test etliche system-suspend zum testen, das mag eine Desktop-HD auch nicht so gerne (dauernd spin-up, spin-down ...).

Ein simples Beispiel:

meine optische Logitech Maus: die rote Laser-Diode geht weder unter Hardy, noch unter Lucid jemals aus (autosuspend) - also soch ein Aufwand, um ggf. noch 3 oder 5 Watt im normalen Betrieb zu sparen ... hat mich bisher genügend Zeit gekostet.

Und noch eine Info: das Problem betrifft ja nicht nur Lucid, auch Karmic (hatte ich mal getestet), Squeeze, Fedora 13, also alle neueren Kernel!

Du darfst gerne weiter testen, falls du entsprechend widerspenstige Hardware hast 😉

Ingo

Ich bin da meistens dann auch zu faul - habe die Kiste tagsüber einfach durchlaufen lassen. Auch, wenn ich mal 1-4h weg bin. Aber dann wäre das schon ein Grund, monatlich mal 7 EUR Strom zu sparen oder so. Oder nicht nur vor dem Ding zu hocken. 😉

Ansonsten aber lese ich gern nach und denke mit - probiere auch mal was aus. Aber solche stundenlangen Orgien mit der Suche nach der Nadel im Heuhaufen (und dann noch udev "erlernen" usw. → Theorie vs. Praxis - die ersten "Gehversuche" ...), das nervt mich dann doch eher an. Derweil lös ich lieber Probleme von anderen, echte Probleme. Da lern ich in der Zeit wenigstens was in Breite oder Tiefe einer Materie und mach nicht nur stupide Tests (oder lese Dinge in einer Tiefe nach, die mich so tief gar nicht unbedingt interessieren). 😉

Ich hoff(t)e halt, dass das bei Lucid dann einfach so geht. 😉 Sollte ja schon bei Karmic besser geworden sein. Nicht nur bei 3D-Treibern, nehme ich an.

Hi Benno,

bei mir ist es etwas anders. Meistens verbeiße ich mich in eine Idee, um was besser zu machen oder ein Problem zu lösen und gebe dann keine Ruhe bis es erledigt oder gelöst ist. So war das auch hier als ich Lucid probiert habe und dann feststellen mußte, das eben doch nicht "einfach alles geht". Unter Hardy konnte ich das s2ram-Problem mit Hilfe des Forums und Wiki's noch vergleichsweise einfach lösen.

Auf Lucid war ich dann echt sauer (obwohl es auf meinem Netbook prima läuft) wegen ein paar Dingen (u.a. plymouth). War manchmal schon so weit und habe an neue Hardware gedacht. Aber das "Ubuntu-Certified Hardware" kannst du ja den Hasen verfüttern: nirgends ist zu lesen, welche Funktionen mit welcher Hardware-Variante getestet und "certified" wurde. So habe ich dann immer mal wieder gestöbert und versucht, eine Lösung zu finden - in diesem Forum war das sicher zu viel verlangt - bis jetzt endlich der Knoten geplatzt ist.

Ich hatte mich auch schon mit dem Gedanken abgefunden, über die 3 Jahre Supportdauer von Hardy hinaus einfach mit Hardy weiter zu machen und es dabei zu belassen. Mir reicht die eigentlich solide Harware (Athlon64 X2-4200 mit 6GB ECC-RAM) auch die nächsten Jahre noch aus - und das alles nur um Lucid ordentlich zu betreiben ???

Das lästige war nur, daß ich alle Tests auf realer Hardware machen mußte, eine VM ist da nicht sehr hilfreich 😉

Viele Grüße, Ingo

P.S.: habe jetzt auch noch einen Link im Wiki-Artikel eingebaut, mal sehen, ob's Rückmeldungen gibt?

Ich war zufrieden, dass Wine (zu 9.04-Zeiten, die bei mir noch andauern) so weit war (über 1.0 schon vorinstalliert) und dass auch UMTS einfach so lief. So war Software, Netzzugang (bzw. als Notfall-Zugang) und Hardware weitestgehend von Beginn an abgesichert und das Abenteuer konnte losgehen. Ich brauchte mich eigentlich um nix kümmern, wollte mir aber auf jeden Fall das Wissen dazu aneignen, wie man exotische Hardware und Win-Software ans Laufen bekommt. Das heißt aber nicht, dass ich alles durchboxen will und mir da nicht einfach 1 Test reicht und den Rest nur anlesen.

Damit man bei Bedarf gleich loslegen kann, ohne erst 1-2h rumlesen und testen zu müssen. Bei 90% hatte ich auch mal aufgehört, zu meinem DVB-T-Stick gab es im Wiki 7 (!) Installationsvarianten und ich wollte gern eine einfache, die ich mir merken kann und nichts mit kompilieren zu tun hat. Nunja, das wäre dann die letzte Möglichkeit gewesen, aber die Zeit war mal wieder überstrapaziert und ich brauche sowieso nur OTR für Fernsehen. Also hab ich das auch erstmal ad acta gelegt. 😀

Hast du zufällig den Wiki-Link rumfliegen?

Edit: Ich will eigentlich auch nur alle 2-3 Jahre wechseln, aber ich denke, es wird sich zw. 1 und 2 Jahren einpendeln, weil sich doch viel tut und Sachen wie Suspend für mich unter Luxus fallen. 😉 Ansonsten die Grundfunktionen funktionieren ja meistens.

Benno-007 schrieb:

Hast du zufällig den Wiki-Link rumfliegen?

Na klar: http://wiki.ubuntuusers.de/pm-utils und da ganz einfach nach Lucid suchen (Ctrl+F), die 2. und 3. Fundstellen.

Edit: Ich will eigentlich auch nur alle 2-3 Jahre wechseln, aber ich denke, es wird sich zw. 1 und 2 Jahren einpendeln, weil sich doch viel tut und Sachen wie Suspend für mich unter Luxus fallen. 😉 Ansonsten die Grundfunktionen funktionieren ja meistens.

Aber wie man hier sieht, gibt es auch mal Rückschläge.

Habe übrigens gefunden, daß man beides zusammen machen muß, sonst gibt es Probleme. Also:

• im BIOS den "USB Legacy Support" abschalten und

• mit dem kernel-parameter 'usbcore.autosuspend=-1' booten

Das war dann auch noch großes Glück, daß ich genau diese Kombination probiert habe ☺

Ohne den Parameter 'usbcore.autosuspend=-1' braucht der PC im Betrieb ca. 5 Watt weniger, aber nur, wenn man den USB-Legacy-Support abschaltet (sonst verhindert offenbar das BIOS den autosuspend und der Fehler mit nur 1x suspend+resume ist wieder da). Im S§-Zustand ist kein Unterschied in der Leistungsaufnahme.

Und (hat aber mit diesem Problem nicht direkt zu tun): das Modul für die TV-Karte (ivtv) kann natürlich kein suspend, das muß man vorher entladen und wieder laden in der /etc/pm/config.d/00sleep_module

Viele Grüße, Ingo

Darüber hatte ich noch gar nicht so nachgedacht, da ich dachte, die Module müßten für S3/Resume sowieso ent- und geladen werden. Aber klar, Entladen würde ja dann manuell auch nicht gehen, wenn es automatisch nicht ginge.

Ich habe heute schon wieder viel zu viel probiert, statt andere Dinge zu machen. Dabei komm ich dann vom 100. ins 1000. Dennoch habe ich ein paar Dinger durchgezogen bis zu einem Ergebnis. 😉 Bin aber noch dabei und mache mal weiter und schlage vor, wir verlagern unser Offtopic in PNs und ggf. in die Lounge, zumal wir nun auch im Wiki verlinkt sind. 😉

So, es hat mir natürlich doch keine Ruhe gelassen und ich habe die "schwarzen Schafe" letzendlich lokalisiert. Mit folgenden Konfigurationen klappt der suspend auch unter Lucid und ohne die Kernel-Option "usbcore.autosuspend=-1":

• Im BIOS unbedingt "USB Legacy Support" abschalten

• Modul "usb_snd-audio" blacklisten

• Modul "usblp" vor suspend entladen und nach resume wieder laden

Das spart nochmal ca. 50 Cent/Monat bei der Stromrechnung (ca 3-4 Watt, wenn der PC im Betrieb ist).

Kurze Erklärung:

In /var/log/messages fand ich von früher folgende Einträge nach dem 1. suspend + resume:

usblp 2-3:1.0: no reset_resume for driver usblp?
....
snd-usb-audio 1-9:1.2: no reset_resume for driver snd-usb-audio?
snd-usb-audio 1-9:1.3: no reset_resume for driver snd-usb-audio?

Diesen Modulen fehlt also die entsprechende Funktion im Modul (wohl, weil sie im Laptop kaum benötigt werden?).

Modul usblp läßt sich problemlos in der /etc/pm/config.d/00sleep_module eintragen und so entladen/laden.

Modul snd-usb-audio (Mikrophon meiner Logitech WebCam E3500) läßt sich nicht entladen, da von Sound-System blockiert. Da blieb also nur blackklisten in der /etc/modprobe.d/blacklist.conf. Das ist bei mir nicht tragisch, habe ja noch einen Mikrophon-Eingang am PC (Chipset).

Wirklich wichtig ist auf jeden Fall:

Wer noch ein älteres Motherboard und einem BIOS hat, welches die Funktion "USB Legacy Support" bietet, muß dieses abschalten! Damit muß man zwangsläufig eine PS/2-Tastatur benutzen (die Funktion mappt eine USB-Tastatur auf den PS/2-Port). Dies war unter Hardy nicht nötig - und relativiert die Aussage: "Linux kommt viel besser mit etwas älterer Hardware zurecht"

So nun allen viel Erfolg bei eigenen Veruchen,

Ingo

ingo2 schrieb:

So, es hat mir natürlich doch keine Ruhe gelassen und ich habe die "schwarzen Schafe" letzendlich lokalisiert.

Hallo,

auch wenn es reichlich spät kommt:

Ich finde es klasse, das Du Dich so in dieses Problem verbisssen hast; bei mir reichen weder die Geduld, noch die Fähigkeiten so weit 😢

Wirklich wichtig ist auf jeden Fall:

Wer noch ein älteres Motherboard und einem BIOS hat, welches die Funktion "USB Legacy Support" bietet, muß dieses abschalten! Damit muß man zwangsläufig eine PS/2-Tastatur benutzen (die Funktion mappt eine USB-Tastatur auf den PS/2-Port). Dies war unter Hardy nicht nötig - und relativiert die Aussage: "Linux kommt viel besser mit etwas älterer Hardware zurecht"

Kann ich nur bestätigen; das führt einen immer wieder zu der 'dumpfen' Weisheit Never touch a running system, bringt uns aber in der Linux-Entwicklung nicht weiter. =⇒ Man sollte solche 'bugreports' seitens der Entwickler ernst nehmen, sonst springen auch noch die letzten Enthusiasten ab, bzw. bleiben bei ihrem laufenden System;

wer will schon _nur noch_ Systempflege betreiben?

So nun allen viel Erfolg bei eigenen Veruchen,

Ingo

Danke, werde es weiter versuchen...

Ewald

mue.de schrieb:

Kann ich nur bestätigen; das führt einen immer wieder zu der 'dumpfen' Weisheit Never touch a running system, bringt uns aber in der Linux-Entwicklung nicht weiter. Danke, werde es weiter versuchen...

Nur zur Aufmunterung: die in diesem Thread beschriebenen Dinge habe ich alle beibehalten und immer noch das selbe Motherboard. Und darauf läuft jetzt Squeeze absolut stabil und mit problemlosen Suspend (s2ram).

Warum sollte ich grundsolide Hardware (Athlon64-X2 mit 6GB ECC-RAM) gegen was neues tauschen? Nur, weil sie schon 4 Jahre alt ist (lief schon unter Feisty problemlos)? - Also "Never touch ...

Viele Grüße,
Ingo

ingo2 schrieb:

Ich habe inzwischen den Verdacht, daß es irgendwier mit dem Soundsystem zu tun hat wegen dieser Fehlermeldungen (nur Lucid) nach einem resume:

cannot set freq 16000 to ep 0x86

Dennoch: Sound geht nach estem resume.

Vielleicht versuche ich mal alles was mit snd zu tun hat, zu de-installieren - hoffentlich geht das überhaupt und da sind keine Module in den Kernel einkompiliert?

Ohne alte Kamellen aufwärmen zu wollen; bei meinem nicht funktionierenden Resume fand ich in den Logs:

 Sep 13 22:56:33 muelux-LT6cA kernel: [    0.332254] ACPI Warning for \_SB_.PCI0._OSC: Parameter count mismatch - ASL declared 5, ACPI requires 4 (20090903/nspredef-336) 

_SB_: Sound-Blaster?, osc : Oscillator? Wie kann ich der Sache weiter auf den Grund gehen? Wird nicht gerade einiges am Sound-System renoviert?

Gruß

mue.de