Processed: tagging 1087900

2025-01-16 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> tags 1087900 - unreproducible moreinfo
Bug #1087900 {Done: Bastian Blank } [src:linux] linux: kernel 
BUG at fs/nfsd/nfs4recover.c:534
Bug #1089976 {Done: Bastian Blank } [src:linux] 
nfs-kernel-server: Fails to start - segmentation fault
Bug #1091439 {Done: Bastian Blank } [src:linux] installation 
of nfs-kernel-server hangs
Bug #1092607 {Done: Bastian Blank } [src:linux] dracut: 
upstream-dracut-network-nfs autopkgtest fails on amd64
Removed tag(s) moreinfo and unreproducible.
Removed tag(s) moreinfo and unreproducible.
Removed tag(s) moreinfo and unreproducible.
Removed tag(s) unreproducible and moreinfo.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1087900: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1087900
1089976: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1089976
1091439: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1091439
1092607: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1092607
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: changing title of bug 1091788

2025-01-16 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> retitle 1091788 linux-image-6.12.x-amd64: second monitor not recognized with 
> NVidia, but is found booting earlier kernels (6.11.10 and previous)
Bug #1091788 [src:linux] linux-image-6.12.6-amd64: second monitor not 
recognized with kernel 6.12.6, but is in earlier kernels
Changed Bug title to 'linux-image-6.12.x-amd64: second monitor not recognized 
with NVidia, but is found booting earlier kernels (6.11.10 and previous)' from 
'linux-image-6.12.6-amd64: second monitor not recognized with kernel 6.12.6, 
but is in earlier kernels'.
>
End of message, stopping processing here.

Please contact me if you need assistance.
-- 
1091788: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1091788
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1091788: bug is still present with kernel 6.12.9

2025-01-16 Thread Heinz Repp 

I hoped the new kernel would fix this bug, but it is still present in
kernel 6.12.9-amd64. When booting 6.11.10, everything is good and
present, but booting any 6.12.x kernel misses the second monitor.

Bug#1086175:

2025-01-16 Thread Johan Kröckel 
Still a problem on a fresh install with the 12.9 DVD iso.

Bug#1092591: linux-image-6.12.6-amd64: SO_PEERSEC fails with ENOPROTOOPT with AppArmor enabled

2025-01-16 Thread Guido Berhoerster 
>From my superficial reading of the code the error seems to come from here: 
>https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/security/apparmor/lsm.c?h=v6.12.6#n1313

It appears that AppArmor SO_PEERSEC support for unix domain sockets bound to a 
filesystem path name is missing from the upstream kernel and is only enabled as 
a side effect of a patch distributed with AppArmor: 
https://gitlab.com/apparmor/apparmor/-/blob/692e6850ba90582105713a683bed753bad696aab/kernel-patches/v4.17/0002-apparmor-af_unix-mediation.patch
Ubuntu kernels contain a rebased variant of the patch which is likely why 
SO_PEERSEC works on Ubuntu.

The reason I stumbled on this issue is that we (ubports-team) are currently 
packaging lomiri-content-hub which implicitly relies on SO_PEERSEC through the 
DBus daemon to get the AppArmor profile of a process requesting to export a 
file. Without this it is not possible to confine Lomiri/Ubuntu Touch apps 
running on Debian.
-- 
Guido Berhoerster

Bug#1093217: linux-image-6.12.9-amd64: dmesg is spammed full of "AER: Correctable error message received from 0000:e3:00.0"

2025-01-16 Thread Loreno Heer 
Package: src:linux
Version: 6.12.9-1
Severity: minor
X-Debbugs-Cc: loreno.h...@bluewin.ch

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation? Fresh install of Debian/testing. Not sure if
the bug was present in earlier versions of the kernel.
   * What exactly did you do (or not do) that was effective (or
 ineffective)? I tried twice to reseat the PCI device and cleaned the
contacts without any effect.
   * What was the outcome of this action? No change.
   * What outcome did you expect instead? I think this is either a Kernel or a
BIOS bug, I doubt the new hardware is failing and unlikely it is impropperly
installed. There are some suggestions online to disable AER which I find
strange. This would only hide the error messages.

*** End of the template - remove these template lines ***


-- Package-specific info:
** Version:
Linux version 6.12.9-amd64 (debian-kernel@lists.debian.org) 
(x86_64-linux-gnu-gcc-14 (Debian 14.2.0-12) 14.2.0, GNU ld (GNU Binutils for 
Debian) 2.43.50.20241230) #1 SMP PREEMPT_DYNAMIC Debian 6.12.9-1 (2025-01-10)

** Command line:
BOOT_IMAGE=/vmlinuz-6.12.9-amd64 root=/dev/mapper/vg--1-lv--root ro quiet

** Not tainted

** Kernel log:
[   39.667358] amdgpu :e3:00.0:[13] NonFatalErr   
[   39.667372] pcieport :e0:01.1: AER: Correctable error message received 
from :e3:00.0
[   39.667376] amdgpu :e3:00.0: PCIe Bus Error: severity=Correctable, 
type=Transaction Layer, (Receiver ID)
[   39.667378] amdgpu :e3:00.0:   device [1002:744c] error 
status/mask=2000/
[   39.667380] amdgpu :e3:00.0:[13] NonFatalErr   
[   39.667421] pcieport :e0:01.1: AER: Multiple Correctable error message 
received from :e3:00.0
[   39.667433] amdgpu :e3:00.0: PCIe Bus Error: severity=Correctable, 
type=Transaction Layer, (Receiver ID)
[   39.667434] amdgpu :e3:00.0:   device [1002:744c] error 
status/mask=2000/
[   39.667437] amdgpu :e3:00.0:[13] NonFatalErr   
[   39.667456] pcieport :e0:01.1: AER: Correctable error message received 
from :e3:00.0
[   39.667460] amdgpu :e3:00.0: PCIe Bus Error: severity=Correctable, 
type=Transaction Layer, (Receiver ID)
[   39.667462] amdgpu :e3:00.0:   device [1002:744c] error 
status/mask=2000/
[   39.667464] amdgpu :e3:00.0:[13] NonFatalErr   
[   39.687373] pcieport :e0:01.1: AER: Multiple Correctable error message 
received from :e3:00.0
[   39.687387] amdgpu :e3:00.0: PCIe Bus Error: severity=Correctable, 
type=Transaction Layer, (Receiver ID)
[   39.687388] amdgpu :e3:00.0:   device [1002:744c] error 
status/mask=2000/
[   39.687390] amdgpu :e3:00.0:[13] NonFatalErr   
[   39.687404] pcieport :e0:01.1: AER: Correctable error message received 
from :e3:00.0
[   39.687407] amdgpu :e3:00.0: PCIe Bus Error: severity=Correctable, 
type=Transaction Layer, (Receiver ID)
[   39.687409] amdgpu :e3:00.0:   device [1002:744c] error 
status/mask=2000/
[   39.687410] amdgpu :e3:00.0:[13] NonFatalErr   
[   39.687690] pcieport :e0:01.1: AER: Multiple Correctable error message 
received from :e3:00.0
[   39.687702] amdgpu :e3:00.0: PCIe Bus Error: severity=Correctable, 
type=Transaction Layer, (Receiver ID)
[   39.687703] amdgpu :e3:00.0:   device [1002:744c] error 
status/mask=2000/
[   39.687704] amdgpu :e3:00.0:[13] NonFatalErr   
[   39.687725] pcieport :e0:01.1: AER: Correctable error message received 
from :e3:00.0
[   39.687728] amdgpu :e3:00.0: PCIe Bus Error: severity=Correctable, 
type=Transaction Layer, (Receiver ID)
[   39.687730] amdgpu :e3:00.0:   device [1002:744c] error 
status/mask=2000/
[   39.687731] amdgpu :e3:00.0:[13] NonFatalErr   
[   39.691141] pcieport :e0:01.1: AER: Multiple Correctable error message 
received from :e3:00.0
[   39.691154] amdgpu :e3:00.0: PCIe Bus Error: severity=Correctable, 
type=Transaction Layer, (Receiver ID)
[   39.691156] amdgpu :e3:00.0:   device [1002:744c] error 
status/mask=2000/
[   39.691158] amdgpu :e3:00.0:[13] NonFatalErr   
[   39.691212] pcieport :e0:01.1: AER: Correctable error message received 
from :e3:00.0
[   39.691215] amdgpu :e3:00.0: PCIe Bus Error: severity=Correctable, 
type=Transaction Layer, (Receiver ID)
[   39.691216] amdgpu :e3:00.0:   device [1002:744c] error 
status/mask=2000/
[   39.691218] amdgpu :e3:00.0:[13] NonFatalErr   
[   39.731091] pcieport :e0:01.1: AER: Multiple Correctable error message 
received from :e3:00.0
[   39.731105] amdgpu :e3:00.0: PCIe Bus Error: severity=Correctable, 
type=Transaction Layer, (Receiver ID)
[   39.731107] amdgpu :e3:00.0:   device [1002:744c] error 
status/mask

Bug#1092960: marked as done (linux-image-6.1.0-29-amd64: Kernel OOPS when specifying ZRAM block device parameters)

2025-01-16 Thread Debian Bug Tracking System 
Your message dated Thu, 16 Jan 2025 09:12:16 +0100
with message-id 
and subject line Re: Bug#1092960: linux-image-6.1.0-29-amd64: Kernel OOPS when 
specifying ZRAM block device parameters
has caused the Debian Bug report #1092960,
regarding linux-image-6.1.0-29-amd64: Kernel OOPS when specifying ZRAM block 
device parameters
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.)


-- 
1092960: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1092960
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:linux
Version: 6.1.123-1
Severity: normal
X-Debbugs-Cc: rad...@yandex.ru

Dear Maintainer,

   * What led up to the situation?
   Command "modprobe zram" create /dev/zram0
   Command "/sbin/zramctrl -s 1G -f" fail
   systemd-zram-generator do the same

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   Use previous version of kernel (6.1.0-28)

   * What was the outcome of this action?
   Kernel log contains errors and trace. Block device not working. Module 
"zram" can not be removed without reboot.
 
   * What outcome did you expect instead?
   Successfully creating a 1GB block device


-- Package-specific info:
** Version:
Linux version 6.1.0-29-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.123-1 (2025-01-02)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.1.0-29-amd64 
root=UUID=6f8d6915-6a5e-4ab8-915f-e67924b4670a ro quiet

** Not tainted

** Kernel log:
[   19.708321] lowmem_reserve[]: 0 2961 7853 7853 7853
[   19.708326] Node 0 DMA32 free:3053484kB boost:0kB min:25436kB low:31792kB 
high:38148kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB 
active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB 
present:3128744kB managed:3063204kB mlocked:0kB bounce:0kB free_pcp:8200kB 
local_pcp:240kB free_cma:0kB
[   19.708331] lowmem_reserve[]: 0 0 4891 4891 4891
[   19.708336] Node 0 Normal free:4707520kB boost:0kB min:42016kB low:52520kB 
high:63024kB reserved_highatomic:0KB active_anon:456kB inactive_anon:19604kB 
active_file:34212kB inactive_file:52932kB unevictable:0kB writepending:172kB 
present:5242880kB managed:5017352kB mlocked:0kB bounce:0kB free_pcp:34776kB 
local_pcp:4736kB free_cma:0kB
[   19.708341] lowmem_reserve[]: 0 0 0 0 0
[   19.708346] Node 0 DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 
0*512kB 0*1024kB 1*2048kB (M) 3*4096kB (M) = 14336kB
[   19.708360] Node 0 DMA32: 3*4kB (M) 4*8kB (M) 6*16kB (UM) 5*32kB (M) 4*64kB 
(UM) 5*128kB (M) 3*256kB (M) 4*512kB (UM) 6*1024kB (UM) 2*2048kB (M) 742*4096kB 
(M) = 3053484kB
[   19.708380] Node 0 Normal: 252*4kB (UM) 79*8kB (ME) 33*16kB (ME) 11*32kB 
(UM) 8*64kB (UME) 3*128kB (ME) 1*256kB (E) 1*512kB (E) 1*1024kB (E) 20*2048kB 
(UME) 1138*4096kB (UM) = 4707416kB
[   19.708401] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 
hugepages_size=1048576kB
[   19.708403] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 
hugepages_size=2048kB
[   19.708405] 22018 total pagecache pages
[   19.708406] 0 pages in swap cache
[   19.708407] Free swap  = 999420kB
[   19.708409] Total swap = 999420kB
[   19.708410] 2096904 pages RAM
[   19.708410] 0 pages HighMem/MovableOnly
[   19.708411] 72925 pages reserved
[   19.708412] 0 pages hwpoisoned
[  112.714853] zram-generator: vmalloc error: size 61440, exceeds total 
pages, mode:0xdc0(GFP_KERNEL|__GFP_ZERO), 
nodemask=(null),cpuset=/,mems_allowed=0
[  112.714865] CPU: 2 PID: 933 Comm: zram-generator Not tainted 6.1.0-29-amd64 
#1  Debian 6.1.123-1
[  112.714869] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference 
Platform, BIOS VMW201.00V.24006586.B64.2406042154 06/04/2024
[  112.714871] Call Trace:
[  112.714874]  
[  112.714877]  dump_stack_lvl+0x44/0x5c
[  112.714884]  warn_alloc+0x151/0x170
[  112.714891]  __vmalloc_node_range+0x838/0x880
[  112.714897]  ? disksize_store+0x78/0x140 [zram]
[  112.714904]  ? aa_file_perm+0x11f/0x4e0
[  112.714907]  ? srso_alias_return_thunk+0x5/0x7f
[  112.714912]  ? simple_strntoull+0x8c/0xa0
[  112.714917]  __vmalloc_node+0x4a/0x60
[  112.714919]  ? disksize_store+0x78/0x140 [zram]
[  112.714924]  disksize_store+0x78/0x140 [zram]
[  112.714930]  kernfs_fop_write_iter+0x11e/0x1f0
[  112.714936]  vfs_write+0x235/0x3f0
[  112.714943]  ksys_write+0x6b/0xf0
[  112.714947]  do_syscall_64+0x55/0xb0
[  112.714950]  ? seq_release+0x24/0x30
[  112.714953]  ? srso_alias_return_thunk+0x5/0x7f
[  112.714956]  ? kmem_cache_free+0x13b/0x310
[  112.714959]  ? srso_alias_return_thu

Bug#1092960: linux-image-6.1.0-29-amd64: Kernel OOPS when specifying ZRAM block device parameters

2025-01-16 Thread Salvatore Bonaccorso 
Source: linux
Source-Version: 6.1.124-1

Hi,

On Mon, Jan 13, 2025 at 10:46:02PM +0100, Salvatore Bonaccorso wrote:
> Control: forwarded -1 
> https://lore.kernel.org/regressions/010001944286f97d-fe02c461-e7af-4644-9155-a96995709804-000...@email.amazonses.com/
> Control: tags -1 + upstream
> 
> Hi,
> 
> On Tue, Jan 14, 2025 at 12:25:06AM +0300, Pavel Frolov wrote:
> > Package: src:linux
> > Version: 6.1.123-1
> > Severity: normal
> > X-Debbugs-Cc: rad...@yandex.ru
> > 
> > Dear Maintainer,
> > 
> >* What led up to the situation?
> >Command "modprobe zram" create /dev/zram0
> >Command "/sbin/zramctrl -s 1G -f" fail
> >systemd-zram-generator do the same
> > 
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> >Use previous version of kernel (6.1.0-28)
> > 
> >* What was the outcome of this action?
> >Kernel log contains errors and trace. Block device not working. Module 
> > "zram" can not be removed without reboot.
> >  
> >* What outcome did you expect instead?
> >Successfully creating a 1GB block device
> 
> Yes, there is a zram related regression in at least the 6.1.y upstream
> stable series, cf. 
> https://lore.kernel.org/regressions/010001944286f97d-fe02c461-e7af-4644-9155-a96995709804-000...@email.amazonses.com/

This is fixed in 6.1.124 upstream and included in 6.1.124-1.

Regards,
Salvatore

Bug#1089976: nfs-kernel-server: Fails to start - segmentation fault

2025-01-16 Thread Salvatore Bonaccorso 
Control: reassign -1 src:linux
Control: forcemerge 1087900 -1

Hi Bill,

On Wed, Jan 15, 2025 at 08:02:18AM -0800, Bill Brelsford wrote:
> On Wed Jan 15 2025 at 07:08 AM +0100, Salvatore Bonaccorso wrote:
> > > But it still fails in testing (trixie).  I'll try to determine what
> > > future package update fixes it.
> > 
> > I have a suspect what it can be. Can you please post the kernel log /
> > dmesg from the systems which do not work please?
> 
> Attached is dmesg from trixie.
> 
> Bill

