http://bugzilla.opensuse.org/show_bug.cgi?id=1083866 http://bugzilla.opensuse.org/show_bug.cgi?id=1083866#c2 Oliver Neukum changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |suhn@gmx.de Flags| |needinfo?(suhn@gmx.de) --- Comment #2 from Oliver Neukum --- (In reply to Steffen Ungruh from comment #1)

Quick follow-up:

I have not provided any logs since the journal entries appear to be quite unhelpful. No clues given at all.

However, if you want me to investigate further - I do have hardware availability after all - let me know. Just provide me with a step-by-step guide (what to install, what to run etc.) and I'll get you what you need.

Are you positive it worked with v4.14? If so, the likely cause is: commit 0b1655143df00ac5349f27b765b2ed13a3ac40ca Author: Kai-Heng Feng Date: Tue Jan 16 16:46:27 2018 +0800 r8152: disable RX aggregation on Dell TB16 dock If it worked with v4.14, please attach the output of "lsusb -v" -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1083866 http://bugzilla.opensuse.org/show_bug.cgi?id=1083866#c4 --- Comment #4 from Steffen Ungruh --- Created attachment 763134 --> http://bugzilla.opensuse.org/attachment.cgi?id=763134&action=edit "ethtool enp57s0u1u4" to confirm. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1083866 http://bugzilla.opensuse.org/show_bug.cgi?id=1083866#c6 --- Comment #6 from Steffen Ungruh --- Created attachment 763136 --> http://bugzilla.opensuse.org/attachment.cgi?id=763136&action=edit "udevadm info -e" for good measure. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1083866 http://bugzilla.opensuse.org/show_bug.cgi?id=1083866#c8 --- Comment #8 from Steffen Ungruh --- So. I've checked a number of times again just to make sure. The 4.14 kernel is the last "unfreezing" one. I also took a look at the most recent 4.16 from the Kernel:HEAD repo and discovered the same problem. My hopes of that issue going away have therefore vanished. Any suggestions what the cause might be? Is my adapter affected by the commit changes at all? Just to reiterate, I'm willing to install kernel debug packages and all the necessary tools in order to provide useful information. I can run both kernel versions for comparisons sake until the powermanagement (if that's the issue) kicks in or whatever else makes sense. But for that I need some guidance i.e. needed tools, specific commands, what to look out for etc. Kernel debugging would be a first for me. I have a free weekend coming up. Bring it on and I'll deliver. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1083866 http://bugzilla.opensuse.org/show_bug.cgi?id=1083866#c10 --- Comment #10 from Steffen Ungruh --- Created attachment 768110 --> http://bugzilla.opensuse.org/attachment.cgi?id=768110&action=edit Call trace of the blocked kworker -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1083866 http://bugzilla.opensuse.org/show_bug.cgi?id=1083866#c12 Steffen Ungruh changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(suhn@gmx.de) | --- Comment #12 from Steffen Ungruh --- Alright. That took longer than expected. And still, I can not provide a bad commit. While the regular Tumbleweed kernels keep on freezing like clockwork within minutes after a boot, the compiled/bisected ones produce false positives and false negatives alike and are way more erratic in their behavior. I ran the bisect process three times, each time trying to nail down the (then less than obvious) failed states. Once I got send to an drm/amd commit in the 4.13 kernel, once to 4.15 POWERPC spectre patches and finally to a usbip commit. But, my GPU is Intel on an x86-64 and I don't use usbip. So, that was a bust. Nonetheless, it gave me an opportunity to observe the logs closely. Note: The compiled kernels are chattier than the distro ones. This is mostly due to a echo /proc/sys/kernel/hung_task_timeout_secs 0 setting in the latter. So, this seems to be the call trace of the frozen kworker: Apr 24 13:58:49 neroon kernel: INFO: task kworker/0:2:50 blocked for more than 60 seconds. Apr 24 13:58:49 neroon kernel: Not tainted 4.16.2-1-default #1 Apr 24 13:58:49 neroon kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Apr 24 13:58:49 neroon kernel: kworker/0:2 D 0 50 2 0x80000000 Apr 24 13:58:49 neroon kernel: Workqueue: events rtl_work_func_t [r8152] Apr 24 13:58:49 neroon kernel: Call Trace: Apr 24 13:58:49 neroon kernel: ? __schedule+0x28f/0x890 Apr 24 13:58:49 neroon kernel: schedule+0x2f/0x90 Apr 24 13:58:49 neroon kernel: rpm_resume+0xf9/0x7a0 Apr 24 13:58:49 neroon kernel: ? wait_woken+0x80/0x80 Apr 24 13:58:49 neroon kernel: rpm_resume+0x547/0x7a0 Apr 24 13:58:49 neroon kernel: ? dequeue_entity+0xd9/0x430 Apr 24 13:58:49 neroon kernel: __pm_runtime_resume+0x3a/0x50 Apr 24 13:58:49 neroon kernel: usb_autopm_get_interface+0x1d/0x50 [usbcore] Apr 24 13:58:49 neroon kernel: rtl_work_func_t+0x3c/0x27c [r8152] Apr 24 13:58:49 neroon kernel: process_one_work+0x1d4/0x3f0 Apr 24 13:58:49 neroon kernel: worker_thread+0x2b/0x3d0 Apr 24 13:58:49 neroon kernel: ? process_one_work+0x3f0/0x3f0 Apr 24 13:58:49 neroon kernel: kthread+0x113/0x130 Apr 24 13:58:49 neroon kernel: ? kthread_create_worker_on_cpu+0x50/0x50 Apr 24 13:58:49 neroon kernel: ret_from_fork+0x24/0x50 I have attached a gdb trace (see file) of each function nailing it down to the line in the code. Furthermore, I compared it to the logs of older kernels and found a bunch of output that's bee missing since 4.15. If you take a look at the other attached file (Pre-4.15 behaviour) you'll see why. Apr 01 14:18:25 neroon kernel: usb 4-1.4: Disable of device-initiated U1 failed. Apr 01 14:18:25 neroon kernel: usb 4-1.4: Disable of device-initiated U2 failed. Apr 01 14:18:25 neroon kernel: usb 4-1.4: usb_reset_and_verify_device Failed to disable LTM . Apr 01 14:18:25 neroon kernel: usb 4-1.4: USB disconnect, device number 5 Note: the single "." in line 4 is not a typo. Apparently, autosuspend never worked properly. Instead, the kernel - after failing to wake up the device - performs an internal unplug/plug and enlists it thereby as a new one. Pretty dirty, but at least it worked and didn't cause all kinds of havoc on the entire system. So. Now what? What else can I do to further the cause? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1083866 http://bugzilla.opensuse.org/show_bug.cgi?id=1083866#c16 Steffen Ungruh changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(suhn@gmx.de) | --- Comment #16 from Steffen Ungruh --- Nice effort. I see what you did there. Used the kernel-sources from the repo instead of the git tree for this. Patched it. Compiled it. Ran it. Results in the same crash. Call trace is basically identical. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1083866 http://bugzilla.opensuse.org/show_bug.cgi?id=1083866#c18 Steffen Ungruh changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(suhn@gmx.de) | --- Comment #18 from Steffen Ungruh --- You're on to something. I've tested default and vanilla kernels from the OSS, kernel:vanilla and kernel:HEAD repos ranging from 4.16.x to 4.17-rc4. The only kernels which don't break are the 4.17-rc4-vanilla ones regardless of the repo. Everything else freezes within minutes after a reboot. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1083866 http://bugzilla.opensuse.org/show_bug.cgi?id=1083866#c20 --- Comment #20 from Steffen Ungruh --- So, to sum up what we've learned so far: 1. All kernels are affected. 2. The distro kernels break within a very short timeframe after reboot. 3. The vanilla and bisected ones are totally erratic. Sometimes they break, sometimes they don't. (In my last case within a second after network use) 4. And, arch-kernels are also affected. My questions: What differentiates the default and vanilla kernels when it comes to USB power management? How can I test this more efficiently? Meaning, how can this error be provoked. Waiting for something to happen/not happen has proven completely unreliable. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1083866 http://bugzilla.opensuse.org/show_bug.cgi?id=1083866#c21 Michael Rans changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rans@email.com --- Comment #21 from Michael Rans --- I stumbled across this bug report. I have been having similar issues on various versions of Linux Mint with various kernel versions (including 4.15). I have field a bug report against the Linux kernel: https://bugzilla.kernel.org/show_bug.cgi?id=200977 I have referenced this report in there. Did you find a solution to this problem? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1083866 Moritz Moroder changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |moritz.moroder@hotmail.com -- You are receiving this mail because: You are on the CC list for the bug.