NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/54503: Panic during attaching nvme(4) when # of logical CPUs >= 32 ?
The following reply was made to PR kern/54503; it has been noted by GNATS.
From: Rin Okuyama <rokuyama.rk%gmail.com@localhost>
To: =?UTF-8?B?SmFyb23DrXIgRG9sZcSNZWs=?= <jaromir.dolecek%gmail.com@localhost>
Cc: "gnats-bugs%NetBSD.org@localhost" <gnats-bugs%netbsd.org@localhost>
Subject: Re: kern/54503: Panic during attaching nvme(4) when # of logical CPUs
>= 32 ?
Date: Sat, 31 Aug 2019 18:52:18 +0900
On 2019/08/30 23:28, JaromÃr DoleÄ?ek wrote:
> Can you please try a kernel with nvme_q_complete() marked __noinline,
> to see where exactly inside that function the code panics? I've
> reviewed the code and I don't see any particular reason why it would
> fail while setting up 32nd queue.
nvme_q_complete() is not expanded inline even without __noinline.
Instruction at the fault address,
allocated pic msix4 type edge pin 31 level 6 to cpu0 slot 22 idt entry 136
nvme0: for io queue 31 interrupting at msix4 vec 31 affinity to cpu30
prevented execution of 0x0 (SMEP)
fatal page fault in supervisor mode
...
db{0}> bt
db_disasm() at netbsd:db_disasm+0xcd
db_trap() at netbsd:db_trap+0x16b
kdb_trap() at netbsd:kdb_trap+0x12a
trap() at netbsd:trap+0x49d
--- trap (number 6) ---
?() at 0
nvme_poll() at netbsd:nvme_poll+0x154
nvme_attach() at netbsd:nvme_attach+0x12d2
nvme_pci_attach() at netbsd:nvme_pci_attach+0x6fe
...
nvme_poll+0x154 is "test %eax,%eax" just after returning from
nvme_q_complete() in nvme.c:1261.
https://nxr.netbsd.org/xref/src/sys/dev/ic/nvme.c#1261
1240 static int
1241 nvme_poll(struct nvme_softc *sc, struct nvme_queue *q, struct nvme_ccb *ccb,
1242 void (*fill)(struct nvme_queue *, struct nvme_ccb *, void *), int timo_sec)
1243 {
....
1261 if (nvme_q_complete(sc, q) == 0)
0000000000004903 <nvme_poll>:
....
4a52: e8 ee c4 ff ff callq f45 <nvme_q_complete>
4a57: 85 c0 test %eax,%eax
....
I don't understand why "execution of NULL" occurs by such a
instruction. Maybe this is an incorrect alert. By using kernel
with option KUBSAN, I found
nvme0: for io queue 31 interrupting at msix4 vec 31 affinity to cpu30
prevented execution of 0x0 (SMEP)
fatal page fault in supervisor mode
...
db{0}> reboot
UBSan: Undefined Behavior in ../../../../dev/ic/nvme.c:1306:11, member access within null pointer of type 'struct nvme_poll_state'
fatal page fault in supervisor mode
trap type 6 code 0x2 rip 0xffffffff8102487c cs 0x8 rflags 0x10246 cr2 0x40 ilevel 0x3 rsp 0xffffd0b57e9b5fc0
curlwp 0xffffc02d225038c0 pid 0.4 lowest kstack 0xffffd0b57e9b22c0
kernel: page fault trap, code=0
Stopped in pid 0.4 (system) at netbsd:nvme_poll_done+0x7a: movq %rsi,40(%rbx)
This should be the real cause of panic. Then, backtrace reads,
db{0}> bt
nvme_poll_done() at netbsd:nvme_poll_done+0x7a <--- nvme.c:1306
nvme_q_complete() at netbsd:nvme_q_complete+0x259 <--- nvme.c:1374
softint_dispatch() at netbsd:softint_dispatch+0x20b
DDB lost frame for netbsd:Xsoftintr+0x4f, trying 0xffffd0b57e9b60f0
Xsoftintr() at netbsd:Xsoftintr+0x4f
--- interrupt ---
0:
db{0}>
where
https://nxr.netbsd.org/xref/src/sys/dev/ic/nvme.c#1306
1299 static void
1300 nvme_poll_done(struct nvme_queue *q, struct nvme_ccb *ccb,
1301 struct nvme_cqe *cqe)
1302 {
1303 struct nvme_poll_state *state = ccb->ccb_cookie;
....
1306 state->c = *cqe;
https://nxr.netbsd.org/xref/src/sys/dev/ic/nvme.c#1374
1327 static int
1328 nvme_q_complete(struct nvme_softc *sc, struct nvme_queue *q)
1329 {
....
1372 mutex_exit(&q->q_cq_mtx);
1373 ccb->ccb_done(q, ccb, cqe);
1374 mutex_enter(&q->q_cq_mtx);
Do you think why ccb->ccb_cookie becomes NULL? I uploaded full
dmesg and log of DDB at:
http://www.netbsd.org/~rin/nvme_panic_20190829/dmesg.20190831
Thanks,
rin
Home |
Main Index |
Thread Index |
Old Index