Erstellt vor 6 Jahren

Zuletzt geändert vor 5 Jahren

#2003 reopened defect

Badness in local_bh_enable at kernel/softirq.c:149

Erstellt von: SilentBob Verantwortlicher:
Priorität: normal Meilenstein: freetz-future
Komponente: kernel Version: devel
Stichworte: Beobachter:
Product Id: 7170 Firmware Version:

Beschreibung

Problem ist ein Image aus dem aktuellen Trunk für eine 7170 mit "replace-kernel". Sobald das Image mit aktivierten "Replace Kernel" übersetzt wird, kommt es selbst bei geringem Traffik zum Volllaufen des Logs mit der Fehlermeldung:

user.warn kernel: Badness in local_bh_enable at kernel/softirq.c:149
user.warn kernel: Call Trace: [<c00e12c4>] [<9402aca0>]  [<94129448>]  [<941292dc>]  [<940b6520>]  [<940b6520>]  [<c03e6b4c>]  [<c04393c0>]  [<c03e7494>]  [<c03f9598>]  [<c03f54b4>]  [<c00d97ac>]  [<9402b048>]  [<9402ab3c>]  [<9402ab3c>]  [<940

Nach einiger Zeit startet die Box dann neu. Manchmal einige Sekunden nach dem Auftreten der Meldung. Das wiederholt sich dann nach dem Neustart, die Box ist quasi nicht zu benutzen. Je mehr Traffik, desto mehr Fehlermeldungen. Wenn die Box idle ist, treten keine Meldungen auf. Gelegentlich finden sich die Meldungen auch schon direkt nach dem Neustart im Log.

Ich habe jetzt alle möglichen Konfigurationen durch und kann das mit einem frisch aufsetzten Trunk in den default Einstellungen sicher reproduzieren. Sobald ich im menuconfig "replace kernel" auswähle, kommt es zu dem geschilderten Verhalten.

Fazit: Ein mit "replace kernel" übersetzte Image funktioniert auf einer 7170 nicht.

Die selbe Konfiguration, nur ohne "Replace Kernel" läuft zuverlässig. Nur dann eben auch ganz ohne IPv6. Bei einem Image aus "stable-1.2" mit aktivierten "Kernel Replace" tritt dieser Fehler nicht auf. (Ich benötige aber leider den neueren Dnsmasq mit seinen ipv6 Fähigkeiten)

Einen Thread im Forum habe auch schon abgesetzt: http://www.ip-phone-forum.de/showthread.php?t=256175 Evt. findet sich noch jemand mit dem selben Problem.

An dieser Stelle bin ich dann mit meinen Debugger Fähigkeiten auch am Ende und bitte um Hilfe.

Anhänge (3)

180-printk.sh.diff (371 Byte) - hinzugefügt von szepter vor 5 Jahren.
config-7170_04.87_de (56.7 KB) - hinzugefügt von szepter vor 5 Jahren.
9999-disable_local_be_enable_softirq_warning.patch (474 Byte) - hinzugefügt von dneuge vor 5 Jahren.

Alle Anhänge herunterladen als: .zip

Änderungshistorie (51)

comment:1 Antwort: Geändert vor 6 Jahren durch cuma

  • Lösung auf worksforme gesetzt
  • Status von new nach closed geändert

Fazit: Ein mit "replace kernel" übersetzte Image funktioniert auf einer 7170 nicht.

Die selbe Konfiguration, nur ohne "Replace Kernel" läuft zuverlässig. Nur dann eben auch ganz ohne IPv6.

Wenn du nach Badness in local_bh_enable at kernel/softirq.c:149 gesucht hättest, wäre dir aufgefallen dass dies eine "normale" Meldung ist. Abstürze werden vielmehr durch IPv6 verursache. Als ich das noch auf der 7170 hatte lief es

#1724 #260 #1163
—> http://www.ip-phone-forum.de/showthread.php?t=256175

comment:2 als Antwort auf: ↑ 1 Geändert vor 6 Jahren durch SilentBob

Replying to cuma:

Wenn du nach Badness in local_bh_enable at kernel/softirq.c:149 gesucht hättest, wäre dir aufgefallen dass dies eine "normale" Meldung ist. Abstürze werden vielmehr durch IPv6 verursache. Als ich das noch auf der 7170 hatte lief es

Ist aber sehr unschön, wenn das Log innerhalb kürzester Zeit voll läuft und quasi keine anderen Einträge mehr vorhanden sind.
Du hast aber Recht, die Abstürze scheinen tatsächlich nicht damit zusammen zuhängen. Ich habe gerade nochmal ein Image mit replace-kernel, aber ohne ipv6 Modul geflasht. Kann ich den Part in softirq.c gefahrlos auskommentieren? Das macht ja sonst den Syslog quasi sinnbefreit.

Wenn die Abstürze durch IPv6 verursacht werden, soll ich da dann noch weiter testen und mich wieder melden oder lieber dann doch bei stable bleiben und den dnsmasq in der aktuellen Version dort einbauen?

comment:3 Geändert vor 6 Jahren durch cuma

Kann ich den Part in softirq.c gefahrlos auskommentieren? Das macht ja sonst den Syslog quasi sinnbefreit.

Es wurden schon andere nervige Meldungen im Kernel auskommentiert, zb bei den 05.xx die Meldung über eine hohe Last. Einfach Patch anhängen

Wenn die Abstürze durch IPv6 verursacht werden, soll ich da dann noch weiter testen

Ursache könnte deine Konfiguration sein. Mit aiccu & gw6 lief es bei mir auf 71xx Boxen. Auch könnte es einfach Speichermangel sein, oder ein AVM-Watchdog rebootet wegen zu hoher Auslastung. Auch könnte deine Swap Partition/ der USB-Stick kaputt sein. Keine Ahnung…

comment:4 Geändert vor 6 Jahren durch SilentBob

Ich wollte nur noch mal kurz eine Rückmeldung geben:

Nachdem ich gesehen hatte, dass Badness in local_bh_enable at kernel/softirq.c:149 auch bei stable-1.2 auftritt, nur eben nicht ins syslog, sondern nach /dev/debug läuft, habe ich im trunk den patch 180-printk.sk auskommentiert.

Und siehe da, meine 7170 läuft jetzt mit trunk seit 24h, mit ipv6 und unter Last stabil.

Da die 7170 kein DECT besitzt, wäre es vllt. eine gute Idee AVM_PRINTK für diese Box zu benutzen, bzw.
den Patch 180-printk.sk für die 7170 standardmäßig zu deaktivieren?

comment:5 Geändert vor 6 Jahren durch cuma

Bei der 7270 (eine der ersten mit Dect) Firmware 04.8x war die Besonderheit, dass AVM irgendwie die Dect Ausgaben aus dem Log ausgewertet hatte, deshalb ist die in diesem Patch ausgenommen.
Kann es sein dass bei dir Syslog den Ram volllaufen lässt?

comment:6 Geändert vor 6 Jahren durch SilentBob

Mmh, keine Ahnung was da passiert. Ich hatte zwischendurch auch mal auf den USB-Stick geloggt, bzw. auch mal nur in einen (sehr) kleinen Ringspeicher und auch mal das lokale Logging ganz abgeschaltet und nur ins Netzwerk geloggt. Hatte aber am Verhalten nichts geändert. Auch den USB-Stick als Fehlerquelle hatte ich mal weg gelassen.

Also ich vermute auch, dass der Syslog vllt. das Problem verursacht. Immerhin kommen die Meldungen quasi als "Stream", also in ziemlich hoher Frequenz wenn ein Download läuft.

Ich kenne mich ja mit der Hardware nicht aus, aber stelle mir vor, dass es weit weniger Rechenpower braucht, in ein Device (/dev/debug) abzukippen, als einen Dateisystemtreiber zu bitten, doch mal die Logdatei zu bedienen. Von daher kann ich mir gut vorstellen, dass der Syslog o. das Dateisystem hier irgendwann nicht mehr hinterher kommt.

Im Moment bin ich froh, dass es jetzt so läuft. Wie würde ich sowas testen? Ich habe das alte Image ja noch, dann könnte ich bei Gelegenheit mal testen, wenn es hilft.

comment:7 Geändert vor 6 Jahren durch cuma

Der Stream vom Download dürfte wesentlich größer sein als der von Syslog. Ich glaube /dev/debug ist auch ein Ringpuffer und verwirft irgndwann Daten. Ich benutze überall Syslog mit Logging ins Netzwerk, hatte bislang keine Probleme damit (3020 bis 7390)
Wenn du 180-printk.sk drin lässt, aber Syslog ausschaltest, läuft es dann?

comment:8 Geändert vor 6 Jahren durch SilentBob

Also mit Revision 10019. scheint es jetzt zu laufen. Identische Konfiguration, egal ob mit STD_PRINTK oder AVM_PRINTK . Die ursprüngliche Meldung Badness in local_bh_enable at kernel/softirq.c:149 tritt nicht mehr auf, auch nicht in /dev/debug . Irgendeine andere Änderung scheint das Problem gelöst zu haben. Cool!

comment:9 Geändert vor 6 Jahren durch cuma

Das müsste dann aber lokal bei dir gewesen sein :)

