[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: =?UTF-8?B?SmFyb23DrXIgRG9sZcSNZWs=?= <jaromir.dolecek%gmail.com@localhost>
To: Rin Okuyama <rokuyama.rk%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: Fri, 30 Aug 2019 16:28:31 +0200
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.
Can you also send output of 'nvmectl identify nvme0' when booted
successfully i.e. with HT disabled.
Le ven. 30 ao=C3=BBt 2019 =C3=A0 12:36, Rin Okuyama <rokuyama.rk%gmail.com@localhost>=
a =C3=A9crit :
> On 2019/08/30 0:12, Jarom=C3=ADr Dole=C4=8Dek wrote:
> > Le jeu. 29 ao=C3=BBt 2019 =C3=A0 13:00, <coypu%sdf.org@localhost> a =C3=A9crit :
> >> on irc jared points out
> >> arch/x86/include/intrdefs.h
> >> 50:#define MAX_INTR_SOURCES 32
> > I think this is only per CPU limit.
> I think so too. Actually, ixg(4) uses MSI-X interrupts with 49 vectors
> when hyper threading is enabled:
> Considering with wiz@'s workaround, I guess that something may go wrong
> when MSI-X interrupts are established in the nvme(4) code.
Main Index |
Thread Index |