phy_readDie Methode in /include/linux/phy.h gibt einen 32-Bit-Wert zurück. PHY-Treiber verwenden diese Methode zum Lesen von 16-Bit-MII-Registern. Die phy_readMethode gibt einen 32-Bit-Wert zurück. Das Speichern eines 16-Bit-Werts in einem 32-Bit-Feld macht aus 0xFFFF 0x0000FFFF. In einem 16-Bit-Feld wäre das als -1 (Fehler) betrachtet und auch so behandelt worden, aber das Speichern in 32 Bit macht es zu einem großen positiven Wert statt zu einem Fehler. Dies ändert den Verlauf der Treiberausführung und ändert die Verbindungsparameter auf unerwünschte Weise.
Ich habe dies für genphy_read_statusMethoden beobachtet, bei denen der von phy_readis und int(4 Bytes) zurückgegebene Wert jedoch 0xFFFF enthält, falls Verwaltungszeilen entfernt werden oder ein Fehler auftritt. Da der zurückgegebene Wert 4 Bytes groß ist, schlagen alle Prüfungen, ob er kleiner als null ist, fehl. In einem solchen Szenario werden Verbindungsgeschwindigkeit und Duplizität auf die maximal mögliche Geschwindigkeit (d. h. 1000 Mbit/s) geändert, auch wenn dies nicht möglich ist.
Wie geht also der PHY-Treiber mit einer solchen Situation um? Ist es normal, dass Link seine Konfiguration auf diese Weise ändert, wenn ein solcher Hardwarefehler auftritt? Das Ändern der Lesegröße von int auf u16 könnte das Problem lösen, warum wird das also nicht gemacht?
Alle diese Probleme wurden im Linux-Kernel 3.8.13 beobachtet. Die neueste Linux-Quelle scheint ähnlich zu sein, obwohl ich die Fehlersituation darauf nicht getestet habe.