RSDT entry 3 is corrupt

K

Knittelfeld

Active Member
Hallo,

bekomme die Meldung "acpidump RSDT entry 3 is corrupt" waehrend des Bootens.

Wie kann ich das fixen?

Habe versucht mit acpidump mehr Informationen zu bekommen aber "no permissions".
Mit "sysctl kern.allowkmem >0" hat es auch nicht geklappt.
 
midnight schrieb:
Hier hatte auch jemand diese Meldung:


sendbug -P > somefile sollte als root laut der Mail auch die acpi tables speichern. Evtl. bekommst Du dann mehr Infos.
Zum Vergrößern anklicken....
Ja das hat auch soweit geklappt, der output enthaelt auch acpidump.
Jetzt ist das Problem das es nicht lesbar ist.

Code: 
acpidump:
begin-base64 644 RSDT.0
UlNEVEQAAAABFzEyMjIxMFJTRFQxNzQ3IhIQIE1TRlSXAAAAAAJ4v5ADeL9wBHi/QIB5v7D0eL/A
gHm/8PR4vxCeeb8=
====

Wenn ich das richtig verstehe ist es Base64 codiert deswegen hab ich es probiert zu decodieren
da bekomme ich das:

Code: 
m"ڱH4RSDTD���122210RSDT1747" MSFT����xxpx@yxyxy


acpixtract -a und iasl -d bringen mich auch nicht weiter ohne das richtige dump file.
 
Laut manpage: acpidump is run at startup and stores the results in /var/db/acpi. Um ehrlich zu sein habe ich auch keinen Plan, wie man damit was anfangen kann. Evtl. mal wie in der Mail beschrieben via senbug an die Entwicker schicken.
 
midnight schrieb:
Laut manpage: acpidump is run at startup and stores the results in /var/db/acpi. Um ehrlich zu sein habe ich auch keinen Plan, wie man damit was anfangen kann. Evtl. mal wie in der Mail beschrieben via senbug an die Entwicker schicken.
Zum Vergrößern anklicken....
Perfekt! Danke!
Damit konnte ich jetzt mit acpixtract -a und iasl -d eine Lesebare Datei erzeugen.

Nur das ich da null rauslesen kann was mir weiterhilft.
:confused:
Email hab ich schon geschreiben.

Code: 
/*
 * Intel ACPI Component Architecture
 * AML/ASL+ Disassembler version 20230628 (64-bit version)
 * Copyright (c) 2000 - 2023 Intel Corporation
 *
 * Disassembly of RSDT.0, Tue May 28 17:21:29 2024
 *
 * ACPI Data Table [RSDT]
 *
 * Format: [HexOffset DecimalOffset ByteLength]  FieldName : FieldValue (in hex)
 */

[000h 0000 004h]                   Signature : "RSDT"    [Root System Description Table]
[004h 0004 004h]                Table Length : 00000044
[008h 0008 001h]                    Revision : 01
[009h 0009 001h]                    Checksum : 17
[00Ah 0010 006h]                      Oem ID : "122210"
[010h 0016 008h]                Oem Table ID : "RSDT1747"
[018h 0024 004h]                Oem Revision : 20101222
[01Ch 0028 004h]             Asl Compiler ID : "MSFT"
[020h 0032 004h]       Asl Compiler Revision : 00000097

[024h 0036 004h]       ACPI Table Address   0 : BF780200
[028h 0040 004h]       ACPI Table Address   1 : BF780390
[02Ch 0044 004h]       ACPI Table Address   2 : BF780470
[030h 0048 004h]       ACPI Table Address   3 : BF798040
[034h 0052 004h]       ACPI Table Address   4 : BF78F4B0
[038h 0056 004h]       ACPI Table Address   5 : BF7980C0
[03Ch 0060 004h]       ACPI Table Address   6 : BF78F4F0
[040h 0064 004h]       ACPI Table Address   7 : BF799E10

Raw Table Data: Length 68 (0x44)

    0000: 52 53 44 54 44 00 00 00 01 17 31 32 32 32 31 30  // RSDTD.....122210
    0010: 52 53 44 54 31 37 34 37 22 12 10 20 4D 53 46 54  // RSDT1747".. MSFT
    0020: 97 00 00 00 00 02 78 BF 90 03 78 BF 70 04 78 BF  // ......x...x.p.x.
    0030: 40 80 79 BF B0 F4 78 BF C0 80 79 BF F0 F4 78 BF  // @.y...x...y...x.
    0040: 10 9E 79 BF                                      // ..y.
 
Ohne jetzt viel zu wissen würde ich sagen, dass man das ignorieren kann. Wenn relevant, dann eher nur für Windows. (MSFT=MicroSoftFormatTable?)
Oem Revision : 20101222 ist ziemlich sicher ein Datum und anfängliche UEFI-Versionen/BIOSse, gerade aus der Zeit waren verbuggt.

Es ist auch denkbar, dass einfach nur durch einen Zahlendreher die checksum nicht passt und es deswegen 'corrupt' ist, der relevante Wert aber trotzdem passt.
Vielleicht kommst du mit neuerer Firmware für das Board weiter, aber das sollte wirklich nicht kritisch sein.

