sandisk cruzer mini quirks [failure] on RELENG_4

Peter C. Lai sirmoo at
Thu Mar 3 01:10:07 GMT 2005

On Sat, Feb 26, 2005 at 09:02:14AM -0800, ALeine wrote:
> sirmoo at wrote: 
> > I did this as the first hack. It made the problem worse. I'll try
> > patching both umass.c and scsi_da.c maybe they will have some sort of
> > synergistic effect.

Adding DA_Q_NO_SYNC_CACHE in scsi_da.c in conjunction with IGNORE_RESIDUE in 
umass.c makes the problem worse; see below.

> You said the problem occurs only when you copy files to the device using
> cp(1) and not dd(1). The main difference between how cp(1) and dd(1) copy
> files (other than cp(1) mmap(2)-ing files which are <= 8 Mb in size)
> is that cp(1) copies files in 64kb (MAXBSIZE) chunks while dd(1) copies
> files in 512 byte chunks by default. They both use read(2) and write(2),
> so I would suggest using dd with bs=64k and then applying the bisection
> method to find the largest transfer block size for writing the device
> can handle.
> Does this problem occur with cpdup (ports/sysutils/cpdup) as well?
> It currently copies files in 32kb chunks, which could easily be changed
> since the transfer block size is set in a single place. You may want to
> patch cpdup to use the maximum transfer block size the device can handle
> as a temporary workaround and then use cpdup for copying files to the
> device.

I am unable to keep the device (and system) consistently stable with bs > 512.
Any larger blocksizes, and the device will crash at least 25% of the time.
With DA_Q_NO_SYNC_CACHE in place, the device is no longer consistently stable
even with 512 byte blocksizes. cp(1) works better than without cache syncing,
but cp(1) will still take the box down often. Turning on usb debugging just 
shows that the write fails and umass is unable to clear the stall as the 
device will subsequently timeout. It is notable that the usb subsystem mallocs
and frees 8192 bytes per transaction by default. At the end of the transfer, 
it steps down to 4096 and 2048 byte allocations during the cleanup. However, 
when the device stalls on a transfer (dd bs > 512), the stall can occur in 
the middle of a file, not just at the end of the transfer.

> > maybe i should just bite the bullet and upgrade the box to 5.3.
> Let's hope you won't have to. :-) Can you verify that this problem does
> not occur on 5.x without upgrading (by using a FreeSBIE LiveCD)?

Well, RELENG_5 is now frozen, with lots of commits in the past week. 5.3 is
now technically "old", so it probably doesn't matter if I try. I will be
getting new hardware to install RELENG_5 on next week, so I can test it on 
that, and anything needing to be patched will have to go into 5.5. Someone
else said that their PNY pendrive no longer crashes their RELENG_5 box after
a recent world remake, but I am too unfamiliar with how all the subsystems 
work together to say if it is a difference in usb or cam or something entirely 
unrelated; and I am too lazy to compare code side-by-side. (I'm not even a 
real(tm) C programmer, I just play one on TV!)

Something I noted in a recent umass.c commit[1] was code that looks like it 
tells the scsi subsystem to abort all write attempts to umass if usbd reports 
the device is disconnected; this might prevent two things: 1. the usb 
subsystem currently gets stuck in a loop trying to clear the stall. 2. the 
kernel panic that now happens if you remove the pendrive at this point.


Peter C. Lai
University of Connecticut
Dept. of Molecular and Cell Biology
Yale University School of Medicine
SenseLab | Research Assistant

More information about the freebsd-hackers mailing list