Bug #2037

Panic Bad link elm while building packages

Added by ftigeot about 3 years ago. Updated about 3 years ago.

Status:FeedbackStart date:
Priority:NormalDue date:
Assignee:dillon% Done:

0%

Category:-
Target version:-

Description

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/

core.txt.0 (95.6 KB) ftigeot, 03/29/2011 04:35 PM

History

#1 Updated by masterblaster about 3 years ago

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\)" <> wrote:

>
> New submission from Francois Tigeot <>:
>
> 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 <>
> <http://bugs.dragonflybsd.org/issue2037>
> _____________________________________________________

#2 Updated by dillon about 3 years ago

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

#3 Updated by masterblaster about 3 years ago

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\)" <> wrote:

>
> Matthew Dillon <> 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 <>
> <http://bugs.dragonflybsd.org/issue2037>
> _____________________________________________________
>

Also available in: Atom PDF