Edit:
Falls Spieltrieb vorhanden, im BIOS mal die Bootmodi durchchecken, UEFI-only, UEFI-first oder sowas. Heißt manchmal auch signiertes Booten oder GPT-Boot, WIN8-Boot, irgendwas in der Richtung. Falls das aktiv ist, einfach mal das andere testen. Legacy-boot oder so, aber das will man mittlerweile generell nicht mehr, wenn das Auswirkungen auf Steckkarten oä. hat.
 
mr44er schrieb:
Ohne jetzt viel zu wissen würde ich sagen, dass man das ignorieren kann. Wenn relevant, dann eher nur für Windows. (MSFT=MicroSoftFormatTable?)
Oem Revision : 20101222 ist ziemlich sicher ein Datum und anfängliche UEFI-Versionen/BIOSse, gerade aus der Zeit waren verbuggt.

Es ist auch denkbar, dass einfach nur durch einen Zahlendreher die checksum nicht passt und es deswegen 'corrupt' ist, der relevante Wert aber trotzdem passt.
Vielleicht kommst du mit neuerer Firmware für das Board weiter, aber das sollte wirklich nicht kritisch sein.

Edit:
Falls Spieltrieb vorhanden, im BIOS mal die Bootmodi durchchecken, UEFI-only, UEFI-first oder sowas. Heißt manchmal auch signiertes Booten oder GPT-Boot, WIN8-Boot, irgendwas in der Richtung. Falls das aktiv ist, einfach mal das andere testen. Legacy-boot oder so, aber das will man mittlerweile generell nicht mehr, wenn das Auswirkungen auf Steckkarten oä. hat.
Zum Vergrößern anklicken....
hab im BIOS 2 Optionen "APCI 2.0 Support" und "APCI Support" standert Einstellung ist:
APCI 2.0 Support=Disabeld
APCI Support=Enabeld
Fehler: RSDT entry 3 is corrupt.

wenn ich
APCI 2.0 Support=Disabeld
APCI Support=Disabeld
bekomme ich den Fehler: XSDT entry 2 is corrupt.

wenn ich
APCI 2.0 Support=Enabeld
APCI Support=Enabeld
bekomme ich den Fehler: XSDT entry 3 is corrupt.

wenn ich
APCI 2.0 Support=Enabeld
APCI Support=Disabeld
bekomme ich den Fehler: XSDT entry 2 is corrupt.

Naja werd es jetzt erstmal ignorieren bis ich mal Zeit habe um da weiter zu Forschen.
 
Das sollte beides enabled sein, komplett ACPI abschalten ist keine gute Lösung. :)

Ich bin mir recht sicher, dass das irgendwas mit dem Boot zu tun hat, aber da die Kiste ja eh durchbootet kein Problem.
 
okay habe ACPI2.0 angeschaltet.

Temperaturen und Stromversorgung scheinen normal sein.

sysctl hw.sensors
Code: 
hw.sensors.cpu0.temp0=37.00 degC
hw.sensors.cpu0.frequency0=2350000000.00 Hz
hw.sensors.cpu1.frequency0=2600000000.00 Hz
hw.sensors.cpu2.frequency0=2600000000.00 Hz
hw.sensors.cpu3.frequency0=2400000000.00 Hz
hw.sensors.lm0.temp0=33.00 degC
hw.sensors.lm0.temp1=32.50 degC
hw.sensors.lm0.temp2=1.00 degC
hw.sensors.lm0.fan0=4821 RPM
hw.sensors.lm0.fan1=1171 RPM
hw.sensors.lm0.volt0=0.95 VDC (VCore)
hw.sensors.lm0.volt1=11.25 VDC (+12V)
hw.sensors.lm0.volt2=3.31 VDC (+3.3V)
hw.sensors.lm0.volt3=3.30 VDC (+3.3V)
hw.sensors.lm0.volt4=-6.86 VDC (-12V)
hw.sensors.lm0.volt5=2.04 VDC
hw.sensors.lm0.volt6=1.68 VDC
hw.sensors.lm0.volt7=3.39 VDC (3.3VSB)
hw.sensors.lm0.volt8=0.59 VDC (VBAT)
 
mr44er hat wohl recht gehabt damit das es ein Fehler der checksum ist.
Hab das hier gefunden:
https://github.com/chrissicool/l4openbsd/blob/master/usr.sbin/acpidump/acpidump.c

Code: 
474        if (acpi_checksum(sdp, sdp->len))
475                    errx(1, "RSDT entry %d is corrupt", i);

Falls jemand sich genauer damit beschaeftigen will hier noch ein Link zum Lesen, sind auch nur 1126 Seiten :):
https://uefi.org/sites/default/files/resources/ACPI_Spec_6_5_Aug29.pdf

oder auf Youtube:
https://www.youtube.com/@UEFIForum/featured


Das hat zwar mein "Problem" noch nicht geloest aber ich bleib drann. Wenn ich eine Loesung gefunden habe werde ich bescheid sagen.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben