i386/127222: Regression in 7.0 usb storage generic driver

[Daniel Feenberg]

>Number:         127222
>Category:       i386
>Synopsis:       Regression in 7.0 usb storage generic driver
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-i386
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Sep 08 20:30:01 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator:     Daniel Feenberg
>Release:        7.0
>Organization:
National Bureau of Economic Research
>Environment:
uname -a

FreeBSD mysql2 7.0-RELEASE-p4 FreeBSD 7.0-RELEASE-p4 #0: Tue Sep  2
19:32:35 UTC 2008root at i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  i386

Also relevant section from dmesg:

ohci0: [GIANT-LOCKED]
ohci0: [ITHREAD]
usb0: OHCI version 1.0, legacy support
usb0: <OHCI (generic) USB controller> on ohci0
usb0: USB revision 1.0
uhub0: <(0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
uhub0: 2 ports with 2 removable, self powered

>Description:
On some of our servers, if I boot to FreeBSD 6.2 the USB flash drives
work, whereas when I boot to FreeBSD 7 they do not work, failures being
running out of space when there should be plenty, or newfs failing, or
when you mount the device files and directories are missing.

This occurs for us only on systems with the OHCI Generic USB controller.
On our other systems with the UHCI USB controllers both 6.2 and 7.0 work
flawlessly. Therefore I believe this is a regression from 6.2 to 7.0 in
the Generic OHCI USB controller code.
>How-To-Repeat:
The exact problem depends on the brand of thumbdrive used. Some show
errors during initialization, some do not. Here is an example that
initializes, but fails later. It is typical:

  mysql2# fdisk -I /dev/da1
  ******* Working on device /dev/da1 *******
  fdisk: Geom not found: "da1"
  mysql2# bsdlabel -w /dev/da1s1
  mysql2# newfs /dev/da1s1a
  /dev/da1s1a: 496.0MB (1015760 sectors) block size 16384, fragment size
  2048 using 4 cylinder groups of 124.00MB, 7936 blks, 15872 inodes.
  super-block backups (for fsck -b #) at:
  160, 254112, 508064, 762016
  mount /dev/da1s1a /localscsi

Now we write to the device till it is full, but find that the "full"
device has 329,604 available blocks according to df. It may be coincidence, but this is close to the size of a cylinder group. We do not see problems like
this in 6.2.

  mysql2# yes >/localscsi/file.foo
  /localscsi: write failed, filesystem is full
  yes: stdout: No space left on device
  mysql2# df /localscsi
  Filesystem  1K-blocks   Used  Avail Capacity  Mounted on
  /dev/da1s1a    491798 122852 329604    27%    /localscsi

Another clue is the output from fsck which seems to think it needs more
than 4 GB of storage to fsck a 512MB drive:

  umount /localscsi
  mysql2# fsck /dev/da1s1a
  ** /dev/da1s1a
  ** Last Mounted on /localscsi
  ** Phase 1 - Check Blocks and Sizes
  fsck_4.2bsd: cannot alloc 4294967292 bytes for inoinfo

>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted: