No; it seems to be tied to this specific issue, and I was seeing even before getting logs just now, whenever I'd start one of the bad kernels in recovery mode. But no, I've never seen that in any other logs, or on any other screens outside of those popping up in relation to this problem. On Thu, Dec 28, 2017 at 06:29:05PM +0100, Thomas Gleixner wrote: > On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote: > > On Thu, Dec 28, 2017 at 05:10:28PM +0100, Thomas Gleixner wrote: > > > On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote: > > > > Actually, it decided to cooperate for just long enough for me to get > > > > the dmesg out. Attached. > > > > > > > > This is from the kernel you asked about: Dou's patch + yours, i.e. the > > > > latest one in that git log I just sent, booted up with 'apic=debug'. > > > > > > Ok. As I suspected that warning does not trigger. I would have been > > > massively surprised if that happened. So Dou's patch is just a red herring > > > and just might change the timing enough to make the problem 'hide'. > > > > > > Can you try something completely different please? > > > > > > Just use plain Linus tree without any additional patches on top and disable > > > CONFIG_NO_HZ_IDLE, i.e. select CONFIG_HZ_PERIODIC. > > > > > > If that works, then reenable it and add 'nohz=off' to the kernel command > > > line. > > > > > > > No go here I'm afraid: > > > > Linus' clean 4.15-rc5 compiled with CONFIG_HZ_PERIODIC exhibits the > > familiar behaviour: lockups, sometimes instant upon trying to log in, > > sometimes logging me in and freaking out seconds later. > > Ok. So it's not the issue I had in mind. > > Back to some of the interesting bits in the logs: > > [ 36.017942] spurious APIC interrupt through vector ff on CPU#0, should never happen. > > Does that message ever show up in 4.14 or 4.9? > > Thanks, > > tglx _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel