Bug#982478: linux-image-5.10.0-3-amd64: kernel bug in pwc breaks webcam usage
Package: src:linux Version: 5.10.13-1 Severity: important Tags: patch Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Linux Kernel 5.10 introduced a bug to pwc which breaks some webcams (eg Logitech Quickcam Zoom) This bug did not exist in 5.9 * What exactly did you do (or not do) that was effective (or ineffective)? Start an application which uses the webcam like Cheese or Zoom. * What was the outcome of this action? Webcam does not work the LED at the webcam flickers shortly but no picture * What outcome did you expect instead? Working live video *** End of the template - remove these template lines *** dmesg shows [ 428.111814] WARNING: CPU: 0 PID: 1449 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x141/0x200 [ 428.111815] Modules linked in: cpufreq_ondemand vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_device pwc videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi edac_mce_amd snd_hda_intel snd_intel_dspcfg kvm_amd binfmt_misc soundwire_intel soundwire_generic_allocation kvm snd_soc_core irqbypass snd_compress soundwire_cadence eeepc_wmi snd_hda_codec ghash_clmulni_intel asus_wmi snd_hda_core snd_hwdep soundwire_bus battery sparse_keymap aesni_intel snd_pcm rfkill serio_raw libaes crypto_simd snd_timer cryptd glue_helper rapl ccp pcspkr snd sp5100_tco wmi_bmof watchdog k10temp sg soundcore rng_core evdev acpi_cpufreq msr parport_pc ppdev lp parport fuse configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic sd_mod t10_pi crc_t10dif crct10dif_generic sr_mod cdrom uas usb_storage hid_generic usbhid hid amdgpu crct10dif_pclmul [ 428.111900] crct10dif_common crc32_pclmul crc32c_intel gpu_sched i2c_algo_bit ttm i2c_piix4 drm_kms_helper ahci libahci cec xhci_pci xhci_hcd drm libata r8169 realtek mdio_devres usbcore libphy scsi_mod usb_common wmi video gpio_amdpt gpio_generic button [ 428.111928] CPU: 0 PID: 1449 Comm: pipewire Tainted: G OE 5.10.0-3-amd64 #1 Debian 5.10.13-1 [ 428.111930] Hardware name: System manufacturer System Product Name/PRIME B450M-A, BIOS 2807 02/01/2021 [ 428.111933] RIP: 0010:dma_map_page_attrs+0x141/0x200 [ 428.111938] Code: 89 c8 4c 89 df e8 cf 22 00 00 49 89 c2 eb 8c 48 85 c0 74 0c 48 39 d8 48 0f 47 c3 e9 76 ff ff ff 48 89 d8 e9 6e ff ff ff 0f 0b <0f> 0b 49 c7 c2 ff ff ff ff e9 63 ff ff ff 49 89 f2 4c 2b 50 18 e9 [ 428.111940] RSP: 0018:b802025a7cb0 EFLAGS: 00010246 [ 428.111943] RAX: RBX: 992d07f1ee00 RCX: 0002 [ 428.111944] RDX: 2580 RSI: f9e8857b0c00 RDI: 992d694da0a0 [ 428.111946] RBP: R08: R09: [ 428.111947] R10: R11: 992d694da0a0 R12: 992d694da000 [ 428.111949] R13: 992d5ec3 R14: 992d07a3 R15: [ 428.111952] FS: 7f76d9b68b80() GS:99340fa0() knlGS: [ 428.111953] CS: 0010 DS: ES: CR0: 80050033 [ 428.111955] CR2: 0d6b925565a8 CR3: 00010819a000 CR4: 003506f0 [ 428.111957] Call Trace: [ 428.111969] start_streaming+0x292/0x4a0 [pwc] [ 428.111978] vb2_start_streaming+0x63/0x100 [videobuf2_common] [ 428.111985] vb2_core_streamon+0x54/0xb0 [videobuf2_common] [ 428.111998] __video_do_ioctl+0x39e/0x3d0 [videodev] [ 428.112013] video_usercopy+0x173/0x590 [videodev] [ 428.112026] ? v4l_print_control+0x20/0x20 [videodev] [ 428.112032] ? __schedule+0x28a/0x870 [ 428.112044] v4l2_ioctl+0x48/0x50 [videodev] [ 428.112049] __x64_sys_ioctl+0x83/0xb0 [ 428.112053] do_syscall_64+0x33/0x80 [ 428.112057] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 428.112060] RIP: 0033:0x7f76d9c64cc7 [ 428.112064] Code: 00 00 00 48 8b 05 c9 91 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 99 91 0c 00 f7 d8 64 89 01 48 [ 428.112066] RSP: 002b:7ffc24729a38 EFLAGS: 0246 ORIG_RAX: 0010 [ 428.112069] RAX: ffda RBX: 0003 RCX: 7f76d9c64cc7 [ 428.112070] RDX: 7ffc24729a44 RSI: 40045612 RDI: 0029 [ 428.112071] RBP: 5603bc718698 R08: 0001 R09: 0030 [ 428.112073] R10: 0018 R11: 0246 R12: 0029 [ 428.112074] R13: 7ffc24729a44 R14: 5603bc71a7b8 R15: 5603bc71b700 [ 428.112078] ---[ end trace 7aac295dd2fac45d ]--- [ 428.112081] pwc: Failed to allocate urb buffer 0 [ 428.623806] pwc: Failed to allocate urb buffer 0 A bug report for Fedora exists: https://bugzilla.redhat.com/show_bug.cgi?id=1918778 Fedora integrated this patch in their 5.10 kernel: https://lkml.org/lkml/2021/1/21/1300 I tested their patched 5.10 kernel and c
Bug#963025: (no subject)
Got the same issue with latest kernel and iwlwifi firmware from sid > cat /proc/version Linux version 5.10.0-3-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 5.10.12-1 (2021-01-30) > dpkg -l firmware-iwlwifi ii firmware-iwlwifi 20201218-3 all Binary firmware for Intel Wireless cards As far as I can tell, it only happens when trying to connect to a 5GHz wifi network using 80mhz wide channel. I updated my AP configuration to use only 20 or 40mhz channels and everything works fine now. I also found an old bug [1] describing the same issue, but it's stated to be solved and has been closed. Hope this can help, Cheers, Jean Baptiste [1]: https://bugzilla.kernel.org/show_bug.cgi?id=205055 OpenPGP_signature Description: OpenPGP digital signature
Re: [patch 09/14] tmpfs: disallow CONFIG_TMPFS_INODE64 on alpha
On Wed, Feb 10, 2021 at 8:17 PM Linus Torvalds
wrote:
>
> On Wed, Feb 10, 2021 at 5:39 AM Heiko Carstens wrote:
> >
> > I couldn't spot any and also gave the patch below a try and my system
> > still boots without any errors.
> > So, as far as I can tell it _should_ be ok to change this.
>
> So your patch (with the fix on top) looks sane to me.
>
> I'm not entirely sure it is worth it, but the fact that we've had bugs
> wrt this before does seem to imply that we should do this.
>
> I'd remove the __kernel_ino_t type entirely, but I wonder if user
> space might depend on it. I do find
>
>#ifndef __kernel_ino_t
>typedef __kernel_ulong_t __kernel_ino_t;
>#endif
>
> in the GNU libc headers I have, but then I don't find any actual use
> of that, so it looks like it may be jyst a "we copied things for other
> reasons".
I checked debian codesearch to see if there are any users in
distro source code and found exactly one instance that will
definitely break at compile time:
https://sources.debian.org/src/nfs-utils/1:1.3.4-4/support/include/nfs/nfs.h/?hl=99#L99
This is a copy of a kernel header that was removed ten years ago
with commit c152292f9ee7 ("nfsd: remove include/linux/nfsd/syscall.h").
The mainline version of that package removed the contents in 2016 in
the following release (2.1.1), but debian is still on the previous
version (1.3.4)
http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=fc1127d754578cd1
Someone will have to update the package for Debian, but it seems
that would be a good idea anyway.
Arnd
Re: Please revert CONFIG_MIPS_O32_FP64_SUPPORT change mipsel
Ivo De Decker 于2021年2月9日周二 下午9:45写道： > > Hi, > > On Mon, Jun 08, 2020 at 08:15:38PM +0300, Adrian Bunk wrote: > > On Fri, May 29, 2020 at 11:03:14PM +0200, Aurelien Jarno wrote: > > > On 2020-05-28 09:04, YunQiang Su wrote: > > > > Adrian Bunk 于2020年5月21日周四 下午3:40写道： > > > > > On Thu, May 21, 2020 at 06:41:34AM +0800, YunQiang Su wrote: > > > > > > Adrian Bunk 于2020年5月21日周四 上午4:44写道： > > > > > > > On Tue, May 19, 2020 at 11:43:30AM +0800, Shengjing Zhu wrote: > > > > > > > > > > > > > > > > FTR, after giving back golang-1.14 mipsel several times, it's > > > > > > > > finally > > > > > > > > built, by a longson builder. > > > > > > > > So I guess it only occurs on octeon. Since the porterbox eller > > > > > > > > is also > > > > > > > > octeon, it also can't build any go program. > > > > > > > > > > > > > > On eller golang-1.14 fails to build both in sid and buster > > > > > > > chroots. > > > > > > > > > > > > > > golang-1.11 also fails to build in a buster chroot with floating > > > > > > > point > > > > > > > test errors. > > > > > > > > > > > > > > golang-1.14 gets unbroken by GOMIPS=softfloat. > > > > > > > > > > > > > > The only kernel configuration change on eller in the buster point > > > > > > > release is CONFIG_MIPS_O32_FP64_SUPPORT=y, everything observed > > > > > > > would > > > > > > > make sense if the problem is that golang-1.11 and golang-1.14 are > > > > > > > not compatible with CONFIG_MIPS_O32_FP64_SUPPORT. > > > > > > > > > > > > It is just support O32_FP64. I don't expect it will have any effect. > > > > > > Since currently, the toolchain/libraries are all FPXX. > > > > > > > > > > Only the gcc/binutils toolchain/libraries or also the Go toolchain? > > > > > > > > you are right. the current golang still output FP32 object... > > > > So, we think that it is buggy. > > > > > > > > Since Loongson CPU has some strange behaviour, it even can work... > > > > Let's try to patch golang to support FPXX or FP64. > > > > > > > > https://github.com/golang/go/issues/39289 > > > > > > That's probably a solution for bullseye/sid, however we can't backport > > > such changes and rebuild the go world in buster. I therefore think that > > > for buster the kernel change has to be reverted. > > > > What is clear at this point is that the kernel change should be reverted > > in buster since it causes a regression (including build failures on > > buildds). I am cloning this bug for a revert in the kernel of > > https://salsa.debian.org/kernel-team/linux/-/commit/947fbc66183d022fe3de7871dfb262d2b87af826 > > > > I am marking the version in bullseye as found since we might run into > > the same problem again when buster DSAs will be built on machines > > running the bullseye kernel after the release of bullseye. It might be > > possible to mitigate this problem (e.g. in the kernel or by keeping some > > buildd running with the buster kernel), but without an open bug this > > issue might get forgotten and then resurface after the bullseye release. > > Could the mips porters comment on this? Given that we're close to the release > of bullseye, I'm not convinced it's a good idea to change this now. Yes. It will be a problem to run with buster's golang program on bullseys's kernel. Let's have another way to get this problem sloved without revert this changes. Maybe detect the golang applications and run them in FP32 mode? > > Cheers, > > Ivo > >
Bug#962485: Please revert CONFIG_MIPS_O32_FP64_SUPPORT change mipsel
Moin On Thu, Feb 11, 2021 at 10:15:02AM +0800, YunQiang Su wrote: > > Could the mips porters comment on this? Given that we're close to the > > release > > of bullseye, I'm not convinced it's a good idea to change this now. This option is also a dependency of several types of CPU support. So it might not be feasable to disable. > Yes. It will be a problem to run with buster's golang program on > bullseys's kernel. > Let's have another way to get this problem sloved without revert this changes. Sure, by discontinuing support for go on mips for example. > Maybe detect the golang applications and run them in FP32 mode? The kernel already does. But it seems go decided to set the FPXX marker on it's objects. See https://github.com/golang/go/issues/39435 Bastian -- Captain's Log, star date 21:34.5...
