On Wed, Nov 22, 2017 at 10:58 PM, Ingo Molnar <mi...@kernel.org> wrote: > > * Ingo Molnar <mi...@kernel.org> wrote: > >> >> * Ingo Molnar <mi...@kernel.org> wrote: >> >> > > Anyway, I booted your config (more or less -- I munged it through >> > > virtme-configkernel --update first) with 17 vCPUs and it seems fine. >> > > Is the issue reliable enough to bisect? >> > >> > Ok, it should be bisectable, will try to bisect it. >> >> The latestest entry-stack code appears to be working fine though. >> >> So one of the below fixes from yesterday appears to have done the trick. >> >> I'll re-test today to make sure: maybe it's more sporadic than I thought, in >> one >> of the bootups I got the do_IRQ warning only once, in half a day of uptime. > > I re-tested and it all seems fine now. I suspect it got fixed by: > > ca37e57bbe0c: x86/entry/64: Add missing irqflags tracing to > native_load_gs_index() > > still it is weird, because I boot that system with latest -tip on a daily > basis, > and don't remember having seen that warning. > > Do you have any theory for why the entry stack changes would uncover this bug?
No. I also don't see why it would have anything to do with irqflag tracing. As far as I know, the unhandled IRQ warning has nothing to do with tracing or lockdep.
