Re: kern/58730: NFS client locks up waiting on nfscn2

[Rin Okuyama <rokuyama.rk%gmail.com@localhost>]

On 2024/11/05 20:29, Martin Husemann wrote:
> On Tue, Nov 05, 2024 at 07:34:22PM +0900, Rin Okuyama wrote:
> > Have you found out the blamed commit? I was about opening a PR for
> > similar problems below, but stalled on narrowing down the commits.
>
> Yes:
>
> cvs rdiff -u -r1.325 -r1.326 src/sys/dev/usb/ehci.c
> cvs rdiff -u -r1.40 -r1.41 src/sys/dev/usb/ehcireg.h
> cvs rdiff -u -r1.52 -r1.53 src/sys/dev/usb/ehcivar.h
>
> broke things for me.
>
> I do
>
>   cd sys/dev/usb && cvs up -r1.325 ehci.c && cvs up -r1.40 ehcireg.h && \
> 	cvs up -r1.52 ehcivar.h
>
> before building a kernel for the Kirkwood machine and everything is all fine.
>
> Nick suggested to review mvgbe bus dma sync operations (and I was planning
> to do that), but now saw that USB is affected too, so something in this commit
> must be wrong (and unrelated to mvgbe bugs).

Thank you for info! I've confirmed that restoring USBMALLOC_COHERENT for
usb_allocmem() in ehci.c fixes the problems both for landisk/HDL_U and
evbppc/NSLU2.

I've found that behavior for bus_dmamap_sync(9) is different b/w
arm32/bus_dma.c and landisk/bus_dma.c; for BUS_DMASYNC_PREREAD,
whereas the former carries out write-back only for misalined parts,
the latter does for segment if its address or length is misalined.

However, even if the behavior is sync with arm32/bus_dma.c:

https://gist.github.com/rokuyama/6e5ffaf956cd39db4752c69fa792096a

the problem for landisk/HDL_U is not improved for me.

Thanks,
rin