linux-kernel - Re: [REGRESSION][BISECTED] BU40N Blu-Ray drive broken since 7627a0edef54

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <67357bab-9de8-41ff-a43f-3da2ace5a814@heusel.eu>
Date: Tue, 14 Jan 2025 17:06:46 +0100
From: Christian Heusel <christian@...sel.eu>
To: Niklas Cassel <cassel@...nel.org>
Cc: Mario Limonciello <mario.limonciello@....com>, 
	Damien Le Moal <dlemoal@...nel.org>, Mika Westerberg <mika.westerberg@...ux.intel.com>, 
	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org, regressions@...ts.linux.dev
Subject: Re: [REGRESSION][BISECTED] BU40N Blu-Ray drive broken since
 7627a0edef54

Hello Niklas,

On 25/01/13 05:26PM, Niklas Cassel wrote:
> Hello Christian,
> 
> On Sat, Jan 11, 2025 at 05:41:10PM +0100, Christian Heusel wrote:
> > On 25/01/10 05:21PM, Christian Heusel wrote:
> > > On 25/01/10 12:24PM, Niklas Cassel wrote:
> > > > On Fri, Jan 10, 2025 at 10:04:46AM +0100, Christian Heusel wrote:
> > > >
> > > > > So if anyone has feedback on why the patch does not work or any
> > > > > alternative ideas for a solution that would be highly appreciated!
> > 
> > So weirdly the quirk from the patch for the same kernel _does work_ when
> > the user passes the kernel parameter "ahci.mobile_lpm_policy=1":
> > 
> > [   24.035361] ata4.00: Model 'HL-DT-ST BD-RE BU40N', rev '1.03', applying quirks: nolpm
> > 
> > Any idea why that could be? Is it maybe not the device itself but the
> > controller that it connects to that is borked and in need of the quirk?
> 
> So from the 6.6.69-1-lts log, which you claim is working, we see this:
> <dmesg-snip>
>
> Since this is running AHCI, default reset is ahci_do_hardreset() (COMRESET).
> 
> The SATA link up/link down messages are printed after resetting each port.
> We can see that we get link up on ata3 and ata5, but link is down on ata6
> and ata4.
> 
> Seeing link down after a reset is not correct, and I think we should first
> focus on seeing link up for ata4, before knowing if we also need a quirk or
> not.

Thanks for your detailed explanation!

> Could you please try this patch?
> 
> diff --git a/drivers/ata/libata-sata.c b/drivers/ata/libata-sata.c
> index 9c76fb1ad2ec..b0bff5fe3e03 100644
> --- a/drivers/ata/libata-sata.c
> +++ b/drivers/ata/libata-sata.c
> @@ -660,7 +660,7 @@ int sata_link_hardreset(struct ata_link *link, const unsigned int *timing,
>         /* Couldn't find anything in SATA I/II specs, but AHCI-1.1
>          * 10.4.2 says at least 1 ms.
>          */
> -       ata_msleep(link->ap, 1);
> +       ata_msleep(link->ap, 20 + 10 + 1);
>  
>         /* bring link back */
>         rc = sata_link_resume(link, timing, deadline);
> 
> 
> 
> If that works to get link up after reset, you can continue to see if the
> LPM quirk is needed or not. (And I will need to write a proper fix so
> that we sleep the correct amount of time while holding PxSCTL.DET in 1).

Sadly the patch applied on top of 6.13-rc7 did not work, atleast it did
not immediately bring the device back up again after the reset. You can
see the users full answer [here][0]. I also attached the dmesg, but as
that cuts off rather quickly I have also asked the user to do a longer
test.

> Kind regards,
> Niklas

Cheers,
Chris

[0]: https://bbs.archlinux.org/viewtopic.php?pid=2220082#p2220082

View attachment "linux-mainline-6.13-rc7-1.1-dmesg.log" of type "text/plain" (88858 bytes)

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)