In many cases softlockup can not be reported after disabling IRQ for long time

[Russell King - ARM Linux]

On Thu, Feb 02, 2012 at 10:58:41AM -0500, Don Zickus wrote:
> The only thing I can think of is that the clock/jiffies isn't updated
> until after the hrtimer is run.  I'm not sure if there is any guarantee
> for ordering once interrupts are enabled.
> 
> But that is just a guess.
> 
> I guess in theory, I would expect that when interrupts are enabled, the
> system would immediately jump into an IRQ context, update the
> clock/jiffies, then run all the other irq handlers like hrtimers, which
> would see the new time and do the right thing.  After everything is done,
> the system would return to your test code and re-enable preemption
> allowing the softlockup thread to run again.
> 
> I could be very wrong though. :-)

The first thing to confirm is whether disabling interrupts for 10s
results in the system losing proper track of time.  If it does, then
you've immediately found the problem.

So, what you need to do us to use /usr/bin/time to execute a userspace
command which causes your thread to simulate a soft-lockup.  If you
arrange for your soft-lockup to last for (eg) exactly 10 seconds, and
/usr/bin/time reports less than 10 seconds have passed, you've found
why the system can't report it.