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

["Rin Okuyama via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/58730; it has been noted by GNATS.

From: Rin Okuyama <rokuyama.rk%gmail.com@localhost>
To: Martin Husemann <martin%duskware.de@localhost>
Cc: gnats-bugs%netbsd.org@localhost, netbsd-bugs%NetBSD.org@localhost, gnats-admin%netbsd.org@localhost
Subject: Re: kern/58730: NFS client locks up waiting on nfscn2
Date: Wed, 6 Nov 2024 21:42:58 +0900

 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