acpi0: <FSC PC> on motherboard

J

JasMich.de

New Member
Hallo zusammen,
ich habe gerade FreeBSD 12 auf meinem PC installiert, wenn ich nun normal (!=save mode) boote, bekomme ich die Meldung "acpi0: <FSC PC> on motherboard" und der Start unterbricht, wobei im save mode alles normal klappt. Im Anhang ist noch ein Bild vom Ganzen.
Ich habe es auch schon mit FreeBSD 11 oder 9 probiert, aber es gibt das selbe Problem.

Könnt ihr mir helfen?

Danke schon im Voraus,
JasMich.de
 

Anhänge

  • rsz_fehlermeldung-min.jpg
    rsz_fehlermeldung-min.jpg
    276,5 KB · Aufrufe: 354
ok, ich will mal mit belanglosen Allgemeinplätzen anfangen.

Für mich sieht es so aus, als wenn das ACPI deines Mainboards/BIOS nicht mit FreeBSD kompatibel ist.
Dies vorausgesetzt stellt sich die Frage, ob du davon etwas im BIOS ändern/setzen und ob du vielleicht das BIOS generell erneuern kannst, also vielleicht auf die aktuellste Version bringen.
Wenn das nicht geht, kann man evtl acpi für FreeBSD abschalten, wenn man das möchte.
In dem Fall frage ich mich aber, ob oder wie andere Systeme mit dem PC klarkommen, etwa ein GNU/Linux, von denen es ja zahlreiche Live-Versionen zum einfachen testen gibt. Wenn das problemlos geht, würde ich eher ein Freies System aus dem Lager wählen. Aber das ist mein persönlicher Gedanke.

Zusätzlich und nicht direkt zum Problem: ich finde die 12er FreeBSD noch nicht interessant für normale Nutzer, wenn es keinen besonderen Grund für diese gibt. Sie ist noch nicht fertig entwickelt. Im Bild siehst du auch oben den Hinweis, dass ein spezieller Beobachtungsmodus aktiviert ist, der helfen soll, noch vorhandene Fehler besser aufspüren zu können. Das macht man als normaler Nutzer ja lieber nicht.
 
Hallo, GNU/Linux, GNU/Hurd, macOS (inoffiziell) und Windows laufen super auf dem Rechner. Wie deaktiviert man den in dem installierten FreeBSD das ACPI?
 
JasMich.de schrieb:
Wie deaktiviert man den in dem installierten FreeBSD das ACPI?
Zum Vergrößern anklicken....
Zu all solchen Fragen hilft dir das Handbuch oft schon einen Schritt weiter. Diesmal diese Seite:
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/bsdinstall-install-trouble.html

generell ist es nicht verkehrt, sich die defaults anzusehen, in diesem Fall:
/boot/defaults/loader.conf
Oft kann man da auch Hinweise für ein weiteres Vorgehen ableiten.

Dass andere Systeme klaglos auf dem Rechner laufen, ist sehr vorteilhaft. Es bedeutet aber nicht, dass FreeBSD Fehler im BIOS ebenso toleriert. FreeBSD ist hier recht konservativ und benutzt keine Hacks, um unbedingt auf jeder HW laufen zu können, wie das oft bei anderen Systemen oder Distributionen gemacht wird. Manchmal braucht eine HW auch bestimmte Treiber und die gibt es mitunter nicht für FreeBSD, was daran liegen kann, dass sich niemand findet, der diese Treiber schreibt. Manchmal hat FreeBSD aber gar nicht die Mechanismen, um bestimmte Treiber anderer Systeme direkt einzubinden.
Eine mögliche Abhilfe bei BIOS-Problemen mit FreeBSD ist daher ein Update des BIOS auf den neuesten Stand.

Wir reden hier aber ziemlich Glaskugel und auf Grund meiner eigenen Deutung des eingestellten Fotos. Mehr Info könnte nicht schaden.
 
JasMich.de schrieb:
wenn ich nun normal (!=save mode) boote, bekomme ich die Meldung "acpi0: <FSC PC> on motherboard" und der Start unterbricht, wobei im save mode alles normal klappt.
Zum Vergrößern anklicken....
EIn Bios-Problem kann es damit ja schon mal nicht sein.

Wenn der Single-User-Modus klappt, dann boote mal den und wechsle dann in den Multi-User-Modus (STRG+D oder exit<ENTER>), was passiert dann?

Rob
 
KobRheTilla schrieb:
Wie kommst du darauf? Der Kernel meckert doch gar nicht über ACPI, sondern erkennt es.

Rob
Zum Vergrößern anklicken....

aber dabei steht er auch und macht nicht weiter. Erkennen alleine genügt doch nicht. Deshalb meine Vermutung, dass es ein Problem mit ACPI gibt, worüber ja auch immer wieder berichtet wird.
Bei mir etwa sieht das so aus:
Code: 
dmesg | grep acpi
acpi0: <INTEL DG965CO> on motherboard
acpi0: Power Button (fixed)
cpu0: <ACPI CPU> on acpi0
cpu1: <ACPI CPU> on acpi0
atrtc0: <AT realtime clock> port 0x70-0x71,0x74-0x77 irq 8 on acpi0
attimer0: <AT timer> port 0x40-0x43,0x50-0x53 irq 0 on acpi0
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
acpi_button0: <Sleep Button> on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
 
JasMich.de schrieb:
Also im loader habe ich das acpi disabled; trotzdem bleibt er an der selben Stelle hängen.
Zum Vergrößern anklicken....

nach dem Hinweis von KobRheTilla habe ich denn auch mal nachgedacht und musste mir eingestehen, dass "save mode" != "ohne ACPI" ist. Das hatte ich einfach irgendwie vorausgesetzt oder etwas verwechselt. Gibt es beide Optionen beim Bootmenü?
Egal.
Lies mal hier für "save mode":
https://forums.freebsd.org/threads/56524/
Das ist viel vernünftiger.

edit. PS: wie ich eben sehe, heißt das Ding "safe mode". ;)
 
Der Kernel gibt eine Statuszeile aus, wenn das jeweilige Modul erfolgreich geladen wurden. Also wenn er sagt, dass ACPI geladen ist, ist er über ACPI hinweg und hängt beim nächsten Modul. Ich würde im erste Schritt einmal einen Verbose Boot machen (kann man im Menü auswählen oder am Loader-Prompt 'boot -v') und schauen, ob man daraus erkennen kann, wo er hängen bleibt.
 
Yamagi schrieb:
Also wenn er sagt, dass ACPI geladen ist, ist er über ACPI hinweg und hängt beim nächsten Modul.
Zum Vergrößern anklicken....

das ist bei mir eben wieder etwas mit ACPI. Man weiß ja nie, was bei anderen Rechnern und anderen Betriebssystem-Versionen tatsächlich in welcher Reihenfolge dran ist. Ich habe eben nur mein eigenes System, das funktioniert, als Referenz.
Das war oben aber tatsächlich so nicht ersichtlich, also nochmal die folgenden Zeilen als Ausschnitt aus dmesg, sie erscheinen so direkt nacheinander:
Code: 
acpi0: <INTEL DG965CO> on motherboard
acpi0: Power Button (fixed)
cpu0: <ACPI CPU> on acpi0
cpu1: <ACPI CPU> on acpi0
Das ist auch das erste Auftreten von ACPI in dmesg. Ich deute das so, dass ein ACPI erkannt wird und dann womöglich auch das entsprechende Modul geladen ist, dann müssten aber einige Zuordnungen und Aktionen als nächstes erfolgen und das scheint nicht statt zu finden. Deshalb meine Vermutung mit inkompatiblem ACPI.
 
Also, um das Problem einzugrenzen: folgende Optionen werden im "safe mode" (den ich mit single-user mode verwechselte) gesetzt:

Code: 
kern.smp.disabled=1
hw.ata.ata_dma=0
hw.ata.atapi_dma=0
hw.ata.wc=0
hw.eisa_slots=0
kern.eventtimer.periodic=1
kern.geom.part.check_integrity=0

siehe /boot/menu-commands.4th

Ich würde diese in der /boot/loader.conf übernehmen und so lange jeweils neu booten und einen Eintrag entfernen, bis die relevanten Einträge übergeblieben sind.

Rob
 
Da er recht früh im stirbt, würde ich darauf wetten, dass es einer von diesen drei ist:
  • 'kern.smp.disabled=1': Der Kernel bleibt hängen, sobald er die zweite CPU initialisieren will. Das wäre dann ein böse kaputtes BIOS.
  • 'kern.eventtimer.periodic=1': Eventtimer feuern nie, dadurch bleibt der Kernel hängen.
  • 'hw.eisa_slots=0': EISA ist seit mindestens 25 Jahren tot (und in 12.0 entfernt), aber wenn das BIOS es noch anbietet, kann es Nebenwirkungen haben.
Die Eventtimer sind halb so schlimm, heißt halt zwischen 1,5 und 2W Mehrverbrauch, aber das bringt niemanden im. SMP wäre echt kacke, weil man dann auf eine CPU begrenzt ist. Damit könnte man es wohl vergessen.
 
  • Like
Reaktionen: lme
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben