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

[Magliano Andrea via Redmine <bugtracker-admin@xxxxxxxxxxxxxxxxxxxxx>]

Issue #2092 has been updated by Magliano Andrea.


Fresh (and finally usable) core: https://84.73.12.43/crash/core22.txz

At v2.13.0.357.gcdb8af with patch (just to better isolate the problem):

diff --git a/sys/dev/disk/ahci/ahci.c b/sys/dev/disk/ahci/ahci.c
index 2752c6c..d9c4733 100644
--- a/sys/dev/disk/ahci/ahci.c
+++ b/sys/dev/disk/ahci/ahci.c
@@ -3558,7 +3558,8 @@ ahci_ata_cmd_done(struct ahci_ccb *ccb)
        xa->flags &= ~(ATA_F_TIMEOUT_DESIRED | ATA_F_TIMEOUT_EXPIRED);
        ccb->ccb_port->ap_expired &= ~(1 << ccb->ccb_slot);

-       KKASSERT(xa->state != ATA_S_ONCHIP && xa->state != ATA_S_PUT);
+       KKASSERT(xa->state != ATA_S_ONCHIP);
+       KKASSERT(xa->state != ATA_S_PUT);
        ahci_unload_prdt(ccb);

        if (xa->state != ATA_S_TIMEOUT)

----------------------------------------
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