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)
- 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 ...
- 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)
