Re: Kernel und Module

On Fri, Nov 09, 2012 at 08:43:07AM +0100, Lars Engels wrote:
> On Fri, Nov 09, 2012 at 02:10:50AM +0100, Bernd Walter wrote:
> >
> > Der USB-Controller sollte tot sein, wenn der Rechner im suspend ist.
> > Ein USB Controller schickt regelmässig Frames zum Gerät.
> > Wenn die ausbleiben sollte das Gerät auch in suspend gehen und im Fall
> > von Bus-powered gar auf absolut minimalistischen Strombedarf runter
> > gehen.
> > Zumindest darf es keinen Strom auf den Port geben, d.h. es muss auch
> > der detection-pull up deaktiviert werden und damit ist das Gerät aus
> > Sicht von USB disconnected.
> > Ausnahme sind nur Geräte, die explizit für Standby deklariert sind
> > und dazu gehören z.B. Tastaturen mit denen man den Rechner aus dem
> > Standby heraus holen kann.

Unter Linux ist es bei mir seit etwa Kernel 3.2 so, daß ich mittels
eines Drückens der Any-Key-Taste den PC aus dem Suspend holen kann.
Das ging vorher ausschließlich über den Power-On-Schalter.
BIOS-seitig kann ich nur ändern, ob USB-Evets Wake-Signale auslösen.
Ein Ein/Abschalten im BIOS ändert am o.g. Feature hingegen nichts.

> > Der USB-Controller bekommt dann von solchen Geräten im suspend ein
> > spezielles Signal (kenne ich im Detail nicht mehr, weil nie auf
> > low-level gebraucht).
> > Wenn das Gerät erst nach dem aufwecken einen disconnect macht ist
> > durchaus anzunehmen, dass das ACPI mit zum abschalten der CPU eben noch
> > nicht komplet im suspend ist, d.h. der USB-Controller auch noch aktiv
> > ist und erst beim aufwecken der CPU stopt.
> > Damit wird im suspend natürlich auch mehr Strom verbraucht.
> > Man sollte bei solchen Symptomen sehr vorsichtig sein, das wäre nicht
> > der erste Fall, bei dem das BIOS den Lüfter abschaltet, aber nicht alle
> > Wärmeerzeuger - wer weiß, was da noch alles an bleibt...
> > Schon alleine die Tatsache, dass es externe, aber keine internen Geräte
> > betrifft ist schon eine Merkwürdigkeit, die annehmen lässt, dass das
> > BIOS die Ports anders bheandelt - aus OS Sicht sind die immer gleich.
>
> Danke für die ausführliche Erklärung.
> Mir ist daraufhin eingefallen, dass ich im BIOS die Option "Always power
> on USB ports" aktiviert hatte, somit werden die Ports im Standby und im
> ausgeschalteten Zustand weiter mit Strom versorgt. Das habe ich jetzt
> deaktiviert, aber das Resultat bleibt gleich: Ab dem zweiten Aufwachen
> schlafen die Ports weiter. Schade...

Also ich bin erheblich weiter gekommen nachdem ich die USB-Treiber
nun als ladbare Module habe.
Bei mir ist es auch so: ach dem _ersten_ Resume sind sowohl Maus und
Keyboard funktionstüchtig. Nach dem zweiten Resume evtl. noch die
Maus, aber nie die Tastatur. In rc.suspend/rc.resume lade/entlade
ich das ohci-Modul (daß ist bei mir nachweislich das einzige Modul,
was eine Wirkung zeigt, kein ukbd, kein uhid usw.).
Im Gegensatz zum GENERIC-Kernel werden mir nun mit usbconfig die
beiden low-speed/USB1.1 Geräte Maus und Keyboard auch immer
angezeigt, und es gibt keine Fehlermeldungen mehr in
dmesg/messages - das unabhängig ob beide Geräte denn auch
funktionieren. Ich habe versucht mittels usbconfig die Geräte einzel
zu resetten, power_on/off, aber ohne Erfolg.

Aber: ich habe gleichzeitig eine ssh-Sitzung auf den Recher. Wenn
ich davon dann eingebe:
kldunload ohci && sleep 10 && kldload ohci
dann kann ich _immer_ Maus+Tastatur wieder erwecken. Diese
zehnsekündige Pause brauche ich, da ein kürzeres Intervall zwischen
Ent- und Wiederladen nicht funktioinert.
Was das Ganze nun wieder merkwürdig macht: Bringe ich diese Sequenz
in die rc.resume ein dann funktioniert es _nie_. Nur wenn ich es
"seperat" über die ssh-Sitzung mache hat das Erfolg. Und das
verstehe wer will <g>. Ich meine in rc.resume passiert nun nichts
mehr, was Einfluß auf die Sequenz haben könnte...
Ausgeführt wird es, ich sehe es an der Num-Lock-LED und habe auch
per touch ein paar Status-Files anlegen lassen.
Ich habe die Sequenz auch in ein extra Skript ausgelagert, noch mehr
sleeps eingebaut, es ist verhext: Nur über ssh kann ich nach dem
zweiten Resume die Eingabegeräte wieder einschalten.
Ich brauche das ohci-Modul noch nichtmal vor dem Suspend zu entladen
um mittels der obigen Sequenz meine Eingabegeräte wieder zu
erwecken. Es wäre aber schon klasse (und hilfreich zu wissen), warum
das in der rc.resume nicht funktioniert. Wenn man schon zu solchen
Krücken greifen muß ;-)

Meine Überlegung wäre noch zu versuchen: ein minütlicher cronjob
prüft ob eine durch das rc.resume-Skript angelegtes Statusfile
vorhanden ist und startet ggf. die Sequenz oben (bzw. ein Skript
damit). So könnte ich prüfen, ob irgendein Automatismus den Umweg
über ssh vermeiden könnte.

Gruß
        Gerhard

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Fri 09 Nov 2012 - 11:57:37 CET