Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)

[Cyril Brulebois]

Salvatore Bonaccorso  (2024-04-10):
> 6.7.9-2 in unstable does not exibit the issue.

Besides some reverts, the key fix seems to be
321da3dc1f3c92a12e3c5da934090d2992a8814c in master (v6.8-rc6~14^2~5),
which was backported as d97e1c3602240bd35c48ef9aa978e0c47a511d03
(v6.7.7~167), so that seems rather consistent with your findings.

Just got notified that the two reverts + cherry-pick reached the stable
queue for 6.1, so I'd expect this to be fixed upstream by the time
v6.1.86 is released.

  https://lore.kernel.org/linux-scsi/20240411044021.xejk54iznz3cd...@mraw.org/
  https://lore.kernel.org/linux-scsi/2024041155-croon-dried-f649@gregkh/


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)

[Cyril Brulebois]

Control: forwarded -1 
https://lore.kernel.org/stable/20240410193207.qnb75osxuk4ov...@mraw.org/

Salvatore Bonaccorso  (2024-04-10):
> Yes, if you prefer to not do the forwarding upstream (stable list, CC
> to involved people + regression list), then I can try to take care of
> it. Obviously the former would be great, as you are the finder and
> have done all the work.

Thanks for nudging me into walking those extra few meters. Let's see how
that goes…


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)

[Salvatore Bonaccorso]

Control: tags -1 + upstream

Hi,

On Wed, Apr 10, 2024 at 07:00:14PM +0200, Cyril Brulebois wrote:
> Cyril Brulebois  (2024-04-10):
> > Intermediate results based on upstream stable releases: v6.1.80 is good,
> > v6.1.81 is bad. Still ~200 commits to bisect.
> 
> Final results:
> 
> kibi@genova:~/hack/linux.git ((cf33e6ca12d81...)|BISECTING)$ git bisect 
> bad
> cf33e6ca12d814e1be2263cb76960d0019d7fb94 is the first bad commit
> commit cf33e6ca12d814e1be2263cb76960d0019d7fb94
> Author: Mike Christie 
> Date:   Thu Dec 29 13:01:40 2022 -0600
> 
> scsi: core: Add struct for args to execution functions
> 
> [ Upstream commit d0949565811f0896c1c7e781ab2ad99d34273fdf ]
> 
> Move the SCSI execution functions to use a struct for passing in 
> optional
> args. This commit adds the new struct, temporarily converts 
> scsi_execute()
> and scsi_execute_req() ands a new helper, scsi_execute_cmd(), which 
> takes
> the scsi_exec_args struct.
> 
> There should be no change in behavior. We no longer allow users to 
> pass in
> any request->rq_flags value, but they were only passing in RQF_PM 
> which we
> do support by allowing users to pass in the BLK_MQ_REQ flags used by
> blk_mq_alloc_request().
> 
> Subsequent commits will convert scsi_execute() and scsi_execute_req() 
> users
> to the new helpers then remove scsi_execute() and scsi_execute_req().
> 
> Signed-off-by: Mike Christie 
> Reviewed-by: Bart Van Assche 
> Reviewed-by: Christoph Hellwig 
> Reviewed-by: John Garry 
> Signed-off-by: Martin K. Petersen 
> Stable-dep-of: 321da3dc1f3c ("scsi: sd: usb_storage: uas: Access 
> media prior to querying device properties")
> Signed-off-by: Sasha Levin 
> 
>  drivers/scsi/scsi_lib.c| 52 
> ++
>  include/scsi/scsi_device.h | 51 
> -
>  2 files changed, 62 insertions(+), 41 deletions(-)
> 
> 
> That's one of the 3 commits suggested by Diederik, good hunch.
> 
> I know hindsight is always 100% but “There should be no change in
> behavior.”… :D
> 
> Of course, since there are companion changes afterwards, it cannot be
> simply reverted on top of either v6.1.82 (Debian) or v6.1.84 (upstream).
> 
> 
> I'd appreciate if someone could carry the ball through the appropriate
> channels upstream.

Great, thanks a lot for your bisecting work!

Yes, if you prefer to not do the forwarding upstream (stable list, CC
to involved people + regression list), then I can try to take care of
it. Obviously the former would be great, as you are the finder and
have done all the work.

Regards,
Salvatore

Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)

[Cyril Brulebois]

Cyril Brulebois  (2024-04-10):
> Of course, since there are companion changes afterwards, it cannot be
> simply reverted on top of either v6.1.82 (Debian) or v6.1.84 (upstream).
> 
> 
> I'd appreciate if someone could carry the ball through the appropriate
> channels upstream.

And of course I only spotted minutes after sending the previous mail
that v6.1.85 got published while I was busy bisecting. It's also
affected by this bug.

For the sake of completeness: except for the initial report, all tests
were performed with the “SATA disk in a VM” setup described in my first
follow-up.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)

[Cyril Brulebois]

Cyril Brulebois  (2024-04-10):
> Intermediate results based on upstream stable releases: v6.1.80 is good,
> v6.1.81 is bad. Still ~200 commits to bisect.

Final results:

kibi@genova:~/hack/linux.git ((cf33e6ca12d81...)|BISECTING)$ git bisect bad
cf33e6ca12d814e1be2263cb76960d0019d7fb94 is the first bad commit
commit cf33e6ca12d814e1be2263cb76960d0019d7fb94
Author: Mike Christie 
Date:   Thu Dec 29 13:01:40 2022 -0600

scsi: core: Add struct for args to execution functions

[ Upstream commit d0949565811f0896c1c7e781ab2ad99d34273fdf ]

Move the SCSI execution functions to use a struct for passing in 
optional
args. This commit adds the new struct, temporarily converts 
scsi_execute()
and scsi_execute_req() ands a new helper, scsi_execute_cmd(), which 
takes
the scsi_exec_args struct.

There should be no change in behavior. We no longer allow users to pass 
in
any request->rq_flags value, but they were only passing in RQF_PM which 
we
do support by allowing users to pass in the BLK_MQ_REQ flags used by
blk_mq_alloc_request().

Subsequent commits will convert scsi_execute() and scsi_execute_req() 
users
to the new helpers then remove scsi_execute() and scsi_execute_req().

Signed-off-by: Mike Christie 
Reviewed-by: Bart Van Assche 
Reviewed-by: Christoph Hellwig 
Reviewed-by: John Garry 
Signed-off-by: Martin K. Petersen 
Stable-dep-of: 321da3dc1f3c ("scsi: sd: usb_storage: uas: Access media 
prior to querying device properties")
Signed-off-by: Sasha Levin 

 drivers/scsi/scsi_lib.c| 52 
++
 include/scsi/scsi_device.h | 51 
-
 2 files changed, 62 insertions(+), 41 deletions(-)


That's one of the 3 commits suggested by Diederik, good hunch.

I know hindsight is always 100% but “There should be no change in
behavior.”… :D

Of course, since there are companion changes afterwards, it cannot be
simply reverted on top of either v6.1.82 (Debian) or v6.1.84 (upstream).


I'd appreciate if someone could carry the ball through the appropriate
channels upstream.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)

[Cyril Brulebois]

Cyril Brulebois  (2024-04-10):
> v6.1.84 with stable's .config & bindeb-pkg still does; next up for me:
> confirming good/bad and bisecting.

Intermediate results based on upstream stable releases: v6.1.80 is good,
v6.1.81 is bad. Still ~200 commits to bisect.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)

[Diederik de Haas]

On Wednesday, 10 April 2024 15:32:02 CEST Cyril Brulebois wrote:
> Cyril Brulebois  (2024-04-10):
> > Salvatore Bonaccorso  (2024-04-10):
> > > On Tue, Apr 09, 2024 at 03:33:09PM +0200, Diederik de Haas wrote:
> > > > Does the problem go away if you revert the following commits on top of
> > > > -19?
> > > > 
> > > > db6338f45971b4285ea368432a84033690eaf53c
> > > > scsi: core: Move scsi_host_busy() out of host lock for waking up EH
> > > > handler
> > > > 
> > > > 1ebd75cefaac6fd74729a7d3157f6eaa59960ae2
> > > > scsi: core: Move scsi_host_busy() out of host lock if it is for
> > > > per-command
> > > > 
> > > > cf33e6ca12d814e1be2263cb76960d0019d7fb94
> > > > scsi: core: Add struct for args to execution functions
> > 
> > Preparing that test right now, thanks Diederik.
> 
> This doesn't build, but I didn't try very hard:
> 
> /home/kibi/debian-kernel/linux.git/drivers/scsi/sd.c: In function
> ‘sd_read_block_zero’:
> /home/kibi/debian-kernel/linux.git/drivers/scsi/sd.c:3300:9: error:
> implicit declaration of function ‘scsi_execute_cmd’; did you mean
> ‘scsi_execute_req’? [-Werror=implicit-function-declaration]

Then it got troublesome even earlier then I expected ;-)
If you do `gitk -- drivers/scsi/` on 'master', then you'll see a huge list of 
recent commits ... which probably didn't get backported all ...
A lot of them landed in 6.8.

That Salvatore could confirm the issue should help.

Good luck,
  Diederik

signature.asc
Description: This is a digitally signed message part.

Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)

[Cyril Brulebois]

Salvatore Bonaccorso  (2024-04-10):
> 6.7.9-2 in unstable does not exibit the issue.

v6.1.84 with stable's .config & bindeb-pkg still does; next up for me:
confirming good/bad and bisecting.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)

[Salvatore Bonaccorso]

On Wed, Apr 10, 2024 at 03:42:44PM +0200, Salvatore Bonaccorso wrote:
> Control: tags -1 - moreinfo
> Control: tags -1 + confirmed
> 
> hi Cyril,
> 
> On Wed, Apr 10, 2024 at 03:32:02PM +0200, Cyril Brulebois wrote:
> > Cyril Brulebois  (2024-04-10):
> > > Salvatore Bonaccorso  (2024-04-10):
> > > > On Tue, Apr 09, 2024 at 03:33:09PM +0200, Diederik de Haas wrote:
> > > > > Does the problem go away if you revert the following commits on top 
> > > > > of -19?
> > > > > 
> > > > > db6338f45971b4285ea368432a84033690eaf53c
> > > > > scsi: core: Move scsi_host_busy() out of host lock for waking up EH 
> > > > > handler
> > > > > 
> > > > > 1ebd75cefaac6fd74729a7d3157f6eaa59960ae2
> > > > > scsi: core: Move scsi_host_busy() out of host lock if it is for 
> > > > > per-command
> > > > > 
> > > > > cf33e6ca12d814e1be2263cb76960d0019d7fb94
> > > > > scsi: core: Add struct for args to execution functions
> > > 
> > > Preparing that test right now, thanks Diederik.
> > 
> > This doesn't build, but I didn't try very hard:
> > 
> > /home/kibi/debian-kernel/linux.git/drivers/scsi/sd.c: In function 
> > ‘sd_read_block_zero’:
> > /home/kibi/debian-kernel/linux.git/drivers/scsi/sd.c:3300:9: error: 
> > implicit declaration of function ‘scsi_execute_cmd’; did you mean 
> > ‘scsi_execute_req’? [-Werror=implicit-function-declaration]
> > 
> > > > Or if that does not find the culprit, would you be able to bisect the
> > > > upstrema changes beweeen 6.1.76 and 6.1.82?
> > 
> > I think I'll try and pinpoint when that regression came up, then figure
> > out what to try to get rid of it. Also testing v6.1.84 while I'm at it.
> > 
> > > > > 4b085736e44d ("ata: libata-core: Do not try to set sleeping devices 
> > > > > to standby")
> > 
> > Reverting that one got me a successful build but that didn't help.
> > 
> > 
> > I'll need to find some more time to switch from throwing a patch into
> > the packaging repository to bindeb-pkg'ing from the mainline repository,
> > and to automate testing as much as possible. I'm familiar with the
> > exercise with Raspberry Pi thingies, but I'd expect some tweaks to be
> > required in the amd64 case.
> 
> FWIW, I can reproduce the issue myself as well, so that makes us both
> already bit more independent to debug the issue.

6.7.9-2 in unstable does not exibit the issue.

Regards,
Salvatore

Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)

[Salvatore Bonaccorso]

Control: tags -1 - moreinfo
Control: tags -1 + confirmed

hi Cyril,

