Date: Thu, 15 May 2014 11:20:03 GMT From: John Baldwin <jhb@FreeBSD.org> To: freebsd-amd64@FreeBSD.org Subject: Re: amd64/189668: Using arcconf on FreeBSD 11 Current Causes Dumps Root User To DB> Prompt Message-ID: <201405151120.s4FBK3QN059003@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR amd64/189668; it has been noted by GNATS. From: John Baldwin <jhb@FreeBSD.org> To: Pete Long <pete@nrth.org>, freebsd-gnats-submit@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@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201405151120.s4FBK3QN059003>