[...]
> [   33.734128] r8169 :05:07.0 eth0: Link is Up - 100Mbps/Full - flow 
> control rx/tx
> [   40.873091] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state 
> recovery directory
> [   40.967422] NFSD: Using legacy client tracking operations.
> [   40.971774] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state 
> recovery directory
> [   40.976080] [ cut here ]
> [   40.980166] kernel BUG at fs/nfsd/nfs4recover.c:534!
> [   40.984266] Oops: invalid opcode:  [#1] PREEMPT SMP PTI
> [   40.988166] CPU: 0 UID: 0 PID: 1935 Comm: rpc.nfsd Not tainted 
> 6.12.6-amd64 #1  Debian 6.12.6-1
> [   40.988236] Hardware name: To Be Filled By O.E.M. S62E/S62E, BIOS 0303
> 08/03/2007
> [   40.988236] RIP: 0010:nfsd4_legacy_tracking_init+0x17d/0x1b0 [nfsd]
> [   40.988236] Code: 19 48 89 de 48 c7 c7 50 99 cb c1 e8 6d fb ff ff 89 c5 85 
> c0 0f 85 10 61 00 00 48 c7 c7 90 f3 d2 c1 31 ed e8 85 26 3e f8 eb 07 <0f> 0b 
> bd f4 ff ff ff 48 8b 44 24 08 65 48 2b 04 25 28 00 00 00 75
> [   40.988236] RSP: 0018:bc09c0f87c80 EFLAGS: 00010282
> [   40.988236] RAX: 0049 RBX: a0364b4d8000 RCX: 
> 0003
> [   40.988236] RDX:  RSI: 0003 RDI: 
> 0001
> [   40.988236] RBP: bbca3600 R08:  R09: 
> bc09c0f87b10
> [   40.988236] R10: bb0b4348 R11: 0003 R12: 
> a0364b4d8000
> [   40.988236] R13: a0364b4d8000 R14: a0364c306b40 R15: 
> a0364b4d8000
> [   40.988236] FS:  7faff2288740() GS:a036bd40() 
> knlGS:
> [   40.988236] CS:  0010 DS:  ES:  CR0: 80050033
> [   40.988236] CR2: 7f0d8a7e1320 CR3: 02cfc000 CR4: 
> 26f0
> [   40.988236] Call Trace:
> [   40.988236]  
> [   40.988236]  ? __die_body.cold+0x19/0x27
> [   40.988236]  ? die+0x2e/0x50
> [   40.988236]  ? do_trap+0xca/0x110
> [   40.988236]  ? do_error_trap+0x6a/0x90
> [   40.988236]  ? nfsd4_legacy_tracking_init+0x17d/0x1b0 [nfsd]
> [   40.988236]  ? exc_invalid_op+0x50/0x70
> [   40.988236]  ? nfsd4_legacy_tracking_init+0x17d/0x1b0 [nfsd]
> [   40.988236]  ? asm_exc_invalid_op+0x1a/0x20
> [   40.988236]  ? nfsd4_legacy_tracking_init+0x17d/0x1b0 [nfsd]
> [   40.988236]  nfsd4_client_tracking_init+0x57/0x1b0 [nfsd]
> [   40.988236]  nfs4_state_start_net+0x2f9/0x3a0 [nfsd]
> [   40.988236]  nfsd_svc+0x1ac/0x310 [nfsd]
> [   40.988236]  write_threads+0xf9/0x1c0 [nfsd]
> [   40.988236]  ? __pfx_write_threads+0x10/0x10 [nfsd]
> [   40.988236]  nfsctl_transaction_write+0x4a/0x80 [nfsd]
> [   40.988236]  vfs_write+0xf8/0x450
> [   40.988236]  ksys_write+0x6d/0xf0
> [   40.988236]  do_syscall_64+0x82/0x190
> [   40.988236]  ? do_user_addr_fault+0x36c/0x620
> [   40.988236]  ? exc_page_fault+0x7e/0x180
> [   40.988236]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
> [   40.988236] RIP: 0033:0x7faff238f090
> [   40.988236] Code: 2d 0e 00 64 c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 
> 1f 84 00 00 00 00 00 80 3d d9 af 0e 00 00 74 17 b8 01 00 00 00 0f 05 <48> 3d 
> 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 28 48 89
> [   40.988236] RSP: 002b:7ffeff5e5298 EFLAGS: 0202 ORIG_RAX: 
> 0001
> [   40.988236] RAX: ffda RBX: 0003 RCX: 
> 7faff238f090
> [   40.988236] RDX: 0003 RSI: 55744ca80340 RDI: 
> 0003
> [   40.988236] RBP: 55744ca80340 R08: 0064 R09: 
> fffe
> [   40.988236] R10:  R11: 0202 R12: 
> 0002
> [   40.988236] R13: 55744ca7c116 R14: 55748c50c2a0 R15: 
> 
> [   40.988236]  
> [   40.988236] Modules linked in: xt_nat ipt_REJECT nf_reject_ipv4 
> xt_conntrack xt_tcpudp iptable_mangle iptable_nat nf_nat nf_conntrack 
> nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_filter ip_tables x_tables 
> nfsd auth_rpcgss nfs_acl nfs lockd grace netfs sunrpc firewire_sbp2 sr_mod 
> at24 cdrom iTCO_wdt intel_pmc_bxt iTCO_vendor_support watchdog coretemp i915 
> kvm_intel snd_hda_codec_si3054 snd_hda_codec_realtek kvm 
> snd_hda_codec_generic snd_hda_scodec_component snd_hda_intel uvcvideo 
> drm_buddy iwl4965 snd_intel_dspcfg snd_intel_sdw_acpi sha512_ssse3 
> drm_display_helper snd_hda_codec sha256_ssse3 cec videobuf2_vmalloc iwlegacy 
> uvc snd_hda_core videobuf2_memops rc_core sha1_ssse3 snd_hwdep mac80211 
> videobuf2_v4l2 snd_pcm_oss ttm r852 snd_mixer_oss videodev snd_pcm sm_common 
> drm_k

Processed: Re: Bug#1089976: nfs-kernel-server: Fails to start - segmentation fault

2025-01-16 Thread Debian Bug Tracking System 
Processing control commands:

> reassign -1 src:linux
Bug #1089976 [nfs-kernel-server] nfs-kernel-server: Fails to start - 
segmentation fault
Bug reassigned from package 'nfs-kernel-server' to 'src:linux'.
No longer marked as found in versions nfs-utils/1:2.8.2-1.
Ignoring request to alter fixed versions of bug #1089976 to the same values 
previously set
> forcemerge 1087900 -1
Bug #1087900 {Done: Bastian Blank } [src:linux] linux: kernel 
BUG at fs/nfsd/nfs4recover.c:534
Bug #1091439 {Done: Bastian Blank } [src:linux] installation 
of nfs-kernel-server hangs
Bug #1092607 {Done: Bastian Blank } [src:linux] dracut: 
upstream-dracut-network-nfs autopkgtest fails on amd64
Bug #1087900 {Done: Bastian Blank } [src:linux] linux: kernel 
BUG at fs/nfsd/nfs4recover.c:534
Added tag(s) unreproducible and moreinfo.
Added tag(s) moreinfo and unreproducible.
Added tag(s) unreproducible and moreinfo.
Bug #1089976 [src:linux] nfs-kernel-server: Fails to start - segmentation fault
Set Bug forwarded-to-address to 
'https://lore.kernel.org/linux-nfs/z22diiv98xbsf...@eldamar.lan/'.
Marked Bug as done
Added indication that 1089976 affects src:dracut
Marked as fixed in versions linux/6.12.8-1 and linux/6.13~rc6-1~exp1.
Marked as found in versions linux/6.8.9-1, linux/6.12~rc6-1~exp1, 
linux/6.11.9-1, linux/6.11.5-1, and linux/6.12.6-1.
Added tag(s) upstream and confirmed.
Bug #1091439 {Done: Bastian Blank } [src:linux] installation 
of nfs-kernel-server hangs
Bug #1092607 {Done: Bastian Blank } [src:linux] dracut: 
upstream-dracut-network-nfs autopkgtest fails on amd64
Merged 1087900 1089976 1091439 1092607

-- 
1087900: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1087900
1089976: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1089976
1091439: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1091439
1092607: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1092607
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1092465: linux-image-6.12.6-amd64: Set CONFIG_BT_INTEL_PCIE=M to add bluetooth support for Intel BE201

2025-01-16 Thread The Nino . 
On Wed, 8 Jan 2025 12:59:58 +0100 Salvatore Bonaccorso  
wrote:
> Hi,
>
> On Wed, Jan 08, 2025 at 10:02:06AM +0100, TheNino wrote:
> > Package: src:linux
> > Version: 6.12.6-1
> > Severity: important
> > Tags: d-i
> > X-Debbugs-Cc: the.n...@outlook.com
> >
> > Dear Maintainer,
> >
> > please set CONFIG_BT_INTEL_PCIE=M to enable btintel_pcie module compilation
> > since it prevents BE201 network card to proviude bluetooth support.
> >
> > I guess it was disable in 6.11 due to CVE-2024-46869 that is now fixed in 
> > 6.12
> > since rc1.
> >
> > I think the option is safe, considering that the module is available in 
> > Ubuntu
> > 24.10 (kernel 6.11 where the issue is fixed since 6.11.1).
> >
> > Same applies to newer versions of the package (i.e., 6.12.8 currently in 
> > sid).
>
> No it was afaics never enabled and disabled inbetween, and is a new
> option since v6.10-rc1.
>
> See
> https://git.kernel.org/linus/c2b636b3f788d10486a6691ad6dd3ec4c93bd78e
>
> We will likely enable the option.
>
> Regards,
> Salvatore
>
>

Even better, good to know. I hope to see it enabled soon, since 6.12.9 still 
has not it.

Regards

Bug#1089976: nfs-kernel-server: Fails to start - segmentation fault

2025-01-16 Thread Salvatore Bonaccorso 
Hi Bill,

On Thu, Jan 16, 2025 at 07:18:53PM -0800, Bill Brelsford wrote:
> Hi Salvatore,
> 
> On Thu Jan 16 2025 at 09:30 AM +0100, Salvatore Bonaccorso wrote:
> > On Wed, Jan 15, 2025 at 08:02:18AM -0800, Bill Brelsford wrote:
> > > [   40.980166] kernel BUG at fs/nfsd/nfs4recover.c:534!
> > > [   40.984266] Oops: invalid opcode:  [#1] PREEMPT SMP PTI
> 
> > So this is what I suspected. This is #1087900 in src:linux and fixed
> > in 6.12.8-1.
> 
> I'm embarassed! I thought I had checked dmesg, but obviously hadn't.
> It's working on trixie now with the latest kernel update (6.12.9-1).

Thanks for reporting back, I'm glad your issue is resolved!

Regards,
Salvatore

Bug#1089976: nfs-kernel-server: Fails to start - segmentation fault

2025-01-16 Thread Bill Brelsford 
Hi Salvatore,

On Thu Jan 16 2025 at 09:30 AM +0100, Salvatore Bonaccorso wrote:
> On Wed, Jan 15, 2025 at 08:02:18AM -0800, Bill Brelsford wrote:
> > [   40.980166] kernel BUG at fs/nfsd/nfs4recover.c:534!
> > [   40.984266] Oops: invalid opcode:  [#1] PREEMPT SMP PTI

> So this is what I suspected. This is #1087900 in src:linux and fixed
> in 6.12.8-1.

I'm embarassed! I thought I had checked dmesg, but obviously hadn't.
It's working on trixie now with the latest kernel update (6.12.9-1).

> *But* that said, I strongly encourage you to switch to a systemd
> running system for your nfs server. We still ship the init scripts in
> the packaging, but for instance you do not start with them the more
> advanced client tracking daemons. The legacy tracking methods will
> disapear at some point upstream completely and in fact for the next
> experimental upload I aim to disable NFSD_LEGACY_CLIENT_TRACKING
> (cf.
> https://salsa.debian.org/kernel-team/linux/-/merge_requests/1298).

Yes, it's time for me to switch to systemd.  

Thanks very much for your help!

Bill

Re: Bug#1093200: librsvg: FTBFS on mips64el: error: failed to acquire jobserver token; Caused by: Bad address (os error 14)

2025-01-16 Thread Shengjing Zhu 
On Fri, Jan 17, 2025 at 7:30 AM Adrian Bunk  wrote:
>
> On Thu, Jan 16, 2025 at 11:22:11PM +0100, Aurelien Jarno wrote:
> > On 2025-01-16 18:27, Aurelien Jarno wrote:
> > > Hi,
> > >
> > > On 2025-01-16 11:02, Simon McVittie wrote:
> > > > Control: found -1 2.58.93+dfsg-2
> > > >
> > > > On Thu, 16 Jan 2025 at 10:45:28 +, Simon McVittie wrote:
> > > > > librsvg/2.59.2+dfsg-1 failed to build on mips64el across multiple 
> > > > > retries,
> > > > > most recently in
> > > > > .
> > > >
> > > > This does not seem to be a new problem. Looking back at older buildd 
> > > > logs,
> > > > I can see the same error message
> > > >
> > > > > > error: failed to acquire jobserver token
> > > > > >
> > > > > > Caused by:
> > > > > >   Bad address (os error 14)
> > > >
> > > > in most of the build logs since 2024-08-15:
> > > >
> > > > https://buildd.debian.org/status/fetch.php?pkg=librsvg&arch=mips64el&ver=2.58.93%2Bdfsg-2&stamp=1723723132&raw=0
> > > > https://buildd.debian.org/status/fetch.php?pkg=librsvg&arch=mips64el&ver=2.58.93%2Bdfsg-3&stamp=1723726896&raw=0
> > > > https://buildd.debian.org/status/fetch.php?pkg=librsvg&arch=mips64el&ver=2.58.93%2Bdfsg-3&stamp=1723730758&raw=0
> > > > https://buildd.debian.org/status/fetch.php?pkg=librsvg&arch=mips64el&ver=2.58.93%2Bdfsg-3&stamp=1723736907&raw=0
> > > > https://buildd.debian.org/status/fetch.php?pkg=librsvg&arch=mips64el&ver=2.58.93%2Bdfsg-3&stamp=1723739367&raw=0
> > > > https://buildd.debian.org/status/fetch.php?pkg=librsvg&arch=mips64el&ver=2.58.93%2Bdfsg-3&stamp=1723746654&raw=0
> > > > etc.
> > > >
> > > > So I don't think this is genuinely a regression between testing and
> > > > unstable as it would appear to be from librsvg's inability to migrate.
> > > >
> > > > It seems to happen consistently on mipsel-osuosl-04 and mipsel-osuosl-05
> > > > (Quad Core Loongson 3A3000), with the package building successfully on 
> > > > the
> > > > slower buildds -01 and -02 (Rhino Labs UTM8), and inconsistently
> > > > succeeding or failing on -03 (another Quad Core Loongson 3A3000).
> > > >
> > > > As a stopgap to allow librsvg to migrate, please could someone schedule
> > > > a build on mipsel-osuosl-01 or mipsel-osuosl-02 and see whether that
> > > > succeeds? It'll be more time-consuming but better than nothing.
> > >
> > > mipsel-osuosl-01 and mipsel-osuosl-02 have been disabled because they
> > > don't boot with the bullseye or bookworm kernels and thus we can't use
> > > them in unshare mode. Technically they have not yet been decommissioned,
> > > so while we can probably schedule a manual build in chroot mode, it
> > > looks wrong to get it uploaded in the archive.
> >
> > That said I have launched a build anyway on mipsel-osuosl-01 in case it
> > helps to learn something. It built successfully, so it points to a
> > hardware or kernel issue.
>
> There is recently a general instability/race in mips64el Rust/Go/Erlang
> builds, the most common pattern is that the build often (but not always)
> fails.
>

For Go, the following test fails frequently.

--- FAIL: TestRead (0.05s)
--- FAIL: TestRead/SpecialFile (0.05s)
read_test.go:25: read /sys/devices/system/cpu/online: bad address
read_test.go:25: read /sys/devices/system/cpu/online: bad address

I think the first time I saw that is
https://buildd.debian.org/status/fetch.php?pkg=golang-1.22&arch=mips64el&ver=1.22%7Erc1-2&stamp=1704593490&raw=0
Which uses kernel 6.1.69-1.

> Additionally, git also nearly always fails to build:
> https://buildd.debian.org/status/logs.php?pkg=git&arch=mips64el
>
> In the case of git, there is a clear pattern that the 5.10 -> 6.1
> upgrade causes the problem, and for the other issues I'd also
> suspect that.
>
> Looking at librsvg logs, 6.1.76-1 -> 6.1.99-1 seems where it broke.
>
> Looking through kernel changelogs, MIPS changes in this range were:
> - [mips*] scall: Save thread_info.syscall unconditionally on entry
>   Closes: #1068365 (util-linux mkfds-multiplexing-{pselect6,poll,ppoll} 
> failures)
> - [mips*] Clear Cause.BD in instruction_pointer_set
> - [mips*] reserve exception vector space ONLY ONCE
>
> OTOH, git already looks broken with 6.1.76-1.
>
> An interesting data point might be if any of these issues go away with
> the bookworm-backports kernel, librsvg/git/erlang seem to FTBFS pretty
> reliably with the (recent) 6.1 kernels.
>
> > Regards
> > Aurelien
>
> cu
> Adrian
>


-- 
Shengjing Zhu

Processed: found 1088159 in 6.1.124-1

2025-01-16 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> found 1088159 6.1.124-1
Bug #1088159 [src:linux] linux-image-6.1.0-27-amd64 fails mpt3sas_cm0 
_scsih_probe
Marked as found in versions linux/6.1.124-1.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1088159: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1088159
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: found 1086175 in 6.1.123-1

2025-01-16 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> found 1086175 6.1.123-1
Bug #1086175 [src:linux] linux-image-6.1.0-26-amd64: panic at shutdown with 
rootfs on RAID1 while initialy resyncing
Bug #1089158 [src:linux] Kernel Panic on Shutdown/Restart During RAID Resync 
with mdadm on Debian 12.7
Marked as found in versions linux/6.1.123-1.
Marked as found in versions linux/6.1.123-1.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1086175: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1086175
1089158: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1089158
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1093243: linux-image-6.1.0-29-amd64 causes mariadb hangs

2025-01-16 Thread Xan Charbonnet 
Package: src:linux
Version: 6.1.123-1
Severity: important
X-Debbugs-Cc: x...@charbonnet.com

Dear Maintainer,

One of my machines runs mariadb as an asynchronous slave of a production
database.  Every day it makes an LVM snapshot of its database partition, then
starts a secondary instance of mariadb with the snapshot as its data drive.
It then outputs everything, piped through bzip3, to an archive file.

This has worked for a long time but recently started failing: the secondary
mariadb instance will claim to still be executing a SELECT, but no data will
ever be put into the pipe.

This appears to have started after bookworm 12.9 on the evening of Sunday the
12th.  So I rolled back to kernel 6.1.119-1 from linux-image-6.1.0-28-amd64.
It worked perfectly.  My other backup server which I have not yet upgraded to
Debian 12.9 is also working perfectly.

There are other weird things too which I have associated with the new kernel:
the mariadb replication on this machine will sometimes just stop.  It appears
to be writing a commit, but I have to kill -9 it.

And over in production, two of the servers in a Galera cluster were upgraded.
The cluster has been unstable since then: every once in a while, one of the
members will just stop being able to do any writing and I have to kill -9 the
mariadb process.

But the issue which I can readily repeat any time is the one I first brought
up.  Here is some data from experiments I have run:

6.1.0-28-amd64 -- replication able to catch up
Process started 2025-01-15 19:46
Canceled by user 2025-01-15 20:52 47179030576 bytes, still being written
(That is, this was working: still running after an hour, file still growing.)

6.1.0-29-amd64 -- replication unable to catch up
Process started 2025-01-16 11:31
Canceled by user 2025-01-16 11:46
1162798112 bytes, last write 2025-01-16 11:36
(That is, mariadb stopped outputting any data after 5 minutes and had to be
kill -9'd)

Attempt 2 started 2025-01-16 13:02
Canceled by user 2025-01-16 13:19
2149409328 bytes, last write 2025-01-16 13:10
(This one lasted 8 minutes)

Attempt 3 started 2025-01-16 13:52
Canceled by user 2025-01-16 14:14
3352755856 bytes, last write 2025-01-16 14:07
(Got 15 minutes this time)

6.1.0-30-amd64 -- unsure about replication performance
Process started 2025-01-16 11:51
Canceled by user 2025-01-16 12:14
2956803424 bytes, last write 2025-01-16 12:04
(The issue persists in 6.1.124-1: hung after 13 minutes)


Please let me know what other information I can provide.  As indicated, I can
make this problem happen at will, which might be helpful for troubleshooting.

Thank you!





-- Package-specific info:
** Version:
Linux version 6.1.0-29-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.123-1 (2025-01-02)

** Command line:
BOOT_IMAGE=/vmlinuz-6.1.0-29-amd64 
root=UUID=ac0f357b-d33c-418b-9451-b61a7b60d592 ro quiet

** Not tainted

** Kernel log:
[   24.398913] systemd[1]: Starting systemd-journald.service - Journal 
Service...
[   24.409135] systemd[1]: Starting systemd-modules-load.service - Load Kernel 
Modules...
[   24.409745] systemd[1]: Starting systemd-remount-fs.service - Remount Root 
and Kernel File Systems...
[   24.410343] systemd[1]: Starting systemd-udev-trigger.service - Coldplug All 
udev Devices...
[   24.411245] systemd[1]: Finished kmod-static-nodes.service - Create List of 
Static Device Nodes.
[   24.416991] systemd[1]: modprobe@efi_pstore.service: Deactivated 
successfully.
[   24.417110] systemd[1]: Finished modprobe@efi_pstore.service - Load Kernel 
Module efi_pstore.
[   24.431690] systemd[1]: modprobe@configfs.service: Deactivated successfully.
[   24.431806] systemd[1]: Finished modprobe@configfs.service - Load Kernel 
Module configfs.
[   24.432453] systemd[1]: Mounting sys-kernel-config.mount - Kernel 
Configuration File System...
[   24.485775] loop: module loaded
[   24.489145] ACPI: bus type drm_connector registered
[   24.489198] systemd[1]: modprobe@loop.service: Deactivated successfully.
[   24.489327] systemd[1]: Finished modprobe@loop.service - Load Kernel Module 
loop.
[   24.489939] systemd[1]: modprobe@drm.service: Deactivated successfully.
[   24.490048] systemd[1]: Finished modprobe@drm.service - Load Kernel Module 
drm.
[   24.491592] systemd[1]: Finished systemd-modules-load.service - Load Kernel 
Modules.
[   24.492253] systemd[1]: Starting systemd-sysctl.service - Apply Kernel 
Variables...
[   24.503090] fuse: init (API version 7.38)
[   24.503584] systemd[1]: modprobe@fuse.service: Deactivated successfully.
[   24.503712] systemd[1]: Finished modprobe@fuse.service - Load Kernel Module 
fuse.
[   24.504491] systemd[1]: Mounting sys-fs-fuse-connections.mount - FUSE 
Control File System...
[   24.506343] device-mapper: core: CONFIG_IMA_DISABLE_HTABLE is disabled. 
Duplicate IMA measurements will not be recorded in the IMA log.
[   24.506364] device-mapper: uevent: version

Re: Bug#1093200: librsvg: FTBFS on mips64el: error: failed to acquire jobserver token; Caused by: Bad address (os error 14)

2025-01-16 Thread Adrian Bunk 
On Thu, Jan 16, 2025 at 11:22:11PM +0100, Aurelien Jarno wrote:
> On 2025-01-16 18:27, Aurelien Jarno wrote:
> > Hi,
> > 
> > On 2025-01-16 11:02, Simon McVittie wrote:
> > > Control: found -1 2.58.93+dfsg-2
> > > 
> > > On Thu, 16 Jan 2025 at 10:45:28 +, Simon McVittie wrote:
> > > > librsvg/2.59.2+dfsg-1 failed to build on mips64el across multiple 
> > > > retries,
> > > > most recently in
> > > > .
> > > 
> > > This does not seem to be a new problem. Looking back at older buildd logs,
> > > I can see the same error message
> > > 
> > > > > error: failed to acquire jobserver token
> > > > >
> > > > > Caused by:
> > > > >   Bad address (os error 14)
> > > 
> > > in most of the build logs since 2024-08-15:
> > > 
> > > https://buildd.debian.org/status/fetch.php?pkg=librsvg&arch=mips64el&ver=2.58.93%2Bdfsg-2&stamp=1723723132&raw=0
> > > https://buildd.debian.org/status/fetch.php?pkg=librsvg&arch=mips64el&ver=2.58.93%2Bdfsg-3&stamp=1723726896&raw=0
> > > https://buildd.debian.org/status/fetch.php?pkg=librsvg&arch=mips64el&ver=2.58.93%2Bdfsg-3&stamp=1723730758&raw=0
> > > https://buildd.debian.org/status/fetch.php?pkg=librsvg&arch=mips64el&ver=2.58.93%2Bdfsg-3&stamp=1723736907&raw=0
> > > https://buildd.debian.org/status/fetch.php?pkg=librsvg&arch=mips64el&ver=2.58.93%2Bdfsg-3&stamp=1723739367&raw=0
> > > https://buildd.debian.org/status/fetch.php?pkg=librsvg&arch=mips64el&ver=2.58.93%2Bdfsg-3&stamp=1723746654&raw=0
> > > etc.
> > > 
> > > So I don't think this is genuinely a regression between testing and
> > > unstable as it would appear to be from librsvg's inability to migrate.
> > > 
> > > It seems to happen consistently on mipsel-osuosl-04 and mipsel-osuosl-05
> > > (Quad Core Loongson 3A3000), with the package building successfully on the
> > > slower buildds -01 and -02 (Rhino Labs UTM8), and inconsistently
> > > succeeding or failing on -03 (another Quad Core Loongson 3A3000).
> > > 
> > > As a stopgap to allow librsvg to migrate, please could someone schedule
> > > a build on mipsel-osuosl-01 or mipsel-osuosl-02 and see whether that
> > > succeeds? It'll be more time-consuming but better than nothing.
> > 
> > mipsel-osuosl-01 and mipsel-osuosl-02 have been disabled because they
> > don't boot with the bullseye or bookworm kernels and thus we can't use
> > them in unshare mode. Technically they have not yet been decommissioned,
> > so while we can probably schedule a manual build in chroot mode, it
> > looks wrong to get it uploaded in the archive.
> 
> That said I have launched a build anyway on mipsel-osuosl-01 in case it
> helps to learn something. It built successfully, so it points to a
> hardware or kernel issue.

There is recently a general instability/race in mips64el Rust/Go/Erlang 
builds, the most common pattern is that the build often (but not always) 
fails.

Additionally, git also nearly always fails to build:
https://buildd.debian.org/status/logs.php?pkg=git&arch=mips64el

In the case of git, there is a clear pattern that the 5.10 -> 6.1 
upgrade causes the problem, and for the other issues I'd also
suspect that.

Looking at librsvg logs, 6.1.76-1 -> 6.1.99-1 seems where it broke.

Looking through kernel changelogs, MIPS changes in this range were:
- [mips*] scall: Save thread_info.syscall unconditionally on entry
  Closes: #1068365 (util-linux mkfds-multiplexing-{pselect6,poll,ppoll} 
failures)
- [mips*] Clear Cause.BD in instruction_pointer_set
- [mips*] reserve exception vector space ONLY ONCE

OTOH, git already looks broken with 6.1.76-1.

An interesting data point might be if any of these issues go away with 
the bookworm-backports kernel, librsvg/git/erlang seem to FTBFS pretty
reliably with the (recent) 6.1 kernels.

> Regards
> Aurelien

cu
Adrian