Mailinglist Archive: opensuse-mobile-de (216 mails)

[Stefan Seyfried <seife@xxxxxxxxxxxxxxxxxxxxxxx>]

Hallo,

On Mon, Jul 11, 2005 at 11:17:28PM +0200, David Huecking wrote:
> allo! - Das mag ich hier so: nahezu sofort kompetente Antworten und Hilfe(-Versuche)! Super.

Nun ja, ich tue was ich kann. Oder anders ausgedrückt: bei einem
qualifizierten Bugreport ist es einfach, kompetent zu antworten :-)

> On Sonntag 10 Juli 2005 22:03, Stefan Seyfried wrote:

> OK, den Code rund um die for-Schleife in der powersaved.cpp hatte ich mir auch 
> angeguckt, aber da ich bisher keinen Hintergrund zu all dem habe, was man da 
> per select abfragen kann... sicherlich eine längere Aufgabe per Autodidakt da 
> einzusteigen.

Ja, der Code ist auch nicht unbedingt durchsichtig, was auch dazu führt,
daß ich jedes Mal, wenn jemand die select-loop angefaßt hat, danach wieder
aufräumen und Fehler beseitigen muß ;-)

> > Das einzige was mir dazu einfallen würde, warum select hier ein
> > "invalid argument" liefern sollte, wäre ein verwirrter Timeout.
> > 
> > Was steht denn in POWERSAVED_POLLING_INTERVAL in
> > /etc/sysconfig/powersave/common?
> david@bree:~> grep POWERSAVED_POLLING_INTERVAL  /etc/sysconfig/powersave/common
> POWERSAVED_POLLING_INTERVAL=""
> 
> Sollte also der default von 333 sein.
> 
> Aber mal sehen: 
> Ein 
> POWERSAVED_POLLING_INTERVAL="333" 

Ja. Du solltest das mit den "Default:"-Kommentaren im Konfigurationsfile
beim powersaved nicht zu Ernst nehmen ;-) Das ist mir vor ein paar Wochen
auch aufgefallen und die nächste Version hat das nun gefixt, die 
einkompilierten Defaults stimmen mit denen im Configfile überein (und dort
steht für die defaults nur noch "", so wie es sein soll).
Konkret: einkompiliert ist / war "2000"

> eingetragen und ein
>  rcpowersaved start
> bringt zwar noch einmalig die Syslog-Meldung:
> Jul 11 22:39:26 bree [powersave][8462]: WARNING in Function start; line 371: Select returned an Error, but not interrupted through a signal: Invalid argument This is not nice, but normal after a suspend2disk
> Jul 11 22:39:33 bree last message repeated 219312 times
> Das war's dann aber. Powersaved läuft wie er soll; CPU bei 600MHz und bei Bedarf höher.

Ja, dadurch daß der timeout kleiner ist, wird der eigentliche bug maskiert
vermute ich. Ich untersuche das mal genauer und mache evtl. ein YOU (du bist
allerdings bisher der einzige, den das getroffen hat).

> Der Vollständigkeit halber hier das Ergebnis ohne den Wert in POWERSAVED_POLLING_INTERVAL:
> Jul 11 22:02:43 bree [powersave][8020]: Debug:  Needed 0 sec and 355 usec time to process functions after select 
> Jul 11 22:02:43 bree [powersave][8020]: Debug:  Select waiting: 2 secs and 4294966 millisecs 

hier ist das Problem: die Milisekunden hatten einen underflow. Der Code der "schuld" ist:

  else {
    req.tv_sec  = config->current_scheme->POLL_INTERVAL / 1000
                   - process_time / (1000*1000);
    req.tv_usec = (config->current_scheme->POLL_INTERVAL * 1000 % 1000000)
                   - process_time % (1000*1000);
    pDebug (DBG_DEBUG, "Needed %lu sec and %lu usec time to process functions after select\n",
    process_time / (1000*1000), process_time % (1000*1000));
  }

Das Problem ist, daß bei einer "geraden" Sekunde Poll-Interval (2,0 bei dir) 
	req.tv_usec = 0 - process_time
wird. Das muß aber positiv bleiben (und vermutlich unter 1000000, aber da bin
ich nicht sicher. Der Workaround ist einfach: POLLING_INTERVAL darf kein
"gerader Tausender" sein (obwohl 1001 auch Schwierigkeiten macht, sobald
process_time > 1msec ist). Mit den "üblichen Werten" zwischen 100 und 500
ist aber alles in Butter.

> > (nach ein paar sekunden schnell strg-c drücken)
> > danach mal schauen, in welchem select-zweig er war ("Select waiting without
> > timeout" oder "Select waiting: xxx secs and yyy millisecs").
> Ein Ctrl+C tat es nicht, sondern nur ein kill -9, aber was soll's.

Ja, da dein STRG-C nur den select-loop unterbrochen hat, und dort -EINTR
explizit "kein Fehler" ist => nicht abbricht :-)

> Ok, Du hast den Überblick. 8-)

Ich hoffe, du jetzt auch.

> Einen herzlichen Dank und auf zur nächsten Übung (Suspend to RAM und to disk)...
> Da dies ja der zweite Versuch der Mail ist, hier noch das Erbebnis vom Supend:
> Beides 2RAM und 2disk funktioniert out of the box. Nach Aufwachen USB und Sound noch da.  :-)
> Gab's da sonst noch typische Schwierigkeiten?

Eigentlich nicht. Meine Erfahrung ist: Auf Maschinen, wo suspend to RAM geht,
ist es zuverlässig, suspend2disk geht bei mir sowieso immer.

Du solltest halt keinen "Blödsinn" machen:
 - Externe USB/FiWi-Platte während des suspend ab/anstecken
 - Zwischendurch ein anderes Betriebssystem booten (Windows/Knoppix/Rescue)
   und _irgendwie_ auf die Platte zugreifen (ich würde nicht mal lesend drauf
   zugreifen - evtl. wird beim unmount doch das dirty-flag zurückgesetzt)
 - Prinzipiell ist es kritisch, die Hardware während des suspend zu verändern
   sei es dock/undock oder anstecken einer Maus (obwohl das wirklich
   funktionieren sollte).

USB/FiWi wird versucht dadurch zu lösen, daß
 - die Filesysteme möglichst unmounted werden
 - die Module usb-storage, sbp2 (fiwi) und die hostcontroller entladen
   werden. Dadurch wird die Hardware "virtuell abgesteckt"
Aber wenn du erst gar keinen "Blödsinn" probierst, ist es auch
wahrscheinlicher keine Probleme. Man muß ja nicht mit dem Feuer spielen :-)
 
> Nochmals Dank! - Gute Arbeit!

Ich kann immerhin für mich verbuchen, daß der Bug nicht von mir eingebaut,
sondern nur gefunden wurde :-) (schon vor 2 Wochen, ich dachte aber nicht,
daß er jemand tatsächlich treffen würde).

Viel Spaß
-- 
Stefan Seyfried