Bug #1330
open
Hammer, usb disk, SYNCHRONIZE CACHE failure
Added by josepht over 15 years ago.
Updated over 10 years ago.
Description
This is for 2.2-RELEASE. I have a 2.5" drive in an external USB
enclosure with one big Hammer filesystem on it. The disk is ~75GB.
When the daily cronjob to cleanup hammer runs it fails with these
errors:
Thanks,
Joe
Apr 6 03:02:10 jupiter kernel: (da0:umass-sim0:0:0:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0
Apr 6 03:02:10 jupiter kernel: (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error
Apr 6 03:02:10 jupiter kernel: (da0:umass-sim0:0:0:0): SCSI Status: Check Condition
Apr 6 03:02:10 jupiter kernel: (da0:umass-sim0:0:0:0): ILLEGAL REQUEST asc:20,0
Apr 6 03:02:10 jupiter kernel: (da0:umass-sim0:0:0:0): Invalid command operation code
Apr 6 03:02:10 jupiter kernel: (da0:umass-sim0:0:0:0): (da0:umass-sim0:0:0:0):
SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): ILLEGAL REQUEST asc:20,0
Apr 6 03:02:10 jupiter kernel: (da0:umass-sim0:0:0:0): Invalid command operatio n code
Apr 6 03:02:10 jupiter kernel: Unretryable error
Apr 6 03:02:10 jupiter kernel: (da0:umass-sim0:0:0:0): error 22
Apr 6 03:02:10 jupiter kernel: (da0:umass-sim0:0:0:0): Unretryable Error
Apr 6 03:02:10 jupiter kernel: HAMMER: Critical error inode=-1 while flushing meta-data
Apr 6 03:02:10 jupiter kernel: HAMMER: Forcing read-only mode
Apr 6 03:02:10 jupiter kernel: HAMMER: Critical write error during flush, refusing to sync UNDO FIFO
:This is for 2.2-RELEASE. I have a 2.5" drive in an external USB
:enclosure with one big Hammer filesystem on it. The disk is ~75GB.
:When the daily cronjob to cleanup hammer runs it fails with these
:errors:
:
:Thanks,
:Joe
I'm not sure what's going on here. HAMMER does issue a synchronize cache
op but it should be ignoring the error. Maybe the recovery from the
unsupported synchronize cache op is causing a later write op to fail.
-Matt
I updated to 2.3-DEVELOPMENT and now the machine hangs at this point.
I get nothing on the serial console. No network connectivity. No
core dump either. I can give you access to the machine or provide any
information you may need.
I also tried adding a quirk to scsi_da.c for my device but still get
the hang.
I can't rule out flaky hardware at this point either.
Joe
Matthew Dillon wrote:
I think there are devices that claim to support this operation but in
reality do not support it. Or something like this. FreeBSD has a quirk file
for this. For example my Seagate USB disk always prints those synchronize
cache failure messages on FreeBSD. Look out for NO_SYNCHRONIZE_CACHE
in this file:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/usb/storage/umass.c?rev=1.9
Regards,
Michael
I tried adding the NO_SYNCHRONIZE_CACHE quirk but got the same
results.
Joe
- Description updated (diff)
- Category set to Other
- Status changed from New to Feedback
- Assignee deleted (
0)
- Target version set to 3.8
Hi Joe,
Is it possible to test this again? And maybe against the new usb stack?
Thanks,
Antonio Huete
- Category changed from Other to Unverifiable
- Target version changed from 3.8 to Unverifiable
Moving to unverifiable. We need that specific hardware to test it. Feel free to update the ticket if any relevant testing is performed on current releases.
Also available in: Atom
PDF