NetBSD 9.0 amd64 USB/SCSI issue

[Bruce Lilly <bruce.lilly+nbsd%gmail.com@localhost>]

https://mail-index.netbsd.org/current-users/2020/06/27/msg038982.html
describes an issue one user found; there's only one follow-up, and it's
not encouraging.

I've had similar issues accessing EXT2 formatted USB flash drives and
external USB hard drives on NetBSD 9.0 amd64:
NetBSD cq60-615dx.blilly.net 9.0 NetBSD 9.0 (GENERIC) #0: Fri Feb 14
00:06:28 UTC 2020
mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/amd64/compile/GENERIC
amd64 x86_64 Intel 686-class NetBSD

With a PNY 512 GB USB3 flash drive directly connected to a USB 2
port, I get the same "failed to create xfers" message described in the
above-referenced report (which I found via Google).  Following the
information in that report, I tried again with a 10 ft. cable between the
port and drive, and the system then worked...for a while (see below).
Specifically, w/o cable:
[ 114515.101006] umass1 at uhub7 port 5 configuration 1 interface 0
[ 114515.101006] umass1: PNY (0x154b) USB 3.0 FD (0xd9), rev 2.10/1.10, addr 3
[ 114515.101006] umass1: using SCSI over Bulk-Only
[ 114515.101006] umass1: autoconfiguration error: failed to create xfers
and with cable between port and drive:
[ 115039.400477] umass1 at uhub7 port 5 configuration 1 interface 0
[ 115039.400477] umass1: PNY (0x154b) USB 3.0 FD (0xd9), rev 2.10/1.10, addr 3
[ 115039.400477] umass1: using SCSI over Bulk-Only
[ 115039.400477] scsibus1 at umass1: 2 targets, 1 lun per target
[ 115039.400477] sd1 at scsibus1 target 0 lun 0: <PNY, USB 3.0 FD,
PMAP> disk removable
[ 115039.400477] sd1: fabricating a geometry
[ 115039.400477] sd1: 461 GB, 472512 cyl, 64 head, 32 sec, 512
bytes/sect x 967704576 sectors
[ 115039.410486] sd1: fabricating a geometry
and I could then proceed to run disklabel (really? "rpm" for a flash drive!?)
and mount the EXT2 filesystem (which disklabel incorrectly calls NTFS):
# /dev/sd1:
type: SCSI
disk: USB 3.0 FD
label: fictitious
flags: removable
bytes/sector: 512
sectors/track: 32
tracks/cylinder: 64
sectors/cylinder: 2048
cylinders: 472512
total sectors: 967704576
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0           # microseconds
track-to-track seek: 0  # microseconds
drivedata: 0

5 partitions:
#        size    offset     fstype [fsize bsize cpg/sgs]
 d: 967704576         0     unused      0     0        # (Cyl.      0 - 472511)
 e: 967437440    267136       NTFS                     # (Cyl.    130*- 472511)
disklabel: boot block size 0
disklabel: super block size 0

An external WD USB hard drive (which has an attached ca. 1.5m cable)
was recognized w/o error messages and could be mounted.

In both cases, however, after a while (a couple of hours) processes accessing
files on the drives hung and could not be terminated, even with kill -9 issued
by the superuser (to me, that means that something in the kernel code is
deadlocked, and that's a serious problem).   Obviously that precluded a normal
shutdown as shutdown waited for interminable processes (rsync, ls, sync,
even umount).  I have had data corruption as a result (which, fortunately, I
think I've been able to recover from).   For now, I am reluctant to mount any
removable media under NetBSD 9.0  (didn't have this issue with 8.x).

Incidentally, the installation is itself on a USB flash drive, which seems to
work reasonably well aside from the USB/SCSI issue and a few unrelated
glitches.  FWIW:
# /dev/sd0:
type: unknown
disk: sd
label: fictious
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 16
sectors/cylinder: 1008
cylinders: 65535
total sectors: 240353280
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0           # microseconds
track-to-track seek: 0  # microseconds
drivedata: 0

4 partitions:
#        size    offset     fstype [fsize bsize cpg/sgs]
 a: 232161216        64     4.2BSD      0     0     0  # (Cyl.      0*- 230318*)
 b:   8191936 232161344       swap                     # (Cyl. 230318*- 238445*)
 c: 240353216        64     unused      0     0        # (Cyl.      0*- 238445*)
 d: 240353280         0     unused      0     0        # (Cyl.      0 - 238445*)

and mount -v:
/dev/sd0a on / type ffs (local, root file system, fsid: 0x400/0x78b,
reads: sync 27194702 async 2285, writes: sync 119569 async 310572)
tmpfs on /tmp type tmpfs (local, fsid: 0xab01/0x69ab, reads: sync 0
async 0, writes: sync 0 async 0)
kernfs on /kern type kernfs (local, fsid: 0x8b01/0x1d28b, reads: sync
0 async 0, writes: sync 0 async 0)
ptyfs on /dev/pts type ptyfs (local, fsid: 0x7b01/0x6b7b, reads: sync
0 async 0, writes: sync 0 async 0)
procfs on /proc type procfs (local, fsid: 0x1b01/0x1ae1b, reads: sync
0 async 0, writes: sync 0 async 0)
tmpfs on /var/shm type tmpfs (local, fsid: 0xab02/0x69ab, reads: sync
0 async 0, writes: sync 0 async 0)

Accessing the same non-root USB drives mentioned above from other OSes (Linux,
MS Windows 7) on the same machine has no problems (including from a USB
flash-installed version of Linux).

At the moment, my workaround is to mount removable media on another
machine running something other than NetBSD 9.0, transferring files
over a network connection, which is a PITA compared to direct access.

Another, less-critical disklabel-ish issue is improper filesystem type
[mis-]identification,
e.g.:
# disklabel /dev/wd0
# /dev/wd0:
type: ESDI
disk: wd0
label: fictitious
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 16
sectors/cylinder: 1008
cylinders: 1938021
total sectors: 1953525168
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0           # microseconds
track-to-track seek: 0  # microseconds
drivedata: 0

10 partitions:
#        size    offset     fstype [fsize bsize cpg/sgs]
 d: 1953525168         0     unused      0     0        # (Cyl.      0
- 1938020)
 e:    407552      2048       NTFS                     # (Cyl.      2*-    406*)
 f: 251658224    409600       NTFS                     # (Cyl.    406*- 250067*)
 g:  26161152 1927360512       NTFS                     # (Cyl.
1912064 - 1938017*)
 i:  41934848 252069888       swap                     # (Cyl. 250069*- 291671*)
 j: 1633327104 294006784 Linux Ext2      0     0        # (Cyl.
291673*- 1912037*)
disklabel: boot block size 0
disklabel: super block size 0

What is mis-identified as "Linux Ext2" is in fact XFS (the filesystem,
not the font
server :-/) .