Wir brauchen aber erst einmal "replace kernel"
Was genau verhindert das? Die Quellen für die 7590 sind doch verfügbar ...
Meines Erachtens sollte man stattdessen aber ohnehin erkunden, wie da ein "sk_buff" ohne passenden Socket (also ohne "Besitzer") auftauchen kann, als "so empfangen" (ja, in welchem Kontext denn bitte?) ... das ganze Recycling von "sk_buff"-Strukturen ist ja auch eine Lantiq-Spezialität (FAST_SKB und SKB_RECYCLE), die AVM m.E. gar nicht nutzt und da wäre für mich dann doch wieder die Frage, warum vom "tun"-Device eine solche Struktur ohne "sk"-Member überhaupt übergeben wird oder ob die nicht bei irgendeinem PA-Hook in der weiteren Verarbeitung einfach nur falsch interpretiert wurde (die werden ja teilweise auch rein zum Zählen von Paketen aufgerufen) und als "beschleunigt, damit bereits erledigt" abgehakt wird, woraufhin dann der Buffer fälschlicherweise "orphaned" wird und hier aber trotzdem weiterhin in den Mühlen der Verarbeitung verbleibt.
Ansonsten wird in "tun.c" ein solcher "sk_buff" ja nur dann "orphaned" (und zwar absichtlich), wenn er erfolgreich
gesendet wurde und da wäre dann die Frage, wie der es wieder in irgendeine Receive-Queue geschafft haben soll mit seinem Socket == NULL.
Was man mal testen könnte (zur Eingrenzung des Fehlers), wäre die Reaktion des Systems mit unterschiedlichen Stufen der Paket-Beschleunigung ... bei den neuen Versionen ist die ja über die Support-Seite zu steuern. Tritt das Problem dann nicht auf, liegt es vermutlich wirklich an irgendeinem der AVM-Hooks, die da alle mit "avm_pa_irgendwas" beginnen.
Wenn das dann doch keinen Hinweis liefert, bräuchte man mal einen echten Stack-Trace und vielleicht noch ein paar printk-Erweiterungen vor diesem "BUG_ON", damit man z.B. einen Hex-Dump des "sk_buff" mal sieht und erkennen kann, woher der kommt (AVM packt ja zusätzlich noch das Source-Device in den Header) und wohin er eigentlich gehen sollte ... dann kann man auch besser verfolgen (in Kombination mit dem Stack-Trace), wo hier der eigentliche Fehler liegt.
Was nutzt es einem, wenn man die "BUG_ON"s von AVM wieder entfernt und dann stürzt es irgendwo dahinter ab, weil "sk_buff->sk" der Pointer auf die "sock"-Struktur sein soll (und nicht noch einmal geprüft wird, z.B. bei irgendwelchen Konstrukten, die dann über mehrfache Pointer-Referenzen auf "sock"-Member zugreifen wollen - ein "grep" mit "->sk->" über die Sourcen zeigt schnell, daß es solche Stellen gibt - auch wenn natürlich damit nicht auf den ersten Blick geklärt ist, ob da nicht noch eine Abfrage davor erfolgt ist) und es aber nicht ist ... so ganz aus Jux und Tollerei wird AVM das da vorne nicht eingebaut haben, immerhin kann man dann anhand des Stack-Traces noch sehen, wie dieser "sk_buff" seinen Weg zu der Stelle fand.
