amd64/189668: Using arcconf on FreeBSD 11 Current Causes Dumps Root User To DB> Prompt

[Pete Long]

>Number:         189668
>Category:       amd64
>Synopsis:       Using arcconf on FreeBSD 11 Current Causes Dumps Root User To DB> Prompt
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-amd64
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun May 11 14:50:00 UTC 2014
>Closed-Date:
>Last-Modified:
>Originator:     Pete Long
>Release:        10.0-STABLE FreeBSD
>Organization:
n/a
>Environment:
FreeBSD frak.nrth.lab 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r265678: Thu May  8 15:37:57 BST 2014     root at frak.nrth.lab:/usr/obj/usr/src/sys/RAWSEX  amd64

Previously running the kernel below with no issues:

FreeBSD frak.nrth.lab 10.0-RELEASE-p2 FreeBSD 10.0-RELEASE-p2 #0: Tue Apr 29 17:06:01 UTC 2014     root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
>Description:
Hi all,

More than likely a case of PEBKAC but here goes.

I have an HP Proliant ML110 G5 server using an Adaptec 3405 RAID controller (3 x SATA drives. Cannot afford SAS). I updated my kernel to 11.0-CURRENT using svn and also updated the ports tree in the same manner.

Everything I need to run works fine except for one program in ports; namely arcconf. 

Running '/usr/local/sbin/arcconf GETCONFIG 1' drops my root prompt to a 'DB>' prompt with some talk of a KDB backtrace.

Apologies if this isn't any help but here is the output generated right after that command (whilst running the 11.0-CURRENT kernel) in dmesg:

[Begin dmesg stdout]

May 10 23:21:41 frak kernel: KDB: stack backtrace:
May 10 23:21:41 frak kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe023334bdb0
May 10 23:21:41 frak kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe023334be60
May 10 23:21:41 frak kernel: witness_checkorder() at witness_checkorder+0xdc2/frame 0xfffffe023334bef0
May 10 23:21:41 frak kernel: __lockmgr_args() at __lockmgr_args+0x9ca/frame 0xfffffe023334c020
May 10 23:21:41 frak kernel: ffs_lock() at ffs_lock+0x84/frame 0xfffffe023334c070
May 10 23:21:41 frak kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfffffe023334c0a0
May 10 23:21:41 frak kernel: _vn_lock() at _vn_lock+0xaa/frame 0xfffffe023334c110
May 10 23:21:41 frak kernel: vget() at vget+0x67/frame 0xfffffe023334c150
May 10 23:21:41 frak kernel: vfs_hash_get() at vfs_hash_get+0xe1/frame 0xfffffe023334c1a0
May 10 23:21:41 frak kernel: ffs_vgetf() at ffs_vgetf+0x40/frame 0xfffffe023334c230
May 10 23:21:41 frak kernel: softdep_sync_buf() at softdep_sync_buf+0xafc/frame 0xfffffe023334c310
May 10 23:21:41 frak kernel: ffs_syncvnode() at ffs_syncvnode+0x286/frame 0xfffffe023334c390
May 10 23:21:41 frak kernel: ffs_truncate() at ffs_truncate+0x6ae/frame 0xfffffe023334c570
May 10 23:21:41 frak kernel: ufs_direnter() at ufs_direnter+0x81a/frame 0xfffffe023334c630
May 10 23:21:41 frak kernel: ufs_makeinode() at ufs_makeinode+0x560/frame 0xfffffe023334c7e0
May 10 23:21:41 frak kernel: VOP_CREATE_APV() at VOP_CREATE_APV+0xf1/frame 0xfffffe023334c810
May 10 23:21:41 frak kernel: vn_open_cred() at vn_open_cred+0x2eb/frame 0xfffffe023334c960
May 10 23:21:41 frak kernel: kern_openat() at kern_openat+0x26f/frame 0xfffffe023334cae0
May 10 23:21:41 frak kernel: amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe023334cbf0
May 10 23:21:41 frak kernel: Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe023334cbf0
May 10 23:21:41 frak kernel: --- syscall (5, FreeBSD ELF64, sys_open), rip = 0x800de47ca, rsp = 0x7fffffffd608, rbp = 0x7fffffffd6f0

[End dmesg stdout]

If I type 'reboot' at the prompt my server reboots fine and all is well.

Reverting back to 10.0-STABLE with a ports tree update as well solves the issue. I already know it works on 10.0-RELEASE.

I can now run '/usr/local/sbin/arcconf GETCONFIG 1' and receive the following (edited here for brevity output):

Controllers found: 1
----------------------------------------------------------------------
Controller information
----------------------------------------------------------------------
   Controller Status                        : Optimal
   Channel description                      : SAS/SATA
   Controller Model                         : Adaptec 3405
   Controller Serial Number                 : 7C2510D7488
   Physical Slot                            : 3
   Temperature                              : 48 C/ 118 F (Normal)
   Installed memory                         : 128 MB
   Copyback                                 : Disabled
   Background consistency check             : Disabled
   Automatic Failover                       : Enabled
   Stayawake period                         : Disabled
   Spinup limit internal drives             : 0
   Spinup limit external drives             : 0
   Defunct disk drive count                 : 0
   Logical devices/Failed/Degraded          : 1/0/0
   --------------------------------------------------------
   Controller Version Information

 [...]


I'm completely happy with the configuration I've got now (on 10.0-STABLE) but thought it might be beneficial to report the problem. I realise CURRENT is fairly hot.

Many thanks for a superior OS.

Regards,

Pete.

>How-To-Repeat:
Install Adaptec 3405 RAID controller on a server running FreeBSD 11.0-CURRENT amd64 and attempt to run the 'arcconf' command available in /usr/ports/sysutils/arcconf.


>Fix:
Revert to FreeBSD 10.0-STABLE or 10.0-CURRENT and re-install the 'arcconf' port.

>Release-Note:
>Audit-Trail:
>Unformatted: