Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 08 Jun 2016 06:32:40 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-bugs@FreeBSD.org
Subject:   [Bug 209099] ata2: already running! panic: bad link elm 0xfffff80003b7e6a0 prev->next != elm
Message-ID:  <bug-209099-8-U7MjKe2MAr@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-209099-8@https.bugs.freebsd.org/bugzilla/>
References:  <bug-209099-8@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209099

daryl@ci.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daryl@ci.com.au

--- Comment #5 from daryl@ci.com.au ---
I have an Asus P8B-X motherboard with 16G memory and an Intel 530 Series
120G SSD as the boot drive. We are running FreeBSD 10.3-STABLE #3 r300822.

I believe I have this same issue. I was using salt minion to update this
machine and it hung (several times). Prior to the hang I would always see t=
he
console message:

ata2: already running!

The machine would continue to run for a short period of time and then become
unresponsive. A few minutes later I might get a panic otherwise it would ju=
st=20
be in a hung state.

I was able to pull apart the minion and found it was camcontrol causing the
issue. I create a script that looped over the command:

camcontrol identify ada0=20

and I am able to cause the system to either hang or panic regularly.
Using the kernel debugger I was able to glean this information:

spin lock 0xffffffff816f17e0 (sleepq chain) held by 0xfffff800g
panic: spin lock held too long=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20
cpuid =3D 6=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
KDB: stack backtrace:=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe046562e=
800=20=20
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe046562e8b0=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20
vpanic() at vpanic+0x126/frame 0xfffffe046562e8f0=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
panic() at panic+0x43/frame 0xfffffe046562e950=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
_mtx_lock_spin_cookie() at _mtx_lock_spin_cookie+0x287/frame 0xfffffe046562=
e9c0=20
wakeup() at wakeup+0xf/frame 0xfffffe046562e9e0=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
vnlru_proc() at vnlru_proc+0x157/frame 0xfffffe046562ea70=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
fork_exit() at fork_exit+0x9a/frame 0xfffffe046562eab0=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe046562eab0=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20
--- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 ---=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20
KDB: enter: panic=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
[ thread pid 20 tid 100078 ]=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20
Stopped at      kdb_enter+0x3e: movq    $0,kdb_why

If salt is disabled and I dont run camcontrol commands, this machine is sta=
ble.
We have several other machines with different mother boards using the same
kernel that dont have this problem.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-209099-8-U7MjKe2MAr>