Diskussion:Peripheral Component Interconnect
Ich mach dann noch die Status-, Command- und Base-Address-Register fertig. Ich prüfe noch ab welcher Version Hypertransport und PCI-X 4096 Bytes Config-Space unterstützen (das wurde dort erst implementiert nachdem PCI-Express fertig war). Ich würde an ein paar Stellen noch auf spezifische Unterschiede der PCI-Nachfolger gegenüber dem Original eingehen. Gibt es noch sonst irgendwelche Wünsche? --Erik.vikinger 14:18, 28. Feb. 2010 (CET)
- Wie detailliert sollen eigentlich die PCI-Nachfolger erklärt werden? Mit Hypertransport kommt das OS, dem BIOS sei dank, kaum in Berührung. PCI-X dürfte in kaum einem Privat-PC zu finden sein und AGP stirbt schneller aus als es gekommen ist. Ich denke wirklich interessant sind vor allem der klassische PCI und der überragende PCI-Express. --Erik.vikinger 21:07, 3. Mär. 2010 (CET)
TODO : Im Abschnitt "Zugriff auf den Konfigurations-Adressraum" müssen noch die einzelnen Möglichkeiten aufgezählt und erklärt werden. Für die 4096 Bytes großen Bereiche gibt es neue Zugriffsmethoden. Das suche ich mal bei Gelegenheit zusammen. --Erik.vikinger 23:56, 28. Feb. 2010 (CET)
Welche Capabilities sollten eigentlich alle beschrieben werden? Bitte macht Euch da mal Gedanken und äußert Wünsche. Ich denke PCI-Express -Controll-irgendwas könnte wichtig sein weil man das in modernen und zukünftigen PCs sehr häufig antrifft. MSI(-X) ist zwar interessant, vor allem wenn man IRQ-Sharing vermeiden möchte, wird aber auf PCs üblicherweise (leider) nicht benutzt. PCI-Power-Management ist wohl für die meisten Hobby-OSe uninteressant (gut für mich davon hab ich nämlich (noch) keine Ahnung). --Erik.vikinger 10:15, 1. Mär. 2010 (CET)
TODO : Es müssen noch ein paar Begriffe (wie z.B. Master und Target) erläutert werden. Die werden in der Spec und vielen anderen Texten so benutzt und sollten auch hier verwendet werden. --Erik.vikinger 18:26, 1. Mär. 2010 (CET)
TODO : Nachprüfen ob das 66 MHz Capable Bit wirklich bei allen PCI-Nachfolgern ungültig ist. --Erik.vikinger 18:38, 1. Mär. 2010 (CET)
TODO : Etwas über Bridges und das PCI-Interrupt-Routing schreiben. --Erik.vikinger 17:27, 3. Mär. 2010 (CET)
- Außerdem sollte was über die Topologie, also Bus vs. Point-to-Point, geschrieben werden. --Erik.vikinger 21:07, 3. Mär. 2010 (CET)
Wie interessant ist das Thema Power-Management wirklich? Ich lese mich an der Stelle gerne etwas tiefer in die Spezifikationen ein, werde ich wohl früher oder später eh machen müssen. Also wenn das wirklich von Interesse ist dann schreibe ich dazu auch gerne mal einen Abschnitt. --Erik.vikinger 20:44, 3. Mär. 2010 (CET)
Beispielcode
Der Beispielcode ist [strike]scheinbar[/strike] Fehlerhaft. --Programm Noob 19:36, 22. Jul. 2010 (CEST)
- Wenns nur scheinbar ist, ist ja alles in Ordnung. Spaß beiseite: Ich habe ihn mir jetzt nicht angesehen, aber du könntest ihn dann ja korrigieren, wenn du aber nicht sicher bist, wie es richtig geht, dann sag uns, was falsch ist, oder wenn dir da auch nicht so sicher bist, dann sag uns wenigstens, woran du siehst, dass er falsch ist. —Clici McXan 20:16, 22. Jul. 2010 (CEST)
- Ich melde mich mal, weil ich dazu geraten habe, das hier zu melden: Die Meldung "FEHLER : 32Bit-Memory-BAR %u enthält keine beschreibbaren Adressbits!\n" kommt bei 5 von 6 Geräten an seinem PC. Das liegt den if-Abfragen, die auf sehr komische Bedingungen testen, wie zum Beispiel: (get_number_of_highest_set_bit(barValue) != 31) || (lowestBit > 31) || (lowestBit < 4). Die erste Alternative kann ich nicht mit der Spec in Einklang bringen, und sollte so wie ich das sehe immer wahr sein. Die zweite ist vermutlich auch immer Wahr, außer wenn barValue = 0x80000000, aber dann ist die erste Alternative wahr. Und die dritte Alternative ist immer false. Ich denke mal der Code wurde nie getestet, und vermutlich nicht mal dafür gedacht ausgeführt zu werden. --Jidder 20:35, 22. Jul. 2010 (CEST)
- Diese Meldung basiert aber nicht auf der if-Abfrage, wobei ich auch nicht erklären kann, wieso die immer kommt… Die Abfrage selbst hingegen sehe ich nicht als falsch an, das höchste Bit muss immer gesetzt sein (es wurde ja 0xFFFFFFF0 reingeschrieben, wäre das höchste Bit nicht gesetzt, dann müsste der Bereich ja 4 GB groß sein (was bei 32 Bit merkwürdig wäre), soweit ich das sehe), das niedrigste Bit sollte eben spätestens 0x80000000 sein (gut, erübrigt sich durch die erste Abfrage) und die dritte sorgt dafür, dass es ein gültiges Speicher-BAR ist (die unteren vier Bit dürfen nicht beschreibbar sein, afaik). Ich probiere den Code mal selbst aus (wie auch immer) und sehe dann weiter. —Clici McXan 22:25, 22. Jul. 2010 (CEST)
- Ich habe den Code auch mal unverändert getestet und da ließ er sich nichteinmal kompilieren. Es gibt immer die Meldung von GCC pci.c:158: error: invalid operands to binary + (have 'pci_bdf_t' and 'int') Das ist hier die Zeile 119 "const uint32_t barHighValue = pci_config_readd(addr+4,barOffset); // und wieder zurücklesen" --Programm Noob 22:36, 22. Jul. 2010 (CEST)
- Das mit dem höchsten Bit sehe ich ein. Aber die zweite Alternative führt eben genau dann zur Fehlermeldung, weil das unterste Bit nicht 0x80000000 (also lowestBit > 31) ist. --Jidder 22:42, 22. Jul. 2010 (CEST)
- Wenn das unterste Bit über 31 ist (also mehr als 4 GB), dann läuft was schief. Insofern finde ich diesen Test vollkommen in Ordnung (bei 64 Bit könnte man nochmal drüber nachdenken). —Clici McXan 22:50, 22. Jul. 2010 (CEST)
- Ich stimme dir zu, dass wenn das unterste Bit über 31 ist, was schief läuft. Aber nochmal ein kurzer Realtitätsabgleich: Im Code steht, dass was schiefläuft wenn das unterste Bit unter 31 ist. Oder hab ich einen Knick in der Optik? --Jidder 22:55, 22. Jul. 2010 (CEST)
- if (… || (lowestBit > 31) || …) { … return } – sieht für mich so aus, als würde es abbrechen, wenn das unterste Bit über 31 ist… —Clici McXan 23:50, 22. Jul. 2010 (CEST)
- lol ... hast Recht. Ich hab da wirklich mehrmals auf das > geguckt, und es für ein Kleinerzeichen gehalten. Das hätte aber auch mal jemand dranschreiben können ... --Jidder 00:23, 23. Jul. 2010 (CEST)
- if (… || (lowestBit > 31) || …) { … return } – sieht für mich so aus, als würde es abbrechen, wenn das unterste Bit über 31 ist… —Clici McXan 23:50, 22. Jul. 2010 (CEST)
- Ich stimme dir zu, dass wenn das unterste Bit über 31 ist, was schief läuft. Aber nochmal ein kurzer Realtitätsabgleich: Im Code steht, dass was schiefläuft wenn das unterste Bit unter 31 ist. Oder hab ich einen Knick in der Optik? --Jidder 22:55, 22. Jul. 2010 (CEST)
- Wenn das unterste Bit über 31 ist (also mehr als 4 GB), dann läuft was schief. Insofern finde ich diesen Test vollkommen in Ordnung (bei 64 Bit könnte man nochmal drüber nachdenken). —Clici McXan 22:50, 22. Jul. 2010 (CEST)
- Ich habe es jetzt in qemu getestet (echte Hardware geht gerade nicht), sieht funktionierend aus. Kompiliert mit -Wall -Wextra -pedantic -std=gnu99. Wobei das offensichtlich ein Fehler da ist, das +4 muss wohl eher ans barOffset (und die Aussage „das war der Test, ob ihr auch alle aufpasst“ wäre gar nicht so falsch ^^). —Clici McXan 22:48, 22. Jul. 2010 (CEST)
- Diese Meldung basiert aber nicht auf der if-Abfrage, wobei ich auch nicht erklären kann, wieso die immer kommt… Die Abfrage selbst hingegen sehe ich nicht als falsch an, das höchste Bit muss immer gesetzt sein (es wurde ja 0xFFFFFFF0 reingeschrieben, wäre das höchste Bit nicht gesetzt, dann müsste der Bereich ja 4 GB groß sein (was bei 32 Bit merkwürdig wäre), soweit ich das sehe), das niedrigste Bit sollte eben spätestens 0x80000000 sein (gut, erübrigt sich durch die erste Abfrage) und die dritte sorgt dafür, dass es ein gültiges Speicher-BAR ist (die unteren vier Bit dürfen nicht beschreibbar sein, afaik). Ich probiere den Code mal selbst aus (wie auch immer) und sehe dann weiter. —Clici McXan 22:25, 22. Jul. 2010 (CEST)
- Ich melde mich mal, weil ich dazu geraten habe, das hier zu melden: Die Meldung "FEHLER : 32Bit-Memory-BAR %u enthält keine beschreibbaren Adressbits!\n" kommt bei 5 von 6 Geräten an seinem PC. Das liegt den if-Abfragen, die auf sehr komische Bedingungen testen, wie zum Beispiel: (get_number_of_highest_set_bit(barValue) != 31) || (lowestBit > 31) || (lowestBit < 4). Die erste Alternative kann ich nicht mit der Spec in Einklang bringen, und sollte so wie ich das sehe immer wahr sein. Die zweite ist vermutlich auch immer Wahr, außer wenn barValue = 0x80000000, aber dann ist die erste Alternative wahr. Und die dritte Alternative ist immer false. Ich denke mal der Code wurde nie getestet, und vermutlich nicht mal dafür gedacht ausgeführt zu werden. --Jidder 20:35, 22. Jul. 2010 (CEST)
Allgemein was zu dem Code: Was soll der hier? Mit den ganzen Fehlermeldungen sieht das danach aus, als würde da ein Test der Hardware auf Funktionsfähigkeit durchgeführt werden. Solche Dinge gehören meiner Meinung nach nicht an diesen Platz, der Artikel ist eh schon ziemlich geschwätzig. --Jidder 22:55, 22. Jul. 2010 (CEST)
- Du kennst die PCI-Spec? Wenn man PCI ordentlich benutzen möchte gibt es da eine ganze Menge zu beachten, das die meisten hier sich nicht dafür interessieren liegt schlicht daran das auf einem normalen PC das BIOS sich um all das kümmert und gute Boot-Loader dem OS nur noch ne simple Liste mit den (vom BIOS) zugewiesenen Ressourcen präsentieren. Ich habe nichts dagegen wenn der Artikel (der wirklich schon recht umfangreich ist obwohl so wichtige Dinge wie Bridges noch gar nicht richtig erklärt werden) in zwei Teile gesplittet wird. Einmal eine Kurzfassung für diejenigen die dem BIOS bzw. Boot-Loader vertrauen und einmal eine Langfassung für all jene die die Möglichkeiten des PCI wirklich nutzen wollen oder gar selber enumerieren wollen/müssen. Wenn der Code zu umfangreich ist habe ich nichts dagegen wenn er gekürzt wird. --Erik.vikinger 15:21, 23. Jul. 2010 (CEST)
Der große Beispielcode ist von mir und wurde bei mir tatsächlich weder kompiliert noch getestet (das habe ich damals im IRC auch deutlich gesagt und um Tests gebeten), ich habe den Buchstabengetreu nach der PCI-Spec geschrieben. Das der so gründlich testet liegt daran das ich schon oft PCI-Devices gesehen hab die sich nicht ganz an die Spec halten, falls das wirklich zu einem Problem wird dann versuche ich das ganze etwas zu entschärfen. Ich wollte das der Code alle Möglichkeiten gründlich abtestet. Wenn die Meldung "FEHLER : 32Bit-Memory-BAR %u enthält keine beschreibbaren Adressbits!\n" kommt dann bedeutet dass das in einem unbenutztem BAR das prefetchable-Bit gesetzt ist und das darf eigentlich nicht sein ist aber auch kein so schwerwiegender Fehler (@Jidder: schick mir doch mal die eine passende lspci-Aufgabe von den betreffenden Geräten dann schau ich mal wie ich den Code am geschicktesten verbessere). Wenn gewünscht mache ich daraus ein Warning ;) . Die +4 war tatsächlich an der falschen Stelle, sorry. Das die 'while( ( value & mask ) != 0 )' gegen 'while (!(value & mask))' ausgetauscht wurden finde ich persönlich nicht besonders gut, ich bevorzuge es nur auf Dinge zu testen die eindeutig TRUE oder FALSE ergeben. --Erik.vikinger 10:19, 23. Jul. 2010 (CEST)
- „!x“ entspricht imho exakt „x == 0“ (das != war da eher nicht angebracht, soweit ich das erkennen kann)… —Clici McXan 13:56, 23. Jul. 2010 (CEST)
- Bei '(value & mask)' kommt aber ein uint32_t raus (weil beide Werte eben diesen Types sind) und damit kein Boolean, bei mir meckert der gcc soetwas normalerweise an. --Erik.vikinger 15:21, 23. Jul. 2010 (CEST)
- g++ vielleicht, aber gcc eher nicht. Wie gesagt, ich habe es mit -Wall -Wextra -pedantic -std=gnu99 kompiliert (c99 wird wohl auch gehen), und es kam keine Warnung. —Clici McXan 16:21, 23. Jul. 2010 (CEST)
- Okay, ist ein berechtigter Einwand. Ich benutze eigentlich immer C++ und bevorzuge daher Tests auf eindeutige Boolean-Werte, auch wenn ich weiss das die C-Spec da etwas relaxter ist. Wenn die Leute hier im Wiki das so wie es jetzt ist haben wollen dann stehe ich dem nicht im Weg. Insgesamt betrachte ich Deine Aussage (insbesondere mit -pedantic) als Kompliment an meine Fähigkeit aus dem Stand heraus ein (fast) fehlerfreies Programm abzuliefern ;) . --Erik.vikinger 17:40, 23. Jul. 2010 (CEST)
- g++ vielleicht, aber gcc eher nicht. Wie gesagt, ich habe es mit -Wall -Wextra -pedantic -std=gnu99 kompiliert (c99 wird wohl auch gehen), und es kam keine Warnung. —Clici McXan 16:21, 23. Jul. 2010 (CEST)
- Bei '(value & mask)' kommt aber ein uint32_t raus (weil beide Werte eben diesen Types sind) und damit kein Boolean, bei mir meckert der gcc soetwas normalerweise an. --Erik.vikinger 15:21, 23. Jul. 2010 (CEST)
- Ich kann dir keine Ausgabe von lspci geben, weil nicht ich diese Meldungen hatte. --Jidder 16:42, 23. Jul. 2010 (CEST)
- Sorry ich hab das "seinem" als "meinem" gelesen, ich werde eben doch langsam alt. Dann die selbe Bitte an Programm Noob. --Erik.vikinger 17:40, 23. Jul. 2010 (CEST)
- lspci ist ein Linux Befehl? Geht der auch von einer Live-CD? Mache ich natürlich gerne. --Programm Noob 22:38, 23. Jul. 2010 (CEST)
- Ja und Ja, das wäre sehr nett. Die Ausgabe von "lspci -vv -x" wäre mir am liebsten. Eventuell muss noch ein "sudo" davor. Bei akuten Fragen zur Linux-Konsole können Dir sicher fast alle im IRC helfen. --Erik.vikinger 08:47, 24. Jul. 2010 (CEST)
- lspci ist ein Linux Befehl? Geht der auch von einer Live-CD? Mache ich natürlich gerne. --Programm Noob 22:38, 23. Jul. 2010 (CEST)
- Sorry ich hab das "seinem" als "meinem" gelesen, ich werde eben doch langsam alt. Dann die selbe Bitte an Programm Noob. --Erik.vikinger 17:40, 23. Jul. 2010 (CEST)