sandisk cruzer mini quirks [failure] on RELENG_4
Peter C. Lai
sirmoo at cowbert.2y.net
Thu Mar 3 01:10:07 GMT 2005
On Sat, Feb 26, 2005 at 09:02:14AM -0800, ALeine wrote:
> sirmoo at cowbert.2y.net 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
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 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