The SATA_ini162x.

The SATA_ini162x.

[Magnus Elfvendahl]

Hi

Is there a workaround to activate the driver again?

We have a small production server that stopped working due to Ubuntu 
disabling access to the drives connected to the controller.

Fortunately for us, we are not using the RAID function of the unit, only 
using it as a disc-controller. That is, the pass-through function.

I have been ill for a long time and not been able to start doing 
research as the what the issue is, and I just found this information.


Best regards.

Magnus

Re: The SATA_ini162x.

[Damien Le Moal]

On 2/12/23 23:53, Magnus Elfvendahl wrote:
> Hi
> 
> Is there a workaround to activate the driver again?
> 
> We have a small production server that stopped working due to Ubuntu 
> disabling access to the drives connected to the controller.

That is not a lot of information to go on... What is in dmesg ? Anything
logged there ?

> 
> Fortunately for us, we are not using the RAID function of the unit, only 
> using it as a disc-controller. That is, the pass-through function.
> 
> I have been ill for a long time and not been able to start doing 
> research as the what the issue is, and I just found this information.
> 
> 
> Best regards.
> 
> Magnus
> 

-- 
Damien Le Moal
Western Digital Research

Re: The SATA_ini162x.

[Ioannis Barkas]

Hello Magnus,

I will give you more details about it since I reported the issue with
this controller many years ago.

Yes you can activate the driver but you will need to enable this
driver and build your own kernel. That is needed since the driver is
disabled by default. There is at least one underlying issue that has
got unnoticed and has not been solved yet thus the driver is
considered experimental. My PCI card has an eSATA connector routed to
port 0 and a SATA connector routed to port 1. Back then, I had tested
the SATA port and believed that the driver could only handle port 0.

Damien if you are willing to investigate this and help me fix it, I am
at your disposal. I still have the card with this controller, the
datasheet of the IC manufacturer, an AMD based PC with a PCI slot and
lots of disks for testing. What is more, I had done some tests back in
December and the issue remains. Here is what 6.1 prints:
[    1.947670] sata_inic162x 0000:05:06.0: version 0.4
[    1.947716] sata_inic162x 0000:05:06.0: inic162x support is broken
with common data corruption issues and will be disabled by default,
contact linux-ide@vger.kernel.org if in production use

Here is the problem:
[    3.285163] ata8.00: native sectors (1) is smaller than sectors (976773168)

I tested the eSATA port and it behaves exactly the same as the SATA
port. I have also performed some modifications but those were in the
wrong direction as I completely broke the driver thus it could not
detect attached devices. That brought a libata bug to the surface and
I need to send a patch about it. Back to sata_inic, I have not figured
out how it works with both channels.

Hope to get better Magnus really soon!

Best regards.

Re: The SATA_ini162x.

[Damien Le Moal]

On 2/23/23 06:28, Ioannis Barkas wrote:
> Hello Magnus,
> 
> I will give you more details about it since I reported the issue with
> this controller many years ago.
> 
> Yes you can activate the driver but you will need to enable this
> driver and build your own kernel. That is needed since the driver is
> disabled by default. There is at least one underlying issue that has
> got unnoticed and has not been solved yet thus the driver is
> considered experimental. My PCI card has an eSATA connector routed to
> port 0 and a SATA connector routed to port 1. Back then, I had tested
> the SATA port and believed that the driver could only handle port 0.
> 
> Damien if you are willing to investigate this and help me fix it, I am
> at your disposal. I still have the card with this controller, the
> datasheet of the IC manufacturer, an AMD based PC with a PCI slot and
> lots of disks for testing. What is more, I had done some tests back in
> December and the issue remains. Here is what 6.1 prints:
> [    1.947670] sata_inic162x 0000:05:06.0: version 0.4
> [    1.947716] sata_inic162x 0000:05:06.0: inic162x support is broken
> with common data corruption issues and will be disabled by default,
> contact linux-ide@vger.kernel.org if in production use
> 
> Here is the problem:
> [    3.285163] ata8.00: native sectors (1) is smaller than sectors (976773168)

Are you using drives with HPA ? (host protected area, see:
https://en.wikipedia.org/wiki/Host_protected_area).

That normally is drive dependent, not adapter dependent. And with TCG now, HPA
is not really a thing anymore and not used on any recent drive (that I know of
at least).

Could you try with recent drives (HDDs or SSDs) that do not have HPA ? And maybe
also try to see if the libata argument "ata_ignore_hpa=1" helps.

You could also try adding a horkage for that HPA drive (see
ATA_HORKAGE_BROKEN_HPA examples in libata-core.c, ata_device_blacklist array).
Note to self: there is unfortunately no libata.force= argument for hpa. Will
need to add that.

> 
> I tested the eSATA port and it behaves exactly the same as the SATA
> port. I have also performed some modifications but those were in the
> wrong direction as I completely broke the driver thus it could not
> detect attached devices. That brought a libata bug to the surface and
> I need to send a patch about it. Back to sata_inic, I have not figured
> out how it works with both channels.
> 
> Hope to get better Magnus really soon!
> 
> Best regards.

-- 
Damien Le Moal
Western Digital Research

Re: The SATA_ini162x.

[Ioannis Barkas]

Hello Damien,

Sorry for the late reply, I have been busy porting an ancient android
kernel to GCC 10 and have consumed lots of time on that.

Most drives support HPA but it was not enabled on my device. Kernel
could boot without HPA but I would not recommend it. I have seen x86
firmware using it to backup its image in HPA area so we could get into
big trouble.

I am sure that this is not an HDD issue but can verify that HPA is
workable on another host. Will test an AMD one and test a boot with
the proposed argument. I planned to test it with an LBA28 disk but
haven't done so as I need a spare one. Will definitelly do it during
the weekend.

Thank you!

On Thu, 23 Feb 2023 at 01:43, Damien Le Moal
<damien.lemoal@opensource.wdc.com> wrote:
>
> On 2/23/23 06:28, Ioannis Barkas wrote:
> > Hello Magnus,
> >
> > I will give you more details about it since I reported the issue with
> > this controller many years ago.
> >
> > Yes you can activate the driver but you will need to enable this
> > driver and build your own kernel. That is needed since the driver is
> > disabled by default. There is at least one underlying issue that has
> > got unnoticed and has not been solved yet thus the driver is
> > considered experimental. My PCI card has an eSATA connector routed to
> > port 0 and a SATA connector routed to port 1. Back then, I had tested
> > the SATA port and believed that the driver could only handle port 0.
> >
> > Damien if you are willing to investigate this and help me fix it, I am
> > at your disposal. I still have the card with this controller, the
> > datasheet of the IC manufacturer, an AMD based PC with a PCI slot and
> > lots of disks for testing. What is more, I had done some tests back in
> > December and the issue remains. Here is what 6.1 prints:
> > [    1.947670] sata_inic162x 0000:05:06.0: version 0.4
> > [    1.947716] sata_inic162x 0000:05:06.0: inic162x support is broken
> > with common data corruption issues and will be disabled by default,
> > contact linux-ide@vger.kernel.org if in production use
> >
> > Here is the problem:
> > [    3.285163] ata8.00: native sectors (1) is smaller than sectors (976773168)
>
> Are you using drives with HPA ? (host protected area, see:
> https://en.wikipedia.org/wiki/Host_protected_area).
>
> That normally is drive dependent, not adapter dependent. And with TCG now, HPA
> is not really a thing anymore and not used on any recent drive (that I know of
> at least).
>
> Could you try with recent drives (HDDs or SSDs) that do not have HPA ? And maybe
> also try to see if the libata argument "ata_ignore_hpa=1" helps.
>
> You could also try adding a horkage for that HPA drive (see
> ATA_HORKAGE_BROKEN_HPA examples in libata-core.c, ata_device_blacklist array).
> Note to self: there is unfortunately no libata.force= argument for hpa. Will
> need to add that.
>
> >
> > I tested the eSATA port and it behaves exactly the same as the SATA
> > port. I have also performed some modifications but those were in the
> > wrong direction as I completely broke the driver thus it could not
> > detect attached devices. That brought a libata bug to the surface and
> > I need to send a patch about it. Back to sata_inic, I have not figured
> > out how it works with both channels.
> >
> > Hope to get better Magnus really soon!
> >
> > Best regards.
>
> --
> Damien Le Moal
> Western Digital Research
>