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 |Received on Fri Nov 07 2008 - 23:11:30 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:37 UTC