On 14/02/2022 22:29, Damien Le Moal wrote:
On 2/15/22 03:06, John Garry wrote:
On 14/02/2022 02:17, Damien Le Moal wrote:
This first part of this series (patches 1 to 24) fixes handling of NCQ
NON DATA commands in libsas and many bugs in the pm8001 driver.
The fixes for the pm8001 driver include:
* Suppression of all sparse warnings, fixing along the way many le32
handling bugs for big-endian architectures
* Fix handling of NCQ NON DATA commands
* Fix of tag values handling (0*is* a valid tag value)
* Fix many tag iand memory leaks in error path
* Fix NCQ error recovery (abort all task execution) that was causing a
crash
The second part of the series (patches 25 to 31) iadd a small cleanup of
libsas code and many simplifications of the pm8001 driver code.
With these fixes, libzbc test suite passes all test case. This test
suite was used with an SMR drive for testing because it generates many
NCQ NON DATA commands (for zone management commands) and also generates
many NCQ command errors to check ASC/ASCQ returned by the device. With
the test suite, the error recovery path was extensively exercised. The
same tests were also executed with a SAS SMR drives to exercise the
error path.
The patches are based on the 5.18/scsi-staging tree.
Hi Damien,
jfyi, I still see the hang with this series. I don't think that the tag
fixes were relevant unfortunately.
As mentioned above, I did test with a SAS drive too (an SMR one to
heavily test the error path) and it worked perfectly.
Note that using Martin's rc1 based scsi-staging tree, I did see a lot of
KASAN complaints on boot regarding MSI/PCI setup. These warnings are
gone with rc3/4. What kernel version base are you using ?
I was using mkp 5.18 staging tree from yesterday as baseline:
https://github.com/hisilicon/kernel-dev/commits/private-topic-sas-5.17-damien-pm8001-v3
If I start using rc4 then I would get conflicts (which obviously would
be resolvable easily enough), but I doubt it is an issue (in using rc1).
I could not find the ARM board I have in the lab yesterday. Will try
again to find it and test with it.
That would be brilliant if you could. This problem could even be down to
defconfig differences (between arm64 and x86_64).
Thanks,
John
