micro-atx fuer athlon mit vcore einstellbar

Vielen Dank erstmal für die Infos!!!
Evtl. melde ich mich nochmal wegen der Kernelconfig, wenn es soweit ist und ich nicht weiterkomme ...
Habe gerade mein Board abgeholt, aber ohne Netzteil, Laufwerk etc. von Hewlett kann ich noch nicht viel machen
Gruß
Bernd

wie schaut es aus, neue Erkenntnisse was die ATX Boards betrifft, das Gehäuse ist ja schon angekündigt zur Auslieferung...

werde wohl doch auf ein Sockel 754 MoBo zurückgreifen, damit es unter Linux ordentlich rennt...habe keine Zeit lange daran rum zu basteln.

Hi,

Ich hatte die letzten Tage wenig Zeit um weiter zu machen
--> im Moment gibts keine neueren Erkenntnisse, d.h. im Prinzip gehts,
aber man muß schon etwas basteln.

linuxdep: im Moment würde ich definitiv zu einem anderen MoBo raten.

Gruß,
Günter

Hallo,
wollte mal einen Status-Report zu meinem MSI RS480M2 mit Athlon 64 3000+ und ein paar Fragen loswerden:

Ich habe das Board nun unter Debian mit Kernel 2.6.11 laufen.
Wichtig ist erstmal nur, dass man den APIC im BIOS deaktiviert.

Bin größtenteils nach Thorstens Installationsanleitung (Debian-vdr-howto) vorgegangen, habe dabei aber kernel-image-2.6.11-9-amd-64-k8 und kernel-source-2.6.11 verwendet.
Dabei sind schon die ersten Ungereimtheiten aufgetaucht: In der config-2.6.11-9-amd64-k8, die beim kernel-image dabei war, gibt es Parameter (z.B. gleich der erste: "CONFIG_X86_64=y"), die durch ein "make menuconfig" einfach verschwinden, weil wohl unbekannt. Sollte mit der config-2.6.11-9-amd64-k8 als .config für kernel-source-2.6.11 nicht genau der Kernel aus kernel-image-2.6.11-9-amd-64-k8 herauskommen? Scheint wohl nicht so zu sein, aber das nehme ich mal so hin.

Zu den einzelnen Features und Problemen:
- Reboot funktioniert
Habe einige Tage damit verbracht, den Reboot hinzubekommen. Dieser wollte unter 2.6.11 einfach nicht funktionieren. Nach dem Herunterfahren drehten die Lüfter voll auf und der Bildschirm blieb schwarz, Abhilfe schaffte nur noch der Netzschalter. gjung hat mir freundlicherweise seine kernel-config zum gentoo2.6.11r4 zur Verfügung gestellt (danke nochmal!), das hat mir aber unglücklicher- und seltsamerweise nicht weitergeholfen. Mit der .config zum 2.4er-Kernel funktionierte es dann aber. So konnte ich das Problem letztendlich einkreisen: Die Option "OHCI HCD support" (CONFIG_USB_OHCI_HCD) musste ich deaktivieren bzw. als Modul kompilieren und vor dem Rebooten mit "rmmod ohci_hcd" entfernen. Irgendwie seltsam. Wenn ich das richtig verstanden habe, benötige ich OHCI aber für USB 1.1, also für den Powermate? Hatte bisher noch kein USB-Gerät angeschlossen, mal sehen ob das dann funktioniert ...

