NitroAV FW RAID / sbp0 problems?
Andrew Edmond
edmond at aravia.com
Fri Apr 29 15:13:44 PDT 2005
All --
After 2 days of research over here, I am finally writing into the list for
help, because I can't tell what is going on here or how to fix it. I've
done as much testing, reading, updating of sources I can, so maybe someone
here knows what the !#@ is going on ;)
Bottom line is that I'm getting these messages alot, but only when the
filesystem is copying a large file (which this fs has to do a lot):
Apr 29 15:03:36 screamfs kernel: (da0:sbp0:0:0:0): Invalid command operation
code
Apr 29 15:03:37 screamfs kernel: (da0:sbp0:0:0:0): SYNCHRONIZE CACHE. CDB:
35 0 0 0 0 0 0 0 0 0
Apr 29 15:03:37 screamfs kernel: (da0:sbp0:0:0:0): ABORTED COMMAND asc:20,0
Apr 29 15:03:37 screamfs kernel: (da0:sbp0:0:0:0): Invalid command operation
code
Apr 29 15:03:37 screamfs kernel: (da0:sbp0:0:0:0): SYNCHRONIZE CACHE. CDB:
35 0 0 0 0 0 0 0 0 0
Apr 29 15:03:37 screamfs kernel: (da0:sbp0:0:0:0): ABORTED COMMAND asc:20,0
Apr 29 15:03:37 screamfs kernel: (da0:sbp0:0:0:0): Invalid command operation
code
I am using a NitroAV system (nice little external RAID firewire units), I
have both the 2 disk and 5 disk versions:
(http://www.nitroav.com/store/customer/home.php?cat=10)
I have a new firewire 800 card and am using firewire 800 cables:
Apr 29 05:16:34 screamfs kernel: fwohci0: <Texas Instruments TSB82AA2> mem
0xfbb00000-0xfbb03fff,0xfbc00000-0xfbc007ff irq 19 at dev
ice 7.0 on pci1
Apr 29 05:16:34 screamfs kernel: fwohci0: OHCI version 1.10 (ROM=1)
Apr 29 05:16:34 screamfs kernel: fwohci0: No. of Isochronous channels is 4.
Apr 29 05:16:34 screamfs kernel: fwohci0: EUI64 00:01:56:0e:00:00:2c:9e
Apr 29 05:16:34 screamfs kernel: fwohci0: invalid speed 7 (fixed to 3).
Apr 29 05:16:34 screamfs kernel: fwohci0: Phy 1394a available S800, 3 ports.
Apr 29 05:16:34 screamfs kernel: fwohci0: Link S800, max_rec 4096 bytes.
Apr 29 05:16:34 screamfs kernel: firewire0: <IEEE1394(FireWire) bus> on
fwohci0
Apr 29 05:16:34 screamfs kernel: fwe0: <Ethernet over FireWire> on firewire0
Apr 29 05:16:34 screamfs kernel: if_fwe0: Fake Ethernet address:
02:01:56:00:2c:9e
Apr 29 05:16:34 screamfs kernel: fwe0: Ethernet address: 02:01:56:00:2c:9e
Apr 29 05:16:34 screamfs kernel: fwe0: if_start running deferred for Giant
Apr 29 05:16:34 screamfs kernel: sbp0: <SBP-2/SCSI over FireWire> on
firewire0
Apr 29 05:16:34 screamfs kernel: fwohci0: Initiate bus reset
Apr 29 05:16:34 screamfs kernel: fwohci0: node_id=0xc800ffc0, gen=1,
CYCLEMASTER mode
Apr 29 05:16:34 screamfs kernel: firewire0: 1 nodes, maxhop <= 0, cable IRM
= 0 (me)
Apr 29 05:16:34 screamfs kernel: firewire0: bus manager 0 (me)
Apr 29 05:16:34 screamfs kernel: fwohci0: phy int
You can see the firmware on the remote devices are:
# camcontrol devlist
<Oxford 922G Master 0107> at scbus0 target 0 lun 0 (da0,pass0)
<Oxford 922G Master 0107> at scbus0 target 1 lun 0 (da1,pass1)
The tunefs looks good:
screamfs# tunefs -p /dev/da0s1
tunefs: ACLs: (-a) disabled
tunefs: MAC multilabel: (-l) disabled
tunefs: soft updates: (-n) disabled
tunefs: maximum blocks per file in a cylinder group: (-e) 2048
tunefs: average file size: (-f) 16384
tunefs: average number of files in a directory: (-s) 64
tunefs: minimum percentage of free space: (-m) 8%
tunefs: optimization preference: (-o) time
tunefs: volume label: (-L)
The disk is formatted UFS2, as seen here:
screamfs# dumpfs /dev/da0s1 | less
magic 19540119 (UFS2) time Fri Apr 29 14:56:58 2005
superblock location 65536 id [ 4234b75c 26acb731 ]
ncg 8306 size 781421665 blocks 756835800
bsize 16384 shift 14 mask 0xffffc000
fsize 2048 shift 11 mask 0xfffff800
frag 8 shift 3 fsbtodb 2
minfree 8% optim time symlinklen 120
maxbsize 16384 maxbpg 2048 maxcontig 8 contigsumsize 8
nbfree 80613086 ndir 8 nifree 195622848 nffree 47
bpg 11761 fpg 94088 ipg 23552
nindir 2048 inopb 64 maxfilesize 140806241583103
sbsize 2048 cgsize 16384 csaddr 3000 cssize 133120
sblkno 40 cblkno 48 iblkno 56 dblkno 3000
cgrotor 5351 fmod 0 ronly 0 clean 1
avgfpdir 64 avgfilesize 16384
flags none
fsmnt /mnt/screamfs
volname swuid 0
Lastly:
FreeBSD 5.4-STABLE #0: Fri Apr 29 14:07:36 PDT 2005
CPU: AMD Athlon(tm) XP 2600+ (2079.56-MHz 686-class CPU)
Origin = "AuthenticAMD" Id = 0x681 Stepping = 1
Features=0x383fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,
CMOV,PAT,PSE36,MMX,FXSR,SSE>
AMD Features=0xc0400000<AMIE,DSP,3DNow!>
real memory = 939327488 (895 MB)
avail memory = 909545472 (867 MB)
So.... what the !# is causing the Synch cache errors? I am getting the
kernel to panic I guess because of too many of these errors as well. Any
help is appreciated.
Andrew
<http://www.screamnetworks.com/images/bcard/andrew_edmond_bcard.gif>
More information about the freebsd-firewire
mailing list