Re: USB umass hard drive "failed to create xfers" when attaching

[Paul Goyette <paul%whooppee.com@localhost>]

This is now PR kern/54997

On Mon, 17 Feb 2020, Paul Goyette wrote:

> > > > With a 9.99.46 kernel built from sources dated 2020-02-07 16:26:35 UTC
> > > > I get the following errors when plugging in a USB hard drive:
> > > >
> > > > umass0 at uhub1 port 2 configuration 1 interface 0
> > > > umass0: Western Digital (0x1058) Ext HDD 1021 (0x1021), rev 2.00/20.02, 
> > > > addr 32
> > > > umass0: using SCSI over Bulk-Only
> > > > umass0: autoconfiguration error: failed to create xfers
> > > >
> > > > This worked correctly with a 9.99.42 kernel built from sources dated
> > > > 2020-01-25 19:35:05 UTC
> > >
> > > When it was working, this is what dmesg reported:
> > >
> > > umass0 at uhub1 port 1 configuration 1 interface 0
> > > umass0: Western Digital (0x1058) Ext HDD 1021 (0x1021), rev 2.00/20.02, 
> > > addr 6
> > > umass0: using SCSI over Bulk-Only
> > > scsibus0 at umass0: 2 targets, 1 lun per target
> > > sd0 at scsibus0 target 0 lun 0: <WD, Ext HDD 1021, 2002> disk fixed
> > > sd0: fabricating a geometry
> > > sd0: 1863 GB, 1907727 cyl, 64 head, 32 sec, 512 bytes/sect x 3907024896 
> > > sectors
> > > sd0: fabricating a geometry
> > >
> > >
> > > > Anyone got any clues on how this got broke?  Or how to fix?
> >
> > More info...
> >
> > First, this is on a amd64 system, witwh 8core/16thread and 128GB of RAM.
> >
> > On IRC it was suggested (thanks, maya!) that the error message might be
> > related to memory fragmentation.  I didn't believe it (given how much
> > RAM I have), but a quick check with top(1) showed that I had more than
> > 100GB of 'file cache' active.  So, I unmounted all my development trees
> > (to force the cache to get flushed).  Sure enough, I am now able to
> > successfully mount the USB drive!
> >
> > So, sounds like "something somewhere isn't quite right (tm)".  I would
> > have expected a memory allocation failure to automatically trigger some
> > mechanism to reclaim some of the file cache...
>
> And, based on more discussion, this would seem to be a kernel virtual
> address fragmentation issue, and not related to physical memory being
> available.  The concensus on IRC is that this is a bug in the xhci(4)
> driver.
>
>
> +--------------------+--------------------------+-----------------------+
> | Paul Goyette       | PGP Key fingerprint:     | E-mail addresses:     |
> | (Retired)          | FA29 0E3B 35AF E8AE 6651 | paul%whooppee.com@localhost     |
> | Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette%netbsd.org@localhost   |
> +--------------------+--------------------------+-----------------------+
>
> !DSPAM:5e4abe59169311060514377!

+--------------------+--------------------------+-----------------------+
| Paul Goyette       | PGP Key fingerprint:     | E-mail addresses:     |
| (Retired)          | FA29 0E3B 35AF E8AE 6651 | paul%whooppee.com@localhost     |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette%netbsd.org@localhost   |
+--------------------+--------------------------+-----------------------+