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@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx 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 >
