He is stepping into native_safe_halt() when this bug occurs (processor has halted). I am starting to wonder is this is a linux bug or intel bug. I am starting to lean towards intel bug possibly. I will go and review intels documentation about what happens when a processor has been halted, is triggered with an NMI, then someone reloads the processor with the trap flag set then returns to a hlt instruction.
Wow, this fucking cool .. I can debug Linus' "I halt when idle" core function in the linux scheduler. On 12/16/15, Jeff Merkey <linux....@gmail.com> wrote: > On 12/16/15, Jeff Merkey <linux....@gmail.com> wrote: >> Setting the (trap flag | resume flag) inside of an nmi handler results >> in a hard lockup while setting the resume flag works fine. >> >> The watchdog detector fails to detect the lockup. I am currently >> examining the trap gate and interrupt gate setup on Linux and if >> anyone has any ideas it would be nice to be able to debug and step >> through the nmi handlers. I got breakpoints to work. I noticed >> kgdb/kdb just punts here and refuses to allow someone to step inside >> an nmi handler. >> >> There is no reason Linux should not allow this to work since windows >> does and every other OS out there. I have seen this across some rex64 >> sysret calls as well this lockup behavior. >> >> Anyone who is an intel expert with any clues would love some input if >> you know about this problem. >> >> Jeff >> > > More info. Linux is getting a trap and it looks like the IDT is > getting swapped when it gets it -- POW - Dead Linux. > > Damn ... Well, it will be long night and lots of builds ... > > Jeff > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
