Re: [suse-laptop] HP Omnibook Xe3

Am Montag, 27. August 2001 12:33 schrieb Roland Martin:
Am Montag, 27. August 2001 11:56 schrieben Sie:
Am Montag, 27. August 2001 09:50 schrieb Roland Martin:
Am Montag, 27. August 2001 01:11 schrieben Sie:
Am Sonntag, 26. August 2001 22:25 schrieb Roland Martin:
Hello.
Hi Roland,
Two important things:
1) I'm trying (still in vein) to run suspend to disk under my SuSE 7.2 but nothing happens, except a blank display for two seconds. i compiled several new kernels, but still nothing.
I got exactly the same problem. Started that thread two days ago already. I have also tried several kernels without success. What BIOS version do you have. Perhaps the BIOS is not 100% APM compilant. Just a thought...
Ich probier grade ACPI aus. gibts da schon etwas ?? die sondertasten werden scheinbar nur von apm efasst...
Das habe ich noch nicht probiert, aber die Linux ACPI-Implentierung ist sowieso noch nicht ganz komplett. Die Chanen, mit ACPI zum Ziel zu kommen, sind also IMHO recht gering...
ja. bei mir geht's auch nur ohne den ide support fuer 32 bit i/o
das ist ein Phoenix 4.0 BIOS Version 6.0... ???
Ja. Bei mir Revision GC.M1.63 Das soll laut HP Support seite auch die aktuelle Version sein.
hm....
ob das apm kompatibel ist wiess ich nicht, aber ein neues BIOS draufmachen ist nicht so mein ding...
Das wäre kein so größes Problem. Man braucht den Flash ja nur aus dem Netz zu ziehen und auf eine WinBlows 98 Boot Diskette kopieren. Aber wie gesagt gibt es scheinbar keine aktuellere Version.
woher kann ich erfahren ob dieses bios ein (anscheinend) apm problem hat ?
Da gbt es wohl nur eine Möglichkeit: Jemanden finden, bei dem Suspend unter Linux mit diesem BIOS läuft. Was besseres fällt mir leider auch nicht ein.
da gabs mal einen auf dieser liste, aber der hatte seine hibernation partition geloescht und schobs darauf. aber das ist ja quatsch (??) denn der erste suspend request geht erstmal in den suspen to ram mode, oder??
Nicht unbedingt. Bei anderen Laptops kann man im BIOS einstellen, ob beim Drücken der Suspend-Taste suspend-to-RAM oder suspend-to-disk erfolgen soll. Bei diesem BIOS kann man allerdings nicht sehr viel einstellen...
und aussrdem habe ich meine IBM Thinkpad hibernation partition auf /dev/hda1 noch.. daran kanns also (??) nicht liegen..zumal m$ suspend ja geht...
Ich habe alles platt gemacht, auf als erste Partition eine 3 GB Patition erstellt, Windows 2000 drauf installiert. Der Rest für Linux und dann unter Linux mit lphdisk die Suspend-Partition /dev/hda4 eingerichtet. Unter Windows 2000 funktioniert auch das. Es muss also an was anderem liegen...
aber apm waer mir schon wichtig...die howto's sagen mir da auch nix neues...ausser "bau dir einen neuen kernel..." hab ich nun schon nummer zwanzig, glaub ich .
Ich habe es mit einem selbstcompiliertem Kernel 2.4.7 mit SuSE Patches und mit dem unverändertem SuSE Standad-Kernel 2.4.4 probiert. Ich denke, es liegt nicht am Kernel.
geht denn das nun bei dir, oder nicht ??
Bis jetzt leider noch nicht.
sollte ich vielleicht ein aelteres bios nehmen??
Meinst du, dass die aktuelle BIOS-Version einen Bug eingebaut haben, der in der älteren nicht existiert?? Sein kann ja fast alles.... Ich wüßte allerdings nicht, wo man eine ältere BIOS-Version herbekäme, um das zu testen. Die aktuelle kann man von der HP Support Seite runterladen.
Das ist ein binäres Kernel Modul für Kernel 2.2.12 Es kann nur mit dem Kernel funktionieren, für den es compiliert wurde. Also keine Chance... Dachte mir scho, dass die den Quellcode nicht rausrücken. Aber wie gesagt: Ordentliche Spezifikationen, die es mir ermöglichen würden, einen entsprechenden Treiber zu schreiben, würden mich auch schon zufrieden stellen... Bisher leider nichts gefunden.
Vielleicht sollte man mal beim HP Support anfragen. Die sind eigentlich sehr Linux-freundlich.
habe ich, der fuer Linux zustaendige Bruce Perens sagte mir, er benutze ein pcmcia modem unter linux. aber er wuerde hart daran arbeiten, dass hp in zukunft linux freundlichere produkte auf den markt bringt..hilft mir im moment auch nicht viel...
zu finden unter http://www.wiu.edu/users/muslu/essfaq.html
ist eine nette seite von Andrew Wettstein. der hat aber auch keinen neueren treiber, und ess tech schiebt den alten raus....
Take it easy, we'll find a way. There is always a solution on Linux... :-)
normalerweise schon, aber das sieht sehr verkorkst aus.... vo allem weils halt unter m$ leuft aergert mich das immer noch am meissten...
Ja, so ist das, und so wird es auch noch eine Weile bleiben, bis Linux die nötige Verbreitung im Desktop-Bereich gefunden hat, die die Hersteller zwingt, entsprechende Treiber zu entwickeln oder wenigstens die Spezifikationen für ihre Hardware rauszurücken, damit wir uns selbst helfen können...
kann man nicht einen windows-reverse treiber schreiben ??
Abgesehen davon, das Reverse Engineering verboten ist, ist es sehr zeitaufwendig, da man sich mit Hilfe eines Debuggers durch seitenlangen Assembler-Code wühlen muss. Hast du schon mal den Assembler-Code eines schlecht programmierten Windows Treibers gesehen? Ich schon... Was meinst du, warum der NTFS Support von Linux so schlecht ist, obwohl es NT schon so lange gibt? Reverse Engineering ist ein Höllen-Job... HP müsste die Specs von dem Chip ja haben, sonst würden sie das Ding ja nicht verkaufen. Schick mir doch mal die eMail-Adresse von Bruce Perens. Vielleicht kann ich ja durch eine "offizielle" Mail über meine Firma was erreichen. Ich würde ihm anbieten, einen Treiber zu entwickeln und ihn unter der GPL zur Verfügung zu stellen, wenn er uns die Spezifikationen zur Verfügung stellen kann.
ich habe auch schon versucht in der include/linux/tty.h ein paar dinge fuer den alten treiber zu finden, aber no chance... das ist mir viel zu kompliziert.
Das wird nicht hinhauen. Die Treiber Struktur der 2.4er Kernel hat sich in wesentlichen Punkten verändert. Grundsätzlich kann man ein Modul sowieso nur für den Kernel verwenden, für den es compiliert wurde. Wenn es dich interessiert kann ich dir "Linux Device Drivers", 2nd edition von Allessandro Rubini empfehlen.
es gibt auch ein nettes howto, wie man den treiber in einen 2.2.17 (oder hoeher) einbaut. ich versuch das mal... wenns klappt schreib ich daruber eine mini-howto/faq oder sonstwas. aber apm macht mir am meisten sorgen... das will ich unbedingt ans laufen kriegen. sonst kann ich nicht ruhig schlafen 8)
Ein Freund von mir hat das gleiche Problem auf einem ThinkPad und sucht auch nach einer Lösung. Ich sag dir bescheid, wenn sich was findet.
Roland
Robert

Am Montag, 27. August 2001 14:09 schrieben Sie:
Am Montag, 27. August 2001 12:33 schrieb Roland Martin:
Am Montag, 27. August 2001 11:56 schrieben Sie:
Am Montag, 27. August 2001 09:50 schrieb Roland Martin:
Am Montag, 27. August 2001 01:11 schrieben Sie:
Am Sonntag, 26. August 2001 22:25 schrieb Roland Martin:
Hello.
Hi Roland,
Two important things:
1) I'm trying (still in vein) to run suspend to disk under my SuSE 7.2 but nothing happens, except a blank display for two seconds. i compiled several new kernels, but still nothing.
I got exactly the same problem. Started that thread two days ago already. I have also tried several kernels without success. What BIOS version do you have. Perhaps the BIOS is not 100% APM compilant. Just a thought...
Ich probier grade ACPI aus. gibts da schon etwas ?? die sondertasten werden scheinbar nur von apm efasst...
Das habe ich noch nicht probiert, aber die Linux ACPI-Implentierung ist sowieso noch nicht ganz komplett. Die Chanen, mit ACPI zum Ziel zu kommen, sind also IMHO recht gering...
ja. bei mir geht's auch nur ohne den ide support fuer 32 bit i/o
das ist ein Phoenix 4.0 BIOS Version 6.0... ???
Ja. Bei mir Revision GC.M1.63 Das soll laut HP Support seite auch die aktuelle Version sein.
hm....
ob das apm kompatibel ist wiess ich nicht, aber ein neues BIOS draufmachen ist nicht so mein ding...
Das wäre kein so größes Problem. Man braucht den Flash ja nur aus dem Netz zu ziehen und auf eine WinBlows 98 Boot Diskette kopieren. Aber wie gesagt gibt es scheinbar keine aktuellere Version.
woher kann ich erfahren ob dieses bios ein (anscheinend) apm problem hat ?
Da gbt es wohl nur eine Möglichkeit: Jemanden finden, bei dem Suspend unter Linux mit diesem BIOS läuft. Was besseres fällt mir leider auch nicht ein.
da gabs mal einen auf dieser liste, aber der hatte seine hibernation partition geloescht und schobs darauf. aber das ist ja quatsch (??) denn der erste suspend request geht erstmal in den suspen to ram mode, oder??
Nicht unbedingt. Bei anderen Laptops kann man im BIOS einstellen, ob beim Drücken der Suspend-Taste suspend-to-RAM oder suspend-to-disk erfolgen soll. Bei diesem BIOS kann man allerdings nicht sehr viel einstellen...
und aussrdem habe ich meine IBM Thinkpad hibernation partition auf /dev/hda1 noch.. daran kanns also (??) nicht liegen..zumal m$ suspend ja geht...
Ich habe alles platt gemacht, auf als erste Partition eine 3 GB Patition erstellt, Windows 2000 drauf installiert. Der Rest für Linux und dann unter Linux mit lphdisk die Suspend-Partition /dev/hda4 eingerichtet.
Unter Windows 2000 funktioniert auch das. Es muss also an was anderem liegen...
aber apm waer mir schon wichtig...die howto's sagen mir da auch nix neues...ausser "bau dir einen neuen kernel..." hab ich nun schon nummer zwanzig, glaub ich .
Ich habe es mit einem selbstcompiliertem Kernel 2.4.7 mit SuSE Patches und mit dem unverändertem SuSE Standad-Kernel 2.4.4 probiert.
hast du schon 2.2.x versucht ?? da konnte man, wenn ich mich recht erinner, noch einige andere apm switches benutzen.. die howto's reden auch meisstens vom 2.2.x kernel...
Ich denke, es liegt nicht am Kernel.
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. man kann doch auch die bios parameteruebergabe rauswerfen... hab ich naemlich auch schon versucht... aber nix da. und alle moeglichen hdparm switches ... die bringens auch nich. dann hab ich noch einen ganz nackten kernel gebaut, nur das mindeste reingestopft (ext fs support und nur "80 zeichen "modus) und alle module raus... wieder nix
geht denn das nun bei dir, oder nicht ??
Bis jetzt leider noch nicht.
sollte ich vielleicht ein aelteres bios nehmen??
Meinst du, dass die aktuelle BIOS-Version einen Bug eingebaut haben, der in der älteren nicht existiert?? Sein kann ja fast alles.... Ich wüßte allerdings nicht, wo man eine ältere BIOS-Version herbekäme, um das zu testen. Die aktuelle kann man von der HP Support Seite runterladen.
Das ist ein binäres Kernel Modul für Kernel 2.2.12 Es kann nur mit dem Kernel funktionieren, für den es compiliert wurde. Also keine Chance... Dachte mir scho, dass die den Quellcode nicht rausrücken. Aber wie gesagt: Ordentliche Spezifikationen, die es mir ermöglichen würden, einen entsprechenden Treiber zu schreiben, würden mich auch schon zufrieden stellen... Bisher leider nichts gefunden.
Vielleicht sollte man mal beim HP Support anfragen. Die sind eigentlich sehr Linux-freundlich.
habe ich, der fuer Linux zustaendige Bruce Perens sagte mir, er benutze ein pcmcia modem unter linux. aber er wuerde hart daran arbeiten, dass hp in zukunft linux freundlichere produkte auf den markt bringt..hilft mir im moment auch nicht viel...
zu finden unter http://www.wiu.edu/users/muslu/essfaq.html
ist eine nette seite von Andrew Wettstein. der hat aber auch keinen neueren treiber, und ess tech schiebt den alten raus....
Take it easy, we'll find a way. There is always a solution on Linux... :-)
normalerweise schon, aber das sieht sehr verkorkst aus.... vo allem weils halt unter m$ leuft aergert mich das immer noch am meissten...
Ja, so ist das, und so wird es auch noch eine Weile bleiben, bis Linux die nötige Verbreitung im Desktop-Bereich gefunden hat, die die Hersteller zwingt, entsprechende Treiber zu entwickeln oder wenigstens die Spezifikationen für ihre Hardware rauszurücken, damit wir uns selbst helfen können...
kann man nicht einen windows-reverse treiber schreiben ??
Abgesehen davon, das Reverse Engineering verboten ist, ist es sehr zeitaufwendig, da man sich mit Hilfe eines Debuggers durch seitenlangen Assembler-Code wühlen muss. Hast du schon mal den Assembler-Code eines schlecht programmierten Windows Treibers gesehen? Ich schon...
8) kann ich mir leibhaft vorstellen...
Was meinst du, warum der NTFS Support von Linux so schlecht ist, obwohl es NT schon so lange gibt? Reverse Engineering ist ein Höllen-Job...
HP müsste die Specs von dem Chip ja haben, sonst würden sie das Ding ja nicht verkaufen.
also der bruze meint noe...
Schick mir doch mal die eMail-Adresse von Bruce Perens. Vielleicht kann ich ja durch eine "offizielle" Mail über meine Firma was erreichen. Ich würde ihm anbieten, einen Treiber zu entwickeln und ihn unter der GPL zur Verfügung zu stellen, wenn er uns die Spezifikationen zur Verfügung stellen kann.
ich habe auch schon versucht in der include/linux/tty.h ein paar dinge fuer den alten treiber zu finden, aber no chance... das ist mir viel zu kompliziert.
Das wird nicht hinhauen. Die Treiber Struktur der 2.4er Kernel hat sich in wesentlichen Punkten verändert. Grundsätzlich kann man ein Modul sowieso nur für den Kernel verwenden, für den es compiliert wurde. Wenn es dich interessiert kann ich dir "Linux Device Drivers", 2nd edition von Allessandro Rubini empfehlen.
es gibt auch ein nettes howto, wie man den treiber in einen 2.2.17 (oder hoeher) einbaut. ich versuch das mal... wenns klappt schreib ich daruber eine mini-howto/faq oder sonstwas. aber apm macht mir am meisten sorgen... das will ich unbedingt ans laufen kriegen. sonst kann ich nicht ruhig schlafen 8)
Ein Freund von mir hat das gleiche Problem auf einem ThinkPad und sucht auch nach einer Lösung. Ich sag dir bescheid, wenn sich was findet.
Roland
Robert
Roland