- Cool & Quiet funktioniert
Mein Athlon 64 3000+ hat "nur" 2 Performance States:
Max. P-State 1800 MHz 1.4V TDP 67 Watt
Min. P-State 1000 MHz 1.1V TDP 21 Watt
(Hätte mir noch 'ne Frequenz unter 1GHz gewünscht ...)
Das Rauf-/Runtertakten funktioniert automatisch, nachdem ich die entsprechenden Kernel-Optionen eingestellt habe und den "ondemand-governor" aktiviert habe.

- Hoch- und Runterfahren per Powerbutton und Fernbedienung über AVBoard (/etc/acpi/powerbtn.sh) funktionieren.

- WakeOnLan funktioniert ("ethtool -s eth0 wol g")

- Wakeup funktioniert wahrscheinlich
Habe mich erst etliche Stunden mit der mehr oder weniger erfolgreichen Konfiguration von nvram-wakeup rumgeschlagen (mit Verlust der BIOS-Einstellungen etc.), bis ich mir gedacht habe, dass ich ja auch mal acpi-wakeup über /proc/acpi/alarm probieren könnte. Nachdem ich immer gelesen hatte, dass das nur mit der Uhrzeit und nicht mit dem Datum funktioniert (siehe http://www.linux-magazin.de/Ar…004/08/wakeup/wakeup.html), hatte ich es lieber gleich mit nvram-wakeup versucht. Im Kernel-Source konnte ich aber nicht erkennen, dass das Datum deaktiviert ist, und anscheinend funktioniert es auch. Das muss ich aber noch genauer verifizieren.

- lm-sensors funktioniert (noch) nicht
Der Chip wird wohl nicht unterstützt. Hat das sonst jemand am Laufen oder wie kann ich noch an die Temperaturwerte vom Board kommen?

Vielleicht kann ja jemand soweit damit etwas anfangen. Würd' mich über weitere Tipps oder Bestätigungen freuen ...
Zur eigentlichen vdr-Installation bin noch gar nicht gekommen.

Es gibt übrigens 'ne neue BIOS-Version 3.4 und auch Linux-Treiber für den Radeon Xpress 200, bringt aber wahrscheinlich nichts, oder?

So, genug geschrieben. Gute Nacht!
Bernd

Zitat

Original von berndm

- Reboot funktioniert
Habe einige Tage damit verbracht, den Reboot hinzubekommen. Dieser wollte unter 2.6.11 einfach nicht funktionieren. Nach dem Herunterfahren drehten die Lüfter voll auf und der Bildschirm blieb schwarz, Abhilfe schaffte nur noch der Netzschalter. gjung hat mir freundlicherweise seine kernel-config zum gentoo2.6.11r4 zur Verfügung gestellt (danke nochmal!), das hat mir aber unglücklicher- und seltsamerweise nicht weitergeholfen. Mit der .config zum 2.4er-Kernel funktionierte es dann aber. So konnte ich das Problem letztendlich einkreisen: Die Option "OHCI HCD support" (CONFIG_USB_OHCI_HCD) musste ich deaktivieren bzw. als Modul kompilieren und vor dem Rebooten mit "rmmod ohci_hcd" entfernen. Irgendwie seltsam. Wenn ich das richtig verstanden habe, benötige ich OHCI aber für USB 1.1, also für den Powermate? Hatte bisher noch kein USB-Gerät angeschlossen, mal sehen ob das dann funktioniert ...

zwischenzeitlich habe ich neue Erkenntnisse bzgl reboot und USB.
Da ich beim Versuch den Powermate zum laufen zu bekommen auf
heftige Probleme mit USB gestoßen bin, habe ich mich nochmal in
den BIOS Einstellungen umgeschaut und bemerkt, daß sowohl
USB-Keyboad als auch USB-Mouse 'enabled' waren. Nachdem ich diese
'disabled' habe (werden ja nicht benötigt) waren nicht nur die
Probleme mit USB weg sondern auch die Probleme mit APIC
(dopelte Clocjkgeschw. und Netzwerk-Durchsatz) alsauch das
Reboot Problem, d.h. ich kann jetzt den APIC sowohl im BIOS
alsauch im Kernel enabled lassen und es gehen jetzt auch Kernel
Konfigurationen die vorher reproduzierbar nicht gingen.
Das Einzige was jetzt noch nicht ganz sauber ist, USB-1.1 und USB-2.0
Geräte am selben Steckerblock führen reproduzierbar zu Hängern im BIOS.

Es sieht also ganz so aus alsob das BIOS im Bereich USB noch einige
Bugs hat.
Aber ich bin jetzt soweit mit dem Board zufrieden. Das einizige was ich
jetzt noch zum laufen bringen muß ist WLAN.

Gruß,
Günter

Zitat

Da ich beim Versuch den Powermate zum laufen zu bekommen auf
heftige Probleme mit USB gestoßen bin, habe ich mich nochmal in
den BIOS Einstellungen umgeschaut und bemerkt, daß sowohl
USB-Keyboad als auch USB-Mouse 'enabled' waren. Nachdem ich diese
'disabled' habe (werden ja nicht benötigt) waren nicht nur die
Probleme mit USB weg sondern auch die Probleme mit APIC
(dopelte Clocjkgeschw. und Netzwerk-Durchsatz) alsauch das
Reboot Problem, d.h. ich kann jetzt den APIC sowohl im BIOS
alsauch im Kernel enabled lassen und es gehen jetzt auch Kernel
Konfigurationen die vorher reproduzierbar nicht gingen.

Alles anzeigen

USB-Keyboard u. -Mouse habe ich gleich zu Beginn zusammen mit APIC deaktiviert und nicht weiter beachtet. Trotzdem hatte ich besagte Reboot-Probleme. Welche BIOS-Version benutz du? Habe noch die 3.2, die dabei war.

Zitat

Das Einzige was jetzt noch nicht ganz sauber ist, USB-1.1 und USB-2.0
Geräte am selben Steckerblock führen reproduzierbar zu Hängern im BIOS.

Bei EHCD gibt es im Kernel noch eine Option mit "Translators" oder so, welches evtl. den "Companion OHCD-Controller" überflüssig machen soll. Vielleicht ist das noch eine Stelle zum Testen?
BTW: Wie hast du den Powermate angeschlossen? Intern über eine USB-Buchse eines gekauften USB-Slotblechs?

Zitat

Aber ich bin jetzt soweit mit dem Board zufrieden.

Jau, geht mir auch so.

Zitat

Das einizige was ich
jetzt noch zum laufen bringen muß ist WLAN.

Prima, das habe ich langfristig auch vor. Da weiß ich ja, wenn ich dann fragen muss ...

Wie sieht es bei dir mit ACPI-Wakeup und Temperatur-Sensoren aus?
Gruß
Bernd

Ach ja, was mir negativ aufgefallen ist:
Die 20 (zwanzig!!!!!) Sekunden Pause zwischen Memory-Check und IDE-Detection, in der absolut nichts Erkennbares passiert.

Zitat

USB-Keyboard u. -Mouse habe ich gleich zu Beginn zusammen mit APIC deaktiviert und nicht weiter beachtet. Trotzdem hatte ich besagte Reboot-Probleme. Welche BIOS-Version benutz du? Habe noch die 3.2, die dabei war.

Interresant, ich benutze auch noch die 3.2 und habe wie gesagt keine
reboot und ACPI Probleme mehr.

Zitat

Bei EHCD gibt es im Kernel noch eine Option mit "Translators" oder so, welches evtl. den "Companion OHCD-Controller" überflüssig machen soll. Vielleicht ist das noch eine Stelle zum Testen?

Da kann man sicher noch mal damit spielen, ich glaube aber nicht das
das die reboot Thematik grundsätzlich löst. Da muß wohl eher MSI
mit einem BIOS Update ran (-> wann auch immer das passieren wird)

Zitat

BTW: Wie hast du den Powermate angeschlossen? Intern über eine USB-Buchse eines gekauften USB-Slotblechs?

Derzeit noch extern, ich muß mir erst noch ein passendes Kabel für
den internen MB Stecker anfertigen.

Zitat

Wie sieht es bei dir mit ACPI-Wakeup und Temperatur-Sensoren aus?

ACPI Wakeup hatte ich nicht geplant. Kurzfristig NVRAM-Wakeup und
lanfristig ein Zusatzboard (AVR + i2c Clock).
Die Temparatursensoren hatte bisher noch gar nicht berücksichtigt,
aber Du hast recht das ist noch eine weitere Baustellen.

Gruß,
Günter

Tja was soll ich sagen, nachdem ich innerhalb einer halben Stunde WLAN
zum laufen gebracht habe, bin ich wegen der Reboot Probleme noch mal
ins BIOS um einerseits die Einstellungen mal aufzuschreiben damit ich sie
mit denen von Bernd vergleichen kann und habe dabei andererseits die
Quick-Boot Einstellung aktiviert. Nach dem "Save and Reset" ging nichts
mehr. Ich komme nicht mehr ins BIOS, Clear BIOS und alle anderen
Standard-Maßnahmen fruchten nichts. Es sieht fast so aus alsob die
Quick-Boot Einstellung das Board schlichtweg unbenutzbar gemacht hat.
Das wars dann also erstmal von meiner Seite.

Gruß,
Günter

Ups, hört sich gar nicht gut an.
Wenn du mit der "Quick-Boot Einstellung" den "Quick Power On Self Test" meinst, den habe ich schon länger auf enabled stehen, ohne Probleme.
Habe irgendwo gelesen, dass die beschriebenen Clear-CMOS-Prozeduren nicht richtig funktionieren, stattdessen solle man die Batterie für 2 Stunden rausnehmen ...
Viel Erfolg!
Bernd

edit: Den APIC konnte ich auch wieder aktivieren, ohne dass es Probleme mit dem Netzwerk gibt. Vor dem Reboot muss ich trotzdem ein "rmmod ohci_hcd" machen, wenn's funktionieren soll.

Zitat

Original von berndm
Habe irgendwo gelesen, dass die beschriebenen Clear-CMOS-Prozeduren nicht richtig funktionieren, stattdessen solle man die Batterie für 2 Stunden rausnehmen ...

Das werde ich doch mal probieren.

Hatte gestern um 23:15 noch eine Support-Anfrage an MSI (Deutschland!)
geschickt wegen meines Problems.
Um 23:30 hatte ich schon Antwort: ich solle den BIOS Chip zwengs neu
Flashen einschicken.
Heute morgen um 8:00 habe ich zurückgeschrieben daß ich mir nicht
vorstellen kann daß sich das BIOS selbst kaputschreibt.
Um 8:30 hatte ich Antwort: das wohl der Kollege in der Nacht etwas
schnell war und anscheinend doch das Board defekt sei, und ich es
an den Händler zurückschicken soll.
Auch wenn das nicht so direkt hilfreich war, es gibt auch Mainboard-Hersteller
die schnell auf Anfragen von Privatpersonen reagieren.

Gruß,
Günter

Ok, mein Board geht wieder!!
Das ziehen der CMOS Batterie für 4h wars, danke Bernd für den Tip.

Gruß,
Günter

Freut mich
Langsam müssten wir alle Probleme durchhaben ...
Bernd

Zitat

Original von berndm
Freut mich
Langsam müssten wir alle Probleme durchhaben ...
Bernd

abwarten.

Aber ich habe noch einen Tip bzgl. USB für dich. Ich bin mir nicht ganz
sicher ob diese BIOS Einstellung bei der 3.2 Version auch da ist, da ich
im Zuge meines kleinen Problems auch gleich mal auf 3.3 upgedatet habe.
Bei mir gibt es 2 USB Controller Einstellungen:
1. EHCI Controller
2. OnChip USB-Controller
EHCI habe ich enabled, OnChip USB habe ich disabled, der Kernel
erkennt das OHCI Device trotzdem. Mit dieser Einstellung sind meine
Probleme mit den gemischten 1.0 (Griffin) und 2.0 Geräten weg und
ich kann ohne irgentwelche Spezial-Maßnahmen reproduzierbar
rebooten.

Gruß,
Günter

zu früh gefreut. Nach einem Power-Off am Netzteil wird USB mit obiger
Einstellung nicht mehr initialisiert, und der Kernel erkennt gar kein USB
mehr. Das BIOS verhält sich also höchst interresant, wenn USB mal
enabled war, dann bleibt es das auch wenn ich im BIOS disabled einstelle,
egal ob reboot oder shutdown -> standby, erst wenn ich die Power
ganz wegnehme, dann wird der Chipsatz nach den dann gültigen
BIOS Einstellungen initialisiert. Das heist, es gibt keine saubere
Lösung für meine Problem mit der Kombi Griffin + Terratec USB DVB-T.
Denn wenn USB im BIOS enabled ist, dann hängt das BIOS beim USB-Scan
und lässt sich nur durch den Reset-Taster zum weitermachen überreden.

Eine Idee ist mir gerade noch eingefallen, ich schau mal was passiert
wenn ich den Boot via USB Device disable, vieleicht spart sich das
Bios dann ja den USB-Scan.

Gruß,
Günter

Zitat

Original von gjung
Bei mir gibt es 2 USB Controller Einstellungen:
1. EHCI Controller
2. OnChip USB-Controller

Gibt's im 3.2er BIOS auch und habe mich auch schon gefragt, was diese Einstellungen zu bedeuten haben (Ist der EHCI Controller kein OnChip USB-Controller?)

Zitat

Das heist, es gibt keine saubere
Lösung für meine Problem mit der Kombi Griffin + Terratec USB DVB-T

Hattest du das Problem nicht nur, wenn du beides an demselben Steckerblock betreibst?
Bin bisher noch gar nicht dazu gekommen, meinen PowerMate anzuschließen. Das wird dann aber vorerst wohl das einzige USB-Gerät bleiben.

Zitat

Eine Idee ist mir gerade noch eingefallen, ich schau mal was passiert
wenn ich den Boot via USB Device disable, vieleicht spart sich das
Bios dann ja den USB-Scan.

Hat es was gebracht? Habe das bei mir, glaube ich, auch sofort deaktiviert, so wie alles, was ich dem Anschein nach nicht brauchen werde ...
Gruß
Bernd

Zitat

habe mich auch schon gefragt, was diese Einstellungen zu bedeuten haben

die Reihenfolge der Einträge im BIOS ist falsch. OnChip USB enabled/disabled
USB komplett. EHCI enabled/disabled USB2.0 aber nur wenn OnChip enabled ist.

Zitat

Hattest du das Problem nicht nur, wenn du beides an demselben Steckerblock betreibst?

Das hat sich leider im laufe der Tests auch als zu frühe Freude herausgestellt.
Wie bei vielem anderem auch verhält sich das BIOS nicht immer ganz reproduzierbar.
Es ist in Wirklichkeit wohl so, daß jeglicher gemischt Betrieb zwischen USB1.x und
USB2.0 Geräten zu einem potentiellen Hänger führt. Vieleicht ist das aber auch ein
Powermate Problem, denn laut Protokoll ist Powermate ein USB1.0 Gerät. Leider
habe ich auf die schnelle kein USB1.1 Gerät für einen Gegentest zur Verfügung.

Zitat

Hat es was gebracht?

Leider nicht.

Ich hab jetzt halt mal eine weitere Supportanfrage an MSI gestellt mit der Frage
nach einer neuen BIOS Version, mal schauen was die antworten.

Ansonsten bin ich jetzt erst mal bis Do nächste Woche nicht verfügbar,
ich werde eine bischen Wandern in Südtirol.

Gruß,
Günter

Hallo gjung,
ich hoffe, du hattest eine angenehme vdr-freie Zeit!

Ich habe meinen PowerMate nun auch angeschlossen und dank der Hilfe von macfly auch zum Laufen bekommen (viel(!) Isolierband).
Seltsamerweise behebt der PowerMate mein Reboot-Problem
PowerMate angeschlossen: Reboot geht
PowerMate nicht angeschlossen: Hänger nach Runterfahren, es sei denn, ich mache vorher rmmod ohci_hcd.
Muss ich das verstehen?

Ach ja, BIOS Ver. 3.4 sollte man sich wohl besser nicht installieren, weil dort angeblich die Lüfter-/Temperatur-Anpassung rausgefallen ist. Gerade dieses Feature gefällt mir sehr gut. Versteh' einer die Leute bei MSI :gaga

Jetzt muss ich nur noch herausfinden, warum mein LCD so laaaaangsaaaaam ist ...

Gruß
Bernd

Zitat

Original von berndm
Hallo gjung,
ich hoffe, du hattest eine angenehme vdr-freie Zeit!

Danke, hatte ich

Zitat

Original von berndm
Seltsamerweise behebt der PowerMate mein Reboot-Problem
...
Muss ich das verstehen?

Mehr als seltsam, passt aber zu meinen Erfahrungen mit dem Mainboard.

Zitat

Original von berndm
Ach ja, BIOS Ver. 3.4 sollte man sich wohl besser nicht installieren, weil dort angeblich die Lüfter-/Temperatur-Anpassung rausgefallen ist. Gerade dieses Feature gefällt mir sehr gut. Versteh' einer die Leute bei MSI

Das mit der Lüfter-Anpassung stimmt, man kann die Lüfter Geschwindigkeit
nicht mehr frei wählen. Es sind, wie in anderen BIOSen auch, drei Geschw.
vorgegeben, und man kann nur noch die Temperatur wählen bei denen
diese Drehzahl eingestellt wird.
Aber, diese BIOS Version behebt mein Problem mit der gemischten USB1.0
und USB2.0 Bestückung. D.h. ich habe jetzt keinerlei Re-/Boot Probleme
mehr.
Das einzige was wohl nicht so ohne weiters geht ist der NVRAM Wakeup,
da gibt es Probleme mit der CMOS-Checksum. Ich bin aber nach den
ersten Versuchen zuversichtlich den ACPI Wakeup, incl. Tag-des-Monats,
hinzubekommen. Die Angaben im der FADT Tabelle vom BIOS bzgl.
Tag-des-Monats passen zwar nicht, aber da werde ich ganz frech den
ACPI Treiber hacken.

Gruß,
Günter

Hi!

Zitat

Original von gjung
Das mit der Lüfter-Anpassung stimmt, man kann die Lüfter Geschwindigkeit
nicht mehr frei wählen. Es sind, wie in anderen BIOSen auch, drei Geschw.
vorgegeben, und man kann nur noch die Temperatur wählen bei denen
diese Drehzahl eingestellt wird.
Aber, diese BIOS Version behebt mein Problem mit der gemischten USB1.0
und USB2.0 Bestückung. D.h. ich habe jetzt keinerlei Re-/Boot Probleme
mehr.

Alles anzeigen

Ah, interessant. MSI erwähnt als einzige Änderung in Ver. 3.4 die Unterstützung der Venice-Cores. Haben aber wohl nebenbei (fast) alles andere auch noch geändert ...
Ist es jetzt noch möglich, den Lüfter vollständig abzuschalten (Heraufsetzen der untersten Temperaturschranke)? In der jetzigen Version kann ich die Spannung ja auf 0 setzen, bei Runtertakten auf 1GHz scheint die passive Kühlung ja zu reichen (muss ich noch länger testen.)

Zitat

Das einzige was wohl nicht so ohne weiters geht ist der NVRAM Wakeup,
da gibt es Probleme mit der CMOS-Checksum. Ich bin aber nach den
ersten Versuchen zuversichtlich den ACPI Wakeup, incl. Tag-des-Monats,
hinzubekommen.

Das Problem mit nvram-wakeup hatte ich auch (s.o.).
Das Schreiben von addr_stat verhunzt das CMOS. Hatte mir schon eine Alternative überlegt und halbwegs getestet (addr_stat nicht schreiben, sondern nur die Zeitangaben und den Timer im BIOS immer auf enabled stehen lassen.) Habe es dann aber mit acpi-wakeup probiert und es scheint ohne Änderung zu funktionieren.

Zitat

Die Angaben im der FADT Tabelle vom BIOS bzgl.
Tag-des-Monats passen zwar nicht, aber da werde ich ganz frech den
ACPI Treiber hacken.

Hmm, bei mir hat er für die "Tag-des-Monats"-Adresse (acpi_gbl_FADT->day_alrm) die 13 (dezimal) ermittelt. Habe nur kurze Tests gemacht, aber scheint richtig zu sein!?
Habe da woanders auch kurz was zu geschrieben:
http://www.vdrportal.de/board/thread.php?threadid=34864&sid=

Gruß
Bernd

PS: Habe mal den TV-Ausgang getestet. Er scheint sich nur aktivieren zu lassen, wenn im BIOS "TV only" eingestellt ist, alle anderen Optionen funktionieren nicht, d.h. eine gleichzeitige Anzeige auf Monitor und TV ist nicht möglich. Weiß jemand, wie man den angezeigten Bereich anpassen kann? Bei mir werden die ersten Spalten der Konsole auf dem TV abgeschnitten.