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

[John Baldwin]

The following reply was made to PR amd64/189668; it has been noted by GNATS.

From: John Baldwin <jhb at FreeBSD.org>
To: Pete Long <pete at nrth.org>, freebsd-gnats-submit at FreeBSD.org
Cc:  
Subject: Re: amd64/189668: Using arcconf on FreeBSD 11 Current Causes Dumps
 Root User To DB> Prompt
Date: Thu, 15 May 2014 07:11:21 -0400

 On 5/11/14, 10:46 AM, Pete Long wrote:
 > 
 >> 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
 
 A WITNESS warning shouldn't drop to db>.  Also, if you reboot from db>,
 usually any messages you get from DDB don't get logged.  I suspect this
 is just an unrelated LOR warning before the actual crash you are seeing.
  Can you ensure your system is configured for crashdumps and get a dump?
  It would be good to get the message just before the db> prompt (which
 is likely a panic message) as well as the stack trace of the dump from kgdb.
 
 -- 
 John Baldwin