[Jessie] CIFS lässt System einfrieren

[BlackEye]

Hallo liebe Debianfreunde,

mein System ist immer auf den aktuellsten Stand. Zumindest 2-3 Tagesaktuell.
Seit Monaten aber habe ich immer schlimmere Probleme mit Samba/CIFS und langsam fängt es richtig an zu nerven. An meinem Arbeitsplatz habe ich 9 aktive Verbindungen mit unserem Domaincontroller und diese brauche ich auch um täglich zu arbeiten. In unregelmäßigen Abständen scheint Samba aber ein echtes Problem mit irgend welchen Verbindungen und haben und bringt dabei das halbe System zum Stillstand. Das äußert sich dann in eingefrorenen Dialogen die auf irgend eine Antwort warten und in der Zwischenzeit keinerlei Interaktion ermöglichen (siehe Screenshot [1]).
Tritt dieser Zustand ein, kann ich maximal noch mit dem Applikationen arbeiten die bereits laufen und dort muss ich tunlichst auf Dialoge mit Dateioperationen verzichten (Dateien öffnen/Speichern/Suchen/etc...). Nach einigen Minuten (~20) lösen sich diese "Erfrierungen" und alles ist wieder normal. Zumindest bis zum nächsten Hänger...
Mit dmesg erhalte ich folgende hübsche Information (und davon mehrere mit unterschiedlichen betroffenen Prozessen):

Code: Alles auswählen

[27862.756790] INFO: task plasma-desktop:1604 blocked for more than 120 seconds.
[27862.756793]       Tainted: P           O  3.16.0-4-amd64 #1
[27862.756794] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[27862.756795] plasma-desktop  D ffff8800d6007038     0  1604      1 0x00000000
[27862.756797]  ffff8800d6006be0 0000000000000082 0000000000013280 ffff8803f24fffd8
[27862.756799]  0000000000013280 ffff8800d6006be0 ffff880409d90420 ffff8803f24ff910
[27862.756800]  ffff880409d90424 ffff8800d6006be0 00000000ffffffff ffff880409d90428
[27862.756801] Call Trace:
[27862.756807]  [<ffffffff8150c365>] ? schedule_preempt_disabled+0x25/0x70
[27862.756809]  [<ffffffff8150de13>] ? __mutex_lock_slowpath+0xd3/0x1c0
[27862.756811]  [<ffffffff81273c12>] ? md5_final+0x62/0x150
[27862.756816]  [<ffffffff8150df1b>] ? mutex_lock+0x1b/0x2a
[27862.756819]  [<ffffffffa05aadd3>] ? cifs_reconnect_tcon+0x153/0x2e0 [cifs]
[27862.756823]  [<ffffffffa05cf541>] ? cifs_verify_signature+0xe1/0x150 [cifs]
[27862.756825]  [<ffffffffa05aaff5>] ? smb_init+0x25/0x80 [cifs]
[27862.756828]  [<ffffffffa05b0e3c>] ? CIFSSMBQPathInfo+0x5c/0x260 [cifs]
[27862.756831]  [<ffffffffa05d3f93>] ? cifs_query_path_info+0x63/0x180 [cifs]
[27862.756835]  [<ffffffffa05ca156>] ? cifs_buf_release+0x16/0x20 [cifs]
[27862.756837]  [<ffffffffa05b0faf>] ? CIFSSMBQPathInfo+0x1cf/0x260 [cifs]
[27862.756840]  [<ffffffffa05c6320>] ? cifs_get_inode_info+0x230/0x6c0 [cifs]
[27862.756843]  [<ffffffffa05c444e>] ? is_size_safe_to_change+0x1e/0x90 [cifs]
[27862.756846]  [<ffffffffa05bbe9c>] ? build_path_from_dentry+0x10c/0x290 [cifs]
[27862.756849]  [<ffffffffa05c8158>] ? cifs_revalidate_dentry_attr+0xf8/0x1c0 [cifs]
[27862.756852]  [<ffffffffa05c825f>] ? cifs_revalidate_dentry+0xf/0x30 [cifs]
[27862.756855]  [<ffffffffa05bbb83>] ? cifs_d_revalidate+0x23/0xb0 [cifs]
[27862.756857]  [<ffffffff811b188e>] ? lookup_fast+0x25e/0x2b0
[27862.756859]  [<ffffffff811b2919>] ? link_path_walk+0x1d9/0x890
[27862.756860]  [<ffffffff811bd4df>] ? dput+0x1f/0x170
[27862.756862]  [<ffffffff811b302b>] ? path_lookupat+0x5b/0x780
[27862.756864]  [<ffffffff8113c8a9>] ? find_get_entry+0x19/0x90
[27862.756865]  [<ffffffff811b3776>] ? filename_lookup+0x26/0xc0
[27862.756866]  [<ffffffff811b7864>] ? user_path_at_empty+0x54/0x90
[27862.756868]  [<ffffffff812b6ec8>] ? lockref_put_or_lock+0x48/0x80
[27862.756870]  [<ffffffff811ac346>] ? vfs_fstatat+0x46/0x90
[27862.756871]  [<ffffffff811a9541>] ? __fput+0x161/0x1d0
[27862.756872]  [<ffffffff811ac81d>] ? SYSC_newlstat+0x1d/0x40
[27862.756874]  [<ffffffff8108500c>] ? task_work_run+0x9c/0xd0
[27862.756877]  [<ffffffff81012ea9>] ? do_notify_resume+0x69/0xa0
[27862.756878]  [<ffffffff8150fa2a>] ? int_signal+0x12/0x17
[27862.756880]  [<ffffffff8150f76d>] ? system_call_fast_compare_end+0x10/0x15

Ich weiß hier nicht mehr weiter. In den Samba-Protokollen steht nix (zumindest sehe ich da nichts) und mit dem Domaincontroller hat es definitiv nichts zu tun. Alle anderen können normal arbeiten (alles Windows Arbeitsplätze). Es muss irgendwas mit meinem Rechner zu tun haben.
Hat hier jemand eine schlaue Idee oder Informationen die mir weiter helfen könnte?

Besten Dank im Voraus!

Martin

[1] http://i.imgur.com/3jEGTEi.png

[rendegast]

Versuche Kernel 3.19 experimental oder den Vorgänger 3.18 (von snapshot.debian.org).

Für eventuellen Modulbau:
linux-kbuild-3.19 ist noch nicht verfügbar.


Weiterhin ram-Test memtest86+
(obwohl sich dann auch anderes als cifs fehlerbehaftet zeigen sollte)

[NAB]

Tainted: P

?

[BlackEye]

Tainted: P

?

Bin mir nicht sicher, könnte vielleicht an nvidia oder vbox liegen?

[BlackEye]

Versuche Kernel 3.19 experimental oder den Vorgänger 3.18 (von snapshot.debian.org).

Für eventuellen Modulbau:
linux-kbuild-3.19 ist noch nicht verfügbar.


Weiterhin ram-Test memtest86+
(obwohl sich dann auch anderes als cifs fehlerbehaftet zeigen sollte)

Leider bin ich bei dem Thema "Kernel selbst bauen" unter Debian nicht sonderlich bewandert. Bisher nutze ich den in Jessie enthaltenen Kernel. Gibt es eine Doku wie den Testing-Kernel unter jessie installiere?

[rendegast]

... bei dem Thema "Kernel selbst bauen" ...

Es geht nicht um kernel-Bauen.

Der Kernel, dessen debian-Paket linux-image-X.Y-... ist erstmal von alleine lauffähig.
Es werden aber gegebenenfalls nachträglich gebaute Module benötigt,
Bsp. Grafik-Pakete fglrx oder nvidia, virtualbox.
Um deren Code an einen vorhandenen Kernel anzupassen benötigt es Zusatzpakete,
im allgemeinen dkms, die passendene linux-headers-X.Y-... und linux-kbuild-X.Y.
Ebendieses linux-kbuild-X.Y ist für den Kernel(-Paket) 3.19~experimental noch nicht paketiert
(passiert gelegentlich, wird sich wohl in 1-2 Tagen ändern)
Daher können für den Kernel 3.19~experimental momentan mithilfe seiner linux-headers noch keine Module nachträglich gebaut werden.

Das Paketset kernel 3.18~experimental

Code: Alles auswählen

# dpkg -l | grep 3.18 | cut -c -110
ii  linux-compiler-gcc-4.9-x86                                  3.18.6-1~exp1                       amd64     
ii  linux-headers-3.18.0-trunk-amd64                            3.18.6-1~exp1                       amd64     
ii  linux-headers-3.18.0-trunk-common                           3.18.6-1~exp1                       amd64     
ii  linux-image-3.18.0-trunk-amd64                              3.18.6-1~exp1                       amd64     
ii  linux-kbuild-3.18                                           3.18.5-1~exp1                       amd64     

ist aber komplett von snapshot.debian.org erhältlich.


Falls Du keine solch nachträglich gebauten Module verwendest,
ist das unerheblich.

Code: Alles auswählen

dpkg -l | egrep "linux-|dkms"

dkms status | sort -V

------------------------------------------------------------------------------------------
EDIT Nachtrag,
Das 3.18 baut nicht das fglrx-Modul (hier experimental, dito für das aus jessie)

Code: Alles auswählen

# dkms status | sort -V
fglrx, 14.12, 3.16.0-4-amd64, x86_64: installed
nvidia-current, 340.65, 3.16.0-4-amd64, x86_64: installed
nvidia-current, 340.65, 3.18.0-trunk-amd64, x86_64: installed
nvidia-legacy-96xx, 96.43.23, 3.16.0-4-amd64, x86_64: installed
nvidia-legacy-96xx, 96.43.23, 3.18.0-trunk-amd64, x86_64: installed
nvidia-legacy-173xx, 173.14.39, 3.16.0-4-amd64, x86_64: installed
nvidia-legacy-173xx, 173.14.39, 3.18.0-trunk-amd64, x86_64: installed
nvidia-legacy-304xx, 304.125, 3.16.0-4-amd64, x86_64: installed
nvidia-legacy-304xx, 304.125, 3.18.0-trunk-amd64, x86_64: installed
vboxhost, 4.3.22, 3.16.0-4-amd64, x86_64: installed
vboxhost, 4.3.22, 3.18.0-trunk-amd64, x86_64: installed

(das virtualbox wäre direkt von oracle)

[BlackEye]

Okay danke - ich denke damit komme ich zurecht.

Da nvidia und virtualbox in meinem System ist und diese selbst ihre Module bauen müssen werde ich den 3.18 testen und dafür einen snapshot von experimental von anfang des Jahres hinzufügen.
Mal schauen ob das klappt

[NAB]

Bin mir nicht sicher, könnte vielleicht an nvidia oder vbox liegen?

Versuche es erst mal ohne nvidia-Treiber. Mal schauen, ob die Fehler dann verschwinden. Das wäre das einfachste, bevor du mit neuen Kerneln experimentierst.

Und läuft eine VM während die Probleme auftreten?

Und welche Netzwerkkarte benutzt du eigentlich? Zeigt die irgendwelche Auffälligkeiten im dmesg?

[BlackEye]

Bin mir nicht sicher, könnte vielleicht an nvidia oder vbox liegen?

Versuche es erst mal ohne nvidia-Treiber. Mal schauen, ob die Fehler dann verschwinden. Das wäre das einfachste, bevor du mit neuen Kerneln experimentierst.

Und läuft eine VM während die Probleme auftreten?

Und welche Netzwerkkarte benutzt du eigentlich? Zeigt die irgendwelche Auffälligkeiten im dmesg?

@Nvidia: Es hatte irgend einen Grund warum ich die nvidia Treiber installiert habe - Ich weiss nur nicht mehr welche.. Vermutlich weil die Beschleunigung einfach zu langsam war? Ich hab echt keine Idee mehr..
@VM: Mal läuft eine, mal nicht. Das Problem ist dass ich recht häufig eine VM zum testen und entwickeln benötige. Das wäre schon ein Handicap wenn ich das abschalten müsste.
@Netzwerk: Es handelt sich um eine Realtek Karte:
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)

Während der diese Problem mit dem Netz hat gehen andere Dinge ja nach wie vor. Also z.B. der Browser, Internet-Chat usw.. Selbst wenn ich bestimmte Orte direkt adressiere (ls /mnt/daten/xyz/foo/bar) gehen diese. Aber wehe ich adressiere irgend etwas, wo er alle meine CIFS-Laufwerke abfragen muss (daher auch der Screenshot mit dem ls /mnt/daten - denn dort sind alle meine CIFS-Laufwerke eingemountet).

[NAB]

Ja, du hast ja recht ... da ist irgendwie cifs blockiert. Aber ... ich finde per Google keine ähnlichen Fehler zu Kernel 3.16. Du bist also "der Einzige". Da macht es Sinn zu schauen, was bei dir sonst noch anders ist.

Ein Test mit nouveau wäre einen Versuch wert.

Auf einen Zusammenhang mit Virtualbox könntest du mal achten.

Ein Test mit einem neueren Kernel wäre auch einen Versuch wert - das will ich dir ja gar nicht ausreden.

Und deine Realtek-Karte möchte eigentlich gerne die "firmware-realtek" haben ... sie läuft aber auch ohne.

Ach, und ... ich finde ähnliche Fehler, die nach einem Suspend auftreten. Machst du sowas?

[BlackEye]

Suspend mache ich gar nicht. Mein System läuft von SSD, da geht der Boot doch ziemlich flott

Ich werde das mit virtualbox auf jeden Fall mal im Auge behalten und diese Firmware für die NIC hatte ich bei der Installation mit geladen. Denke die müsste dann auch dabei sein...?

[BlackEye]

So, kleines Update.

Ich habe am Wochenende den Kernel 3.18.0-trunk-amd64 installiert und bin von den nvidia properitären Treibern zurück auf den nouveau Treiber gegangen. Bis eben lief alles gut - jetzt hängt er wieder
Das System ist eben eingefroren als ich auf eine im Thunderbird erhaltene Mail antworten wollte. Es öffnete sich das Antwort-Fenster, aber es blieb weiß, der ursprüngliche Text wurde nicht als Zitat eingefügt und das Fenster war nicht mehr steuerbar. Ob das der Auslöser war weiß ich nicht - bei diesem Vorgang ist es mir nur aufgefallen das er hängt.
Aktuell läuft auch eine VM mit Virtualbox. Diese habe ich eben mal beendet - ändert aber nichts am aktuellen Zustand. Derzeit ist das System seit guten 10 Minuten eingefroren. Bereits laufende Anwendungen die nicht davon betroffen sind laufen noch (daher kann ich auch hier schreiben).

[einige Zeit später]

Ich habe mal ein Wireshark mitlaufen lassen und ein neues "ls /mnt/daten" abgefeuert welches natürlich eingefroren blieb. Wirshark habe ich auf die Suche nach Paketen mit meinem Server geschickt und dort ist mir folgendes interessantes Aufgefallen:

Code: Alles auswählen

[Client -> Server] Trans2 Request
[Server -> Client] Trans2 Response
[wiederholt sich 2 weitere male]
[Client -> Server] Negotiate Protocol Request
[keine Antwort vom Server]
[ca 66 Sekunden später...]
[Client -> Server] (TCP Retransmission) Negotiate Protocol Request
[keine Antwort vom Server]
[ca 120 Sekunden später...]
[Client -> Server] (TCP Retransmission) Negotiate Protocol Request
[keine Antwort vom Server]
[ca 120 Sekunden später...]
[Client -> Server] (TCP Retransmission) Negotiate Protocol Request
[und so weiter...]

Aktuell hat sich Thunderbird wieder befreit. Einige Zeit später hat sich mein "ls /mnt/daten" auch wieder gelöst.
Mit diesen neuen Informationen von Wireshark bin ich nun mal auf die Suche gegangen und habe folgenden interessanten Eintrag gefunden:
http://serverfault.com/questions/145920 ... ares-fails

Dort ist ziemlich genau meine Situation beschrieben, nur das ich hier kein Windows XP/2003 sondern ein Linux Client einsetze. Aber auch hier handelt es sich serverseitig um ein Windows 2008 und mein Linux spricht ebenfalls SMBv1.
Ich werde mich also mal an die dort gegebene Lösung mit dem deaktivieren von SMBv2 halten und schauen ob sich dabei etwas neues ergibt.

Schöne Grüße
Martin

[NAB]

Was sagt eigentlich die Ausgabe von "ifconfig" dazu? Verwirft er (eingehende) Pakete?

[BlackEye]

Was sagt eigentlich die Ausgabe von "ifconfig" dazu? Verwirft er (eingehende) Pakete?

Kann man nicht sagen denke ich:

Code: Alles auswählen

# ifconfig 
eth0      Link encap:Ethernet  Hardware Adresse 74:d4:35:14:b2:93  
          inet Adresse:10.0.0.99  Bcast:10.0.0.255  Maske:255.255.255.0
          inet6-Adresse: fe80::76d4:35ff:fe14:b293/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:480309 errors:0 dropped:16 overruns:0 frame:0
          TX packets:345831 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX bytes:222750056 (212.4 MiB)  TX bytes:127719389 (121.8 MiB)

lo        Link encap:Lokale Schleife  
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
          UP LOOPBACK RUNNING  MTU:65536  Metrik:1
          RX packets:125079 errors:0 dropped:0 overruns:0 frame:0
          TX packets:125079 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX bytes:64517492 (61.5 MiB)  TX bytes:64517492 (61.5 MiB)

Es gibt zwar 16 gedroppte Pakete - aber das ist ja eigentlich 'überschaubar'

[NAB]

Jupp, das sollte egal sein. Gedroppte Pakete werden ja neu angefordert und sollten noch mal gesendet werden, falls der Server nicht pennt.

Das scheint wirklich am Server zu liegen. Naja, oder daran, dass dein Rechner nicht richtig mit ihm redet.

Probiere es erst mal ohne SMBv2, sonst hätte ich noch die Virtualbox-Theorie im Angebot. (Das lief beim ifconfig oben nicht, oder?)

[BlackEye]

[...]
sonst hätte ich noch die Virtualbox-Theorie im Angebot. (Das lief beim ifconfig oben nicht, oder?)

Mein Rechner ist seit heute morgen durchgängig im Betrieb und VB lieft am heutigen Tag schon ein mal. Aktuell ist sie aber aus. D.h. im obigen ifconfig-Snapshot ist VB-Betrieb mit enthalten, war zur Zeit der Ausführung des Befehls aber nicht mehr aktiv.

Jupp, das mit dem SMBv2 werde ich mal testen und melde mich hier wieder, wenn ich weitere Infos habe.