[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <689f8224-f118-47f0-8ae0-a7377c6ff386@grabatoulnz.fr>
Date: Thu, 6 Mar 2025 13:27:17 +0100
From: Eric <eric.4.debian@...batoulnz.fr>
To: Niklas Cassel <cassel@...nel.org>
Cc: Salvatore Bonaccorso <carnil@...ian.org>,
Mario Limonciello <mario.limonciello@....com>,
Christoph Hellwig <hch@...radead.org>,
Mika Westerberg <mika.westerberg@...ux.intel.com>,
Damien Le Moal <dlemoal@...nel.org>, Jian-Hong Pan <jhp@...lessos.org>,
regressions@...ts.linux.dev, linux-kernel@...r.kernel.org,
stable@...r.kernel.org, linux-ide@...r.kernel.org,
Dieter Mummenschanz <dmummenschanz@....de>
Subject: Re: Regression from 7627a0edef54 ("ata: ahci: Drop low power policy
board type") on reboot (but not cold boot)
Le 06/03/2025 à 11:40, Niklas Cassel a écrit :
> On Thu, Mar 06, 2025 at 11:37:08AM +0100, Niklas Cassel wrote:
>> On Mon, Mar 03, 2025 at 03:58:30PM +0100, Eric wrote:
>>> Hi Niklas
>>>
>>> Le 03/03/2025 à 07:25, Niklas Cassel a écrit :
>>>> Do you see your SSD in the kexec'd kernel?
>>> Sorry, I've tried that using several methods (systemctl kexec / kexec --load
>>> + kexec -e / kexec --load + shutdown --reboot now) and it failed each time.
>>> I *don't* think it is related to this bug, however, because each time the
>>> process got stuck just after displaying "kexec_core: Starting new kernel".
>> I just tired (as root):
>> # kexec -l /boot/vmlinuz-6.13.5-200.fc41.x86_64 --initrd=/boot/initramfs-6.13.5-200.fc41.x86_64.img --reuse-cmd
>> # kexec -e
>>
>> and FWIW, kexec worked fine.
>>
>> Did you specify an initrd ? did you specify --reuse-cmd ?
At one time, I did yes. I can't figure out what's wrong, but working
from the assumption that another way of working around the UEFI's
failure to wake the disk might yield the same information that you're
looking for,
I installed the same system on a USB stick, on which I also installed
grub, so that the reboot is made independent of weather the UEFI sees
the SSD disk or not. I'll attach dmesg extracts (grep on ata or ahci) to
this mail.
One is the dmesg after coldbooting from the USB stick, the other is
rebooting on the USB stick. First of all, the visible result : the SSD
is not detected by linux at reboot (but is when coldbooting).
Here is what changes :
eric@...ihir:~$ diff
/media/eric/trixieUSB/home/eric/dmesg-ahci-ata-coldboot.untimed.txt
/media/eric/trixieUSB/home/eric/dmesg-ahci-ata-reboot.untimed.txt
4c4
< ahci 0000:00:11.0: 4/4 ports implemented (port mask 0x3c)
---
> ahci 0000:00:11.0: 3/3 ports implemented (port mask 0x38)
14c14
< ata3: SATA max UDMA/133 abar m1024@...eb0b000 port 0xfeb0b200 irq 19
lpm-pol 3
---
> ata3: DUMMY
27,28d26
< ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
< ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
29a28
> ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
31,34d29
< ata3.00: Model 'Samsung SSD 870 QVO 2TB', rev 'SVQ02B6Q', applying
quirks: noncqtrim zeroaftertrim noncqonati
< ata3.00: supports DRM functions and may not be fully accessible
< ata3.00: ATA-11: Samsung SSD 870 QVO 2TB, SVQ02B6Q, max UDMA/133
< ata3.00: 3907029168 sectors, multi 1: LBA48 NCQ (not used)
37a33
> ata5.00: configured for UDMA/100
40d35
< ata5.00: configured for UDMA/100
43,46d37
< ata3.00: Features: Trust Dev-Sleep
< ata3.00: supports DRM functions and may not be fully accessible
< ata3.00: configured for UDMA/133
< scsi 2:0:0:0: Direct-Access ATA Samsung SSD 870 2B6Q PQ: 0
ANSI: 5
50,51d40
< ata3.00: Enabling discard_zeroes_data
< ata3.00: Enabling discard_zeroes_data
I hope this is useful for diagnosing the problem.
> Sorry, typo:
>
> s/--reuse-cmd/--reuse-cmdline/
>
>
> Kind regards,
> Niklas
Kind regards,
Eric
View attachment "dmesg-ahci-ata-reboot.txt" of type "text/plain" (2490 bytes)
View attachment "dmesg-ahci-ata-coldboot.txt" of type "text/plain" (3360 bytes)
Powered by blists - more mailing lists