OpenSuse 13.2 lässt Router abstürzen

[radiergummi]

Hallo Forum,
einer meiner Rechner (OpenSuse 13.2 32bit) lässt reproduzierbar den Router (Netgear FVS336G, aktuelle Firmware) abstürzen.

DSL
  +- Modem (D-Link)
         +- Router (Netgear)
                 +- Switch (Netgear)
                         + Server 1 (OpenSuse 13.2 32bit)
                         + Server 2 (OpenSuse 13.2 32bit)
                         + Server 3 (Windows)
                         + Clients (Ubuntu)
                         + Netzwerk-Scanner (Brother)
                         + Netzwerk-Drucker (HP)

Fall 1:
Beim booten des Rechners zuckt der Router, bootet neu (Test LED) und hängt dann (stellt keine Verbindung zum Internet her, verteilt keine DHCP Leases, blockiert das LAN).

Fall 2:
Booten glückt, nach einer Weile (10min, 30min, 1Tag) bekommen Switch und Router LED-Flimmern und der Router hängt sich auf. Der Server schreibt aggressiv /var/log/messages mit Kernel-Meldungen voll.

2017-03-02T13:05:31.420840+01:00 fileserver4 kernel: [10016.075284] BUG: scheduling while atomic: 
swapper/0/0/0x00013d42
2017-03-02T13:05:31.420853+01:00 fileserver4 kernel: [10016.075287] Modules linked in: bnep 
bluetooth 6lowpan_iphc rfkill fuse nfsv3 rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache nfsd 
auth_rpcgss oid_registry nfs_acl lockd sunrpc tcp_diag inet_diag af_packet iscsi_ibft 
iscsi_boot_sysfs xfs libcrc32c raid456 async_raid6_recov async_memcpy async_pq async_xor xor 
async_tx raid6_pq joydev iTCO_wdt iTCO_vendor_support gpio_ich lpc_ich e1000e serio_raw i2c_i801 
mfd_core ptp pps_core shpchp pcspkr x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm 
crc32_pclmul crc32c_intel tpm_tis tpm button dm_mod raid1 md_mod sr_mod cdrom mgag200 syscopyarea 
sysfillrect sysimgblt i2c_algo_bit drm_kms_helper ttm drm fan processor thermal sg
2017-03-02T13:05:31.420855+01:00 fileserver4 kernel: [10016.075344] CPU: 0 PID: 0 Comm: swapper/0 
Tainted: G        W     3.16.7-53-desktop #1
2017-03-02T13:05:31.420856+01:00 fileserver4 kernel: [10016.075346] Hardware name: Supermicro 
X9SCL/X9SCM/X9SCL/X9SCM, BIOS 1.1a 09/28/2011
2017-03-02T13:05:31.420858+01:00 fileserver4 kernel: [10016.075348]  c0b78000 c0b79f0c c0790551 
00000000 c078c9e1 c093aaa8 c0b86e30 00000000
2017-03-02T13:05:31.420859+01:00 fileserver4 kernel: [10016.075353]  00013d42 c0b79f8c c07930bb 
c02b7459 00000000 00200086 c0cb2880 c026d1c0
2017-03-02T13:05:31.420861+01:00 fileserver4 kernel: [10016.075359]  c02b7459 c0cb2880 00000000 
f1de9880 c0b86a40 8f5bf200 00000919 8f5bf200
2017-03-02T13:05:31.420862+01:00 fileserver4 kernel: [10016.075365] Call Trace:
2017-03-02T13:05:31.420863+01:00 fileserver4 kernel: [10016.075375]  [<c0205c56>] 
try_stack_unwind+0x156/0x170
2017-03-02T13:05:31.420865+01:00 fileserver4 kernel: [10016.075383]  [<c020482a>] 
dump_trace+0x5a/0x1b0
2017-03-02T13:05:31.420866+01:00 fileserver4 kernel: [10016.075388]  [<c0205cb6>] 
show_trace_log_lvl+0x46/0x50
2017-03-02T13:05:31.420868+01:00 fileserver4 kernel: [10016.075397]  [<c02049d1>] 
show_stack_log_lvl+0x51/0xe0
2017-03-02T13:05:31.420869+01:00 fileserver4 kernel: [10016.075401]  [<c0205d17>] 
show_stack+0x27/0x50
2017-03-02T13:05:31.420870+01:00 fileserver4 kernel: [10016.075406]  [<c0790551>] 
dump_stack+0x45/0x65
2017-03-02T13:05:31.420871+01:00 fileserver4 kernel: [10016.075410]  [<c078c9e1>] 
__schedule_bug+0x54/0x63
2017-03-02T13:05:31.420873+01:00 fileserver4 kernel: [10016.075415]  [<c07930bb>] 
__schedule+0x70b/0x770
2017-03-02T13:05:31.420874+01:00 fileserver4 kernel: [10016.075420]  [<c079356a>] 
schedule_preempt_disabled+0x2a/0x70
2017-03-02T13:05:31.420875+01:00 fileserver4 kernel: [10016.075425]  [<c028bd00>] 
cpu_idle_loop+0x110/0x3e0
2017-03-02T13:05:31.420877+01:00 fileserver4 kernel: [10016.075429]  [<c028c023>] 
cpu_startup_entry+0x53/0x60
2017-03-02T13:05:31.420878+01:00 fileserver4 kernel: [10016.075434]  [<c0bfec1e>] 
start_kernel+0x415/0x41a

Das geht eine ganze Weile bis schließlich der Rechner stehen bleibt und nicht mehr reagiert - auch auf <Alt><Druck><b> nicht. Der Neustart über den Hauptschalter provoziert jedesmal ein fsck.

Ich stehe hiermit völlig im Regen und habe keinerlei Ansatzpunkt.
Den Thread hier http://linux-club.de/forum/viewtopic.php?f=90&t=107805 habe ich gefunden, kann aber nichts damit anfangen.

Könnt Ihr mir weiterhelfen?

Danke und Gruß

 

[marce]

Fahr den betreffenden Rechner doch mal mit einer Live-CD hoch und check ihn durch. Vermutlich ist da irgendwas defekt - Hardware oder Software. Oder in Folge von einem das andere auch.

 

[radiergummi]

von der Life-CD habe ich nur den MemTest laufen lassen. War alles okay. Ich wüsste nicht, was ich wie sonst noch testen könnte.

 

[marce]

na, den kompletten Rest des Systems. Z.B. wenn das Ding hochgefahren ist und Netzwerk aktiv und steht, ob das Ding dann auch solche Späße veranstaltet.

 

[josef-wien]

Das Live-System sollte aber irgendeine ziemlich neue Distribution sein. 13.2 ist seit 17. Jänner mausetot, falls das Problem tatsächlich seine Ursache in 13.2 hat, wird es dort keine Lösung mehr geben. Aber zuerst denke ich an die Hardware: Netzwerkkarte tauschen, Kabel tauschen, andere Buchse am Router verwenden (falls das nicht schon passiert ist).

 

[muck19]

Ich würde da auch eher ein Hardwareproblem im Vordergrund sehen.

Ich hatte hier auch kürzlich sehr seltsame Probleme. Router reagierte nicht, switch benahm sich seltsam, Rechner ging erst mit einer Verzögerung von 3 Minuten online.

Ursache: Netzwerkkabel -

 

[spoensche]

Das Problem ist folgendes:

Der atomic Task Scheduler erzeugt beim kopieren der Daten eines Prozesses, zwecks CPU Zeit, auf den Stack der CPU einen Fehler, wenn die CPU sich im IDLE Zustand befindet und geweckt werden soll.

Ursache dafür kann z.B. ein ACPI Bug in den Sleepstates sein, ein Hardwaredefekt z.B. CPU.

Wenn du 13.2 gebootet hast poste mal die Ausgabe von

dmesg | egrep -i "err|warn|fail|fault|crit|acpi"

.

Du solltes allerdings sehr Zeitnah ein Distributionsupgrade durchführen, da 13.2 EOL ist und somit keinerlei Security-Patches und Bugfixes mehr bereitgestellt werden.

 

[drcux]

So ein Verhalten kann schon durch ein defektes Netzwerkkabel (Kurzschluss) hervorgerufen werden...