Robert Szentmihalyi wrote:
Am Mittwoch, 29. August 2001 12:56 schrieb Roland Martin:
Robert Szentmihalyi wrote:
Am Dienstag, 28. August 2001 12:16 schrieb Roland Martin:
Hi Robert, ich hab gestern abend noch ziemlich lange die neuen software suspend kernel frickeleien ausprobiert. und ich glaube das funktioniert. Ih muss mir allerdings noch einen alten 2.91 gcc besorgen, und
Der macht aber Probleme mit neuen Kernels...
ja. hat auch nicht alles geklappt. dazu spaeter mehr...
dann werd ich sehen, ob's das haelt was es verspricht. die machen da auch in den kernelquellen rum... das ganze leuft via swap, in die dann ein aktuelles bdflush image reingeschrieben wird. kingt echt vielversprechend, und in dem neuen entwicklerkernel 2.5 solls dann auch "offiziell" rein. aber
ist leider AFAIK noch nicht so stabil. Mußt mal schauen, ob der Code was taugt. Auf jeden Fall ist er noch sehr ALPHA...
extrem alpha. kann auch nur mit dem alten egcs 2.91 kompiliert werden. mann das war vielleicht eine kniffelei... aber jetzt geht der rest nicht mehr zu kompilieren... habs mal auf die laengere bank geschoben 8)
solange will ich auch nicht warten, deswegen versuch ich erstmal deinen tipp von unten (2.4.9). da ich aber isdn habe, wird das wahrscheinlich etwas dauern, bis ich saemtlcihe quellen hab...
Ich hab zwar DSL hier, bin aber nicht sicher, ob ich ein Kabel auftreiben kann, das bis Köln reicht... :-)
Hi Roland,
verzeihung, aber ich schon, s.u.
aber die error message im /var/log/messages sgt immer, das der kernel diesen apm modus nicht machen will.. bzw. irgendwas einen i/o error produziert.
Was für messages kriegst du genau?
hmmm... Ich habe da noch eine Idee. Kannst du mal den 2.4.9 vanilla Kernel testen? Ich kann es im Moment leider nicht, weil die Schublade vom DVD den Geist aufgegeben hat und das Notebook jetzt erst mal ein paar Tage bei HP ist...
ja, mittlerweile hab ich die sourcen, ... aus der uni gezogen. hab eben den kernel gebaut. und : schon wieder nix. kompilationsschalter: <*> Advanced Power Management BIOS support [ ] Ignore USER SUSPEND [ * ] Enable PM at boot time [ * ] Make CPU Idle calls when idle [ * ] Enable console blanking using APM [ ] RTC stores time in GMT [ ] Allow interrupts during APM BIOS calls [ ] Use real Mode APM BIOS call power off naja, und die interrupts sind ja auch nur fuer die thinkpads. da haben uebrigens die apm programmierer, in apm.c ziemlich viele patches fuer thinkpads reingemacht. scheint also ein aehnliches problem zu haben... bin etwas gefrustet, muss ich schon zugeben. aber mir ist noch was lustiges aufgefallen: wenn man den restore time RTC switch mit kompiliert, denkt der kernel immer er waer grad schon zwei stunden suspend gewesen. schau mal hier (von letzter mail..): Aug 28 09:53:03 tuna apmd_proxy: suspend system Aug 28 09:53:04 tuna apmd[124]: System Suspend und nu der zeitsprung... Aug 28 11:54:10 tuna kernel: apm: suspend: Unable to enter requested state ----*************------------- komisch, oder ?? danach wird wieder upgedated, also wieder normale zeit... wenn man den restore RTC switch rausnimmt gehts auch ohne zeitloch. aber keine veraenderung sonst. also hab ich mal etwas geschaufelt... aus arch/i386/kernel/apm.c static u8 apm_bios_call_simple(u32 func, u32 ebx_in, u32 ecx_in, u32 *eax) { u8 error; APM_DECL_SEGS unsigned long flags; __save_flags(flags); APM_DO_CLI; APM_DO_SAVE_SEGS; { int cx, dx, si; /* * N.B. We do NOT need a cld after the BIOS call * because we always save and restore the flags. */ __asm__ __volatile__(APM_DO_ZERO_SEGS "pushl %%edi\n\t" "pushl %%ebp\n\t" "lcall %%cs:" SYMBOL_NAME_STR(apm_bios_entry) "\n\t" "setc %%bl\n\t" "popl %%ebp\n\t" "popl %%edi\n\t" APM_DO_POP_SEGS : "=a" (*eax), "=b" (error), "=c" (cx), "=d" (dx), "=S" (si) : "a" (func), "b" (ebx_in), "c" (ecx_in) : "memory", "cc"); } APM_DO_RESTORE_SEGS; __restore_flags(flags); return error; } dat is unsere funktion. ein direkter bios aufruf. wird von der subroutine suspend, indirekt aufgerufen (ueber umwege..) die funktion gibt ungleich 1 zurueck,weswegen die aufrufende funktion den errorcode kernel: apm: suspend: unable to enter requested state zurueckgiebt. also genau das was wir (nicht) haben wollen! hier die aufruf argumente mit zurueckverfolgten Werten: func = APM_FUNC_STATE (code = 0x5307) ebx_in = APM_DEVICE_ALL (code = 0x0001) ecx_in = APM_STATE_SUSPEND (code 0x0002) eax ist hier eine referenz, wird nachher als fehlercode gebraucht. jetzt meine frage:, bzw. philosophie ins blaue (ich hab im moment echt wenig zeit, wie alle 8) ) wo kann ich denn nachschauen was obige bios aufrufe so anstellen. offensichtlich ist die kommunikation fuer unseren fall gestoert. ich glaube, das der suspend state, hier an das bios uebergeben wird. da das bios damit nix anfangen kann (es gibt keine wirklichen schalter/variablen im bios dafuer !?!?!?), gibts nur -1 oder null zurueck. also kaese. vielleicht sollte man in das bios einen schalter fuer suspend einbauen ??? (kleiner scherz) jetzt mal im ernst: grund zu der annahme: soviel ich bemerke, wird die swap (oder was auch immer, vielleicht ja auch die hibernation partition ???) aktiv, bei dem user suspend request. der flush von oben, klappt also. was meinst du, sollte man mal versuchen dem kernel zu erzaehlen der error waer eins ??, also die bios kommunikation, nach erfolgreichem flush, umgehen ?? moeglicherweise erwartet das bios auch andere nummern (zum beispiel hab ich da APM_DEVICE_ALL (also die 0x0001) in verdacht. vielleicht ists ja auch 0x0100 ?? ich versuch mal rauszukriegen, wie man an bios paramter rankommt.
hast du auch ein omnibook xe3 F233x, oder neuer ??
AFAIK gibt es in dieser Modellreihe nichts neueres. Wir haben das Ding erst vor einer Woche bestellt.
ich hab das ding, bzw. die schublade auch in verdacht recht unstabil zu sein...hoffentlich passiert da nix...haenge grad in
HP hat Gott sei Dank einen schnellen Support...
der endphase meiner diplomarbeit....
Cool. Über was schreibst du denn?
ooch, das wird was ueber Berechnung von Jacibimatrizen (Abhaengigkeit einer Abbildung von den Parametern... erste Ableitung fuer jeden einzelenen Paramter) fuer dreidimensionale Inversion von Daten. Ich werd mal Geophysiker, und wir messen elektromagnetische Felder ueber Geologisch interessanten gebieten (zb vulkane oder altlast deponien, wassersuche in der wueste, erdoel/gas usw.). speisen dazu einen wohl defnierten strom (zumindest theoretisch ) via dipol in den boden, und setzten uns in einigen kilometern entfernung hin. messen das zeitliche verhalten der felder (ueber spulen oder dipole) in bestimmten abstand zu der quelle. das zeitliche verhalten ist durch die rauemliche verteilung der leitfaehigen schichten im boden beeinflusst. und ich schrieb das gehirn-programm, fuer die inversion dreidimensionaler leitfaehigeiten, fuer eine betimmte methode die sich besonders fuer grosse tiefen eignet. aber im grunde gings mir nur um das programmieren dieser jacobimatrix. kann man uebrigens auch fuer robotersteuerungen oder was weis ich neuronale netzwerke benutzen. die matrix sagt ja genau, wie stark ein parameter (roboter: druckaenderung in einem bestimmten hydraulischen gelenk z.b., oder neuronales netzwerk: was passiert wenn ich dorthin gehe...) das ergebnis meines modells beeinflusst. oh, sorry fuer den riesentext. ich wollt dir kein ohr abkauen, dich aber auch nicht mit zwei drei worten abspeisen...
Ich dachte, dass SuSE da vielleicht was kaputt-gepatcht hat. Ich habe diverse Anleitungen gefunden, die auf Red Hat basieren. Da scheint dieses Problem nicht aufzutreten.
ja genau, hab ich auch gelesen. bei manchen stand aber auch suse als distri drin... naja, vielleicht haben die gedacht alle "neuen" versionen waeren gleich, oder so. ich werds auf alle faelle bald versuchen.
----und ab hier macht dann der apmd_proxy seine arbeit und startet sachen wie pcmcia oder soundkartentreiber... und deswegen habe ich auch den kernel in verdacht... von der shell aus gibt mir ein $apm -s apm: Input/output error und den gleichen fehlercode in messages.
koennte man versuchen den kernel hack paramter einzuschalten, bzw gibt der brauchbares aus ??
SysReq nützt dir nur bei einem Kernel oops was.
hmmm, ja.
aha, also nur wenn er abstuerzt? kann man dann auf der console 10 was sehen ?
Man hat, wenn man SysReq Support im Kernel hat, mit bestimmten Tastenkombioationen (ALT + PRINTSCREEN + <TASTE>) werschiedene Möglichkeiten, wenn das System hängt, Informationen rauszuholen (core dump to disk, umleiten auf einen Drucker...) Wenn es dich genau intressiert, lies Doicumentation/sysrq.txt im Kernel tree.
vielleicht koennte man einen Patch, wie's den ja auch fuer Thinkpads gibt, bauen ? auch wenn ich dahingehend keine erfahrung habe, traue ich mir sowas zu (mit huelfae selbstverstehend) ein wenig c code kann ich naemlich lesen... aber man muesste wissen, wie man solche sachen vernuenftig traced...
Man kann z.B. zum Debuggen einige printk() Aufrufe an interessanten Stellen im APM Code einfügen.
wo/wie? printk wie printf fprintf??
kompilieren, und dann mit nem
Das mache ich erst, wenns mit 2.4.9 nicht geht...
geht nich. mach ma 8) aber ich glaub wir finden da eine loesung. bin nur etwas vorsichtig. ist ja immerhin das erste mal das ich direkt den kernle editieren will. und ich hab ehrlich mortsmaessigen respekt vor dem altehrwuerdigen ..
debugger starten. geht sowas mit nem kernel auch ?
Es gibt einen Kernel Debugger.
hmmm....
Da ich im Moment leider gut im Stress bin, habe ich meinen Kollegen gebeten, eine Mail aufzusetzen. Ich werde ihn fragen, ob schon was zurückgekommen ist.
btw. was stellt ihr denn eigentlich her ?? treiber entwickeln ??
der bruze scheint ein echt netter kerl zu sein, wirkte aber mehr so geschaeftsmann maessig, und nicht "wirklich" open-source 8)
Mein Kollege hat die Mail gestern Abend abgeschickt. Mal sehen. Wenn er Geschäftsmann ist, dann weiß er ja, dass er mehr Omnibooks verkaufen kann, wenn die Linux Unterstützung komplett ist...
hoffentlich, das erpart uns wahrscheinlich viele zusaetzliche graue haare.... 8) bis dann. Roland