On Mon, 2012-07-23 at 12:51 -0700, John Stultz wrote: > On 07/19/2012 01:48 PM, Christoph Biedl wrote: > > John Stultz wrote... > > > >> Attached is the test case I used to reproduce and test the solution > >> to the hard-hang deadlock. > > I was wondering whether anybody managed to crash a virtualbox guest > > using your program. No avail, using version 4.1.18 on the host and the > > guest kernel running several 3.0.x (x < 38) kernels on both x32 and > > x64, the guest utilies were stopped. Rather a fun fact I guess but I > > wanted to let you know. > > I've been able to crash a kvm guest with an unpatched kernel with my > test. The issue requires that the adding of the hrtimer causes the > clockevent to be reprogrammed. This usually happens if there's no timers > that expire sooner then the leapsecond timer. So if there are drivers > that set frequent timers, or set timers right before the leapsecond, it > may be difficult to trigger this issue. > > Lowering HZ or adding more vcpus might help if you really want to be > able to trigger the issue. [...]
Your test program also made Linux 3.2.23 (or it may have been .21) lock-up for me in a KVM guest, while 3.2.24-rc1 seemed immune. Ben. -- Ben Hutchings If more than one person is responsible for a bug, no one is at fault.
signature.asc
Description: This is a digitally signed message part
