Re: [PATCH v5 0/7] libsas and drivers: NCQ error handling

[Niklas Cassel]

On Thu, Oct 06, 2022 at 05:41:40PM +0100, John Garry wrote:
> > > > 
> > > Yeah, it just looks to be the longstanding issue of using this card on my
> > > arm64 machine - that is that I get IO timeouts quite regularly. I should
> > > have mentioned that yesterday. This just seems to be a driver issue.
> > Out of curiosity, which arm64 SoC is this?
> 
> HiSilicon hi1620 which contains a custom arm v8 implementation. Note that
> others have also seen the issue with this card on other arm implementations.
> 
> > 
> > While it is very unlikely that this is your problem, but I've encountered
> > an issue on an ARM board before, where the PCIe controller was incorrectly
> > configured in device tree, causing the controller to miss interrrupts,
> > which presented itself to the user as timeouts in the WiFi driver:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=97131f85c08e024df49480ed499aae8fb754067f
> 
> Unlikely. Indeed, when I was checking this issue some time go, I found that
> not only was there no completion interrupt but also no completion when I
> manually examine the completion ring buffer read and write pointers.
> 
> Here's where I discuss this issue earlier a bit:
> https://lore.kernel.org/linux-scsi/PH0PR11MB511238B8FF7B44C375DDDFADEC519@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
> 

Hello John,

For the record, I tested the pm80xx driver on a HoneyComb LX2 board
(an arm64 board using ACPI).

I tried v6.1-rc1 both with and without your series in $subject.

I couldn't see any issues.


What I tried:
-Running fio:
fio --name=test --filename=/dev/sdc --ioengine=io_uring --rw=randrw --direct=1 --iodepth=32 --bs=1M
on three different HDDs simultaneously for 15+ minutes,
without any errors in fio or dmesg.

-Creating and mounting a btrfs volume, doing a huge dd to the filesystem
without issues.

-sg_sat_read_gplog -d --log=0x10 /dev/sda
which successfully returned the log.


It is worth mentioning that this arm64 board has reserved memory regions,
but does not yet have a firmware that supplies a IORT RMR (reserved memory
regions) revision E.d node, which means that in order to get this board to
boot successfully, we need to supply:
"arm-smmu.disable_bypass=0 iommu.passthrough=1"
on the kernel command line.

It could be worth trying the same on your arm64 machine, to see that also
makes the pm80xx driver play nice for you.


Kind regards,
Niklas