Processed: tagging 966218
Processing commands for cont...@bugs.debian.org: > tags 966218 + pending Bug #966218 [src:linux] firmware: failed to load iwl-debug-yoyo.bin (-2) Ignoring request to alter tags of bug #966218 to the same tags previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 966218: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966218 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#968509: Further crashes under linux-image-4.19.0-10-amd64
Hi Richard, On Sat, Aug 22, 2020 at 12:58:47PM +0100, Richard Kettlewell wrote: > I've had further crashes under 4.19.0-10-amd64 on a second machine. > Again, after reverting to 4.19.0-9-amd64 this second machine seems to be > stable. > > The full logs are at http://www.greenend.org.uk/rjk/junk/crashboth.log, > a version without all the iptables clutter is attached. I suspect this is possibly same as #966846. If so this was fixed in 4.19.134 upstream but followup commits were needed as up to commits in 4.19.140 upstream. Would you be able to test 4.19.142? Regards, Salvatore
Bug#969223: Can't rm directory on overlayfs in userns
Source: linux Version: 5.7.10-1 Severity: normal Hi, After enabling overlayfs for userns, I find it doesn't work as expected. $ cat /sys/module/overlay/parameters/permit_mounts_in_userns Y zsj@debian:~/test$ pwd /home/zsj/test zsj@debian:~/test$ tree . ├── lower │ └── a │ └── a ├── merged ├── upper └── work zsj@debian:~/test$ unshare -m -U -r root@debian:~/test# mount -t overlay -o rw,lowerdir=/home/zsj/test/lower,upperdir=/home/zsj/test/upper,workdir=/home/zsj/test/work overlay /home/zsj/test/merged root@debian:~/test# rm -rf merged/a rm: cannot remove 'merged/a': Input/output error -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_USER, TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Processed (with 1 error): Re: Bug#966218: firmware: failed to load iwl-debug-yoyo.bin (-2)
Processing control commands: > notfound -1 20200421-1 Bug #966218 [firmware-iwlwifi] firmware: failed to load iwl-debug-yoyo.bin (-2) No longer marked as found in versions firmware-nonfree/20200421-1. > reassign -1 src:linux Bug #966218 [firmware-iwlwifi] firmware: failed to load iwl-debug-yoyo.bin (-2) Bug reassigned from package 'firmware-iwlwifi' to 'src:linux'. Ignoring request to alter found versions of bug #966218 to the same values previously set Ignoring request to alter fixed versions of bug #966218 to the same values previously set > found -1 5.5.13-1 Bug #966218 [src:linux] firmware: failed to load iwl-debug-yoyo.bin (-2) Marked as found in versions linux/5.5.13-1. > found -1 5.7.17-1 Bug #966218 [src:linux] firmware: failed to load iwl-debug-yoyo.bin (-2) Marked as found in versions linux/5.7.17-1. > forwarded -1 Unknown command or malformed arguments to command. > severity -1 minor Bug #966218 [src:linux] firmware: failed to load iwl-debug-yoyo.bin (-2) Severity set to 'minor' from 'normal' > tags -1 + patch pending upstream fixed-upstream Bug #966218 [src:linux] firmware: failed to load iwl-debug-yoyo.bin (-2) Added tag(s) patch, fixed-upstream, pending, and upstream. -- 966218: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966218 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#966218: firmware: failed to load iwl-debug-yoyo.bin (-2)
Control: notfound -1 20200421-1 Control: reassign -1 src:linux Control: found -1 5.5.13-1 Control: found -1 5.7.17-1 Control: forwarded -1 https://lore.kernel.org/linux-wireless/20200625165210.14904-1-...@kernel.org/ Control: severity -1 minor Control: tags -1 + patch pending upstream fixed-upstream -- An upstream patch [0] that suppresses this (harmless) error message was merged in v5.9-rc1 [1] and should be available in 5.9 and later kernels. As a "workaround" (if the error message bothers you), you may set the iwlwifi module's "enable_ini" parameter to false (e.g., "N"). This will disable the (attempted) loading of the "iwl-debug-yoyo.bin" file -- which fails, obviously, causing this error to be generated. [0]: https://patchwork.kernel.org/patch/11625759/ [1]: https://github.com/torvalds/linux/commit/3f4600d
Bug#966703: linux-image-4.19.0-10-amd64: kworker process with permanent high CPU load
Hi Dirk, Thanks for testing that. On Sat, Aug 29, 2020 at 11:04:43AM +0200, Dirk Kostrewa wrote: > Hi Salvatore, > > I have enabled the verbose debugging mode on the command line and have > appended the first 5000 lines of the dmesg output to this e-mail, running > the current kernel from the Buster backports with the two kworker processes > with high CPU load present. > > After that, I have applied your patch to this kernel and rebooted with the > patched kernel: > > 5.7.0-0.bpo.2-amd64 #1 SMP Debian 5.7.10-1~bpo10+1a~test (2020-08-28) x86_64 > GNU/Linux > > With your patch applied, the two kworker processes with high CPU load > completely disappeared! Unfortunately I suspect this indicates either a HW fault or a HW design error as stated in the found kernel-thread which was just uncovered by the mentioned kernel fix (which we temporarily reverted with the patch). I can try to ask Alan Stern. There might be a workaround workarble for you, the issue should disapear if you prevent the system to automatically try to suspend usb2 root hub (but you have the same on usb1 root hub). # echo on >/sys/bus/usb/devices/usb2/power/control will do that for the usb2 root hub. Regards, Salvatore
Bug#966703: linux-image-4.19.0-10-amd64: kworker process with permanent high CPU load
Hi Salvatore, I have enabled the verbose debugging mode on the command line and have appended the first 5000 lines of the dmesg output to this e-mail, running the current kernel from the Buster backports with the two kworker processes with high CPU load present. After that, I have applied your patch to this kernel and rebooted with the patched kernel: 5.7.0-0.bpo.2-amd64 #1 SMP Debian 5.7.10-1~bpo10+1a~test (2020-08-28) x86_64 GNU/Linux With your patch applied, the two kworker processes with high CPU load completely disappeared! A snapshot of the "top" command shows the following top 10 processes: $ top top - 10:54:43 up 5 min, 3 users, load average: 0.18, 0.26, 0.13 Tasks: 225 total, 1 running, 224 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.1 us, 0.1 sy, 0.0 ni, 99.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 15928.9 total, 14186.5 free, 900.8 used, 841.7 buff/cache MiB Swap: 0.0 total, 0.0 free, 0.0 used. 14711.4 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 344 root -51 0 0 0 0 S 0.3 0.0 0:00.10 irq/134-iwlwifi 425 root 20 0 0 0 0 I 0.3 0.0 0:00.09 kworker/5:3-events 1216 rtkit 21 1 152652 2856 2616 S 0.3 0.0 0:00.01 rtkit-daemon 1272 dirk 20 0 52376 17908 5460 S 0.3 0.1 0:00.02 hp-systray 1 root 20 0 169784 10436 7844 S 0.0 0.1 0:01.64 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd 3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp 4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par_gp 5 root 20 0 0 0 0 I 0.0 0.0 0:00.04 kworker/0:0-events_+ 6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/0:0H-kblockd ... Many thanks for looking after this issue and having found a fix for this! Best regards, Dirk Am 28.08.20 um 16:33 schrieb Salvatore Bonaccorso: hi Dirk, On Wed, Aug 12, 2020 at 05:53:57PM +0200, Dirk Kostrewa wrote: Hi Salvatore, I just found out, that if none of the two USB ports is connected, there are two kworker processes with permanently high CPU load, if one USB port is connected and the other not, there is one such kworker process, and if both USB ports are connected, there is no kworker process with high CPU load. I think, this supports your suspicion that these kworker processes are connected with the overcurrent condition for both USB ports that I also see in the dmesg output. What puzzles me, is that I've observed these oddly behaving kworker processes also with the 5.6 kernel that I've tried from the Buster Backports repository. The kernel parameter variant did not work correctly as there are no dynamic debug output afaics (the double quotes seem to placed in the wrong place), please just try the setting at runtime instead: # echo 'file drivers/usb/* +p;' > /sys/kernel/debug/dynamic_debug/control What I was meaning is (and this is confirmed if you see the issue issue as well with the more recent kernels), that the specified commit actually uncovers the issue present possibly with the HW. Similarly to you someone else, where in known case with faulty HW, reported the following issue upstream: https://lore.kernel.org/lkml/20200720083956.ga4...@dhcp22.suse.cz/ I would like to see if we can collect as much information as possible and possibly crosscheck with upstream. If build the kernel with the attached patch (that is with the commit wich is supsected to uncover the issue), does then the issue goes away? You can folllow the quide in https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2 for the "simple patching and building" and quickly chekcing a patch. Regards, Salvatore dmesg.txt.gz Description: application/gzip
