Nondeterministic AR7xxx-bug (issues/669)

Fortsetzung der Diskussion von TP-Link 841 v8 und v9 OpenWRT Bug:

Da es sich weder um einen Nanostation-, noch um einen TP-Link bug handelt, antworte ich mal in einem neuen Thread, um nicht unter falscher Flagge zu posten:

Ja, ich stimme Dir zu. Da haben die Leute bei OpenWRT offensichtlich ihre Hausaufgaben nicht gemacht.
Oder aber wir als Freifunk müssen feststellen, welche treibende Rolle wir inzwischen einnehmen.
Zumal wir eben Mass-Deployment und Remote-Upgrade im richtig großen Stil fahren und daher Fehler rein statistisch abgesichert zumindest benennen können, wenn sie auch nur bei 1% aller sysupgrades auftreten.

1 „Gefällt mir“

NationalSemiconductors16550AFN vs NS8250 ist aber nun wirklich „blast from the past“.
Ich hätte nicht geglaubt, ein 16Byte-Fifo-Racecondition jemals wieder erleben zu dürfen. Für einen Baustein der 1990 schon etabliert war…

Raymond L. Gwinn schrieb zu seinem Leiden mit dieser Chipfamilie 1990:
"It has reached a point that I anything I touch will break something. "

1 „Gefällt mir“

Etwa DER 16550, der damals als DIE technische Errungenschaft bei der Verbindung schneller Modems gefeiert wurde? Das ist nun wirklich gefühlt in der Kreidezeit gewesen. Was hab ich mich seitdem gedanklich von diesen Dingen entfernt…

2 „Gefällt mir“

@pharmajoe Ja, genau der SIO.
Allem Anschein nach besteht die Möglichkeit, dass ein QC/AR7k-Node beim Booten noch nicht alle Bytes des Bootloaders aus dem FiFo geschoben hat (auf die physikalische Onboard-RS232) wenn das Openwrt mit der Autoconfig-Magie beginnt, um den genauen Chiptyp zu ermitteln.
Dann kann es zum Freeze kommen.