Areca Weirdness

Lawrence Farr freebsd-smp at
Thu Nov 16 06:51:14 PST 2006

Re-posting to -STABLE as it also does it on i386.

I reinstalled i386 stable as of yesterday, and newfs'd all the partitions
"just in case". I got it to crash while doing a mkdir on the areca
partition, so set up crash dumps on the boot drive (it boots off a single
ATA disk, the Areca is additional storage) and it died again running
the periodic scripts last night. The info file from the dump shows:

Dump header from device /dev/ad0s1b
  Architecture: i386
  Architecture Version: 2
  Dump Length: 2145452032B (2046 MB)
  Blocksize: 512
  Dumptime: Thu Nov 16 03:01:09 2006
  Magic: FreeBSD Kernel Dump
  Version String: FreeBSD 6.1-20061115 #0: Wed Nov 15 04:18:11 UTC 2006
    root at
  Panic String: ufs_dirbad: bad dir
  Dump Parity: 632980830
  Bounds: 0
  Dump Status: good

Am I expecting too much with partitions over 2Tb? I've never gone over
2Tb before, so havent come across any issues like this.

> -----Original Message-----
> From: owner-freebsd-amd64 at 
> [mailto:owner-freebsd-amd64 at] On Behalf Of Lawrence Farr
> Sent: 10 November 2006 11:39
> To: freebsd-amd64 at
> Subject: Areca Weirdness 
> I've got an Areca 12 port card running a 6Tb array which is divided
> into 2.1Tb chunks at the moment, as it was doing the same with a
> single 6Tb partition.
> ad0: 58644MB <IC35L060AVER07 0 ER6OA44A> at ata0-master UDMA100
> da0 at arcmsr0 bus 0 target 0 lun 0
> da0: <Areca Arc1 R001> Fixed Direct Access SCSI-3 device
> da0: 166.666MB/s transfers (83.333MHz, offset 32, 16bit), 
> Tagged Queueing
> Enabled
> da0: 2224922MB (4556640256 512 byte sectors: 255H 63S/T 283637C)
> If I newfs it, and copy data to it, I have no problem initially.
> If I then try and copy the data on the disk already to a new
> folder, the machine reboots (it's a remote host with no serial
> attached currently). When it comes back to life, it mounts, and
> shows as:
> /dev/da0       2.1T    343G    1.6T    18%    /usr/home/areca1
> But is completely empty. Unmounting it and trying to fsck it
> errors, as does mounting it by hand.
> [root at nas-2 /home]# fsck -y /dev/da0
> ** /dev/da0
> Cannot find file system superblock
> ioctl (GCINFO): Inappropriate ioctl for device
> fsck_ufs: /dev/da0: can't read disk label
> [root at nas-2 /home]# mount /dev/da0
> mount: /dev/da0 on /usr/home/areca1: incorrect super block
> Are there any known issues with the driver on AMD64? I had
> major issues with it on Linux/386 with large memory support
> (it would behave equally strangely) that went away when I
> took large memory support out, maybe there are some non 64
> bit safe parts common to both?
> _______________________________________________
> freebsd-amd64 at mailing list
> To unsubscribe, send any mail to 
> "freebsd-amd64-unsubscribe at"

More information about the freebsd-stable mailing list