DragonFly BSD
DragonFly bugs List (threaded) for 2011-11
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

[DragonFlyBSD - Bug #2092] Panic: Bad link elm 0x... next->prev != elm


From: Magliano Andrea via Redmine <bugtracker-admin@xxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 22 Nov 2011 15:33:36 -0800

Issue #2092 has been updated by Magliano Andrea.

Description updated

I got master (without the three patches attached, at v2.13.0.327.g739be-DEVELOPMENT) panic'd with http://bugs.dragonflybsd.org/pastes/11 (unfortunately no core). Btw, savecore device is a usb stick.
Crash point is now different because of commit 46528d338822ba0b7e4becd8f66c04e2d9698b24

A core (same crash point) of previous version v2.13.0.259.g56693-DEVELOPMENT is available at:
https://84.73.12.43/crash/core21.txz
----------------------------------------
Bug #2092: Panic: Bad link elm 0x... next->prev != elm
http://bugs.dragonflybsd.org/issues/2092

Author: Magliano Andrea
Status: New
Priority: Normal
Assignee: Matthew Dillon
Category: 
Target version: 


Hi all,

i'm running v2.11.0.397.g4b06a0-DEVELOPMENT x86_64

I got this kind of panic on a daily basis, always at night (probably
while hammer does reblocking?):

Jun 20 03:09:14 randy kernel: ahci0.1: disk_rw: unknown state 6
Jun 20 03:09:14 randy last message repeated 18 times
Jun 20 03:09:14 randy kernel: panic: Bad link elm 0xffffffe01e019e78
next->prev != elm
Jun 20 03:09:14 randy kernel: cpuid = 0
Jun 20 03:09:14 randy kernel: Trace beginning at frame 0xffffffe01de1fa00
Jun 20 03:09:14 randy kernel: panic() at panic+0x1ed
Jun 20 03:09:14 randy kernel: panic() at panic+0x1ed
Jun 20 03:09:14 randy kernel: camisr_runqueue() at camisr_runqueue+0x87
Jun 20 03:09:14 randy kernel: swi_cambio() at swi_cambio+0x169
Jun 20 03:09:14 randy kernel: ithread_handler() at ithread_handler+0x1ba
Jun 20 03:09:14 randy kernel: boot() called on cpu#0

After applying these two patches it's running stable since 4 days.

The difference is now that TAILQ_EMPTY (patch 0002) is in
camisr_runqueue() *and* is protected by a spinlock too. The last maybe
fixes the panic? Does it makes sense?

ByE!


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]