Am Dienstag, 28. August 2001 11:20 schrieb Robert Szentmihalyi:
Am Montag, 27. August 2001 16:20 schrieb Roland Martin:
Am Montag, 27. August 2001 14:09 schrieben Sie:
Am Montag, 27. August 2001 12:33 schrieb Roland Martin:
Am Montag, 27. August 2001 11:56 schrieben Sie:
Am Montag, 27. August 2001 09:50 schrieb Roland Martin:
Am Montag, 27. August 2001 01:11 schrieben Sie: > Am Sonntag, 26. August 2001 22:25 schrieb Roland
Martin: ------------
Ich habe es mit einem selbstcompiliertem Kernel 2.4.7 mit SuSE Patches und mit dem unverändertem SuSE Standad-Kernel 2.4.4 probiert.
hast du schon 2.2.x versucht ?? da konnte man, wenn ich mich recht erinner, noch einige andere apm switches benutzen.. die howto's reden auch meisstens vom 2.2.x kernel...
Nein, habe ich nicht.
Ich denke, es liegt nicht am Kernel.
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?
Aug 28 09:53:03 tuna apmd[124]: Event 0x0002: System Suspend Request Aug 28 09:53:03 tuna apmd_proxy: suspend system Aug 28 09:53:04 tuna apmd[124]: System Suspend Aug 28 11:54:10 tuna kernel: apm: suspend: Unable to enter requested state Aug 28 11:54:10 tuna kernel: PCI: Found IRQ 11 for device 00:10.0 Aug 28 11:54:10 tuna apmd[124]: Event 0x0003: Normal Resume System Aug 28 11:54:10 tuna apmd_proxy: resume suspend ----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 ?? 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... schoenen gruss ... Roland btw. was sagt Bruce Perens ?

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

hallo, ich fand die diskussion mit robert recht aufschlussreich, hat noch jemand was zu der letzten mail ?? ich steh naemlich echt auf'm schlauch... wie sieht das mit bios aufrufen denn so im allgemeinen aus ??? hat sowas mal wer getan ?? Roland
participants (2)
-
Robert Szentmihalyi
-
Roland Martin