Project

General

Profile

Actions
Copy link

Bug #1330

open

Hammer, usb disk, SYNCHRONIZE CACHE failure

Added by josepht over 15 years ago. Updated over 10 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
Unverifiable
Target version:
Unverifiable
Start date:
Due date:
% Done:

0%

Estimated time:

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

Actions
Copy link
 #1

Updated by dillon over 15 years ago

: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
Actions
Copy link
 #2

Updated by josepht over 15 years ago

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

Actions
Copy link
 #3

Updated by mneumann over 15 years ago

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
Actions
Copy link
 #4

Updated by josepht over 15 years ago

I tried adding the NO_SYNCHRONIZE_CACHE quirk but got the same
results.

Joe

Actions
Copy link
 #5

Updated by tuxillo almost 11 years ago

  • 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

Actions
Copy link
 #6

Updated by tuxillo over 10 years ago

  • 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.

Actions
Copy link

Also available in: Atom PDF