BIOS Probleme (was Re: PCI Soundkarte wird von Alsa nicht mehr erkannt)
Jan Seiffert
kaffeemonster at googlemail.com
Mon May 28 20:57:54 CEST 2012
Stefan U. Hegner schrieb:
> Hey Jan,
>
[snip]
> ... so, dann arbeiten wir mal Deine gesammelten Punkte ab:
>
> Am 26.05.2012 02:56, schrieb Jan Seiffert:
>> Und überhaupt. Was hast du in der Kiste alles drin?
>> [ 0.000000] MTRR variable ranges enabled:
>> [ 0.000000] 0 base 000000000 mask F80000000 write-back
>> [ 0.000000] 1 base 080000000 mask FC0000000 write-back
>> [ 0.000000] 2 base 0C0000000 mask FF0000000 write-back
>> [ 0.000000] 3 base 0D0000000 mask FF8000000 write-back
>> [ 0.000000] 4 base 100000000 mask F00000000 write-back
>> [ 0.000000] 5 base 200000000 mask FE0000000 write-back
>> [ 0.000000] 6 base 220000000 mask FF8000000 write-back
>> [ 0.000000] 7 base 0D7F00000 mask FFFF00000 uncachable
>>
>> Gibts für die Hütte ein BIOS-Update? Sonst probier mal mtrr-cleanup, dann geht vielleicht
>> das:
>> [ 15.344778] mtrr: no more MTRRs available
>> beim Init deiner Graka weg...
>>
>> [ 0.673783] ehci_hcd 0000:00:1d.7: cache line size of 32 is not supported
>>
>> Really? BIOS-Update? Neuer Kernel?
>>
> Also, ich habe
>
> 1. BIOS Update durchgeführt
Gut.
> 2. die Option "Discrete MTRR Allocation" DISABLED - ohne zu verstehen
> was das macht. Der Hilfetext "MTRRs are discrete and not
> overlapped. Allows better graphics performance when used with
> Linux an 4GB or more memory" hatte mich bisher dazu bewogen das
> auf ENABLED zu setzen, denn ich habe 8GB RAM.
>
Nun, der Hilfetext ist ein wenig Bananne, oder die sprechen von Linuxen von
vor Anno-Tux (Debian?).
Hier wird es wieder etwas fuddelig.
Die MTRR sagen ja, wie welcher Speicherbereich wie gecached werden kann (also sehr
wichtig für Performance, deine modernen 3GHz CPUs laufen ohne Cache wie nen 386er).
Die Zahlen geben immer eine Basisadresse und eine "Länge" (in der Mask) an.
Unglücklicherweise gibt es da so ein paar Regeln, Empfelungen und Einschränkungen
was man da reinschreiben darf und soll.
Um z.B. den PCI bereich anders zu makieren als das RAM kann man das nun auf zwei
Arten machen:
Überlappend:
von addr 0x00000000 - 0xffffffff cached (Alles ist gecached...)
von addr 0xf0000000 - 0xffffffff uncached (... ausser der Bereich da "oben", wo PCI rumlungert)
oder diskret:
von addr 0x00000000 - 0xefffffff cached (von 0 bis 3GB is gecached ... )
von addr 0xf0000000 - 0xffffffff uncached ( ... von 3BG bis 4GB nicht)
Wenn jetzt z.B. im PCI bereich noch eine GraKa mit Speicher dazu kommt wirds ... lustig
Überlappend:
von addr 0x00000000 - 0xffffffff cached
von addr 0xf0000000 - 0xffffffff uncached
von addr 0xfe000000 - 0xfeefffff write-combining
diskret:
von addr 0x00000000 - 0xefffffff cached
von addr 0xf0000000 - 0xfdffffff uncached
von addr 0xfe000000 - 0xfeefffff write-combining
von addr 0xfef00000 - 0xffffffff uncached
Wie man sieht braucht diskret hier einen MTRR Eintrag mehr als überlappend, und es gibt
nur 7 insgesammt. Je komplexer die HW-Ausstattung, und die adressierung, wird, desto
ekeliger.
Ich sprach ja von Regeln/Empfelungen/Einschränkungen. Nun, die kommen hierbei nun zum
tragen, z.B. wie oft darf ein Bereich überlappend beschrieben werden? Manche CPUs haben
da Errata...
Auch kann nicht jeder Adressbereich immer sauber beschrieben werden mit der mask, das sorgt
für Verschnitt.
Und dann prügelt sich das ganze noch mit den PAT (Die gleichen Attribute, nur noch mal in den
Page-Tables, eine Erweiterung da eben die MTRR zu knapp/doof sind). Und da haben Einige
(Intel-)CPUs wirklich eklige Errata wenn MTRR und PAT nicht zusammen passen (darum hat die
Linux lange auch nicht implementiert).
Ich glaube darum sprechen die da von Linux, aus obskuren Gründen hat früher (das ist wirklich
lange her) Linux diskrete MTRR allokation als "gut" angesehen. Nicht weil es so toll ist
(es braucht mehr Register, zumindest in komplizierten setups), sondern weil es da mal irgendwo
mit irgendeinem BIOS und CPU und Chipset probleme gab.
Linux war "früher" aber auch auf gedeih under verderb auf das BIOS angewiesen. Ja, man kann
über den Userspace mit /proc/mtrr die ganze Tabelle neu schreiben, aber:
a) das will man nicht wirklich
b) wenn der Speicher in dem der Kernel liegt ungecached ist und deshalb der boot 2 std. dauert...
Mittlerweile gibt es einen mtrr-cleaner im Kernel, kann man von der Kernel-commandline anmachen.
Der erstellt eben alle Einträge neu, mit besseren Algorithmen als die meisten BIOSe, und man kann
ihm sagen, wieviele Register er zwingend frei lassen muss (z.B. 1 für die Graka, aber es gibt ja
auch anderes Advancetes Zeug, dicke RAID Controller mit Speicher, vielleicht gleich Vier davon in
der Kiste...). Dabei erstellt er dann eben MTRR Einträge "so gut es geht" (mehr verschnitt).
> Nun sagt mir dmesg:
>
> [ 0.000000] last_pfn = 0x228000 max_arch_pfn = 0x400000000
> [ 0.000000] MTRR default type: uncachable
> [ 0.000000] MTRR fixed ranges enabled:
> [ 0.000000] 00000-9FFFF write-back
> [ 0.000000] A0000-BFFFF uncachable
> [ 0.000000] C0000-C7FFF write-protect
> [ 0.000000] C8000-DFFFF uncachable
> [ 0.000000] E0000-FFFFF write-protect
> [ 0.000000] MTRR variable ranges enabled:
> [ 0.000000] 0 base 0D8000000 mask FF8000000 uncachable
> [ 0.000000] 1 base 0E0000000 mask FE0000000 uncachable
> [ 0.000000] 2 base 000000000 mask E00000000 write-back
> [ 0.000000] 3 base 200000000 mask FE0000000 write-back
> [ 0.000000] 4 base 220000000 mask FF8000000 write-back
> [ 0.000000] 5 base 0D7F00000 mask FFFF00000 uncachable
> [ 0.000000] 6 disabled
> [ 0.000000] 7 disabled
> [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new
> 0x7010600070106
> [ 0.000000] e820 update range: 00000000d7f00000 -
> 0000000100000000 (usable) ==> (reserved)
>
>
> ... ist das besser?
IMHO ja, sieht mir auch klarer aus was da wo liegt, jetzt sind 2 frei so das
die Graka und sonstwas noch einen findet, CPU und Kernel sollten damit
klarkommen.
> - Jedenfalls fallen diese drei
>
> [ 0.357447] pci 0000:00:1c.0: BAR 13: can't allocate resource
> [ 0.357447] pci 0000:00:1c.0: BAR 14: can't allocate resource
> [ 0.357447] pci 0000:00:1c.0: BAR 15: can't allocate resource
>
>
> Fehlermeldungen weg,
Das kommt wohl allgemein vom BIOS update, hat IMHO nix mit den MTRR zu tun.
> sowie der Mecker von der GraKa, dass keine MTRRs
> mehr verfügbar sind. Das muss also gut sein.
>
Eben. Du kannst, wenn er läuft, dir mal mit "cat /proc/mtrr" anschauen, wie es aussieht.
> Leider hat sich aber an dem EHCI Fehler noch nichts geändert:
>
> [ 0.687731] ehci_hcd 0000:00:1d.7: cache line size of 32 is not
> supported
>
Tja, solange USB2 geht und du ordentliche Übertragungsraten über USB2 hast.
C'est la vie...
>
>> Stefan U. Hegner schrieb:
>>
>>> Habe die Bootline mal geändert auf "pci=nocrs" aber leider ohne den
>>> gewünschten Erfolg. Die SB X-Fi wird in /proc/asound/cards und
>>> /proc/asound/modules nicht mehr angelistet.
>>>
>> Kein wunder, aus dem dmesg:
>> PCI: Unknown option `nocrs'
>>
> OK. - sollte ich statt "nocrs" mal was anderes probieren?
Nein, die Soundkarte geht ja jetzt.
Die Zeile sagt ja, das der Kernel die Option nicht kennt, um nocrs auszuprobieren
hätte es einen neueren Kernel gebraucht.
CRS ist wieder ein Teil von ACPI/BIOS-Kernel interaktion. Der Kernel kann PNP Geräte
(zumindest PCI-Geräte) ja durch umprogrammieren der sogennanten BARs an andere Stellen
im Speicher legen, wenn ihm die verteilung des BIOS nicht gefällt.
Dafür schaut er sich an was im Rechner ist (Bridges und Geräte) und wo Platz im Speicher
ist (die E820 Map, ganz am Anfang von dmesg). Leider gibt es da schon mal Probleme, weil
das BIOS nicht allen belegten Platz richtig in der E820 Map einträgt oder wegen sonstwas.
Plötzlich legt der Kernel die Graka in einen Speicherbereich, wo das BIOS beim Standby
eben rumschreibt -> BOOM.
Den BIOS-Pro-Gamern fällt das nicht auf, da Windows die Geräte in umgekehrter Reihenfolge
alloziiert als Linux.
Linux hat "früher" (vor CRS) _immer_ die Geräte neu verteilt, eben um einige BIOS-Bugs
auszugleichen. Ungünstig war, daß das einige Geräte "unbenutzbar" machte (oder meist
Standby/Hypernate).
CRS ist nun gedacht, dass das BIOS dem Kernel hints mitgibt, was wo wie besser liegt.
Aber nichts im BIOS ohne BUGs. Einige BIOSe haben total kaputte CRS-Einträge.
Darum hat Linux für eine lange Zeit CRS nicht implementiert (machte mehr Probleme als
das es löste). Neuere Kernel benutzen jetzt CRS.
Es gibt ein Cut-Off-Date (BIOS-Daten von BIOSen vor, ich glaube es war 2008, werden nicht
benutzt), und eben eine Option das auszumachen, nocrs.
Mit noacpi erreicht man das gleiche, es ist aber ein Holzhammer. Wenn man Probleme in diesem
Bereich hat (ein Gerät ist nicht mehr da/nicht ansprechbar), ist nocrs erstmal der
chirurgische Eingriff um das problem einzugrenzen/zu fixen.
So als Hinweis, falls du mit dem nächsten Debian mal einen neuen Kernel bekommst, oder
jemand anderes Kiste rum spinnt.
> - Allerdings
> ist meine Box schon etwas betagt (von Ende 2007 - nun mit BIOS vom
> 29.12.2010).
>
> Im aktuellen dmesg ist ACPI jedenfalls auch nicht so ganz glücklich:
>
> [ 11.456251] input: Power Button as
> /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/PNP0C0C:00/input/input3
> [ 11.456304] ACPI: Power Button [PWRB]
> [ 11.456351] input: Power Button as
> /devices/LNXSYSTM:00/LNXPWRBN:00/input/input4
> [ 11.456377] ACPI: Power Button [PWRF]
> [ 11.536373] ACPI: SSDT 00000000d7ee32c8 002A3 (v01 PmRef
> Cpu0Ist 00003000 INTL 20050228)
> [ 11.536501] ACPI Error (psargs-0359): [\_SB_.BCMD] Namespace
> lookup failure, AE_NOT_FOUND
> [ 11.536508] ACPI Error (psparse-0537): Method parse/execution
> failed [\_PR_.CPU0._OSC] (Node ffff8802270459e0), AE_NOT_FOUND
> [ 11.536531] ACPI Error (psparse-0537): Method parse/execution
> failed [\_PR_.CPU0._PDC] (Node ffff8802270459c0), AE_NOT_FOUND
> [ 11.538469] processor LNXCPU:00: registered as cooling_device0
> [ 11.539028] ACPI: SSDT 00000000d7ee356b 00234 (v01 PmRef
> Cpu1Ist 00003000 INTL 20050228)
> [ 11.539389] ACPI: SSDT 00000000d7ee2f25 00085 (v01 PmRef
> Cpu1Cst 00003000 INTL 20050228)
> [ 11.539906] ACPI Error (psargs-0359): [\_PR_.CPU0._CST] Namespace
> lookup failure, AE_NOT_FOUND
> [ 11.539910] ACPI Error (psparse-0537): Method parse/execution
> failed [\_PR_.CPU1._CST] (Node ffff880227117ce0), AE_NOT_FOUND
> [ 11.539945] processor LNXCPU:01: registered as cooling_device1
> [ 11.540459] ACPI: SSDT 00000000d7ee379f 00234 (v01 PmRef
> Cpu2Ist 00003000 INTL 20050228)
> [ 11.540848] ACPI: SSDT 00000000d7ee2faa 00085 (v01 PmRef
> Cpu2Cst 00003000 INTL 20050228)
> [ 11.542335] ACPI Error (psargs-0359): [\_PR_.CPU0._CST] Namespace
> lookup failure, AE_NOT_FOUND
> [ 11.542341] ACPI Error (psparse-0537): Method parse/execution
> failed [\_PR_.CPU2._CST] (Node ffff880227163f00), AE_NOT_FOUND
> [ 11.542386] processor LNXCPU:02: registered as cooling_device2
> [ 11.542916] ACPI: SSDT 00000000d7ee39d3 00234 (v01 PmRef
> Cpu3Ist 00003000 INTL 20050228)
> [ 11.543209] ACPI: SSDT 00000000d7ee302f 00085 (v01 PmRef
> Cpu3Cst 00003000 INTL 20050228)
> [ 11.543507] ACPI Error (psargs-0359): [\_PR_.CPU0._CST] Namespace
> lookup failure, AE_NOT_FOUND
> [ 11.543512] ACPI Error (psparse-0537): Method parse/execution
> failed [\_PR_.CPU3._CST] (Node ffff8802271f2d60), AE_NOT_FOUND
>
>
Das sieht nach Thermal/Sleep Management für die CPU aus. Nunja. ACPI halt. Ich
denke Schlimmer ist es damit auch nicht. Dein erstes dmesg deutete darauf hin,
dass das Management über SMI stattfindet (du willst die Kiste also nicht für
echtes RT benutzen...). Das wird jetzt weiterhin der Fall sein, der Kernel konnte
mit dem BIOS eben nicht aushandeln das es da die Finger rauslassen soll, er macht das.
Vielleicht hilft hier ein neuerer Kernel, aber ich denke eher nicht.
C'est la vie.
Und mit acpi=off dreht sich ja in die Richtung eh nix - gell ;)
Also, merke: acpi=off ist heutzutage keine gute idee.
[snip]
>> [ 908.746464] ata1.01: failed command: IDENTIFY DEVICE
>>
>>
> ... da steht in diesem Zusammenhang ja immer noch etwas mehr:
>
> [ 2725.100144] ata1: drained 1 bytes to clear DRQ.
> [ 2725.100149] ata1.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
> frozen
> [ 2725.100153] ata1.01: failed command: IDENTIFY DEVICE
> [ 2725.100157] ata1.01: cmd ec/00:00:00:00:00/00:00:00:00:00/10 tag 0
> pio 512 in
> [ 2725.100158] res 58/00:ff:00:00:00/00:00:00:00:00/10 Emask
> 0x2 (HSM violation)
> [ 2725.100161] ata1.01: status: { DRDY DRQ }
> [ 2725.100183] ata1: soft resetting link
> [ 2725.288691] ata1.00: configured for UDMA/33
> [ 2725.305091] ata1.01: configured for UDMA/100
> [ 2725.307246] ata1: EH complete
>
Jo, naja, es sagt halt: "Määäp, Fehler, Ata-device zickt rum", mehr muss man nicht
sehen um zu wissen: Da ist was faul im Staate Dänemark.
Das ist nämlich nicht der normale Modus Operandi.
>> Kontrollier mal die Verkabelung deiner PATA Festplatte (einmal abziehen und neu anstecken).
>> Gibts für das Ding ein Firmware-update?
>> Könnte auch der SmartD sein. Es gibt Platten die mögen es nicht besonders
>> zwei Herren zu dienen, z.B. OS und SmartD, also letzteren mal von der Platte fernhalten.
>>
>>
> Also ich habe auf ata1.00 ein PATA DVD-LW und auf ata1.01 eine PATA Platte.
> An die Verkabelung komme ich nicht so ohne weiteres dran. - Da muss ich
> mir mal ein Stündchen separat Zeit für nehmen.
>
Hmmmgrs.
Wenn die Hütte seeeehr voll ist dann lass es vielleicht auch einfach. Gefahr das nachher
irgend was anderes zickt...
> Der Smartd läuft ist bei mir gar nicht installiert.
OK, das fällt raus.
> Kann das
> möglicherweise damit zusammenhängen, dass ich die Platte (auf die ich
> immer noch sporadisch Backups schiebe) kurzfristig mit hdparm
> runterfahre? - Aus /etc/hdparm.conf:
>
> /dev/hdb {
> mult_sect_io = 16
> write_cache = off
> dma = on
> io32_support = 1
> # apm = 20
> spindown_time = 240
> keep_settings_over_reset = on
> # keep_features_over_reset = on
> }
>
Jo, kann. Dann ist die Platte wohl etwas doof, nach dem Aufwachen dauerts wohl
bis sie das erste Kommando annimmt. Nicht schön aber wenns bislang gelaufen hat.
Einfach im Auge behalten. Check vielleicht mal alte logs ob das schon immer so wahr.
Ein fehlerfreises Log ist halt deshalb Praktisch weil man dann ein neuer Fehler
sofort ins Auge sticht.
> Nochmal zurück zum BIOS: Zwei Dinge verstehe ich dort absolut nicht. Ich
> habe eine Kentsfield Xeon CPU (X3230) - Aber es gelingt mir nicht per
> Google herauszufinden, ob die für Intel Enhances Speedstep die Optionen
> GV1/GV3 und irgendwelche C-States (von 1 bis 4) unterstützt. Habe das
> erstmal enabled, wüsste aber gerne, was die CPU kann.
>
Ein bischen findest du unter /proc/cpuinfo (in der flags-Zeile). Die C-States
"irgendwo" in Linux. Aber da kommt es drauf an ob Linux mit dem ACPI klar
kommt.
Du kannst ja mal powertop installieren. Da wird das, je nach dem, angezeigt.
Hier mal meins als Beispiel:
Cn Verweildauer P-States (Frequenzen)
C0 (Prozessor läuft) ( 3,2%) 2,67 GHz 4,0%
zyklisches AbfraC1 mwait 0,0m 1,73 GHz 0,2%
C1 mwait 0,8ms ( 0,3%) 1,60 GHz 0,1%
C2 mwait 1,3ms ( 4,5%) 1330 MHz 0,1%
C3 mwait 7,1ms (91,9%) 1197 MHz 95,6%
> Ausserdem gibt es noch die Option "Clock Spectrum Feature" mit dem
> Hinweis "Enable to limit peak EMI emission". - Was mache ich damit?
EMI emission sind - vereinfacht übersetzt - Funkstörungen (oder Störaustrahlungen).
Die ganzen getakteten Busse und Komponenten in deinem Rechner funktionieren halt
auch wie ein Sender. Sie geben ihre Frequenz als Störausstrahlung in die Umgebung ab.
Das Gehäuse (so es denn richtig EMV-Dicht ist) sollte das meiste schlucken.
Denoch, das Gehäuse "vernichtet" solche Aussendungen ja nicht, es bedämpft sie nur
mehr oder weniger stark (und grade HF kommt überall raus...).
Wenn man nun ein guter Nachbar sein will, dann sollte man seine EMV-Ausstrahlung
minimieren. (Der Extreme fall das die RegTP kommt und dein Equipment als Störsender
einsammelt wird wohl eher nicht vorkommen).
Ein Trick diese getakteten Busse/Komponenten einfacher "in den Griff" zu bekommen
ist nun, sie nicht auf einer absoluten Fixen Frequenz arbeiten zu lassen, sondern
die Arbeitsfrequenz ein kleinen wenig um eine Mittenfrequenz schwanken zu lassen
(wir reden hier von 0,5% und ähnliches).
Der Technick fällt das nicht auf, solange alle mit der gleichen Freq. arbeiten, und
in der Perfomance ist es auch egal, es ist halt mal etwas zu langsam, mal etwas zu
schnell.
Es sorgt nur dafür, das man seine Störausstrahlungen auf einen Frequenzbreich "aufteilt".
Man sendet nicht so "hart" auf einer Frequenz. Damit lässt sich das auch besser
bedämpfen und insgesammt ist Welt ein besser Ort.
In anderen BIOSen heist das "Clock Spread Spectrum", was es etwas besser beschreibt,
das ausgesendete Frequenzspektrum wird aufgespreizt, so das die Energiedichte auf
der einzelnen Frequenz geringer wird.
> Knipst man sowas besser an/aus?
>
An.
Ja, es könnte irgendwelche Probleme machen (z.B. jitter), aber wenn man solche Proleme
hat...
Im allgemeinen Empfiehlt sich das für die meisten Rechner. Andere Funbetriebenen Dienste
werden es dir danken.
> LG und 1000 Dank!
>
> Stefan.
>
Gruss
Jan
--
"I'm too sexy for my code." -Awk Sed Fred
More information about the Linux
mailing list