Bug#1025537: nfsd: Kernel Oops while serving NFS
Source: linux Followup-For: Bug #1025537 The 6.1.0 Changelog had some notes about a gnarly bug in the NFS bug having been fixed, so I thought I'd give it a try. Unfortunately, the problem reported here is still present. It has made the machine quite unstable, but I was able to retrieve logs of previous Oopses. 2023-03-02T12:51:02.923421+11:00 supahwinch kernel: [0.00] Linux version 6.1.0-5-amd64 (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.12-1 (2023-02-15) [SNIP]-8< 2023-03-02T13:11:21.468088+11:00 supahwinch kernel: [ 1262.015083] stack segment: [#1] PREEMPT SMP NOPTI 2023-03-02T13:11:21.473246+11:00 supahwinch kernel: [ 1262.019939] CPU: 0 PID: 3345 Comm: nfsd Not tainted 6.1.0-5-amd64 #1 Debian 6.1.12-1 2023-03-02T13:11:21.473258+11:00 supahwinch kernel: [ 1262.024779] Hardware name: HP ProLiant MicroServer, BIOS O41 10/01/2013 2023-03-02T13:11:21.473261+11:00 supahwinch kernel: [ 1262.029613] RIP: 0010:release_pages+0xcd/0x4d0 2023-03-02T13:11:21.473264+11:00 supahwinch kernel: [ 1262.034410] Code: 84 c0 74 1a 48 8b 04 24 48 8d 4c 24 30 49 89 46 08 48 89 44 24 30 4c 89 75 08 48 89 4d 10 49 83 c7 08 4c 39 fb 74 75 49 8b 2f <48> 8b 45 08 a8 01 0f 85 58 01 00 00 0f 1f 44 00 00 4d 85 ed 74 0e 2023-03-02T13:11:21.473268+11:00 supahwinch kernel: [ 1262.044534] RSP: 0018:bc550156fe30 EFLAGS: 00010206 2023-03-02T13:11:21.473271+11:00 supahwinch kernel: [ 1262.049614] RAX: 0007 RBX: 97c2ae3b4b78 RCX: bc550156fe60 2023-03-02T13:11:21.473274+11:00 supahwinch kernel: [ 1262.054703] RDX: bc550156fe60 RSI: bc550156fe60 RDI: de0185ba2148 2023-03-02T13:11:21.473277+11:00 supahwinch kernel: [ 1262.059850] RBP: 000fc000 R08: de0180d57d08 R09: 00019198 2023-03-02T13:11:21.473279+11:00 supahwinch kernel: [ 1262.064975] R10: 0003 R11: R12: 2023-03-02T13:11:21.473282+11:00 supahwinch kernel: [ 1262.070058] R13: R14: de0180d57d08 R15: 97c2ae3b4b28 2023-03-02T13:11:21.473284+11:00 supahwinch kernel: [ 1262.075101] FS: () GS:97c357c0() knlGS: 2023-03-02T13:11:21.473287+11:00 supahwinch kernel: [ 1262.080166] CS: 0010 DS: ES: CR0: 80050033 2023-03-02T13:11:21.473290+11:00 supahwinch kernel: [ 1262.085268] CR2: 7f6e0e512416 CR3: 000109c92000 CR4: 06f0 2023-03-02T13:11:21.473292+11:00 supahwinch kernel: [ 1262.090377] Call Trace: 2023-03-02T13:11:21.473295+11:00 supahwinch kernel: [ 1262.095402] 2023-03-02T13:11:21.473298+11:00 supahwinch kernel: [ 1262.100346] ? nfsd_shutdown_threads+0x90/0x90 [nfsd] 2023-03-02T13:11:21.473300+11:00 supahwinch kernel: [ 1262.105417] __pagevec_release+0x1b/0x30 2023-03-02T13:11:21.473303+11:00 supahwinch kernel: [ 1262.110399] svc_xprt_release+0x1a3/0x1e0 [sunrpc] 2023-03-02T13:11:21.473306+11:00 supahwinch kernel: [ 1262.115547] svc_send+0x59/0x160 [sunrpc] 2023-03-02T13:11:21.473308+11:00 supahwinch kernel: [ 1262.120602] nfsd+0xd5/0x190 [nfsd] 2023-03-02T13:11:21.473311+11:00 supahwinch kernel: [ 1262.125538] kthread+0xe9/0x110 2023-03-02T13:11:21.473313+11:00 supahwinch kernel: [ 1262.130372] ? kthread_complete_and_exit+0x20/0x20 2023-03-02T13:11:21.473315+11:00 supahwinch kernel: [ 1262.135195] ret_from_fork+0x22/0x30 2023-03-02T13:11:21.473318+11:00 supahwinch kernel: [ 1262.139953] 2023-03-02T13:11:21.473321+11:00 supahwinch kernel: [ 1262.144620] Modules linked in: veth xt_nat nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink xfrm_user xfrm_algo xt_addrtype br_netfilter bridge stp llc overlay cmac algif_hash ecb algif_skcipher af_alg bnep ip6t_REJECT nf_reject_ipv6 xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_compat nf_tables nfnetlink binfmt_misc amdgpu isofs gpu_sched cdrom drm_buddy xc2028 zl10353 rc_fusionhdtv_mce ir_kbd_i2c cx23885 altera_ci tda18271 altera_stapl m88ds3103 i2c_mux btusb btrtl cx2341x btbcm tveeprom btintel videobuf2_dvb dvb_core btmtk bluetooth videobuf2_dma_sg videobuf2_memops videobuf2_v4l2 amd64_edac jitterentropy_rng videobuf2_common edac_mce_amd radeon sha512_generic kvm_amd videodev video ctr ccp wmi mc drbg cp210x rng_core snd_pcm ansi_cprng usbserial drm_display_helper ecdh_generic snd_timer joydev snd rfkill kvm cec soundcore evdev ecc pcspkr rc_core drm_ttm_helper xfs ttm irqbypass drm_kms_helper sp5100_tco watchdog i2c_algo_bit acpi_cpufreq sg button 2023-03-02T13:11:21.473327+11:00 supahwinch kernel: [ 1262.144868] k10temp w83795 jc42 tun loop nfsd msr auth_rpcgss nfs_acl lockd parport_pc grace ppdev sunrpc lp drm parport efi_pstore fuse configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 btrfs blake2b_generic zstd_compress raid10 raid456
Bug#1032262: Kernel builds past 5.3 seem to interfere with AMD dedicated GPU performance on Acer Nitro 5 AN515-42 laptop (almost certainly kernel config related)
Package: linux-image-amd64 Version: Any that include kernel versions post-5.3 Hello, I current run Debian 12 (Bookworm) on my Acer Nitro 5 AN515-42 laptop, but this issue has been present in Debian for quite a while. I've noticed that the default kernel has some problems regarding the hybrid Raven Ridge/RX560x setup in this machine. No matter what 3D load is run, the performance of the GPU hardware seems to be locked at its lowest state, resulting in extremely poor performance. This happens regardless of DRI_PRIME setting. Interestingly, this did NOT happen when I tested other distributions on this hardware, such as Fedora and Ubuntu, regardless of kernel version present. The problem also disappears if I use the Xanmod kernel, which is a third-party custom kernel not present in Debian's repositories. Finally, out of curiosity, I compiled the mainline kernel for myself the other day (version 6.1) using the kernel config present by default in the third-party Xanmod kernel, and my compiled kernel resulted in proper and expected performance across the board. For these reasons, I believe the kernel config present in Debian is somehow at fault. Unfortunately, despite looking at the diff between the default kernel config and the custom one I used to build my kernel, I don't really have a good idea of which settings were responsible for the solution to this issue. I would greatly appreciate it if anyone more knowledgeable than me could help to investigate this and perhaps change the default Debian kernel config upstream so that other users who might be affected by this bug can benefit from the solution without having to compile their own kernels.
Processed: Re: Processed (with 1 error): Re: Bug#1015272: liburing autopkgtest started to hang containers in Debian and Ubuntu since ~2022-07-11
Processing commands for cont...@bugs.debian.org: > fixed 1015272 5.10.162-1 Bug #1015272 [linux] liburing autopkgtest started to hang containers in Debian and Ubuntu since ~2022-07-11 There is no source info for the package 'linux' at version '5.10.162-1' with architecture '' Unable to make a source version for version '5.10.162-1' Marked as fixed in versions 5.10.162-1. > fixed 1015272 6.1.8-1 Bug #1015272 [linux] liburing autopkgtest started to hang containers in Debian and Ubuntu since ~2022-07-11 There is no source info for the package 'linux' at version '6.1.8-1' with architecture '' Unable to make a source version for version '6.1.8-1' Marked as fixed in versions 6.1.8-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 1015272: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015272 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1015272: liburing autopkgtest started to hang containers in Debian and Ubuntu since ~2022-07-11
Hi! On Thu, 2023-03-02 at 12:12:06 +0100, Paul Gevers wrote: > Control: fixed -1 5.10.162-1 6.1.8-1 > On Sun, 21 Aug 2022 21:35:58 +0200 Bastian Blank wrote: > > On Sun, Aug 21, 2022 at 07:42:10PM +0200, Guillem Jover wrote: > > > It seems like there was a regression with the latest stable update > > > that affects the autopkgtest for liburing. Reassigning. > > > > Please provide enough information to make isolating the problem > > possible. > > > > https://ci.debian.net/packages/libu/liburing/ is completely silent as > > there are not results for any of the failed runs. > I decided to try again to see if I could collect more information. The test > now passes on amd64, arm64, i386 and ppc64el, all running 5.10.162-1 and on > riscv64 running unstable. However, on armhf, armel (amd64 kernel) and s390x > (all running 5.10.158-2), it seems that the observation of brian is still > true, some test in test-unit test segfaults, the test exits and hangs. > @Guillem, do you see something more in the output below (armhf log) that may > be of interest? And maybe spot something to run in isolation? > Reading the changelog of 5.10.162-1 I see io_uring mentioned a couple of > times. Therefor I assume this bug is fixed in that version. Is it worth > pursuing the real issue here? Thanks for looking into this! As this appears fixed in latest Linux releases, then I'd honestly not bother further, and just try to get the remaining hosts upgraded to the fixed versions. If this was to reappear then it might make sense to look into it again. Regards, Guillem
Bug#1015272: liburing autopkgtest started to hang containers in Debian and Ubuntu since ~2022-07-11
Control: fixed -1 5.10.162-1 6.1.8-1 Hi, On Sun, 21 Aug 2022 21:35:58 +0200 Bastian Blank wrote: On Sun, Aug 21, 2022 at 07:42:10PM +0200, Guillem Jover wrote: > It seems like there was a regression with the latest stable update > that affects the autopkgtest for liburing. Reassigning. Please provide enough information to make isolating the problem possible. https://ci.debian.net/packages/libu/liburing/ is completely silent as there are not results for any of the failed runs. I decided to try again to see if I could collect more information. The test now passes on amd64, arm64, i386 and ppc64el, all running 5.10.162-1 and on riscv64 running unstable. However, on armhf, armel (amd64 kernel) and s390x (all running 5.10.158-2), it seems that the observation of brian is still true, some test in test-unit test segfaults, the test exits and hangs. @Guillem, do you see something more in the output below (armhf log) that may be of interest? And maybe spot something to run in isolation? When I try to destroy the lxc, that fails and in ps output I see this: root 3053528 0.0 0.0 5388 3072 ?Ss 03:34 0:00 [lxc monitor] /var/lib/lxc ci-061-8c60e21c root 3061512 0.0 0.0 0 0 ?Ss 03:35 0:00 \_ [systemd] debian 3110684 0.0 0.0 2140 192 ?DL 03:37 0:00 \_ ./iopoll-leak.t Note the "D" state. Reading the changelog of 5.10.162-1 I see io_uring mentioned a couple of times. Therefor I assume this bug is fixed in that version. Is it worth pursuing the real issue here? Paul root@ci-061-705317d0:/tmp/autopkgtest-lxc.v8gx_5j5/downtmp# cat test-unit-stdout + [ -n ] + CC=gcc + ./configure --cc=gcc prefix/usr includedir/usr/include libdir/usr/lib libdevdir /usr/lib relativelibdir mandir/usr/man datadir /usr/share stringop_overflow yes array_bounds yes __kernel_rwf_tyes __kernel_timespec yes open_how yes statx yes glibc_statx yes C++ yes has_ucontext yes NVMe uring command supportyes liburing_nolibc no CCgcc CXX g++ + make runtests make[1]: Entering directory '/tmp/autopkgtest-lxc.v8gx_5j5/downtmp/build.ksh/src/src' CC setup.ol CC queue.ol CC register.ol CC syscall.ol AR liburing.a ar: creating liburing.a RANLIB liburing.a CC setup.os CC queue.os CC register.os CC syscall.os CC liburing.so.2.3 make[1]: Leaving directory '/tmp/autopkgtest-lxc.v8gx_5j5/downtmp/build.ksh/src/src' make[1]: Entering directory '/tmp/autopkgtest-lxc.v8gx_5j5/downtmp/build.ksh/src/test' CC helpers.o CC 232c93d07b74.t CC 35fa71a030ca.t CC 500f9fbadef8.t CC 7ad0e4b2f83c.t CC 8a9973408177.t CC 917257daa0fe.t CC a0908ae19763.t CC a4c0b3decb33.t CC accept.t CC accept-link.t CC accept-reuse.t CC accept-test.t CC across-fork.t CC b19062a56726.t CC b5837bd5311d.t CC buf-ring.t CC ce593a6c480a.t CC close-opath.t CC connect.t CC cq-full.t CC cq-overflow.t CC cq-peek-batch.t CC cq-ready.t CC cq-size.t CC d4ae271dfaae.t CC d77a67ed5f27.t CC defer.t CC defer-taskrun.t CC double-poll-crash.t CC drop-submit.t CC eeed8b54e0df.t CC empty-eownerdead.t CC eventfd.t CC eventfd-disable.t CC eventfd-reg.t CC eventfd-ring.t CC exec-target.t CC exit-no-cleanup.t CC fadvise.t CC fallocate.t CC fc2a85cb02ef.t CC fd-pass.t CC file-register.t CC files-exit-hang-poll.t CC files-exit-hang-timeout.t CC file-update.t CC file-verify.t CC fixed-buf-iter.t CC fixed-link.t CC fixed-reuse.t CC fpos.t CC fsync.t CC hardlink.t CC io-cancel.t CC iopoll.t CC iopoll-leak.t CC io_uring_enter.t CC io_uring_passthrough.t CC io_uring_register.t CC io_uring_setup.t CC lfs-openat.t CC lfs-openat-write.t CC link.t CC link_drain.t CC link-timeout.t CC madvise.t CC mkdir.t CC msg-ring.t CC multicqes_drain.t CC nolibc.t CC nop-all-sizes.t CC nop.t CC openat2.t CC open-close.t CC open-direct-link.t CC open-direct-pick.t CC personality.t CC pipe-eof.t CC pipe-reuse.t CC poll.t CC poll-cancel.t CC poll-cancel-all.t CC poll-cancel-ton.t CC poll-link.t CC poll-many.t CC poll-mshot-update.t CC poll-mshot-overflow.t CC poll-ring.t CC poll-v-poll.t CC pollfree.t CC probe.t CC read-before-exit.t CC read-write.t CC recv-msgall.t CC
Bug#1032271: Module advansys fails to load on amd64
Package: src:linux Version: 5.10.162-1 Severity: normal Dear maintainer, Loading the 'advansys' module fails with any -amd64 kernel: # modprobe advansys modprobe: ERROR: could not insert 'advansys': No such device The module loads successfully with any -686 or -686-pae kernel. I observed the same behaviour with any stable Debian kernel from 4.9 to 6.1 I have, regardless of whether the supported device and required firmware are present or not. After adding a few printk() in the module code, it appears that the reason is because calls to isa_register_driver() in advansys_init() fail. The failure may be related with some ISA-related config option missing in amd64 kernels. A quick comparison shows that the following options are enabled in -686 config but not in -amd64 config: CONFIG_ISA=y CONFIG_ISA_BUS_API=y CONFIG_ISAPNP=y However I believe a better solution would be to have the module not fail if ISA is disabled, as it also support EISA and PCI devices.
Bug#1032284: Linux-image-6.1.x with rtw88_8723de module
Package: linux-image-6.1.0-5-amd64 Version: 6.1.12-1 Linux-image 6.1 series hangs on boot when rtw88_8723de module is enabled. Blacklisting the module by creating a file in /etc/modprobe.d allows the kernel to boot successfully. This is only a workaround I found at https://forum.endeavouros.com/t/kernel-6-1-stuck-in-boot-before-login-window/35127/11.
