Re: port-amd64/56987 (Certain usb devices can no longer be mounted on -current)

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

The following reply was made to PR port-amd64/56987; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: mlh%goathill.org@localhost (MLH)
Cc: gnats-bugs%netbsd.org@localhost, port-amd64-maintainer%netbsd.org@localhost,
	gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, mlh%goathill.org@localhost
Subject: Re: port-amd64/56987 (Certain usb devices can no longer be mounted on
	-current)
Date: Wed, 19 Jul 2023 15:58:33 +0000

 > Date: Mon, 5 Jun 2023 20:41:51 -0400 (EDT)
 > From: mlh%goathill.org@localhost (MLH)
 > 
 > Any advice on looking into fixing the usb device mounting issues
 > that were broken with the usb changes last year? And yes, the usb
 > subsystem is much more stable with those changes, but I really
 > would like to finish things.
 
 The best thing to do is to bisect to find exactly what change broke
 it.  A lot of things changed between 9.99.93 and 9.99.94 over the
 course of four months.
 
 On any reasonably POSIXish system (doesn't have to be your NetBSD
 machine), you can do this:
 
 $ git clone https://github.com/NetBSD/src
 $ cd src
 $ ./build.sh -O ../obj -T ../tools -U -u -m amd64 -j4 tools
 $ git bisect start
 $ git bisect bad HEAD
 $ git bisect good 8abbca48b237c9edc3ffb387e9074ddcff8b645d
 
 And then, at each step, do
 
 $ ./build.sh -O ../obj -T ../tools -U -u -m amd64 -j4 kernel=GENERIC
 
 and try the kernel at ../obj/sys/arch/amd64/compile/GENERIC/netbsd.
 
 - If it works, run `git bisect good'.
 - If it fails the same way, `git bisect bad'.
 - If it fails to build, or crashes in some other way, tun `git bisect
   skip'.
 
 And keep going until it points you to a particular commit.
 
 (f6d3947777a575d460fc1be6c52252513ecfba93 is the commit that bumped
 the version to 9.99.92.  This range is a little larger than needed,
 but that's fine -- bisection is logarithmic, so checking everything
 from 9.99.92 to now vs checking everything from 9.99.93 to 9.99.94
 will probably only add a couple more iterations.)
 
 
 Another thing that might help, in case there is a thread that is just
 wedged somewhere, is to run:
 
 # crash
 crash> ps
 crash> ps/w
 
 And, if you're using a kernel from the last week:
 
 crash> show all tstiles
 
 And then share the output.  But I suspect it's not a wedged thread;
 that would probably manifest in other ways.
 
 
 It might also help to share dmesg from the working 9.99.93 kernel so
 we can look at all of it side-by-side with the broken 9.99.94 kernel
 or whatever.