comment:10 Geändert vor 6 Jahren durch SilentBob

Strange. Hab nur ein svn up gemacht. Der Patch 180-printk.sh wurde damit wiederhergestellt. Dann nur per make neu gebaut. Naja egal. Läuft und gut. :)

comment:11 Geändert vor 6 Jahren durch SilentBob

Tjo, ich habe nochmal jungfräulich ausgecheckt und habe wieder das "Badness" Problem. Muss wohl doch irgendwas bei mir gewesen sein. Irgendwas wurde wohl nicht neu gebaut. Also alles wieder auf "Anfang". :-( Ich muss wieder den "180-printk.sh" Patch auskommentieren, damit es funktioniert.

Ich würde vorschlagen, bis auf Weiteres bei der 7170 auf den Patch zu verzichten:

isFreetzType 7270_V1 && return 0
isFreetzType 7170 && return 0
[...]

Geht bestimmt auch eleganter… :-)

BTW: Wenn auf der Box die Badness-Meldungen laufen, sind die Ansagetexte und Nachrichten auf dem AB kaum verständlich. Völlig "verstottert" und "abgehackt". Das hört auf, sobald der Traffik und damit die Meldungen stoppen. Alleine das sollte imho schon ein Grund sein, den Patch (vorerst) nicht zu verwenden.

comment:12 Geändert vor 6 Jahren durch cuma

Was steht denn in der Datei um die 149 Zeile?

Zuletzt geändert vor 6 Jahren von cuma (vorher) (Diff)

comment:13 Geändert vor 6 Jahren durch SilentBob

Da geht es wohl um die Behandlung der softirqs:

void local_bh_enable(void)
{
	WARN_ON(irqs_disabled());
	/*
	 * Keep preemption disabled until we are done with
	 * softirq processing:
 	 */
 	sub_preempt_count(SOFTIRQ_OFFSET - 1);

	if (unlikely(!in_interrupt() && local_softirq_pending()))
		do_softirq();

	dec_preempt_count();
	preempt_check_resched();
}
EXPORT_SYMBOL(local_bh_enable);

Das scheint auch Distributions- und Kernelübergreifend im Zusammenhang mit verschiedenen Netzwerkkarten aufzutreten. Zumindest findet man allerhand dazu bei Google. Imho ein tiefergreifendes Kernelproblem.

comment:14 Geändert vor 6 Jahren durch cuma

Ist die WARN_ON Zeile nur für diesen Legeintrag? KOmmentier sie doch mal aus. Ein Patch dafür kann man in make/linux/patches/2.6.13.1/ ablegen. Danach "make kernel-dirclean" und ein "make"

comment:15 Geändert vor 6 Jahren durch ralf

Das löst aber nicht das zugrunde liegende Problem. Es hat sicher einen Grund, dass diese Überprüfung da ist.

comment:16 Geändert vor 5 Jahren durch szepter

Das Verhalten von SilentBob kann ich in dem Maße exakt so nachvollziehen. Die Box bootet in regelmässigen Abständen neu. Ich sehe die Badness-Meldungen ebenfalls im Syslog. Jedoch auch jede Menge mcfw-Einträge…

Wenn ich dann bei laufender FRITZBox ein echo AVM_PRINTK > /dev/debug mache, rebootet die Box nicht mehr neu, sondern verhält sich stabil.

Geändert vor 5 Jahren durch szepter

Geändert vor 5 Jahren durch szepter

comment:17 Geändert vor 5 Jahren durch szepter

  • Lösung worksforme gelöscht
  • Status von closed nach reopened geändert

comment:18 Geändert vor 5 Jahren durch er13

Kann die sporadischen Reboots auf einer 7170 mit replace kernel und sogar ohne IPv6 bestätigen. Habe jedoch noch nicht untersucht, ob es an STD_PRINTK statt AVM_PRINTK liegt.

comment:19 Geändert vor 5 Jahren durch szepter

Bei mir ist IPv6 aktiviert…, habe aber zwei Boxen, auf denen es nicht passiert. Ich hab die Vermutung, dass es mit daran liegt, dass die Box an einer relativ schlechten Leitung zu kämpfen hat…

comment:20 Geändert vor 5 Jahren durch cuma

7141 und 7170 je mit replace kernel rebooten bei mir nicht selbst. vor längerem hatte ich ipv6 aktiviert, jetzt nicht mehr. Evtl einfach RAM voll?

comment:21 Geändert vor 5 Jahren durch szepter

Wie gesagt, das passiert bei mir nur bei einer Box, wenn ich dort auf AVM_PRINTK umschalte, bootet sie nicht neu.

Zwei andere 7170 laufen mit STD_PRINTK und booten nicht neu…

comment:22 Geändert vor 5 Jahren durch cuma

Dann wäre es doch interessant zu wissen was diese irqs auslöst. Mit (schlechter) DSL Leitung könnte durchaus sein, ich hab nämlich kein DSL und keine Reboots

Zuletzt geändert vor 5 Jahren von cuma (vorher) (Diff)

comment:23 Geändert vor 5 Jahren durch szepter

Es könnte m. E. auch vom WLAN her rühren. Die anderen Boxen haben eine stabile DSL-Leitung und das WLAN wird kaum genutzt.

Wie könnte man herausfinden, was diese IRQs verursacht?

comment:24 Geändert vor 5 Jahren durch szepter

Also…

FRITZBox Nr. 1 (welche die Reboots macht):

root@fritz:/var/mod/root# cat /proc/interrupts
           CPU0
  1:    4317623     OHIO System  system timer
  6:    7804865     OHIO System  OHIO primary
  9:          0    OHIO primary  ahci-hcd
 15:       6290    OHIO primary  serial
 23:     675475    OHIO primary  SAR
 27:     577297    OHIO primary  Cpmac Driver
 28:     558050    OHIO primary  ubik2_swirq
 29:     589661    OHIO primary  VLYNQ
 31:    5398092    OHIO primary  DSL
 79:     294831      OHIO vlynq  TNETW1150

ERR:          0

FRITZBox Nr. 2 (keine Reboots):

root@fritz:/var/mod/root# cat /proc/interrupts
           CPU0
  1:    4334063     OHIO System  system timer
  6:    5894569     OHIO System  OHIO primary
  9:          0    OHIO primary  ahci-hcd
 15:       5972    OHIO primary  serial
 23:      22013    OHIO primary  SAR
 27:      22010    OHIO primary  Cpmac Driver
 28:       6169    OHIO primary  ubik2_swirq
 29:     422892    OHIO primary  VLYNQ
 31:    5415513    OHIO primary  DSL
 79:     211445      OHIO vlynq  TNETW1150

ERR:          0

FRITZBox Nr. 3 (auch keine Reboots):

root@fritz:/var/mod/root# cat /proc/interrupts
           CPU0
  1:    4334807     OHIO System  system timer
  6:    5828880     OHIO System  OHIO primary
  9:          0    OHIO primary  ahci-hcd
 15:       5669    OHIO primary  serial
 23:      25981    OHIO primary  SAR
 27:        624    OHIO primary  Cpmac Driver
 28:       6008    OHIO primary  ubik2_swirq
 29:     374111    OHIO primary  VLYNQ
 31:    5416487    OHIO primary  DSL
 79:     187055      OHIO vlynq  TNETW1150

ERR:          0

Offenbar verursacht ubik2_swirq diese IRQs und führt dann in Kombination mit STD_PRINTK irgendwann zum Reboot der Box…

Zuletzt geändert vor 5 Jahren von szepter (vorher) (Diff)

comment:25 Geändert vor 5 Jahren durch cuma

ubik2 macht das Telefon http://www.wehavemorefun.de/fritzbox/Ubik2.ko
wobei ich mit POTS extern und interne keine Probleme hatte

comment:26 Geändert vor 5 Jahren durch szepter

SAR (offenbar Segmentation and Reassembly) erzeugt auch eine Menge IRQs…, was dann auf die DSL-Thematik hindeuten könnte…

POTS scheint auf den Boxen allesamt recht gut zu funktionieren. Auf der ersten Box wird natürlich auch mehr telefoniert, was natürlich dann m. E. auch zu höheren Werten führen dürfte…

comment:27 Geändert vor 5 Jahren durch cuma

  • Meilenstein auf freetz-future gesetzt

comment:28 Geändert vor 5 Jahren durch SilentBob

Ich kann einen direkten Zusammenhang mit der Nutzung von WLAN herstellen/bestätigen. Meine 7170 bootet nicht mehr spontan, wenn ich per Netzwerkkabel angeschlossen bin. (DSL ~8 Mbit/s, Torrents mit Volllast, WLAN eingeschaltet, aber keine Klienten eingebucht = läuft seit >12 Std. stabil.)

comment:29 Geändert vor 5 Jahren durch cuma

Eine 7270 mit Firmware 04.8x bekomme ich auch durch sehr hohe Wlan-Last rebootet

comment:30 Geändert vor 5 Jahren durch szepter

Das könnte in meinem Fall natürlich auch die Ursache sein. Dort wird auch das WLAN sehr viel genutzt, im Gegensatz zu den anderen beiden Boxen.

Wie verhält es sich denn mit den Reboots, wenn ihr auf AVM_PRINTK in dem Fall umschaltet?

Zuletzt geändert vor 5 Jahren von szepter (vorher) (Diff)

comment:31 Geändert vor 5 Jahren durch cuma

Ich hab nun via Lan ein andere Gerät angeschlossen, das den AP macht. Übrigens hat ein Android Handy keine Reboots verursacht, nur ein Laptop

comment:32 Geändert vor 5 Jahren durch szepter

Kannst Du im dmesg irgendwas Eigenartiges erkennen?

comment:33 Geändert vor 5 Jahren durch cuma

Syslog meint bei einer 7270 04.xx während eines Crashes durch starte WLan-Nutzung:

kernel: Oops[#1]:
kernel: Cpu 0
kernel: $ 0   : 00000000 1000ce01 00000001 00000002
kernel: $ 4   : 00000001 976d4dfc 94cd1800 976d4cc8
kernel: $ 8   : 976d4ce8 94cd180c 00000000 00000002
kernel: $12   : 00000001 00000001 2ab6e538 00003c00
kernel: $16   : 94cd1800 976d4cc8 ffffff9f 976d3680
kernel: $20   : 00000001 94cb2a00 00000000 00000000
kernel: $24   : 00000000 c02fa4c4                  
kernel: $28   : 95ec8000 95ecbb38 94cd1800 c0221160
kernel: Hi    : 00000000
kernel: Lo    : 0000002c
kernel: epc   : c021f954 musb_NAK_timer_control+0x5f4/0xffff3ca0 [musb_hdrc]     Tainted: P     
kernel: ra    : c0221160 musb_host_tx+0x6f0/0xffff2590 [musb_hdrc]
kernel: Status: 1000ce02    KERNEL EXL 
kernel: Cause : b0800008
kernel: BadVA : 0000002c
kernel: PrId  : 00019068
kernel: Modules linked in: fuse autofs4 wlan_scan_ap wlan_acl wlan_wep wlan_tkip wlan_ccmp wlan_xauth ath_pci ath_rate_atheros(P) wlan ath_dfs(P) ath_hal(P) avm_ath_extensions(P) musb_hdrc usbcore dect_io(P) avm_dect(P) capi_codec(P) i

comment:34 Geändert vor 5 Jahren durch SilentBob

Ich habe eine (vllt.) interessante Beobachtung gemacht. Alles mehrfach mit dem selben Ergebnis wiederholt.

1) rsync von ~6GB (DSL → Box → WLAN-Klient) = häufige Reboots.

2) rsync von ~6GB (DSL→ Box→ USB-Stick) = keine Reboots. (!)

3) rsync von ~6GB (USB-Stick → Box → WLAN-Klient) = keine Reboots. (!)

Die letzten Beiden kann ich praktisch beliebig oft und lange wiederholen, bei voller
Auslastung des DSL Anschlusses, bzw. beim Letzten, der WLAN Bandbreite.
Es ist mir nicht möglich einen Reboot zu provozieren.

Sobald ich aber aus dem internen Netz von Extern "rsync'e" knallt nach ein paar hundert MB wieder.

comment:35 Geändert vor 5 Jahren durch SilentBob

Was hat es für eine Bewandtnis, dass die 7170 wieder aus 180-printk.sh raus geflogen ist? Soll das jetzt so funktionieren?

comment:36 Geändert vor 5 Jahren durch cuma

Die 7170 wurde entfernt? Hier im Ticket ist kein Commit zu sehen

comment:37 Geändert vor 5 Jahren durch SilentBob

Sorry, stimmt. Mein Fehler. Tschuldigung.

comment:38 Geändert vor 5 Jahren durch cuma

Hattest du die Box aus printk bei dir lokal herausgenommen? Gab es damit keine Problem mehr?

comment:39 Geändert vor 5 Jahren durch SilentBob

Nee, funktioniert nicht. Wenn ich den printk patch anwende, ist meine 7170 quasi unbenutzbar. Also alles wie gehabt. :-/

Geändert vor 5 Jahren durch dneuge

comment:40 Geändert vor 5 Jahren durch dneuge

Hab das gleiche Problem gehabt und scheinbar in den Griff bekommen. Erstmal was da passieren sollte:

  • local_bh_enable soll die Verarbeitung von Soft-IRQs fortsetzen
  • Die Zeile WARN_ON(irqs_disabled()); in kernel/softirq.c:149 (Funktion local_bh_enable) macht folgendes:
    • irqs_disabled prüft nicht einfach nur CPU-Flags ab sondern setzt diese tatsächlich (und vergleicht sie anschließend). Das schlägt wohl fehl; der Assembler-Code scheint nicht auf den in der FBF 7170 verbauten MIPS-Prozessor zu passen. Definition steht in include/asm-mips/interrupt.h:127
    • WARN_ON schreibt dann die Fehlermeldung ins Kernel-Log (quasi wie eine Assertion)
    • gedacht ist das ganze wohl zum Schutz der Reaktivierung als kritischen Abschnitt, da hier erst "manuell" aufgelaufene Events verarbeitet werden bevor es dann mit Soft IRQs wieder richtig weiter geht?

Da das Locking fehlschlägt ergibt sich eine Race Condition vor der das Lock (wenn es funktionieren würde) eigentlich schützen sollte. Das Loggen dauert einige Zeit und wohl lang genug um mit stark gesteigerter Wahrscheinlichkeit diese Race Condition zu treffen und die Fritzbox somit relativ häufig (bei mir 1-2 mal am Tag) zum Absturz zu bringen (Lock-Up CPU/Kernel, Speicherverletzung o.ä.).

Nachdem ich letzte Woche nur WARN_ON weggepatcht hab (nicht aber irqs_disabled!) läuft meine Fritzbox jetzt tatsache wieder seit 7 Tagen sauber durch, andere Änderungen gegenüber der Version die nicht sauber lief hab ich nicht durchgeführt. Patch gegen SVN Branch freetz-stable-2.0 hab ich grad angehangen: 9999-disable_local_be_enable_softirq_warning.patch gehört für die FBF 7170 ins Verzeichnis make/linux/patches/2.6.13.1. Irgendwelche Änderungen an printk oder weitere Einstellungen gegenüber dem SVN-Branch sind dabei nicht erforderlich.

Wenn der Patch auch bei anderen funktioniert wäre es gut, wenn er vielleicht schnellstmöglich in den entsprechenden Branch einfließen könnte. Denke durch die Sicherheitsupdates letztens sind vielleicht doch etwas mehr Leute hiervon betroffen. :)

comment:41 Geändert vor 5 Jahren durch SilentBob

Ich habe jetzt offensichtlich eine stabile Box, mit aiccu + ipv6 + replace kernel und 9999-disable_local_be_enable_softirq_warning.patch, allerdings ohne iptable/ip6tables.

Könnte sein, dass das originale Problem bei ip6tables liegt?
Bin zwar noch am Testen, sieht aber bisher (ohne iptables/ip6tables) gut aus.

comment:42 Geändert vor 5 Jahren durch er13

relevanter Kernel-Commit, eventuell reicht es WARN_ON durch WARN_ON_ONCE zu ersetzen.

comment:43 Geändert vor 5 Jahren durch oliver

Kernel 2.6.13.1 hat kein WARN_ON_ONCE Makro. Daher würde ich vorschlagen den Patch von dneuge so aufzunehmen.

comment:44 Geändert vor 5 Jahren durch ralf

Ich denke auch, dass wir den Patch so nehmen können, unabhängig davon, ob ONCE verfügbar ist. Die Warnung ist nur dann sinnvoll, wenn man sie beachtet und die Ursache dafür beseitigen will.

Die Frage ist also, wollen wir den Fehler korrigieren und ist es überhaupt wahrscheinlich, dass er im open source Teil zu finden ist? Die Logs hier enthalten leider wenig Kontext. Im Ticket selbst stehen nur Adressen ohne Funktionsnamen, bei comment:33 ist unklar ob es überhaupt etwas mit dem Tickt zu tun hat. Zum einen ist es eine andere Box, zum anderen ist kein Hinweis dabei, dass es mit local_be_enable zu tun haben könnte.

Wenn jemand dem Fehler nachgehen will, kann man immer noch den Patch entfernen.

comment:46 Geändert vor 5 Jahren durch oliver

Danke, Sedat. Das ist zwar keine große Änderung. Aber den Patch nur wegen nur einer Verwendung aufzunehmen. Ich bin dagegen.

comment:47 Geändert vor 5 Jahren durch oliver

In 11905:

7170: Add kernel patch to fix reboots with high wlan traffic (refs #2003)

  • patch by dneuge


comment:48 Geändert vor 5 Jahren durch SilentBob

Läuft bei mir (7170) einwandfrei seit 3 Tagen stabil (auch mit iptables/ip6tables) und unter verschiedenen Lastzuständen. Besten Dank!

Hinweis: Hilfe zur Verwendung von Tickets finden Sie in TracTickets.