Kernel panic when copying data to umass device (USB4BSD) - problem found

[Jeremy Chadwick]

On Fri, Nov 07, 2008 at 06:11:26PM +0100, Hans Petter Selasky wrote:
> On Friday 07 November 2008, Jeremy Chadwick wrote:
> > Not sure if this is caused by problems with USB4BSD or not, as I can
> > reproduce it on RELENG_7 (but there, the kernel does not panic; it just
> > "wedges" in a loop/thread somewhere; SSH sessions remain up, but
> > commands running stop; hitting Ctrl-T shows them in all sorts of
> > different states, but the states never change; hitting Ctrl-Alt-Esc does
> > in fact drop me to db>).
> 
> Hi Jeremy,
> 
> I've reproduced the issue with some mods to the usb2_busdma.c on 32-bit 
> arcitecture and have made a fix for this problem.
> 
> Try the following patch and re-test! Some mem-stick benchmarks would be 
> nice ...
> 
> My private SVN also has this patch in addition to P4.

Hans,

To answer your question in your other mail: yes, this is on an amd64
machine with 4GB of RAM installed.

With the patch to usb2_busdma applied, the problem is fixed!  Thank you
very, very much.

As far as benchmarks: I'll keep it simple and try different block sizes.
Numbers are compared against a Windows XP machine using the ATTO
Benchmarking tool (which uses direct I/O read/writes, not filesystem
I/O).

Preface facts:

- Testing done against SanDisk Cruzer Micro 8GB (SDCZ6-8192RB)
- USB 2.0 bus used exclusively on both FreeBSD and Windows
- Write caching disabled for USB drives on Windows XP
- MD5 tests done against 7.1-BETA2-amd64-disc1.iso (573087744 bytes)
- MD5 checksums matched source -- no corruption found on Windows or
  FreeBSD

Software details:

- ATTO Disk Benchmark v2.34
- ATTO configuration: Direct I/O, "Neither" type selected (vs.
  queued/overlapped I/O); data length size = 512MB
- All FreeBSD tests done with HPS's busdma patches applied
- dd read command: dd if=/dev/zero of=/dev/da0 bs=<size>
- dd write command: dd if=/dev/da0  of=/dev/null bs=<size>
- md5 command: time md5 7.1-BETA2-amd64-disc1.iso
- FreeBSD filesystem: UFS1 (16KB blocks), using da0s1 directly
- Windows filesystem: FAT32 (4KB blocks)

                       Read         Write
                       ---------    ---------
Windows ATTO (4KB)      6.87MB/s    1.25MB/s
Windows ATTO (8KB)     11.32MB/s    2.38MB/s
Windows ATTO (16KB)    17.65MB/s    3.61MB/s
Windows ATTO (32KB)    24.24MB/s    4.06MB/s
Windows ATTO (64KB)    29.30MB/s    8.17MB/s
Windows ATTO (128KB)   29.49MB/s    7.74MB/s
Windows md5            2.38 sec     n/a
---------------------
USB4BSD dd (4KB)        6.72MB/s    1.55MB/s **
USB4BSD dd (8KB)       12.32MB/s    2.44MB/s
USB4BSD dd (16KB)      18.45MB/s    3.59MB/s
USB4BSD dd (32KB)      23.88MB/s    4.24MB/s
USB4BSD dd (64KB)      29.32MB/s    8.90MB/s **
USB4BSD dd (128KB)     29.58MB/s    9.00MB/s **
FreeBSD md5            2.51 sec     n/a

** Write speed gradually increased as transfer took place, topping
   out at the value shown; there was occasionally some variance
   in the transfer speed, so it wasn't a pure linear ramp-up.

Points of interest:

- FreeBSD and Windows have about equal read performance, but FreeBSD
  has slightly higher write performance
- Mysterious "gradually increasing speed" with some block sizes
- Jump in write performance with 64KB blocks (firmware optimisation?)
- Slower write performance on Windows with 128KB blocks (I thought I
  was going crazy, but I tested this numerous times)

To be brutally honest, I was expecting FreeBSD to perform badly during
both read and write operations -- I was delightfully surprised to see
the above.  :-)

I have a newer USB flash disk (SanDisk Cruzer Titanium 8GB) arriving
early next week, so I can try that one out for comparison.  SanDisk is
known for tinkering with r/w optimisations in their firmwares.

Cheers!

-- 
| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |