Epox 8kta3+ pro - reboot anstatt ausschalten

geordy · 23. August 2004

Hallo!

Vielleicht kennt ja hier wer mein Problem und hat sogar eine lösung für mich!
Ich versuche schon seit ein paar Tagen das ganze zum laufen zu überreden, jedoch ohne großen Erfolg.

NVRAM guess-script hat mir eine konfigurationen erzeugt. Das einzige was funktioniert ist allerdings directisa. Die Zeit wird dabei richitg im BIOS gestzt. Was nicht funktioniert ist das aktivieren und deaktivieren des RTC-Alarms. Ist mir aber auch nicht so wichtig.

Wenn ich eine Zeit gesetzt habe und den Rechner herunterfahren will ('init 0' oder 'shutdown -h now' oder ...) fährt der Rechner herunter und startet sofort wieder neu. Ohne aktivierteer RTC-Alarm-Zeit funktioniert alles wie erwartet.

Funktioniert das schreiben in den nvram nicht richtig und es werden jedesmal Werte überschrieben die nicht überschrieben werden sollten? Oder läuft sonst villeicht was schief, oder geht es villeicht garnicht mit diesem Board?

Daten:
Board: Epox EP-8kta3+ Pro
NVRAM-Wakeup: 0.97
VDR: 1.3.12
Kernel: 2.6.5-7.104 (SuSE)

Ausgaben beim aufruf von NVRAM-Wakeup:

/dev/nvram:
vdr:~/guess-nvram-module # nvram-wakeup -C nvram-wakeup.conf -s 1093247547
nvram-wakeup: addr_stat (0xFF) is beyond the end of nvram
nvram-wakeup: You might want to use the --directisa command line option.

directisa:
vdr:~/guess-directisa # nvram-wakeup -C nvram-wakeup.conf -s 1093257547 --directisa

All values are displayed as they are stored in the nvram/rtc.
(and do not correspond necessarily to the system date/time)

WakeUp : Enabled (0xFF)
Day : 23 (0x17)
Hour : 11 (0x0B)
Minute : 20 (0x14)
Second : 26 (0x1A)
Checksum: 0x0CB7

Enabling (0xFF) WakeUp-on-RTC in nvram.
New Day : 23 (0x17)
New Hour : 12 (0x0C)
New Minute : 34 (0x22)
New Second : 07 (0x07)
New Checksum: 0x0CB3

Now really WRITING into /dev/nvram...

nvram-wakeup.conf:
################################################
## Mainboard autodetection information:
##
## - Mainboard vendor: ""
## - Mainboard type: "8363A-686B"
## - Mainboard revision: ""
## - BIOS vendor: "Award Software International, Inc."
## - BIOS version: "6.00 PG"
## - BIOS release: "02/05/2002"

addr_sec = 0x3F
addr_min = 0x40
addr_hour = 0x41
addr_day = 0x53
addr_chk_h = 0x6D
addr_chk_l = 0x6E

upper_method = VT82Cxxx

Wäre super wenn jemand eine Idee hätte!

geordy

Bistr-o-Math · 23. August 2004

poste doch noch mal die guess-error.log.

PS.: fuer's posten von logs eignet sich sehr gut der [ code] ... [/code] Befehl

Bistr-o-Math · 23. August 2004

Zitat

Original von geordy
Was nicht funktioniert ist das aktivieren und deaktivieren des RTC-Alarms.

versuch mal mit

Code

addr_stat   = 0x47
shift_stat  = 5

wenn du die guess-error-log postest, kann ich sagen, ob das mit dem stat dann so ichtig
ist. ich frage mich nur, warum guess das nicht erkannt hat...

wenn du erstmal eine richtige Konfiguration hast, koennen wir ueberlegen, was da schioefgeht

geordy · 23. August 2004

Danke für die schnelle Hilfe!
Ich werde den Tip ausprobieren sobald ich wieder direkt am Rechner sitze.

Hier die guess-error.log:

Code

$Id: guess.c,v 1.22 2004/03/04 08:38:14 bistr-o-math Exp $
Opened file 31.23.59.59+ readonly...
Opened file 11.12.13.14+ readonly...
Opened file 01.00.00.00+ readonly...
Opened file 01.00.00.00- readonly...
Assuming size of files 256 bytes
guess: Opening /dev/mem in O_RDONLY mode...
guess: _DMI_ table found: base: 0xF0800, size: 0x484, count: 44
guess: data block   1 at offset 0x000: type   0, size 0x013 ( 19)
guess: found string "Award Software International, Inc."
guess: found string "6.00 PG"
guess: found string "02/05/2002"
guess: data block   2 at offset 0x04A: type   1, size 0x019 ( 25)
guess: data block   3 at offset 0x086: type   2, size 0x008 (  8)
guess: found string ""
guess: found string "8363A-686B"
guess: found string ""
guess: data block   4 at offset 0x0A0: type   3, size 0x00D ( 13)
guess: data block   5 at offset 0x0B6: type   4, size 0x020 ( 32)
guess: data block   6 at offset 0x0F3: type   5, size 0x018 ( 24)
guess: data block   7 at offset 0x10E: type   6, size 0x00C ( 12)
guess: data block   8 at offset 0x122: type   6, size 0x00C ( 12)
guess: data block   9 at offset 0x136: type   6, size 0x00C ( 12)
guess: data block  10 at offset 0x14A: type   6, size 0x00C ( 12)
guess: data block  11 at offset 0x15E: type   7, size 0x013 ( 19)
guess: data block  12 at offset 0x181: type   7, size 0x013 ( 19)
guess: data block  13 at offset 0x1A4: type   8, size 0x009 (  9)
guess: data block  14 at offset 0x1BC: type   8, size 0x009 (  9)
guess: data block  15 at offset 0x1D6: type   8, size 0x009 (  9)
guess: data block  16 at offset 0x1E6: type   8, size 0x009 (  9)
guess: data block  17 at offset 0x1F7: type   8, size 0x009 (  9)
guess: data block  18 at offset 0x208: type   8, size 0x009 (  9)
guess: data block  19 at offset 0x219: type   8, size 0x009 (  9)
guess: data block  20 at offset 0x22E: type   8, size 0x009 (  9)
guess: data block  21 at offset 0x24F: type   9, size 0x00D ( 13)
guess: data block  22 at offset 0x261: type   9, size 0x00D ( 13)
guess: data block  23 at offset 0x273: type   9, size 0x00D ( 13)
guess: data block  24 at offset 0x285: type   9, size 0x00D ( 13)
guess: data block  25 at offset 0x297: type   9, size 0x00D ( 13)
guess: data block  26 at offset 0x2A9: type   9, size 0x00D ( 13)
guess: data block  27 at offset 0x2BB: type   9, size 0x00D ( 13)
guess: data block  28 at offset 0x2CD: type   9, size 0x00D ( 13)
guess: data block  29 at offset 0x2DF: type  10, size 0x008 (  8)
guess: data block  30 at offset 0x2EC: type   9, size 0x00D ( 13)
guess: data block  31 at offset 0x2FE: type   8, size 0x009 (  9)
guess: data block  32 at offset 0x30E: type  13, size 0x016 ( 22)
guess: data block  33 at offset 0x35F: type  16, size 0x00F ( 15)
guess: data block  34 at offset 0x371: type  17, size 0x015 ( 21)
guess: data block  35 at offset 0x396: type  17, size 0x015 ( 21)
guess: data block  36 at offset 0x3BB: type  17, size 0x015 ( 21)
guess: data block  37 at offset 0x3E0: type  17, size 0x015 ( 21)
guess: data block  38 at offset 0x405: type  19, size 0x00F ( 15)
guess: data block  39 at offset 0x417: type  20, size 0x013 ( 19)
guess: data block  40 at offset 0x42D: type  20, size 0x013 ( 19)
guess: data block  41 at offset 0x443: type  20, size 0x013 ( 19)
guess: data block  42 at offset 0x459: type  20, size 0x013 ( 19)
guess: data block  43 at offset 0x46F: type  32, size 0x00B ( 11)
guess: data block  44 at offset 0x47D: type 127, size 0x004 (  4)
guess: Following DMI entries found:
guess:  - Mainboard vendor:   ""
guess:  - Mainboard type:     "8363A-686B"
guess:  - Mainboard revision: ""
guess:  - BIOS vendor:        "Award Software International, Inc."
guess:  - BIOS version:       "6.00 PG"
guess:  - BIOS release:       "02/05/2002"
    checking 0x3F: 0x3B 0x0E 0x00 0x00
    checking 0x40: 0x3B 0x0D 0x00 0x00
    checking 0x41: 0x17 0x0C 0x00 0x00
    checking 0x53: 0x1F 0x0B 0x01 0x01
    checking 0x6D: 0x0D 0x0C 0x0C 0x0C
    checking 0x6E: 0x33 0xB9 0x88 0x88

Alles anzeigen

Bistr-o-Math · 23. August 2004

hattest du beim letzten reboot auch wirklich den wakeup ausgeschaltet?

wenn net oder wenn du dir nicht sicher bist, kannst du die Datei 01.00.00.00- aus beiden Verzeichnissen loeschen und nochmal probieren.

geordy · 23. August 2004

Hmmm ... also eigentlich bin ich mir sicher ... aber wie das so ist wenn nochmal nachgefragt wird ...

Ich werde die zwei Dateien löschen und den durchgang für 01.00.00.00- nochmal wiederholen. Mal sehen ob die conf dann anders ist.
Im Zweifelsfall mache ich alles auch komplett nochmal neu.

Nochmal Danke!

Bistr-o-Math · 23. August 2004

Zitat

Original von geordy
Hmmm ... also eigentlich bin ich mir sicher ...

bei manchen boards muss man ein feld verlassen, sonst wird es nicht gespeichert.
wenn du also ins Feld disable/enable gehst, dann "disabled" auswaehlst und dann Esc
(oder F10 oder was auch immer) drueckst, "vergisst" er deine Aenderung

geordy · 23. August 2004

Mir ist so ein Verhalten bei meinem Board bisher noch nicht aufgefallen, ich behalte es aber mal im Hinterkopf wenn ich es nachher nochmal probiere.

geordy · 23. August 2004

So, der erste Fehler ist ausgemerzt. Es scheint wirklich so zu sein, dass ich beim letzten durchgang vergessen habe im Bios RTC-Alarm zu disablen.

NVRAM-Wakeup funzt jetzt also wie es soll, zumindest mit /dev/nvram. Bei directisa macht die Konfiguration Probleme, ein paar Einträge sind da doppelt. Alle configs und loggings kann man sich hier ansehen.

Das Problem mit dem reboot besteht leider immer noch. Außerdem sieht es so aus, dass das BIOS einen reboot braucht um die Alarm-Einstellung wirklich zu übernehmen (dafür gibt es ja zum Glück schon eine Lösung). Nur leider startet der Rechner immer wieder neu anstatt sich abzuschalten sobald die Alarm-Zeit enabled ist zumindest bei all meinen bisherigen tests.

Gibt es dafür eine Lösung? Wie kann ich den ständigen reboot verhindern?

geordy · 23. August 2004

Ich hab's!

Einfach ACPI ausschalten und schon funktioniert alles wie gewünscht! Es ist nichtmal ein reboot nötig damit zur Alarm-Zeit automatisch gestartet wird.

Wie könnte es schöner sein? Wer braucht schon diesen neumodischen krimskrams wie ACPI?

Danke nochmal für die Tips und für's zuhören! Das hilft manchmal mehr als man glaubt.

geordy

PS: Vielleicht kommt die Konfiguration ja jetzt auch in die neue nvram Version und erspart damit anderen einigen Ärger und die Probleme. Ich teste auch gerne nochmal die directisa conf.

Bistr-o-Math · 24. August 2004

ja, die Konfiguration

http://geordy.homelinux.net/nv…-module/nvram-wakeup.conf

ist sicherlich richtig.

einen reboot brauchst du evtl. wenn du den Status aenderst.

TEST: wakeup auf "in 5 min" setzen, dann mittels nvram-wakeup ausschalten, runterfahren. Er wacht in 5 min trotzdem auf.

oder umgekehrt: wakeup abschalten, reboot, wakeup einschalten und auf "in 5 min" stellen, runterfahren, we wacht nicht auf.

geordy · 24. August 2004

So speziell wurden meine Tests gestern nicht. Hab mich nur erstmal riesig gefreut, dass es überhaupt funktioniert!

Ich werde es aber heute Abend mal ausprobieren und Bericht erstatten.

Wäre für mich aber nicht weiter tragisch, da ich den Status wohl nur extrem selten ändern werde.

kleini · 24. August 2004

Ich habe genau das gleiche Problem mit einem Enmic 8TTX+. Ein Reboot statt einem Shutdown tritt immer nach Zugriff auf NVRAM mit Kernel 2.6 und ACPI. Ohne NVRAM-Zugriff macht das Board einen einwandfreien Shutdown. Mit Kernel 2.4 und ACPI funktioniert der Shutdown auch noch nach einem Zugriff auf das NVRAM. Es scheint also irgendwie ein Fehler mit ACPI im BIOS von den Boards sein.

PS: Das Enmic 8TTX+ ist baugleich mit dem Epox 8KTA3+.

geordy · 24. August 2004

Ich denke auch , dass es am BIOS liegt, nur auf BIOS updates braucht man wohl auch nicht mehr hoffen. Das letzte Update ist schon ziemlich lange her.

Aber da ich ACPI nicht unbedingt brauche ist es mir nicht so wichtig.

Epox 8kta3+ pro - reboot anstatt ausschalten

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema