DragonFlyBSD

Hi all,

same problem 4 cores x86_64 machine (even though i386 install), 2 core dumps:

Mar 18 08:00:48 randy kernel: panic: Bad link elm 0xd8327d10 next->prev != elm
Mar 18 08:00:48 randy kernel: cpuid = 0
Mar 18 08:00:48 randy kernel: Trace beginning at frame 0xd4247d44
Mar 18 08:00:48 randy kernel: panic(ffffffff) at panic+0x164
Mar 18 08:00:48 randy kernel: panic(c0391cd8,d8327d10,d41b4d88,0,d7112e98) at panic+0x164
Mar 18 08:00:48 randy kernel: softclock_handler(c043e0e0,0,0,0,0) at softclock_handler+0xc7
Mar 18 08:00:48 randy kernel: lwkt_exit() at lwkt_exit
Mar 18 08:00:48 randy kernel: boot() called on cpu#0

Apr 1 06:13:12 randy kernel: panic: Bad link elm 0xdaf7b934 prev->next != elm
Mar 21 02:19:26 randy kernel: cpuid = 2
Mar 21 02:19:26 randy kernel: Trace beginning at frame 0xd70e3af4
Mar 21 02:19:26 randy kernel: panic(ffffffff,2,c0418ab8,d70e3b2c,c04e19a0) at panic+0x1a2
Mar 21 02:19:26 randy kernel: panic(c0418ab8,dad605f4,83150f57,e420,c04c6548) at panic+0x1a2
Mar 21 02:19:26 randy kernel: callout_stop(dad605f4,0,ff812000,dad60458,dad605f4) at callout_stop+0x162
Mar 21 02:19:26 randy kernel: callout_reset(dad605f4,afc80,c0258a87,dad60458,dad60458) at callout_reset+0x6f
Mar 21 02:19:26 randy kernel: tcp_timer_keep_activity(dad60458,10,148d,2002a8c0,ae37) at tcp_timer_keep_activity+0xc9
Mar 21 02:19:26 randy kernel: tcp_input(d70e3cc8,d70e3cc4,6,14,0) at tcp_input+0xd42
Mar 21 02:19:26 randy kernel: transport_processing_oncpu(2,e2e0,0,ff812638,ff812524) at transport_processing_oncpu+0x52
Mar 21 02:19:26 randy kernel: ip_input(ee75f600,d70e3d84,c02382ab,ee75f618,0) at ip_input+0xe9d
Mar 21 02:19:26 randy kernel: ip_input_handler(ee75f618,0,c04e19a0,ff812524,ff812000) at ip_input_handler+0x14
Mar 21 02:19:26 randy kernel: netmsg_service_loop(0,0,0,0,0) at netmsg_service_loop+0x73
Mar 21 02:19:26 randy kernel: lwkt_exit() at lwkt_exit
Mar 21 02:19:26 randy kernel: boot() called on cpu#2

On Tue, 29 Mar 2011 16:35:40 +0000
"Francois Tigeot \(via DragonFly issue tracker\)" <sinknull@leaf.dragonflybsd.org> wrote:

New submission from Francois Tigeot <ftigeot@wolfpond.org>:

This panic occured while building packages on a 4-core x86_64 machine.

Complete core dump is available here:
http://dl.zefyris.com/crash.0/

----------
files: core.txt.0
keyword: kernel, x86-64
messages: 9781
nosy: ftigeot
priority: bug
status: unread
title: Panic Bad link elm while building packages

_____________________________________________
DragonFly issue tracker <bugs@lists.dragonflybsd.org>
<http://bugs.dragonflybsd.org/issue2037>
_____________________________________________

See issue 2037, possible fix committed. It looks like there may have been a
race in tsleep() where the stack-declared callout structure could wind up not
being reset prior to tsleep() returning.

8d4468507289f84cc7f60a6520c607713f84f009

Hi Matt,

unfortunately still not ok (for me). Two panics in the last 24 hours (strangely no core dumps) on x86_64.

This issue is in my case unrelated to package building, it happended at times when i wasn't working on the machine, i.e. it was supposed to be (almost) idle.

• with v2.9.1.1706.gc368d-DEVELOPMENT

Apr 20 14:56:52 randy syslogd: kernel boot file is /boot/kernel/kernel
Apr 20 14:56:52 randy kernel: spin_lock: 0xffffffe005dab660, indefinite wait!
Apr 20 14:56:52 randy kernel: panic: Bad link elm 0xffffffe042c67878 next->prev != elm
Apr 20 14:56:52 randy kernel: cpuid = 0
Apr 20 14:56:52 randy kernel: boot() called on cpu#0
Apr 20 14:56:52 randy kernel: Uptime: 2h51m44s
....
and so on with same pattern many times; rest of output is corrupted and unreadable

and this after update to v2.11.0.4.ge92d7-DEVELOPMENT:

Apr 21 03:08:49 randy syslogd: kernel boot file is /boot/kernel/kernel
Apr 21 03:08:49 randy kernel: spin_lock: 0xffffffe005dab660, indefinite wait!
Apr 21 03:08:49 randy kernel: panic: Bad link elm 0xffffffe042c67878 next->prev != elm
Apr 21 03:08:49 randy kernel: cpuid = 0
Apr 21 03:08:49 randy kernel: boot() called on cpu#0
Apr 21 03:08:49 randy kernel: Uptime: 4h45m40s
Apr 21 03:08:49 randy kernel: spin_lock: 0xffffffe005dab660, indefinite wait!
Apr 21 03:08:49 randy kernel: panic: Bad link elm 0xffffffe042c67878 next->prev != elm
Apr 21 03:08:49 randy kernel: cpuid = 0
Apr 21 03:08:49 randy kernel: boot() called on cpu#0
Apr 21 03:08:49 randy kernel: Uptime: 4h45m40s
Apr 21 03:08:49 randy kernel: spin_lock: 0xffffffe005dab660, indefinite wait!
Apr 21 03:08:49 randy kernel: panic: Bad link elm 0xffffffe042c67878 next->prev != elm
Apr 21 03:08:49 randy kernel: cpuid = 0
Apr 21 03:08:49 randy kernel: boot() called on cpu#0
Apr 21 03:08:49 randy kernel: Uptime: 4h45m40s
Apr 21 03:08:49 randy kernel: spin_lock: 0xffffffe005dab660, indefinite wait!
Apr 21 03:08:49 randy kernel: panic: Bad link elm 0xffffffe042c67878 next->prev != elm
Apr 21 03:08:49 randy kernel: cpuid = 0
Apr 21 03:08:49 randy kernel: boot() called on cpu#0
Apr 21 03:08:49 randy kernel: Uptime: 4h45m40s

Thanks!

On Tue, 05 Apr 2011 18:17:23 +0000
"Matthew Dillon \(via DragonFly issue tracker\)" <sinknull@leaf.dragonflybsd.org> wrote:

Matthew Dillon <dillon@apollo.backplane.com> added the comment:

See issue 2037, possible fix committed. It looks like there may have been a
race in tsleep() where the stack-declared callout structure could wind up not
being reset prior to tsleep() returning.

8d4468507289f84cc7f60a6520c607713f84f009

----------
assignedto: -> dillon
nosy: +dillon
status: chatting -> testing

_____________________________________________
DragonFly issue tracker <bugs@lists.dragonflybsd.org>
<http://bugs.dragonflybsd.org/issue2037>
_____________________________________________