On Wed, Apr 10, 2024 at 03:32:02PM +0200, Cyril Brulebois wrote:
> Cyril Brulebois  (2024-04-10):
> > Salvatore Bonaccorso  (2024-04-10):
> > > On Tue, Apr 09, 2024 at 03:33:09PM +0200, Diederik de Haas wrote:
> > > > Does the problem go away if you revert the following commits on top of 
> > > > -19?
> > > > 
> > > > db6338f45971b4285ea368432a84033690eaf53c
> > > > scsi: core: Move scsi_host_busy() out of host lock for waking up EH 
> > > > handler
> > > > 
> > > > 1ebd75cefaac6fd74729a7d3157f6eaa59960ae2
> > > > scsi: core: Move scsi_host_busy() out of host lock if it is for 
> > > > per-command
> > > > 
> > > > cf33e6ca12d814e1be2263cb76960d0019d7fb94
> > > > scsi: core: Add struct for args to execution functions
> > 
> > Preparing that test right now, thanks Diederik.
> 
> This doesn't build, but I didn't try very hard:
> 
> /home/kibi/debian-kernel/linux.git/drivers/scsi/sd.c: In function 
> ‘sd_read_block_zero’:
> /home/kibi/debian-kernel/linux.git/drivers/scsi/sd.c:3300:9: error: 
> implicit declaration of function ‘scsi_execute_cmd’; did you mean 
> ‘scsi_execute_req’? [-Werror=implicit-function-declaration]
> 
> > > Or if that does not find the culprit, would you be able to bisect the
> > > upstrema changes beweeen 6.1.76 and 6.1.82?
> 
> I think I'll try and pinpoint when that regression came up, then figure
> out what to try to get rid of it. Also testing v6.1.84 while I'm at it.
> 
> > > > 4b085736e44d ("ata: libata-core: Do not try to set sleeping devices to 
> > > > standby")
> 
> Reverting that one got me a successful build but that didn't help.
> 
> 
> I'll need to find some more time to switch from throwing a patch into
> the packaging repository to bindeb-pkg'ing from the mainline repository,
> and to automate testing as much as possible. I'm familiar with the
> exercise with Raspberry Pi thingies, but I'd expect some tweaks to be
> required in the amd64 case.

FWIW, I can reproduce the issue myself as well, so that makes us both
already bit more independent to debug the issue.

Regards,
Salvatore

Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)

[Cyril Brulebois]

Cyril Brulebois  (2024-04-10):
> Salvatore Bonaccorso  (2024-04-10):
> > On Tue, Apr 09, 2024 at 03:33:09PM +0200, Diederik de Haas wrote:
> > > Does the problem go away if you revert the following commits on top of 
> > > -19?
> > > 
> > > db6338f45971b4285ea368432a84033690eaf53c
> > > scsi: core: Move scsi_host_busy() out of host lock for waking up EH 
> > > handler
> > > 
> > > 1ebd75cefaac6fd74729a7d3157f6eaa59960ae2
> > > scsi: core: Move scsi_host_busy() out of host lock if it is for 
> > > per-command
> > > 
> > > cf33e6ca12d814e1be2263cb76960d0019d7fb94
> > > scsi: core: Add struct for args to execution functions
> 
> Preparing that test right now, thanks Diederik.

This doesn't build, but I didn't try very hard:

/home/kibi/debian-kernel/linux.git/drivers/scsi/sd.c: In function 
‘sd_read_block_zero’:
/home/kibi/debian-kernel/linux.git/drivers/scsi/sd.c:3300:9: error: 
implicit declaration of function ‘scsi_execute_cmd’; did you mean 
‘scsi_execute_req’? [-Werror=implicit-function-declaration]

> > Or if that does not find the culprit, would you be able to bisect the
> > upstrema changes beweeen 6.1.76 and 6.1.82?

I think I'll try and pinpoint when that regression came up, then figure
out what to try to get rid of it. Also testing v6.1.84 while I'm at it.

> > > 4b085736e44d ("ata: libata-core: Do not try to set sleeping devices to 
> > > standby")

Reverting that one got me a successful build but that didn't help.


I'll need to find some more time to switch from throwing a patch into
the packaging repository to bindeb-pkg'ing from the mainline repository,
and to automate testing as much as possible. I'm familiar with the
exercise with Raspberry Pi thingies, but I'd expect some tweaks to be
required in the amd64 case.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)

[Cyril Brulebois]

Hi Salvatore,

Salvatore Bonaccorso  (2024-04-10):
> On Tue, Apr 09, 2024 at 03:33:09PM +0200, Diederik de Haas wrote:
> > Hi Cyril,
> > 
> > On Tuesday, 9 April 2024 01:06:43 CEST Cyril Brulebois wrote:
> > > Upgrading from linux-image-6.1.0-18-amd64 to linux-image-6.1.0-19-amd64
> > > leads to losing some SMART information, at least as queried by munin (in
> > > Debian 12) when it comes to sensors.
> > 
> > Does the problem go away if you revert the following commits on top of -19?
> > 
> > db6338f45971b4285ea368432a84033690eaf53c
> > scsi: core: Move scsi_host_busy() out of host lock for waking up EH handler
> > 
> > 1ebd75cefaac6fd74729a7d3157f6eaa59960ae2
> > scsi: core: Move scsi_host_busy() out of host lock if it is for per-command
> > 
> > cf33e6ca12d814e1be2263cb76960d0019d7fb94
> > scsi: core: Add struct for args to execution functions

Preparing that test right now, thanks Diederik.

> Or if that does not find the culprit, would you be able to bisect the
> upstrema changes beweeen 6.1.76 and 6.1.82?
> 
> There would be for instance the following ata related change:
> 
> 4b085736e44d ("ata: libata-core: Do not try to set sleeping devices to 
> standby")
> 
> If you can test it with other kernels, does the same happens on
> 6.7.7-1 and 6.7.9-2?

I'm not really keen on playing kernel ping-pong on this particular
machine (which is important in my infrastructure), but I've verified
that adding a SATA disk to an existing VM running Debian 12 on a
QEMU/libvirt Debian 12 host gives me similar results with -18 and -19
kernels (some data in the former case, no data at all in the latter
one).

I think I'd rather stay with 6.1.y kernels if at all possible, to avoid
having to figure out other changes that might be possibly required to
cope with newer kernels.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo 

Cyril,

On Tue, Apr 09, 2024 at 03:33:09PM +0200, Diederik de Haas wrote:
> Hi Cyril,
> 
> On Tuesday, 9 April 2024 01:06:43 CEST Cyril Brulebois wrote:
> > Upgrading from linux-image-6.1.0-18-amd64 to linux-image-6.1.0-19-amd64
> > leads to losing some SMART information, at least as queried by munin (in
> > Debian 12) when it comes to sensors.
> 
> Does the problem go away if you revert the following commits on top of -19?
> 
> db6338f45971b4285ea368432a84033690eaf53c
> scsi: core: Move scsi_host_busy() out of host lock for waking up EH handler
> 
> 1ebd75cefaac6fd74729a7d3157f6eaa59960ae2
> scsi: core: Move scsi_host_busy() out of host lock if it is for per-command
> 
> cf33e6ca12d814e1be2263cb76960d0019d7fb94
> scsi: core: Add struct for args to execution functions

Or if that does not find the culprit, would you be able to bisect the
upstrema changes beweeen 6.1.76 and 6.1.82?

There would be for instance the following ata related change:

4b085736e44d ("ata: libata-core: Do not try to set sleeping devices to standby")

If you can test it with other kernels, does the same happens on
6.7.7-1 and 6.7.9-2?

Regards,
Salvatore

Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)

[Diederik de Haas]

Hi Cyril,

On Tuesday, 9 April 2024 01:06:43 CEST Cyril Brulebois wrote:
> Upgrading from linux-image-6.1.0-18-amd64 to linux-image-6.1.0-19-amd64
> leads to losing some SMART information, at least as queried by munin (in
> Debian 12) when it comes to sensors.

Does the problem go away if you revert the following commits on top of -19?

db6338f45971b4285ea368432a84033690eaf53c
scsi: core: Move scsi_host_busy() out of host lock for waking up EH handler

1ebd75cefaac6fd74729a7d3157f6eaa59960ae2
scsi: core: Move scsi_host_busy() out of host lock if it is for per-command

cf33e6ca12d814e1be2263cb76960d0019d7fb94
scsi: core: Add struct for args to execution functions

signature.asc
Description: This is a digitally signed message part.

Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)

[Cyril Brulebois]

Package: src:linux
Version: 6.1.82-1
Severity: normal

Hi,

Upgrading from linux-image-6.1.0-18-amd64 to linux-image-6.1.0-19-amd64
leads to losing some SMART information, at least as queried by munin (in
Debian 12) when it comes to sensors.

I'm getting the following results on the 2 pairs of disks in this machine:
 - 2×ST4000VN008-2DR1 (sda, sdb)
 - 2×ST8000VN004-2M21 (sdc, sdd)

root@anchorage:~# /usr/sbin/smartctl -A --nocheck=standby -d ata /dev/sda
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-19-amd64] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

Device is in SLEEP mode, exit(2)

For some reason, the “S.M.A.R.T values” graphs is still OK, while the
“HDD temperature” graph (using the aforementioned command) isn't
anymore.

The “Device is in SLEEP mode” status getting reported is obviously a
lie, since all disks are in use (one pair does system stuff, the other
pair does media stuff).

Rebooting a couple of time with this version gives consistent negative
results. Rebooting into linux-image-6.1.0-18-amd64 gives data back.

The trace that appears below seems to happen exactly once per boot (and
not even once per disk).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


-- Package-specific info:
** Version:
Linux version 6.1.0-19-amd64 (debian-ker...@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.82-1 (2024-03-28)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.1.0-19-amd64 root=/dev/mapper/data-root ro quiet

** Tainted: W (512)
 * kernel issued warning

** Kernel log:
[   23.726790] i915 :00:02.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=io+mem:owns=io+mem
[   23.763253] EXT4-fs (dm-13): mounted filesystem with ordered data mode. 
Quota mode: none.
[   23.764773] input: HDA Intel PCH Front Mic as 
/devices/pci:00/:00:1b.0/sound/card0/input5
[   23.765529] input: HDA Intel PCH Rear Mic as 
/devices/pci:00/:00:1b.0/sound/card0/input6
[   23.765566] input: HDA Intel PCH Line as 
/devices/pci:00/:00:1b.0/sound/card0/input7
[   23.765595] input: HDA Intel PCH Line Out as 
/devices/pci:00/:00:1b.0/sound/card0/input8
[   23.765626] input: HDA Intel PCH Front Headphone as 
/devices/pci:00/:00:1b.0/sound/card0/input9
[   23.785394] [drm] Initialized i915 1.6.0 20201103 for :00:02.0 on minor 0
[   23.786295] ACPI: video: Video Device [GFX0] (multi-head: yes  rom: no  
post: no)
[   23.786473] input: Video Bus as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input10
[   23.798653] i915 :00:02.0: [drm] Cannot find any crtc or sizes
[   23.801990] SGI XFS with ACLs, security attributes, realtime, quota, no 
debug enabled
[   23.823066] i915 :00:02.0: [drm] Cannot find any crtc or sizes
[   23.825531] i915 :00:02.0: [drm] Cannot find any crtc or sizes
[   23.916595] XFS (dm-4): Deprecated V4 format (crc=0) will not be supported 
after September 2030.
[   23.920456] EXT4-fs (dm-14): mounted filesystem with ordered data mode. 
Quota mode: none.
[   23.941160] XFS (dm-4): Mounting V4 Filesystem
[   24.076883] EXT4-fs (dm-5): mounted filesystem with ordered data mode. Quota 
mode: none.
[   24.152240] XFS (dm-4): Ending clean mount
[   24.152258] xfs filesystem being mounted at /data/media supports timestamps 
until 2038 (0x7fff)
[   24.160691] EXT4-fs (dm-3): mounted filesystem with ordered data mode. Quota 
mode: none.
[   24.177491] intel_rapl_common: Found RAPL domain package
[   24.177494] intel_rapl_common: Found RAPL domain core
[   24.177495] intel_rapl_common: Found RAPL domain uncore
[   24.177496] intel_rapl_common: Found RAPL domain dram
[   24.177500] intel_rapl_common: RAPL package-0 domain package locked by BIOS
[   24.177505] intel_rapl_common: RAPL package-0 domain dram locked by BIOS
[   24.415347] audit: type=1400 audit(1712616841.356:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lsb_release" pid=867 
comm="apparmor_parser"
[   24.415751] audit: type=1400 audit(1712616841.356:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=868 
comm="apparmor_parser"
[   24.415755] audit: type=1400 audit(1712616841.356:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=868 comm="apparmor_parser"
[   24.430914] audit: type=1400 audit(1712616841.372:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=870 
comm="apparmor_parser"
[   24.430919] audit: type=1400 audit(1712616841.372:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_filter" pid=870 
comm="apparmor_parser"
[   24.430922] audit: type=1400 audit(1712616841.372:7): apparmor="STATUS" 
operation="profile_load"