Re: [PATCH] ata: libata-sata: retry hardreset when device detected but PHY not established

[yangxingui]

On 2026/4/29 9:36, Damien Le Moal wrote:
> On 4/29/26 10:14, yangxingui wrote:
> > On 2026/4/27 12:45, Damien Le Moal wrote:
> > > On 4/27/26 10:51 AM, yangxingui wrote:
> > > > On 2026/4/26 6:53, Damien Le Moal wrote:
> > > > > On 4/25/26 15:04, Xingui Yang wrote:
> > > > > > When sata_link_hardreset() detects that the link is offline, it currently
> > > > > > returns immediately without distinguishing the reason. According to SATA
> > > > > > specification, the SStatus register's det filed (bits 0-3) indicates:
> > > > > >      - 0x0: No device detected, PHY not communicating
> > > > > >      - 0x1: Device detected but PHY communication not established
> > > > > >      - 0x3: Device detected and PHY communication established
> > > > > >
> > > > > > This patch helps improve device detection reliability and adds a check
> > > > > > when the link is offline but det filed shows 0x1, return -EAGAIN to
> > > > > > trigger retry, rather than giving up immediately.
> > > > > >
> > > > > > Signed-off-by: Xingui Yang <yangxingui@xxxxxxxxxx>
> > > > >
> > > > > This is a pure ATA patch so please CC the linux-ide list, not the linux-scsi
> > > > > list.
> > > >
> > > > Ok.
> > > > > Also, please check your mail setup: your email was in my Junk folder.
> > > >
> > > > Well, patche was sent using the git send command.
> > >
> > > Not git send-email, your smtp server. It probably has something wrong with
> > > DMARC. All your emails endup in my junk folder.
> >
> > Alright, it might be related to the company's SMTP server, but this
> > configuration is fixed, and I'm not quite sure how to fix it yet.
> >
> > > > > This is preceeded by a call to sata_link_resume(), which calls
> > > > > sata_link_debounce() and that function makes sure that DET is stable. So if
> > > > > after that DET still shows that their is no PHY, there is likely a big problem
> > > > > with it and it is super slow to be established.
> > > > >
> > > > > In this case, I do not think that doing another hardreset is the right thing to
> > > > > do. Have you tried increasing the deadline for hardreset ? That deadline is used
> > > > > as the limit for the link debounce too.
> > > > >
> > > > > Do you have a specific controller/device where you see this issue ? What exactly
> > > > > is the hardware setup where you see this issue ?
> > > >
> > > > Our customer imports and verifies a new disk, there is an occasional failure in
> > > > performing a hard reset on the disk and no exception log is generated for
> > > > resume and debounce.
> > >
> > > Does this hold for all disks or for only one or some models ?
> >
> > It may be some models, It is not found on other disks.
>
> Some model ? Which one ?

When the disk is properly connected, the log is as follows:

[   22.658068][ T1297] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 
300)
[   22.665083][ T1297] ata1.00: ATA-10: S1XE240S3N6Y9TC1AP, F66002.0, 
max UDMA/100
[   22.727017][  T806] scsi 0:0:0:0: Direct-Access     ATA 
S1XE240S3N6Y9TC1 02.0 PQ: 0 ANSI: 5
> And please remove linux-scsi from your emails for this topic.

Ok.

Thanks,
Xingui
.