NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/56479: Crash in ata_recovery_resume
The following reply was made to PR kern/56479; it has been noted by GNATS.
From: Andreas Gustafsson <gson%gson.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: jdolecek%NetBSD.org@localhost
Subject: Re: kern/56479: Crash in ata_recovery_resume
Date: Wed, 2 Feb 2022 18:38:15 +0200
The crash has now recurred several more times, most recently using a
kernel with debug symbols (still 9.2 GENERIC). Here's the backtrace:
(gdb) bt
#0 0xffffffff80222aaa in cpu_reboot (howto=howto@entry=260, bootstr=bootstr@entry=0x0) at /usr/src/sys/arch/amd64/amd64/machdep.c:728
#1 0xffffffff80994a96 in vpanic (fmt=fmt@entry=0xffffffff81111558 "trap", ap=ap@entry=0xffffc1849432bcc8) at /usr/src/sys/kern/subr_prf.c:336
#2 0xffffffff80994b47 in panic (fmt=fmt@entry=0xffffffff81111558 "trap") at /usr/src/sys/kern/subr_prf.c:255
#3 0xffffffff80224aed in trap (frame=0xffffc1849432be10) at /usr/src/sys/arch/amd64/amd64/trap.c:334
#4 0xffffffff8021d56b in alltraps ()
#5 0xffffffff8027bd27 in ata_recovery_resume (chp=0xffffc18083169a20, drive=0, tfd=21569, flags=<optimized out>) at /usr/src/sys/dev/ata/ata_recovery.c:239
#6 0xffffffff80279912 in ata_thread_run (chp=0xffffc18083169a20, flags=8, type=32768, arg=<optimized out>) at /usr/src/sys/dev/ata/ata.c:1639
#7 0xffffffff8027a236 in atabus_thread (arg=0xffff815ebfc49510) at /usr/src/sys/dev/ata/ata.c:506
#8 0xffffffff80209747 in lwp_trampoline ()
#9 0x0000000000000000 in ?? ()
(gdb) frame 5
#5 0xffffffff8027bd27 in ata_recovery_resume (chp=0xffffc18083169a20, drive=0, tfd=21569, flags=<optimized out>) at /usr/src/sys/dev/ata/ata_recovery.c:239
239 xfer = ata_queue_hwslot_to_xfer(chp, slot);
(gdb) l
234 /* Requeue all unfinished commands for same drive as failed command */
235 for (slot = 0; slot < ch_openings; slot++) {
236 if ((ata_queue_active(chp) & (1U << slot)) == 0)
237 continue;
238
239 xfer = ata_queue_hwslot_to_xfer(chp, slot);
240 if (drive != xfer->c_drive)
241 continue;
242
243 xfer->ops->c_kill_xfer(chp, xfer,
It appears that ata_queue_hwslot_to_xfer() is returning NULL because
chp->ch_queue->active_xfers is empty:
(gdb) print chp->ch_queue->active_xfers
$11 = {tqh_first = 0x0, tqh_last = 0xffff815ec696fbd8}
This looks like a duplicate of PR kern/54790, which IMO should not have
been closed without pulling up the fix to the -9 branch first.
--
Andreas Gustafsson, gson%gson.org@localhost
Home |
Main Index |
Thread Index |
Old Index