sidux.com
Installation, Einstellungen, Systempflege - Toshiba P100-439 DSDT, Sound, ACPI - mit Kernel 2.16.20.1
renewehle - Feb 26, 2007 - 07:41 PM
Post subject: Toshiba P100-439 DSDT, Sound, ACPI - mit Kernel 2.16.20.1
Hallo,
heute häufen sich die Fragen. Starte ich von der CD, dann sehe ich an der Ausgabe, das alles prima erkannt wird. WLAN, Graka usw.
Nach der Installation meckert er nur run und findet einige Hardware nicht mehr. Kann ich irgendwie den Kernel von der CD auf die HDD bringen und diesen zum starten bringen?
Problem ist: Ich habe seit einiger Zeit einen nagelneuen Laptop und ich versuche schon verzweifelt einige Linux-Systeme zum Laufen zu bringen.
Toshiba Satellite Pro P100-439 mit
Graka: GeForce Go 7900 GS
Sound: Cx20549 / Intel 82801 GBM (82801G ICH7)
USB-Controller: Intel 82801
WLAN: Intel 3945 ABG PRO
TFT: Samsung LCD 1650x1050 WSXGA+
Bin für jede Hilfe dankbar
Nachtrag: Dieses Posting ist gelöst, bitte einfach alles lesen.
michaaa62 - Feb 26, 2007 - 09:45 PM
Post subject: RE: nach der Installation sieht alles anders aus
Hallo renewehle,
lass Dich nicht unterkriegen und werde mal konkreter bei der Beschreibung der Fehler, Unklarheiten und sonstigen Ungereimtheiten, damit Dir die Experten helfen können.
Grüsse Micha
hubi - Feb 26, 2007 - 10:12 PM
Post subject: RE: nach der Installation sieht alles anders aus
renewehle,
habe auch einen Toshiba P100, aber Version 138. Nur werde ich aus deinen Angaben nicht schlau:
1. Der installierte Kernel sollte der gleiche sein wie der auf der CD.
2. Welche Hardware geht nicht?
3. Du hast Sound ohne neukompilierte DSDT? Dann frisst mich aber Neid und Zorn 
Grüße
hubi
renewehle - Feb 26, 2007 - 11:02 PM
Post subject: RE: nach der Installation sieht alles anders aus
Ich kann nicht so schnell mitschreiben wie der Bildschirm weg ist. Kann man die Ausgaben protokollieren in eine Datei? Dann könnte ich Euch besser zeigen was ich meine?
P.S.: Sound habe ich wenn ich die Live-CD starte mit den Optionen "acpi=off noapic pci=bios"
lasse ich den acpi weg, höre ich auch kein sound mehr... das soll einer verstehen 
hubi - Feb 26, 2007 - 11:13 PM
Post subject: RE: nach der Installation sieht alles anders aus
renewehle,
werde zwar immer noch nicht schlau, aber irgendwie scheint deine Installation nach dem Grub abzubrechen, während die Live-CD hochfährt.
Wenn dem so ist, starte mit der CD, suche die /var/log/dmesg deiner Installation, kopiere sie irgendwohin, wo du sie hast (USB Stick) und poste sie hierher - entweder in einer Code-box) oder als Anhang (tar.gz machen oder umbenennen in .txt, damit die Forumssoftware den Anhang nimmt).
Leider kann ich dir nicht so richtig am Gerät weiterhelfen, da ich am Toshiba eine Installation vom Sommer habe (war noch Kanotix) und die sidux-Live-CD problemlos geht. Außerdem sehe ich das Gerät erst wieder morgen/heute Früh. Testpartition habe ich keine, nur blindes Vertrauen
hubi
hubi - Feb 26, 2007 - 11:27 PM
Post subject:
Zum Sound: mach mal einen eigenen Thread auf und ich kann dir in den nächsten Tagen sagen, wie du zum Sound kommst, wenn du installiert hast. Die Kernels von slh sind für den Fall vorbereitet.
Aber der Hack ist teuflisch: du musst das DSDT vom Bios abgreifen, Fehler editieren und eine Zeile einfügen, danach mit dem entsprechenden Compiler von Intel eine neue DSDT kompilieren und diese ins initrd.img einbinden. Letzteres nach jedem Kernel-Upgrade.
Wenn ich deine genaue Gerätenummer habe (steht auf einem Label am Boden) und du BIOS v.3.30 hast (ist vom Jänner), könntest du evtl. meine DSDT.aml fahren.
Die Anleitung selber habe ich mir nicht zusammengeschrieben, aber das wäre mal ein Anlass das zu tun in den nächsten Tagen.
Sound mit ACPI kriegst du auch mit Ubuntu, SuSE oder Mandriva, aber auch nur mit dem Hack. Bei anderen Distributionen musst du noch den Kernel patchen und selbst kompilieren.
Der Sound selber ist erst ab Kernel 2.6.20.x ordentlich, da der Conexant Chip erst ab Alsa 1.0.14-rc1 unterstützt ist. Bei älteren Kernel musst du den Alsa-Treiber von den Sourcen aus experimental mittels m-a installieren.
Haarige Sache, sage ich dir, diese hundigen BIOS.
Hier im Forum gibt es schon ein, zwei Threads zu der Sache, falls du dich da reinknien möchtest. Aber es lohnt sich, habe nach einem halben Jahr endlich perfekten Sound und perfektes ACPI.
hubi
renewehle - Feb 27, 2007 - 08:32 AM
Post subject:
So jetzt habe ich einen vollständigen Report. Wenn ich von der CD starte, ist die /var/log/dmesg 0 Bytes groß, damit kann man also nichts anfangen. Das sidux habe ich mal installiert. Starte ich das sidux ohne weitere Boot-Schalter (also ganz normal), dann habe ich folgende dmesg-log:
http://edvbox.de/sidux/dmesg-mit-acpi.txt
Starte sidux mit den Zusatzschaltern "acpi=off noapic pci=bios", dann erhalte ich folgende dmesg-log:
http://edvbox.de/sidux/dmesg-ohne-acpi.txt
Noch eine Anmerkung zu meinen vorhergehenden Postings. Was ich meinte:
Starte ich von der CD, dann sehe ich den Kernel und die Schrift ist in grüner, gelber Farbe. Dort sieht man auch das die kompette Hardware 1A gefunden wird. Die Hardware funktioniert auch sehr gut AUSSER dem WLAN:
http://edvbox.de/sidux/DSC03780.JPG
http://edvbox.de/sidux/DSC03781.JPG
Nach der Installation ist die Schrift vom Kernel nur noch weiß und es kommt zu Fehlermeldungen:
http://edvbox.de/sidux/DSC03776.JPG
Das BIOS in der Version 3.30 habe ich ganz sicher. Meine Gerätenummer kannst Du natürlich auch haben: PSPAHE-002001GR
Werkwürdig ist eben, wenn ich beim Starten "acpi=off noapic pci=bios" schreibe, dann habe ich auch Sound ohne einem Hack! Jedoch bilde ich mir ein, das der Laptop-Lüfter ständig läuft und auch nicht die volle Leistung bringt.
Na jetzt bin ich aber mal auch Antworten gespannt.
devil - Feb 27, 2007 - 09:08 AM
Post subject:
welche farbe die meldungen haben, ist uninteressant.
dein bios hat auf jeden fall ein acpi problem.
was wlan angeht, so solltest du die release note lesen. da die firmware non-free ist, können wir diese nicht beilegen. du findest die einzelnen wlan module hier aufgeführt: http://sidux.com/Article117.html
greetz
devil
slam - Feb 27, 2007 - 09:11 AM
Post subject:
1) Die Farbe der Bootmeldungen ist völlig unwesentlich, und nur eine optische Spielerei für die Live-CD.
2) Grundsätzlich ist der Bootprozess auch etwas unterschiedlich - ein Live-System muss andere Aufgaben erfüllen als ein auf HDD installiertes.
3) Wenn Du ACPI manuell abschaltest (acpi=off), dann läuft natürlich die Lüftersteuerung nicht mehr - auf die Leistung sollte das aber keinen Enfluss haben (ausser das System überhitzt). Selbstverständlich kommen ACPI-Warnungen beim Booten - Du hast es ja manuell deaktiviert. 
4) Wlan ist sicher hinzukriegen, da fehlt recht wahrscheinlich nur die richtige Firmware. Anleitungen dazu findest Du in unserer Releasenote: http://sidux.com/Article116.html.
5) Wenn Du ein sauberes System mit allen ACPI-Funktionen und Sound haben willst, wirst Du um das erstellen/verwenden einer korrigierten DSDT (siehe hubi's Hilfeabgebot) nicht herumkommen.
Greetings,
Chris
renewehle - Feb 27, 2007 - 11:44 AM
Post subject:
Hui, das klingt ja nach einem heißen Eisen. Da brauche ich auf jeden Fall Deine kompetente Hilfe. Ich nutze zwar Linux schon seit einigen Jahren, aber eben nicht sooo intensiv. Abkürzungen wie "DSDT" oder "mittels m-a" sagen mir nichts.
Bin aber gerne bereit alles zu testen um zum Ziel zu kommen. Und mein Ziel war es mit dem neuen Laptop nur noch unter Linux zu arbeiten. Das nenne ich mal ein vernüftiges Ziel
René
hubi wrote:
Zum Sound: mach mal einen eigenen Thread auf und ich kann dir in den nächsten Tagen sagen, wie du zum Sound kommst, wenn du installiert hast. Die Kernels von slh sind für den Fall vorbereitet.
Aber der Hack ist teuflisch: du musst das DSDT vom Bios abgreifen, Fehler editieren und eine Zeile einfügen, danach mit dem entsprechenden Compiler von Intel eine neue DSDT kompilieren und diese ins initrd.img einbinden. Letzteres nach jedem Kernel-Upgrade.
Wenn ich deine genaue Gerätenummer habe (steht auf einem Label am Boden) und du BIOS v.3.30 hast (ist vom Jänner), könntest du evtl. meine DSDT.aml fahren.
Die Anleitung selber habe ich mir nicht zusammengeschrieben, aber das wäre mal ein Anlass das zu tun in den nächsten Tagen.
Sound mit ACPI kriegst du auch mit Ubuntu, SuSE oder Mandriva, aber auch nur mit dem Hack. Bei anderen Distributionen musst du noch den Kernel patchen und selbst kompilieren.
Der Sound selber ist erst ab Kernel 2.6.20.x ordentlich, da der Conexant Chip erst ab Alsa 1.0.14-rc1 unterstützt ist. Bei älteren Kernel musst du den Alsa-Treiber von den Sourcen aus experimental mittels m-a installieren.
Haarige Sache, sage ich dir, diese hundigen BIOS.
Hier im Forum gibt es schon ein, zwei Threads zu der Sache, falls du dich da reinknien möchtest. Aber es lohnt sich, habe nach einem halben Jahr endlich perfekten Sound und perfektes ACPI.
hubi
hubi - Feb 27, 2007 - 11:49 AM
Post subject:
Meine Antworten werden mal langsam reinkommen. Hier eine erste, zu dmesg:
Quote:
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
PCI: Cannot allocate resource region 7 of bridge 0000:00:1c.0
PCI: Cannot allocate resource region 8 of bridge 0000:00:1c.0
PCI: Cannot allocate resource region 9 of bridge 0000:00:1c.0
PCI: Cannot allocate resource region 7 of bridge 0000:00:1c.1
PCI: Cannot allocate resource region 8 of bridge 0000:00:1c.1
PCI: Cannot allocate resource region 9 of bridge 0000:00:1c.1
PCI: Cannot allocate resource region 7 of bridge 0000:00:1c.2
PCI: Cannot allocate resource region 8 of bridge 0000:00:1c.2
PCI: Cannot allocate resource region 9 of bridge 0000:00:1c.2
PCI: Failed to allocate mem resource #6:20000@d0000000 for 0000:01:00.0
Diese Meldung kommt mir bekannt vor, aber versuch mal als Cheatcode in der Grubzeile
Code:
pci=routeirq
Werde ich selber morgen auf Arbeit ausprobieren, bin jetzt schon extern unterwegs. Aber vielleicht siehst du dann diese Meldungen nicht mehr (habe ich nach dem Start des Bootvorgangs, nach grub auch). Wäre toll, wenn du posten könntest, ob sich dieser cheat auf deinen Bootvorgang auswirkt.
hubi
hubi - Feb 27, 2007 - 12:16 PM
Post subject:
Zum Sound. Der Fehler liegt im DSDT, welche von ACPI aufgerufen wird:
Quote:
ACPI: DSDT (v001 TOSQCI Denver 0x06040000 MSFT 0x03000001) @ 0x00000000
Hier siehst du, dass die DSDT aus dem BIOS aufgerufen wird.
Nach dem Hack wird die DSDT nicht mehr vom BIOS eingelesen, sondern von der selbst kompilierten Datei DSDT.aml.
Das BIOS ist von Phoenix Ltd. mit Sitz in Denver, und die ist DSDT ist nicht nur nach DSDT-Standards fehlerhaft kompiliert (der Intel-Compiler gibt Fehler aus).
Etwas ausführlicher:
Normalerweise reicht die Fehlerbereinigung bei Problemen mit ACPI, betrifft aber meistens nicht den Sound, sondern zum Beispiel eine fehlerhafte Batteriestandsanzeige.
Bei den neuen Toshiba-Geräten wurde lange gerätselt, warum beim Sound ein DSDT-Hack nicht ausreicht, bis ein Gentoo-Hacker draufgekommen ist, dass dem BIOS vorgegaukelt werden muss, dass man kein Linux fährt, sondern ein Windows. Man muss also noch eine Zeile in die DSDT einfügen, welche ein Fake Windows vorgaukelt, dann geht der Sound auch mit ACPI perfekt.
Schau dir hier meinen Beitrag bzw. den Thread an. Habe hier auf sidux in Echtzeit meine Lösung gepostet:
http://sidux.com/index.php?name=PNphpBB ... 1833#11833
Zu deiner Produktnummer: bitte lass mir bis morgen Zeit, aber es könnte gehen, dass meine DSDT.aml bei dir funktioniert. Der Rest ist einfach (Einbindung der DSDT.aml ins initrd.img.
Grüße
hubi
PS: das mit den Farben (auf die Idee bin ich nicht gekommen) war bei mir immer so, wenn ich ein Live-System installierte. Das sei mal kein Problem.
hubi - Feb 27, 2007 - 12:39 PM
Post subject:
renewehle wrote:
Hui, das klingt ja nach einem heißen Eisen. Da brauche ich auf jeden Fall Deine kompetente Hilfe. Ich nutze zwar Linux schon seit einigen Jahren, aber eben nicht sooo intensiv. Abkürzungen wie "DSDT" oder "mittels m-a" sagen mir nichts.
Bin aber gerne bereit alles zu testen um zum Ziel zu kommen. Und mein Ziel war es mit dem neuen Laptop nur noch unter Linux zu arbeiten. Das nenne ich mal ein vernüftiges Ziel
http://de.wikipedia.org/wiki/Advanced_C ... n_Table.29
Zu den konkreten Aufgaben:
1. PSPAHE ist wahrscheinlich ok. Für H steht normal 0, 3 oder 6
2. Du hast BIOS v3.30 von Phoenix, ich auch
3. Die BIOS-Dateien sind identisch für alle Satellite P 100
4. Ich poste dir meine DSDT.aml (die DSDT, welche gelesen werden soll)
5. Du kriegst eine Anleitung, wie du initrd.img anweist, nicht aus dem BIOS zu lesen
Punkt 4 und 5 kann ich erst morgen machen, wenn ich wieder am Toshiba bin. Aber zu 99 Prozent funktioniert die Sache, und du hast dann vollen Sound auch mit ACPI (ohne ACPI ist das etwas öde mit dem Schleppi).
Die DSDT.aml ist dann zukunftssicher, da slh den Kernel patcht, aber er ist auch anwendbar zumindest mit Ubuntu, SuSE und Mandriva. Die haben auch den DSDT-Patch im Kernel, der im Vanilla-Kernel von kernel.org nicht enthalten ist. ArchLinux soll auch den Patch bereits im Kernel haben. Du musst nur darauf achten, dass die Methode der Einbindung der DSDT.aml bei anderen Distributionen anders geregelt ist bzw. sein kann.
Wenn meine DSDT.aml passt, dann ersparst du dir den härtesten Teil: das Umschreiben und Rekompilieren der DSDT. Nur beachten solltest du, dass nach einem BIOS-Upgrade diese DSDT.aml mit höchster Wahrscheinlichkeit nicht mehr funktioniert und neu fehlerbereinigt werden muss (so eine neue Version nicht den Fehler behebt - bei mir ist es das dritte BIOS, und keines hat ursprünglich Sound ausgegeben).
Und Linux am Laptop? Ich habe auch nur ausschließlich Linux drauf und war schon ziemlich sauer, als ich am Toshiba keinen Sound hatte, obwohl die KollegInnen drüber sicher erfreut waren
Aber jetzt ist das ein wunderbarer Laptop, auch wenn er einige Nerven und Hirnschmalz gekostet hat. Und dem unbekannten Gentoo-Hacker bin ich zu unendlichem Dank verpflichtet.
Grüße
hubi
renewehle - Feb 27, 2007 - 06:19 PM
Post subject:
Das habe ich schon mal testen könnne, leider hat das kein anderes Ergebnis gebracht, die PCI errors kommen trotzdem noch.
hubi wrote:
Meine Antworten werden mal langsam reinkommen. Hier eine erste, zu dmesg:
Quote:
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
PCI: Cannot allocate resource region 7 of bridge 0000:00:1c.0
PCI: Cannot allocate resource region 8 of bridge 0000:00:1c.0
PCI: Cannot allocate resource region 9 of bridge 0000:00:1c.0
PCI: Cannot allocate resource region 7 of bridge 0000:00:1c.1
PCI: Cannot allocate resource region 8 of bridge 0000:00:1c.1
PCI: Cannot allocate resource region 9 of bridge 0000:00:1c.1
PCI: Cannot allocate resource region 7 of bridge 0000:00:1c.2
PCI: Cannot allocate resource region 8 of bridge 0000:00:1c.2
PCI: Cannot allocate resource region 9 of bridge 0000:00:1c.2
PCI: Failed to allocate mem resource #6:20000@d0000000 for 0000:01:00.0
Diese Meldung kommt mir bekannt vor, aber versuch mal als Cheatcode in der Grubzeile
Code:
pci=routeirq
Werde ich selber morgen auf Arbeit ausprobieren, bin jetzt schon extern unterwegs. Aber vielleicht siehst du dann diese Meldungen nicht mehr (habe ich nach dem Start des Bootvorgangs, nach grub auch). Wäre toll, wenn du posten könntest, ob sich dieser cheat auf deinen Bootvorgang auswirkt.
hubi
hubi - Feb 27, 2007 - 10:41 PM
Post subject:
Danke, dann lassen wir die Errors mal, ich habe sie am Toshiba auch noch. Schauen wir mal, ob ich morgen (Mittwoch) die Anleitung hinkriege, dass du die DSDT einbinden kannst.
hubi
renewehle - Feb 28, 2007 - 07:26 AM
Post subject:
Was ich da geschrieben habe war nicht richtig. Wenn ich also statt "pci=bios" deine variante schreibe "pci=routeirq", dann sieht das so aus: http://edvbox.de/sidux/DSC03789.JPG
hubi - Feb 28, 2007 - 09:53 AM
Post subject:
Der Sache gehe ich auch noch nach, vielleicht kriegen wir dann noch einen perfekten Toshiba hin
Jetzt zum Patchen der DSDT.
1.
Im Anhang meine DSDT.aml als .tar.gz. Diese entpacken und als Root nach / geben (also ganz oben in den Tree, steht zumindest bei http://gaugusch.at/kernel.
2.
Dann lädst du dir folgendes Skript:
http://gaugusch.at/acpi-dsdt-initrd-pat ... d-add-dsdt
Dieses kopierst du am besten nach /boot.
3.
In /boot sichere deine initrd.img-($uname -r), also die aktuelle. Ich hänge immer ein .original dran.
4.
Mit dem Skript patcht du die initrd.img-($uname -r). Die Syntax ist:
sh initrd-add-dsdt initrd.img-($uname -r) /path/to/DSDT.aml.
Hier ein konkretes Beispiel aus meiner internen Anleitung:
Code:
cd /boot
cp initrd.img-2.6.19.3-rc1-slh-smp-1 initrd.img-2.6.19.3-rc1-slh-smp-1.original
sh initrd-add-dsdt initrd.img-2.6.19.3-rc1-slh-smp-1 /DSDT.aml
5.
reboot
Das war's auch schon, jetzt sollte der Sound auch bei ACPI perfekt gehen (beachte, ich habe schon einen 2.6.20-Kernel, der auch das richtige alsa hat.
Zwischen 11.40 und 12.10 bin ich wieder hier am Computer.
Viel Erfolg,
hubi
renewehle - Feb 28, 2007 - 12:16 PM
Post subject:
Das wäre zu schön um wahr zu sein. Habe mit 110% die Sache richtig gemacht. Aber der Laptop macht nicht mit. Nach dem Neustart sehe ich nur sehr kurz ein paar Zeilen (bzImages oder so ähnlich) und dann bleibt der Bildschirm schwarz. Auch nach einer Minute passiert nichts. Schade...
Liegt das evtl an der neueren Kernelversion 2.16.20.1 ???
hubi - Feb 28, 2007 - 01:09 PM
Post subject:
renewehle,
da müsste ich schauen, ob dieser Kernel den DSDT-Patch vielleicht nicht hat, normal hat slh den Patch drinnen, aber ich verwende den Kernel nicht, da er nur einen kleinen Fix hatte, den ich nicht brauche.
Sieht fast so aus, dass das BIOS mit meiner DSDT.aml nicht umgehen kann. Fehler kannst nicht viel machen, wenn du das DSDT.aml hast. Und dass du was gemacht hast, beweist, dass nichts geht.
Ich melde mich nochmal, muss noch eine Runde arbeiten. Später gebe ich mal eine Anleitung, wie du dein DSDT anpassen kannst, aber das ist Geduldsarbeit.
Schade.
Grüße
hubi
hubi - Feb 28, 2007 - 01:51 PM
Post subject:
Habe gecheckt, der dsdt-Patch ist im Kernel. Dann hat der leichte Weg vermutlich leider nicht geklappt. Alles andere ist kernelunabhängig, was wir gemacht haben. Es muss nur das richtige initrd.img gepatcht werden. Das ist wohl passiert.
Grüße
hubi
renewehle - Feb 28, 2007 - 02:46 PM
Post subject:
Der Kernel war bei der Linux-Version schon dabei. Durch das Ändern des Kernels kann ich aber hoffentlich den Laptop nicht kaputt machen? Weil das ja recht hardwarenah programmiert ist?!
renewehle - Mar 02, 2007 - 07:11 PM
Post subject:
Was mache ich jetzt?
hubi - Mar 02, 2007 - 10:46 PM
Post subject:
renewehle,
der Kernel ist gut von der CD, habe nachgeguckt, da ist alles drinnen.
Was du machst, ein bisserl warten. Morgen oder am Sonntag kann ich eine Anleitung schreiben, wie du das DSDT deines BIOS anpasst, und am Montag schicke ich dir eine Diff von meinem Toshiba, damit du siehst, was da so geändert wurde.
Es wird ein Abenteuer werden, aber ich habe das auch erfolgreich geschafft, ohne vorher je was von DSDTs gehört zu haben. Hilfe und Rat kriegst du von mir dann weiterhin in diesem Thread.
Ziel ist: eine funktionierende DSDT, und ab dann ist alles leicht, auch bei einem Kernel-Upgrade. Aber echt schade, dass meine nicht ging.
Zum Kernelupdate: normalerweise bist du mit den stabilen Kerneln von slh auf der sicheren Seite. Ich nutze diese schon seit einem Jahr. Auch lasse ich mir meistens noch zwei weitere Kernel noch am System:
1. den letzten funktionierenden von slh
2. einen von Debian (aus Neugier; aber nicht am Toshiba, da er nicht den DSDT-Patch hat)
Grüße
hubi
renewehle - Mar 03, 2007 - 04:25 PM
Post subject:
Ich habe noch ein interessantes Posting zum Thema gefunden (http://www.linuxquestions.org/questions/showthread.php?t=531575&highlight=p100) aber dort steht ein Befehl iasl ???
Was ist das? Dieser Befehl kann bei mir nicht durchgeführt werden. (command not found)
hubi - Mar 03, 2007 - 04:35 PM
Post subject:
renewehle wrote:
Ich habe noch ein interessantes Posting zum Thema gefunden (http://www.linuxquestions.org/questions/showthread.php?t=531575&highlight=p100) aber dort steht ein Befehl iasl ???
Was ist das? Dieser Befehl kann bei mir nicht durchgeführt werden. (command not found)
Wow! Da hat jemand bereits eine komplette Anleitung für den Toshiba geschrieben. Auch das "Fake Windows" ist drinnen.
iasl ist der Intel-Compiler, den du brauchst:
Code:
apt-get update
apt-get install iasl
Jetzt musst du dich nur noch drüber getrauen. Bei mir hat's geklappt.
Frag jederzeit nach, falls was unklar ist, ich schau hier eh ein paar Mal am Tag rein.
Die Daumen gedrückt,
hubi
renewehle - Mar 03, 2007 - 05:12 PM
Post subject:
Ab Nummer 7. komme ich nicht weiter, weil das Verzeichnis /etc/sysconfig/kernel nicht existiert.
hubi - Mar 03, 2007 - 06:44 PM
Post subject:
Uh, hätte ich genauer schauen sollen. Vergiss das mal ab Punkt 7, wenn du die DSDT.aml hast.
Versuch wieder mit dem Script von Gaugusch die initrd.img-($uname -r) zu patchen (nicht vergessen, wo du die DSDT.aml hingelegt hast). Nach dem Reboot müsste es dann gehen, wenn alles klar gelaufen ist.
Wäre super!
Grüße
hubi
renewehle - Mar 03, 2007 - 06:57 PM
Post subject:
Jetzt meckert er an "initrd-add-dsdt". Ich kann mir leider nicht vorstellen was das ist.
hubi - Mar 03, 2007 - 07:12 PM
Post subject:
Was ist meckern?
renewehle - Mar 03, 2007 - 07:15 PM
Post subject:
Datei oder Verzeichnis nicht gefunden
hubi - Mar 03, 2007 - 07:20 PM
Post subject:
Hier eine Checkliste, um den Fehler einzugrenzen. Es kann nur ein kleiner Fehler sein, wenn Skript und DSDT.aml vorhanden sind.
1. Bist du root?
2. wo ist das Skript?
3. wo ist root, wenn das Skript ausgeführt wird?
4. wo ist DSDT.aml? (Großschreibung wichtig!)
5. am besten ist DSDT.aml in /
6. was ist der genaue Befehl?
hubi
renewehle - Mar 03, 2007 - 07:43 PM
Post subject:
*vor die Stirn klatsch* ich hatte einfach die Datei vorher nicht geladen, so kann er das skript natürlich nicht Laden
Nach dem Neustart habe ich über GRUB normal gestartet. Mir kommt es aber so vor als ob die Zeit, bis der Kernel startet recht lange dauert. Ich habe also ca. 3 Sek lang einen schwarzen Bildschirm.
Außerdem erhalte ich weiter diese PCI Fehlermeldungen am Beginn, auch mit der Zusatzoption "pci=routeirq"
...und, ob Du es glaubst oder nicht, aber ich höre Sound!!! Das ist doch schon mal was!
Wie kann ich prüfen ob das ACPI jetzt richtig läuft?
hubi - Mar 03, 2007 - 08:12 PM
Post subject:
HURRRAAAAH!
- längerer schwarzer Bildschirm: hier auch
- Sound!
- Fehlermeldungen ... habe ich die noch? weiß nicht. Sag ich am Montag.
Das hat imho geklappt. Aber jetzt wollen wir das bestätigt haben, daher gib, was folgendes sagt:
Code:
dmesg | grep DSDT
Und dann kann ich hoffentlich gratulieren,
hubi
renewehle - Mar 03, 2007 - 08:17 PM
Post subject:
Hier die Ausgabe:
Quote:
ACPI: DSDT (v001 TOSQCI Denver 0x06040000 MSFT 0x03000001) @ 0x00000000
ACPI: Looking for DSDT in initramfs... successfully read 31950 bytes from /DSDT.aml.
ACPI (tbget-0297): Table [DSDT] replaced by host OS [20060707]
Was mache ich mit den PCI-Fehlermeldungen?
hubi - Mar 03, 2007 - 08:27 PM
Post subject:
YES!
Zu den Fehlermeldungen: lass sie mal. Ich schaue am Montag auf meinem Toshiba nach (ist am Arbeitsplatz), weiß jetzt nicht, ob ich die auch noch habe.
Wenn du mit iasl keine Fehlermeldung mehr bekommen hast nach dem Kompilieren der DSDT, dann kannst du im Augenblick nicht mehr machen.
Dann werden die Fehler vielleicht irgendwann mal nach einem Kernel-Update weg sein (bitte nicht vergessen, jedes Mal das Skript mit der neuen initrd.img laufen zu lassen) oder ein neues BIOS könnte das mal lösen (aber dann musst du die Prozedur wiederholen).
Wenn du das Gefühl hast, dass alle Hardware läuft, dann lass mal die Fehlermeldungen sein. Ich habe sie auf meinem Gerät genau analysiert, sie betreffen die Soundausgabe und nichts anderes. Wenn der Sound zu deiner Zufriedenheit auch mit ACPI geht, dann können die Fehlermeldungen imho ignoriert werden.
Man müsste auch wissen, ob das gepatchte DSDT erst nach den Fehlermeldungen eingreift. Keine Ahnung. Aber ich denke, man kann das so lassen.
Auf jeden Fall, ganz super gemacht und Toshiba eine lange Nase gezeigt 
Wir werden uns in diesem Thread noch treffen, wenn du Fragen hast, schreib es hier rein. Vielleicht kannst du deinen allerersten Beitrag editieren und Toshiba P100 DSDT in die Überschrift schreiben, da dies, was du jetzt gemacht hast, wie auch unsere Diskussion vielen Leuten wird helfen können.
Gratuliere und ganz herzliche Grüße
hubi
renewehle - Mar 03, 2007 - 08:35 PM
Post subject:
COOL und ein dickes DANKESCHÖN !!!!!!!!
So viel Gedult hat nicht jeder. Hoffentlich gibt es das Forum in einigen Monaten auch noch, fals ich das System neu installieren muß 
Übrigens habe ich den NVIDIA-Treiber von deren Webseite auch installiert gebracht. Das sieht mal richtig gut aus. Jetzt bin ich fast zufrieden. (Werde mal Beryl installieren, hat ja unter Ubuntu auch geklappt )
Den Titel habe ich angepasst, da hattest Du vollkommen Recht. Wenn Du ggfs nochmals nach den PCI-Fehlern schauen könntest, wäre das toll.
Ach, jetzt bin ich selbst ein bisschen Stolz auch mich. Zum Glück habe ich den passenden Link gefunden.
Also, nochmals DANKE und noch schönes WE.
René Sato
renewehle - Mar 03, 2007 - 08:48 PM
Post subject:
Dann mache ich jetzt ein Häckchen für "gelöst".
hubi - Mar 03, 2007 - 08:52 PM
Post subject:
Hehe. Echt groovy
Ich melde mich am Montag nochmal wegen der PCI-Fehler hier, wie das bei mir ausschaut.
Schönes Wochenende auch,
hubi
hubi - Mar 06, 2007 - 11:08 AM
Post subject:
renewehle,
so, jetzt habe ich nicht vergessen. Die PCI-Fehlermeldungen habe ich auch noch. Der Bootvorgang läuft also gleich mit deinem: längeres schwarzes Warten, danach PCI-Fehlermeldungen. Aber ACPI scheint voll zu gehen.
Wenn ich mich richtig erinnere, gibt ohne den DSDT-Patch ACPI der Soundkarte keinen Strom. Drum scheint ja alles zu gehen, nur stumm.
Habe auch in dmesg nachgeguckt, der DSDT-Patch wird vor den Fehlermeldungen initiiert. Naja, solange alles geht ...
Grüße
hubi
renewehle - Mar 06, 2007 - 04:46 PM
Post subject:
Ein Fehler macht nicht noch etwas nervös:
Waiting for /dev to be populat
mtel_rng: FWH not detected
oder so ähnlich.
Außerdem, wenn ich den PC unter KDE heruterfahre, dann klackert die Festplatte so komisch. Das kenne ich unter Windows nicht.
hubi - Mar 06, 2007 - 05:33 PM
Post subject:
Warten auf /dev ist normal.
Zum FWH-Fehler gibt es hier schon einen Thread (ist eine Intel-Sache und den Kernel-Programmierern bekannt):
http://www.sidux.com/PNphpBB2-viewtopic ... art-0.html
Was heißt klackern? Wann klackert sie? Knapp vor dem Ausschalten kann sie klackern, vorher eigentlich eher nicht. Auf gut Deutsch, bei mir am Toshiba klackert nichts (formatiert mit ReiserFS). Mit ext3 formatierte Festplatten klackern eher mal, ist nun mein gaaaaanz subjektiver und durch nichts beweisbarer Eindruck (beim Unmounten z. B., drum darf es ganz am Schluss auch klackern).
Du kannst ja mal von der Installations-CD booten und folgendes laufen lassen, wenn du beunruhigt bist (vorher aber nicht mounten):
Code:
fsck /dev/hda
fsck /dev/sda
Oder wie immer deine Festplatte heißt.
Festplatten können sterben, und wenn sie einen Fehler haben, dann gerne zu Beginn ihrer Karriere (meistens einen Tag, nachdem die Garantie abgelaufen ist).
Im Regelfall halten sie aber lange. Habe hier einige alte in USB-enclosures, die haben schon unter Windows gedient (sechs, sieben Jahre alt) und waren mit allen möglichen Filesystemen formatiert.
Dennoch ist eine Investition unter jedem Betriebssystem Goldes Wert: ein Backup (ich habe praktisch alle Daten doppelt auf externen Festplatten und fahre wöchentlich, wenn ich mir Daten kaufe sofort nach dem Kauf ein Backup). Man kann einen Fehler nie ausschließen, und wenn schließlich es doch ein Garantiefall ist, dann können auch Daten weg sein.
Kleines Beispiel: HP Wien hat mir bei einem Versicherungsschaden für einen Bildschirm an einem Laptop meine komplette Linux-Installation samt Daten platt gemacht und ein nacktes Windows raufgespielt. 
Ohne Backup hätte ich deppert geschaut.
Grüße
hubi
flexo3105 - Mar 17, 2007 - 07:02 PM
Post subject:
hi , bin neu hier und wollt mal ein paar fragen stellen .
ich habe auch ein toshiba , um genau zu sein ein p100-194 , leider
habe ich auch probleme den sound zum laufen zu bekommen auf ubuntu edgy. ich habe mir das hier --> http://www.ubuntuforums.org/showthread. ... shiba+p100
mal angeschaut und mit ein paar verschiedenen dsdt files ausprobiert die meinem laptop am ähnlichsten waren , hat leider nix gebracht . bin leider nicht so der linux pro und wäre für jede hilfe dankbar .
hubi - Mar 17, 2007 - 07:17 PM
Post subject:
flexo3105,
hier in diesem Thread kannst du lernen, wie man eine DSDT.aml erstellt unter der wichtigen Berücksichtigung des Hacks der gentoo-Leute. DSDT.aml können sehr offensichtlich nicht zwischen verschiedenen Laptopversionen ausgetauscht werden, auch wenn es dasselbe BIOS ist.
Wie du die DSDT.aml in Ubuntu einbauen musst, kannst du hier nicht lernen. Unter Debian ist es sehr einfach, aber du musst dich an die Spezifika von Ubuntu halten (ist in deinem Link enthalten). Oder sidux aufspielen. Ist ja auch kein Fehler
Ansonsten: alle Infos, die du brauchst, sind hier im Thread enthalten. Für sidux alle.
hubi
flexo3105 - Mar 17, 2007 - 09:13 PM
Post subject:
hi , habe mal im gentoo forum rumgestöbert , ich wüsste jetzt so ungefähr wo ich nachschaun / was ich ändern müsste , was mir aber noch unklar ist : wo greife ich das dsdt file vom bios ab ? oder seh ich den wald vor lauter bäumen nicht ?
gruss
hubi - Mar 17, 2007 - 09:28 PM
Post subject:
Alle Infos hier im Thread, und die praktische Linkliste aus dem Thread (im zweiten ist dann der Link zum gentoo-Hack, so der erste das nicht sowieso erklärt):
http://www.linuxquestions.org/questions ... light=p100
http://sidux.com/index.php?name=PNphpBB ... 1833#11833
http://gaugusch.at/kernel
http://gaugusch.at/acpi-dsdt-initrd-pat ... d-add-dsdt
Mit dem Rest bist du alleine, da muss dir evtl. Google weiterhelfen, welche Fehler wie korrigiert werden müssen. Habe ich auch so gemacht.
Ist nicht trivial, aber es geht, und der Ubuntu-Kernel soll ja auch den dsdt-patch haben. Der sidux-Kernel von slh hat ihn definitiv. Ohne den Patch wird deine eigene DSDT nicht gelesen.
Grüße
hubi
flexo3105 - Mar 17, 2007 - 09:41 PM
Post subject:
na jut , da werd ich mich dann wohl mal ranwagen müssen..
vielen dank erstmal und noch ein schönes restwochenende,
gruss
flexo3105 - Mar 19, 2007 - 08:59 PM
Post subject:
moin ,
hab jetzt die 18 errors und 2 warnungen in meiner dsdt repariert, jetzt 0 errors und 1 warnung , habe das ganze "eingebaut" , neueste alsa treiber installiert , aber leider gibts immer noch keinen ton von sich 
schade eigentlich ....erkannt wird das ganze schon, hab in der alsa conf auch schon
diverse sachen bei model wie stack3 , toshiba, ref usw usw ausprobiert ,
so langsam weiss ich nicht mehr weiter ...
gruss
edit:
liegt es evtl an meinem kernel ? (2.6-17.11), der sollte doch diesen dsdt patch
schon haben
xwutz - Apr 06, 2007 - 11:19 AM
Post subject:
hubi,
gibt es eigentlich nomal was zu den PCI-Fehlermeldungen?
weil die bei mir auch da sind.
Code:
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
PCI: Cannot allocate resource region 7 of bridge 0000:00:1c.0
PCI: Cannot allocate resource region 8 of bridge 0000:00:1c.0
PCI: Cannot allocate resource region 9 of bridge 0000:00:1c.0
PCI: Cannot allocate resource region 7 of bridge 0000:00:1c.1
PCI: Cannot allocate resource region 8 of bridge 0000:00:1c.1
PCI: Cannot allocate resource region 9 of bridge 0000:00:1c.1
PCI: Cannot allocate resource region 7 of bridge 0000:00:1c.2
PCI: Cannot allocate resource region 8 of bridge 0000:00:1c.2
PCI: Cannot allocate resource region 9 of bridge 0000:00:1c.2
NET: Registered protocol family 8
NET: Registered protocol family 20
hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
hpet0: 3 64-bit timers, 14318180 Hz
PCI-GART: No AMD northbridge found.
PCI: Failed to allocate mem resource #6:20000@d0000000 for 0000:01:00.0
PCI: Bridge: 0000:00:01.0
IO window: 2000-2fff
MEM window: d0000000-d1ffffff
PREFETCH window: c0000000-cfffffff
PCI: Bridge: 0000:00:1c.0
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.1
IO window: disabled.
MEM window: 8c000000-8c0fffff
PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.2
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bus 11, cardbus bridge: 0000:0a:04.0
IO window: 00003400-000034ff
IO window: 00003800-000038ff
PREFETCH window: 88000000-8bffffff
MEM window: 90000000-93ffffff
PCI: Bridge: 0000:00:1e.0
IO window: 3000-3fff
MEM window: d2000000-d20fffff
PREFETCH window: 88000000-8bffffff
ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:01.0 to 64
ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:1c.0 to 64
PCI: Enabling device 0000:00:1c.1 (0000 -> 0002)
ACPI: PCI Interrupt 0000:00:1c.1[B] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1c.1 to 64
ACPI: PCI Interrupt 0000:00:1c.2[C] -> GSI 18 (level, low) -> IRQ 18
PCI: Setting latency timer of device 0000:00:1c.2 to 64
PCI: Enabling device 0000:00:1e.0 (0004 -> 0007)
PCI: Setting latency timer of device 0000:00:1e.0 to 64
PCI: Enabling device 0000:0a:04.0 (0000 -> 0003)
ACPI: PCI Interrupt 0000:0a:04.0[A] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:0a:04.0 to 64
NET: Registered protocol family 2
IP route cache hash table entries: 65536 (order: 7, 524288 bytes)
MfG xwutz
hubi - Apr 06, 2007 - 11:33 AM
Post subject:
xwutz,
sind bei mir auch noch da, aber ich habe das nicht mehr weiter verfolgt, da die Soundkarte nun angesprochen werden kann, und die Bridge-Fehler beziehen sich eindeutig auf die Soundkarte, wenn du lspci checkst.
hubi
jansralf - Jul 11, 2008 - 06:59 PM
Post subject: kein sound mit kernel 2.6.25.10
Hallo habe die verschiedenen links hier alle gecheckt (Toshiba P100-313), und mir nach der Anleitung eine DSDT.aml gebaut und mit dem Script an die initramfs gehängt.
Leider gehts immer noch nicht. Nach dmesg | grep DSDT bekomme ich:
ACPI: DSDT 3FE94BD7, 6249 (r1 TOSQCI Denver 6040000 MSFT 3000000)
ACPI: Checking initramfs for custom DSDT
ACPI: Found DSDT in DSDT.aml.
ACPI: Override [DSDT- Denver], this is unsafe: tainting kernel
ACPI: Table DSDT replaced by host OS
ACPI: DSDT 00000000, 5A11 (r1 TOSQCI Denver 6040000 INTL 20061109)
ACPI: DSDT override uses original SSDTs unless "acpi_no_auto_ssdt"CPU0: Intel Genuine Intel(R) CPU T2250 @ 1.73GHz stepping 08
ACPI: EC: Look up EC in DSDT
---------------------------------------------
Heißt das jetzt, dass die DSDT geladen wurde oder eben nicht weil das den Kernel beschmutzt????
Habe mir auch den Alsa 1.0.17rc3 gebaut. Fehler. Alle Soundanwendungen tuen so als ob sie Sound ausgeben könnten.
Bitte um Hilfe/ kurze Info.
Danke
jansralf
hubi - Jul 12, 2008 - 11:43 PM
Post subject: kein sound mit kernel 2.6.25.10
Kernel tainting ist eine Warnung. Ich denke, das ist nach der Diskussion unter den Kernel-Entwicklern geschehen, ob der dsdt-Patch in den Kernel-Tree kommen soll oder nicht, geschehen. Dies ist abgelehnt worden, auch Linux Torvalds war dagegen. Egal, die meisten Distributionen, so auch sidux, patchen.
Das Witzige bei meinem Toshiba-Laptop war/ist, dass der ungepatchte Standard-Debian-Kernel ohne eigene DSDT.aml Sound gab und gibt. Ich probier das bei jeder neuen Kernel-Serie mal aus Neugierde aus, also auch der Standard-Debian-Sid-Kernel 2.6.25-* gibt mir Sound. Ansonsten funzt der sidux-Kernel mit Patch und eigener DSDT.aml perfekt und ich habe mir schon lange keine dmesg mehr angeschaut.
Falls du mit dem sidux-Kernel nicht hinkommst, probier einfach mal den normalen Debian-Kernel. Wenn du nicht auf ein sidux-Kernel-Modul angewiesen bist, dürfte dabei nicht viel schief gehen.
hubi
jansralf - Jul 16, 2008 - 05:38 PM
Post subject: Re: kein sound mit kernel 2.6.25.10
Hallo Hubi,
danke für den Tipp. den Debian Kernel hatte ich auch schon ausprobiert, stand ja irgendwo hier im Forum. Meine selbsgebastelte DSDT.aml wird also geladen, schade ich hätte gehofft du siehst da einen Fehler.
Heute wurde Alsa 1.0.17 freigegeben, der Changelog sah für mich leider nicht so vielversprechend aus.
Ich probier irgendwann noch einen älteren Kernel. Ansonsten warte ich einfach noch ein bischen mit Linux auf diesem Rechner.
Danke
Ralf
hubi - Jul 16, 2008 - 05:44 PM
Post subject: Re: kein sound mit kernel 2.6.25.10
jansralf wrote:
Meine selbsgebastelte DSDT.aml wird also geladen, schade ich hätte gehofft du siehst da einen Fehler.
Nö, die wird geladen:
Code:
ACPI: Table DSDT replaced by host OS
Das Tainting ist nur ein Hinweis der Kernelentwickler und ein zusätzliches Indiz, dass die DSDT.aml geladen wurde.
Mehr Ideen habe ich nun nicht mehr. Außer dass es vielleicht nicht an der Stromversorgung liegt und du mit 2.6.26 mehr Glück hast. Auf meinem Toshiba gab es auch mal eine Kernel-Serie (2.6.23?), die null Sound produziert hat (weder der sidux-Kernel mit der eigenen DSDT noch der Debian-Kernel ohne).
hubi
jansralf - Aug 06, 2008 - 05:39 PM
Post subject: RE: Re: kein sound mit kernel 2.6.25.10
Hallo Hubi,
mit neustem Kernel und frischem BIOS Upate geht der Sound jetzt auch bei mir. Sogar ohne DSDT.
Danke nochmal.