Bug#978084: marked as done (CPU: 2 PID: 5507 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2548)
Your message dated Tue, 11 May 2021 07:25:04 +0200 with message-id <20210511052504.ga18...@lorien.valinor.li> and subject line Re: Bug#978084: CPU: 2 PID: 5507 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2548 has caused the Debian Bug report #978084, regarding CPU: 2 PID: 5507 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2548 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 978084: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978084 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: src:linux Version: 5.10.2-1~exp1 Severity: minor Hello there, The following message was found after suspension in dmesg: [ 1305.813835] WARNING: CPU: 2 PID: 5507 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2548 dc_link_set_backlight_level+0x8a/0xf0 [amdgpu] [ 1305.813837] Modules linked in: ctr ccm rfcomm nf_tables nfnetlink cmac algif_hash algif_skcipher af_alg bnep tpm_crb btusb snd_hda_codec_conexant btrtl snd_hda_codec_hdmi btbcm btintel btrfs snd_hda_codec_generic bluetooth snd_hda_intel snd_intel_dspcfg jitterentropy_rng soundwire_intel edac_mce_amd soundwire_generic_allocation snd_soc_core drbg kvm_amd rtw88_8822be rtw88_8822b blake2b_generic snd_compress rtw88_pci kvm soundwire_cadence xor rtw88_core snd_hda_codec uvcvideo nls_ascii snd_hda_core snd_hwdep videobuf2_vmalloc nls_cp437 videobuf2_memops videobuf2_v4l2 irqbypass videobuf2_common videodev vfat soundwire_bus mac80211 mc fat ghash_clmulni_intel aes_generic aesni_intel snd_pcm ansi_cprng snd_rn_pci_acp3x ecdh_generic snd_pci_acp3x ecc thinkpad_acpi crypto_simd crc16 libaes cryptd snd_timer glue_helper cfg80211 nvram ledtrig_audio snd raid6_pq libarc4 soundcore rapl sg rfkill ac joydev k10temp ccp sp5100_tco watchdog tpm_tis tpm_tis_core tpm ucsi_acpi acpi_cpufreq wmi_bmof [ 1305.813920] rng_core evdev typec_ucsi typec efi_pstore serio_raw pcspkr fuse configfs efivarfs ip_tables x_tables autofs4 xfs libcrc32c crc32c_generic sd_mod amdgpu rtsx_pci_sdmmc mmc_core gpu_sched i2c_algo_bit ttm xhci_pci drm_kms_helper i2c_piix4 ahci nvme libahci xhci_hcd crc32_pclmul cec crc32c_intel libata psmouse nvme_core drm usbcore scsi_mod t10_pi r8169 crc_t10dif realtek mdio_devres usb_common libphy rtsx_pci crct10dif_generic crct10dif_pclmul crct10dif_common wmi battery video i2c_scmi button [ 1305.813979] CPU: 2 PID: 5507 Comm: xfpm-power-back Tainted: GW 5.10.0-trunk-amd64 #1 Debian 5.10.2-1~exp1 [ 1305.813981] Hardware name: LENOVO 20NECTO1WW/20NECTO1WW, BIOS R11ET40P (1.20 ) 11/17/2020 [ 1305.814140] RIP: 0010:dc_link_set_backlight_level+0x8a/0xf0 [amdgpu] [ 1305.814144] Code: 60 03 00 00 31 c0 48 8d 96 c0 01 00 00 48 8b 0a 48 85 c9 74 06 48 3b 59 08 74 20 83 c0 01 48 81 c2 d8 04 00 00 83 f8 06 75 e3 <0f> 0b 45 31 e4 5b 44 89 e0 5d 41 5c 41 5d 41 5e c3 48 98 48 69 c0 [ 1305.814147] RSP: 0018:b37602b43df0 EFLAGS: 00010246 [ 1305.814150] RAX: 0006 RBX: 9e108a973800 RCX: [ 1305.814152] RDX: 9e1089681ed0 RSI: 9e108968 RDI: [ 1305.814153] RBP: 9e108a91 R08: 0033 R09: 000a [ 1305.814155] R10: 000a R11: f000 R12: 3501 [ 1305.814156] R13: R14: 359c R15: 9e10fc023820 [ 1305.814159] FS: 7ff8adfc3b80() GS:9e1234a8() knlGS: [ 1305.814161] CS: 0010 DS: ES: CR0: 80050033 [ 1305.814163] CR2: 7ff8ae0aade0 CR3: 00010947e000 CR4: 003506e0 [ 1305.814165] Call Trace: [ 1305.814340] amdgpu_dm_backlight_update_status+0xb4/0xc0 [amdgpu] [ 1305.814349] backlight_device_set_brightness+0x7e/0x130 [ 1305.814355] ? kernfs_fop_write+0x131/0x1b0 [ 1305.814360] brightness_store+0x5b/0x70 [ 1305.814364] kernfs_fop_write+0xce/0x1b0 [ 1305.814370] vfs_write+0xc0/0x260 [ 1305.814374] ksys_write+0x5f/0xe0 [ 1305.814380] do_syscall_64+0x33/0x80 [ 1305.814385] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 1305.814389] RIP: 0033:0x7ff8ae148ed3 [ 1305.814392] Code: 8b 15 c1 ef 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 55 c3 0f 1f 40 00 48 83 ec 28 48 89 54 24 18 [ 1305.814394] RSP: 002b:7ffc381e0b88 EFLAGS: 0246 ORIG_RAX: 0001 [ 1305.814396] RAX: ffda RBX: 563a13783000 RCX: 7ff8ae148ed3 [ 1305.814398] RDX: 0002 RSI: 563a13781eb0 RDI: 0003 [ 1305.814399] RBP: 563a13781eb0 R08: R09: 0002 [ 1305.8
Processed (with 5 errors): Re: Bug#978084: CPU: 2 PID: 5507 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2548
Processing commands for cont...@bugs.debian.org: > Source: linux Unknown command or malformed arguments to command. > Source-Version: 5.10.28-1 Unknown command or malformed arguments to command. > tags 978084 - moreinfo Bug #978084 [src:linux] CPU: 2 PID: 5507 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2548 Removed tag(s) moreinfo. > On Mon, May 10, 2021 at 08:53:17PM -0500, NG wrote: Unknown command or malformed arguments to command. > > Hi there, Unknown command or malformed arguments to command. > > I cannot reproduce this bug anymore (tested with linux 5.10.28-1 aka linux Unknown command or malformed arguments to command. Too many unknown commands, stopping here. Please contact me if you need assistance. -- 978084: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978084 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#978084: CPU: 2 PID: 5507 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2548
Hi there, I cannot reproduce this bug anymore (tested with linux 5.10.28-1 aka linux 5.10.0-6-amd64 debian sid) Great! Peace. El 8/05/21 a las 8:02 a. m., Salvatore Bonaccorso escribió: is this still something you can reproduce with a recent 5.10.y kernel? Regards, Salvatore
Bug#988333: linux-image-5.10.0-6-amd64: VGA Intel IGD Passthrough to Debian Xen HVM DomUs not working, but Windows Xen HVMs do work
Package: src:linux Version: 5.10.28-1 Severity: normal Tags: upstream Dear Maintainer, I have been using Xen's PCI and VGA passthrough feature since wheezy and jessie were the stable versions, and back then both Windows HVMs and Linux HVMs would function with the Intel Integrated Graphics Device (IGD), the audio device, and the USB 3 controller passed to them. But with buster and bullseye running as the Dom0, I can only get the VGA/Passthrough feature to work with Windows Xen HVMs. I would expect both Windows and Linux HVMs to work comparably well. -- Package-specific info: Linux version 5.10.0-6-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.2) #1 SMP Debian 5.10.28-1 (2021-04-09) BOOT_IMAGE=/boot/vmlinuz-5.10.0-6-amd64 root=UUID=332b3875-d57c-4083-9d46-3faa28d60691 ro xen-fbfront.video=24,1368,768 quiet - this is what I have on the bullseye DomU. On the Dom0, I have BOOT_IMAGE=/boot/vmlinuz-5.10.0-6-amd64 root=/dev/debian/bullseye ro reboot=bios quiet console=tty1 console=hvc0 On Dom0, the Xen commandline and version (from xl dmesg): dom0_mem=2G,max:2G smt=false pv-l1tf=false iommu=1 no-real-mode edd=off Xen version 4.14.2-pre (Debian 4.14.1+11-gb0b734a8b3-1) (pkg-xen-de...@lists.alioth.debian.org) (x86_64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) debug=n Sun Feb 28 18:49:45 UTC 2021 Bootloader: GRUB 2.02+dfsg1-20+deb10u2 kernel logs (problems reported in Dom0's syslog when trying to start this Debian bullseye Xen HVM DomU with Xen VGA/PCI passthrough configured): May 9 10:52:20 bullseye kernel: [0.00] Linux version 5.10.0-6-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.2) #1 SMP Debian 5.10.28-1 (2021-04-09) May 9 10:52:20 bullseye kernel: [0.00] Command line: placeholder root=/dev/debian/bullseye ro reboot=bios quiet console=tty1 console=hvc0 . . . Start a bullseye Xen HVM configured for PCI/VGA passthrough using the bullseye Xen and Qemu packages for bullseye on Dom0 (Haswell Intel IGD + audio device + USB 3.0 controller): May 10 08:50:03 bullseye kernel: [79077.644346] pciback :00:1b.0: xen_pciback: vpci: assign to virtual slot 0 May 10 08:50:03 bullseye kernel: [79077.644478] pciback :00:1b.0: registering for 16 May 10 08:50:03 bullseye kernel: [79077.644732] pciback :00:14.0: xen_pciback: vpci: assign to virtual slot 1 May 10 08:50:03 bullseye kernel: [79077.644874] pciback :00:14.0: registering for 16 May 10 08:50:03 bullseye kernel: [79077.645024] pciback :00:02.0: xen_pciback: vpci: assign to virtual slot 2 May 10 08:50:03 bullseye kernel: [79077.645107] pciback :00:02.0: registering for 16 May 10 08:50:30 bullseye kernel: [79105.273876] vif vif-16-0 vif16.0: Guest Rx ready May 10 08:50:30 bullseye kernel: [79105.273893] IPv6: ADDRCONF(NETDEV_CHANGE): vif16.0: link becomes ready May 10 08:50:30 bullseye kernel: [79105.278023] xen-blkback: backend/vbd/16/51712: using 4 queues, protocol 1 (x86_64-abi) persistent grants May 10 08:50:44 bullseye kernel: [79119.104937] irq 16: nobody cared (try booting with the "irqpoll" option) May 10 08:50:44 bullseye kernel: [79119.104973] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.0-6-amd64 #1 Debian 5.10.28-1 May 10 08:50:44 bullseye kernel: [79119.104976] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B85M Pro4, BIOS P2.50 12/11/2015 May 10 08:50:44 bullseye kernel: [79119.104979] Call Trace: May 10 08:50:44 bullseye kernel: [79119.104984] May 10 08:50:44 bullseye kernel: [79119.104998] dump_stack+0x6b/0x83 May 10 08:50:44 bullseye kernel: [79119.105008] __report_bad_irq+0x35/0xa7 May 10 08:50:44 bullseye kernel: [79119.105014] note_interrupt.cold+0xb/0x61 May 10 08:50:44 bullseye kernel: [79119.105024] handle_irq_event+0xa8/0xb0 May 10 08:50:44 bullseye kernel: [79119.105030] handle_fasteoi_irq+0x78/0x1c0 May 10 08:50:44 bullseye kernel: [79119.105037] generic_handle_irq+0x47/0x50 May 10 08:50:44 bullseye kernel: [79119.105044] __evtchn_fifo_handle_events+0x175/0x190 May 10 08:50:44 bullseye kernel: [79119.105054] __xen_evtchn_do_upcall+0x66/0xb0 May 10 08:50:44 bullseye kernel: [79119.105063] __xen_pv_evtchn_do_upcall+0x11/0x20 May 10 08:50:44 bullseye kernel: [79119.105069] asm_call_irq_on_stack+0x12/0x20 May 10 08:50:44 bullseye kernel: [79119.105072] May 10 08:50:44 bullseye kernel: [79119.105079] xen_pv_evtchn_do_upcall+0xa2/0xc0 May 10 08:50:44 bullseye kernel: [79119.105084] exc_xen_hypervisor_callback+0x8/0x10 May 10 08:50:44 bullseye kernel: [79119.105091] RIP: e030:xen_hypercall_sched_op+0xa/0x20 May 10 08:50:44 bullseye kernel: [79119.105097] Code: 51 41 53 b8 1c 00 00 00 0f 05 41 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 51 41 53 b8 1d 00 00 00 0f 05 <41> 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc May 10 08:50:44 bullseye kernel:
Processed: tagging 830303, found 830303 in 5.10.28-1
Processing commands for cont...@bugs.debian.org: > tags 830303 - moreinfo Bug #830303 [src:linux] sdhci_pci: SD card reader gives error "mmc0: error -110 whilst initialising SD card" Ignoring request to alter tags of bug #830303 to the same tags previously set > found 830303 5.10.28-1 Bug #830303 [src:linux] sdhci_pci: SD card reader gives error "mmc0: error -110 whilst initialising SD card" Marked as found in versions linux/5.10.28-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 830303: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830303 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#987576: linux: Please enable CONFIG_SND_AUDIO_GRAPH_CARD
There's an upstream commit (part of 5.12) that Vincent referenced that nicely illustrates the difference between what I want to achieve with this bug report and a possible solution applied in that commit (IIUC): https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=25572fb5aa986bdbb35d06c0fb52a9b9d9b3b2c9 In that commit there's a switch from 'audio-graph-card' to 'simple-audio-card'. If that change were applied to Debian, that should make the audio work (too) on a Rock64. And if upstream would backport that commit to 5.10, Debian would only have to upgrade to a latter 5.10 version to get it. But there's a line in that commit message that illustrates what I want to achieve with this bug report: "For newly adding nodes, ASoC guys recommend to use audio-graph-card." What I get from that and is what I assumed previously, is that 'audio-graph-card' is seen as 'basic building block' for audio in SBCs. (Just like 'simple-audio-card' is). And that is why I want it enabled in the Debian kernel(s). Just a 'backport' of above referenced commit would fix my issue on my Rock64s, but afaic it wouldn't fix this bug. Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#833035: linux-image-3.16.0-4-amd64: Keyspan USB serial adapter USA-49WLC failed to load firmware
salvatore wrote: > Control: tags -1 + moreinfo > > Hi, > > On Thu, Oct 19, 2017 at 05:29:41PM -0400, Paul Fox wrote: > > chris wrote: > > > On 10/16/2017 11:32 AM, Paul Fox wrote: > > > > ben, chris -- regarding this bug: > > > > Bug#833035: linux-image-3.16.0-4-amd64: Keyspan USB serial adapter > > > > USA-49WLC failed to load firmware > > > > > > > > whatever became of the proposed patch. i'm running ubuntu 16.04.3, > > > > kernel 4.4.0-97-generic, and the failure is still present there. > > > > > > > > paul > > > > . > > > > > > > The patch provided fixed the bug. I think I responded with the news. > > > > yes -- sorry for not being clear. i was wondering whether the fix had > > gone upstream, and if not, why not. > > Has the fix been upstreamed or the issue fixed in meanwhile with a > recent kernel? > > Regards, > Salvatore > I just dug out the device and tried it. The bug persists in: Linux grass 5.4.0-72-generic #80-Ubuntu SMP Mon Apr 12 17:35:00 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux dmesg log looks much the same as those originally posted, though somewhat different, and the returned error number (-2) is different than the -5 reported by Chris Rhodin: [860822.854435] usb 2-1.8: new full-speed USB device number 5 using ehci-pci [860822.963452] usb 2-1.8: New USB device found, idVendor=06cd, idProduct=011a, bcdDevice=c0.01 [860822.963455] usb 2-1.8: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [860822.963986] keyspan 2-1.8:1.0: Keyspan - (without firmware) converter detected [860822.964036] usb 2-1.8: Direct firmware load for keyspan/usa49wlc.fw failed with error -2 [860822.964041] usb 2-1.8: ezusb_ihex_firmware_download - request "keyspan/usa49wlc.fw" failed [860822.965538] usb 2-1.8: failed to load firmware "keyspan/usa49wlc.fw" [860822.967366] keyspan: probe of 2-1.8:1.0 failed with error -2 [860848.230938] usb 2-1.8: USB disconnect, device number 5 paul =-- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 50.4 degrees)
Processed: tagging 830303
Processing commands for cont...@bugs.debian.org: > tags 830303 - moreinfo Bug #830303 [src:linux] sdhci_pci: SD card reader gives error "mmc0: error -110 whilst initialising SD card" Ignoring request to alter tags of bug #830303 to the same tags previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 830303: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830303 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#830303: mmc0: Unexpected interrupt 0x04000000.
On Mon, May 10, 2021 at 2:51 PM Alexandros Kosiaris wrote: > > On Sun, May 9, 2021 at 11:06 PM Salvatore Bonaccorso > wrote: > > > > Contol: tags -1 + moreinfo > > > > On Mon, Feb 18, 2019 at 11:54:23PM +0200, Alexandros Kosiaris wrote: > > > Hi, > > > > > > For what it's worth, it seems on this specific hardware: > > > > > > Broadcom Limited BCM57765/57785 SDXC/MMC Card Reader [14e4:16bc] > > > > > > the problem can be resolved by passing: > > > > > > debug_quirks2=0x4 to sdhci kernel module. > > > > > > Note that there is also the debug_quirks param. I did set some values > > > for it but the working one is the default, namely 0 > > > > > > For more information have a look at > > > https://bugzilla.kernel.org/show_bug.cgi?id=73241#c55 > > > > > > I just tested it on a Macmini7,1Debian having Stretch with > > > 4.19+101~bpo9+1 kernel. I 'll be using it for the next few days, I am > > > hoping everything will work out ok and I won't have to report more > > > stuff > > > > is the issue still reproducible with a recent kernel? If not we might > > go ahead and close the bugreport. > > It is. I just tried on buster's 4.19.0-16-amd64 and the issue persists > for me. I 'll also try to reproduce with bullseye's 5.10.28-1 and > report results here. Reproduced on bullseye with 5.10.28-1 as well. The fix remains to have in a file in /etc/modprobe.d (e.g. sdhci.conf) the following: options sdhci debug_quirks2=0x4 Regards,
Bug#830303: mmc0: Unexpected interrupt 0x04000000.
On Sun, May 9, 2021 at 11:06 PM Salvatore Bonaccorso wrote: > > Contol: tags -1 + moreinfo > > On Mon, Feb 18, 2019 at 11:54:23PM +0200, Alexandros Kosiaris wrote: > > Hi, > > > > For what it's worth, it seems on this specific hardware: > > > > Broadcom Limited BCM57765/57785 SDXC/MMC Card Reader [14e4:16bc] > > > > the problem can be resolved by passing: > > > > debug_quirks2=0x4 to sdhci kernel module. > > > > Note that there is also the debug_quirks param. I did set some values > > for it but the working one is the default, namely 0 > > > > For more information have a look at > > https://bugzilla.kernel.org/show_bug.cgi?id=73241#c55 > > > > I just tested it on a Macmini7,1Debian having Stretch with > > 4.19+101~bpo9+1 kernel. I 'll be using it for the next few days, I am > > hoping everything will work out ok and I won't have to report more > > stuff > > is the issue still reproducible with a recent kernel? If not we might > go ahead and close the bugreport. It is. I just tried on buster's 4.19.0-16-amd64 and the issue persists for me. I 'll also try to reproduce with bullseye's 5.10.28-1 and report results here. > > Regards, > Salvatore
Bug#711108: linux-image-* should suggest linux-tools-*
Salvatore Bonaccorso : > I'm closing this bug now as I think it's not anymore relevant in this > outlined form. But please let me know if you disagree. Why do you believe so? Did anything change, other than renaming linux-tools to linu-perf?
Bug#837907: marked as done (stat() hangs on a particular file)
Your message dated Mon, 10 May 2021 09:36:41 +0200
with message-id <20210510073641.ga1...@lorien.valinor.li>
and subject line Re: Bug#837907: stat() hangs on a particular file
has caused the Debian Bug report #837907,
regarding stat() hangs on a particular file
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
837907: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837907
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: linux-image-3.16.0-4-amd64
Version: 3.16.36-1+deb8u1
One of our systems is suddenly unable to stat() a particular file
(cookies.sqlite-wal in a user's Firefox profile). Any attempt to
do so hangs in the system call, as shown by strace. The file resides
on an NFSv4 share (sec=krb5p). Other files in the same directory on
the same share remain accessible. The affected file is normally accessible
on the NFS server and from other NFS clients running the same kernel.
The user has reported a similar incident yesterday on some directories
on a different NFS share (also sec=krb5p, but hosted on a different
server). He rebooted to clear up the problem.
I'd like advice on how to troubleshoot this effectively. I've tried
rpcdebug -m {nfs,rpc,nlm} -s all but didn't see any smoking gun; maybe
some information cached by the kernel is suppressing NFS activity
associated with the stat() calls. The log entries I do see say
NFS: nfs_lookup_revalidate(cookies.sqlite-wal) is valid
Some related kernel traces from this system's logs (in chronological order,
with an intervening reboot; the first trace is associated with yesterday's
incident, the second trace is 2-3 minutes newer than the timestamp on
cookies.sqlite-wal):
[97483.663949] INFO: task ls:23767 blocked for more than 120 seconds.
[97483.663951] Tainted: PW O 3.16.0-4-amd64 #1
[97483.663952] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[97483.663954] ls D 8800afd3b808 0 23767 1 0x0004
[97483.663957] 8800afd3b3b0 0086 00012f40
88039a057fd8
[97483.663960] 00012f40 8800afd3b3b0 88041ea137f0
88041edcd128
[97483.663962] 0002 8113eb50 88039a057d60
88039a057e40
[97483.663965] Call Trace:
[97483.663968] [] ? wait_on_page_read+0x60/0x60
[97483.663971] [] ? io_schedule+0x99/0x120
[97483.663974] [] ? sleep_on_page+0xa/0x10
[97483.663977] [] ? __wait_on_bit+0x5c/0x90
[97483.663980] [] ? wait_on_page_bit+0xc6/0xd0
[97483.663983] [] ? autoremove_wake_function+0x30/0x30
[97483.663986] [] ? pagevec_lookup_tag+0x1d/0x30
[97483.663989] [] ? filemap_fdatawait_range+0xd0/0x160
[97483.663993] [] ? filemap_write_and_wait+0x36/0x50
[97483.664002] [] ? nfs_getattr+0x108/0x220 [nfs]
[97483.664005] [] ? vfs_fstatat+0x57/0x90
[97483.664009] [] ? SYSC_newlstat+0x1d/0x40
[97483.664013] [] ? system_call_fast_compare_end+0x10/0x15
[ 9724.415533] INFO: task mozStorage #5:2748 blocked for more than 120 seconds.
[ 9724.415537] Tainted: PW O 3.16.0-4-amd64 #1
[ 9724.415538] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 9724.415539] mozStorage #5 D 8803ee153a88 0 2748 2323 0x
[ 9724.415542] 8803ee153630 0082 00012f40
8803ee2cffd8
[ 9724.415544] 00012f40 8803ee153630 88041ea537f0
88041edaf7a0
[ 9724.415545] 0002 a0669800 8803ee2cfc30
88040b1152c0
[ 9724.415547] Call Trace:
[ 9724.415557] [] ? nfs_pageio_doio+0x50/0x50 [nfs]
[ 9724.415560] [] ? io_schedule+0x99/0x120
[ 9724.415563] [] ? nfs_wait_bit_uninterruptible+0xa/0x10
[nfs]
[ 9724.415566] [] ? __wait_on_bit+0x5c/0x90
[ 9724.415568] [] ? internal_add_timer+0x2a/0x70
[ 9724.415571] [] ? nfs_pageio_doio+0x50/0x50 [nfs]
[ 9724.415573] [] ? out_of_line_wait_on_bit+0x77/0x90
[ 9724.415575] [] ? autoremove_wake_function+0x30/0x30
[ 9724.415578] [] ? nfs_updatepage+0x15e/0x830 [nfs]
[ 9724.415582] [] ? nfs_write_end+0x57/0x320 [nfs]
[ 9724.415585] [] ? iov_iter_copy_from_user_atomic+0x75/0x190
[ 9724.415588] [] ? generic_perform_write+0x11b/0x1c0
[ 9724.415590] [] ? __generic_file_write_iter+0x158/0x340
[ 9724.415592] [] ? generic_file_write_iter+0x39/0xa0
[ 9724.415595] [] ? nfs_file_write+0x83/0x1a0 [nfs]
[ 9724.415598] [] ? new_sync_write+0x74/0xa0
[ 9724.415600] [] ? vfs_write+0xb2/0x1f0
[ 9724.415601] [] ? SyS_write+0x42/0xa0
[ 9724.415603] [] ? SyS_lseek+0x43/0xa0
[ 9724.415605] [] ? system_call_fast_compare_end+0x10/0x15
--- End Message ---
--- Begin Message ---
Hi Ser
Bug#837907: stat() hangs on a particular file
* Salvatore Bonaccorso [2021-05-09 22:37:02 +0200]: > Control: tags -1 + moreinfo > > Do you still can reproduce the issue with a recent kernel? No, I haven't seen it in a while (and never with 4.9 or 4.19 either; nor with 5.10 but that's statistically less significant).
