Re: VirtualBox 4.2.4 freezes PC using RT_PREEMPT kernel

[Thomas Gleixner <tglx@linutronix.de>]

On Wed, 19 Dec 2012, Koehrer Mathias (ETAS/ESS2) wrote:
> > >
> > > I have detected the following issue:
> > > I use an x86 PC using kernel 3.2.34-rt51 and I want to run VirtualBox 4.2.4 using
> > this PC as host.
> > 
> > > However, the PC freezes completely when loading the vbox driver "vboxdrv".
> > > Using the very same kernel without the RT_PREEMPT patch shows no issues.
> > >
> > > Using an older version of VirtualBox (V4.1.22) works fine as well.
> > >
> > > I know that this might be slightly off-topic. However there might be some
> > RT_PREEMPT users that have detected the same issue and know a solution for this.
> > >
> > > I have attached my kernel .config file.
> > >
> > > Thanks for any feedback on this.
> > 
> > Try enabling lock debugging. Likely there is an incompatibility in the
> > vbox driver or even a bug, and that may reveal more details.
> > 
> > Otherwise: KVM is the better choice on Linux hosts, and it works fine
> > over -rt.
> I am about to try this out in parallel. It looks promising...
> 
> 
> In addition, I did a long debug session (using a parallel port LED adapter any many PC resets...) to identify the issue.
> Lock debugging did not work as really everything was frozen or the PC.
> However, I finally identified the critical lines of code.
> The relevant source file is the attached file "spinlock-r0drv-linux.c" of the VirtualBox OSE V4.2.4.
> The freeze happens in line 158 (spin_unlock_irqrestore()).
> 
> ----------- BEGIN CODE FRAGMENT --------------------
> RTDECL(void) RTSpinlockRelease(RTSPINLOCK Spinlock)
> {
>     PRTSPINLOCKINTERNAL pThis = (PRTSPINLOCKINTERNAL)Spinlock;
>     RT_ASSERT_PREEMPT_CPUID_SPIN_RELEASE_VARS();
>     AssertMsg(pThis && pThis->u32Magic == RTSPINLOCK_MAGIC,
>               ("pThis=%p u32Magic=%08x\n", pThis, pThis ? (int)pThis->u32Magic : 0));
>     RT_ASSERT_PREEMPT_CPUID_SPIN_RELEASE(pThis);
> 
>     if (pThis->fFlags & RTSPINLOCK_FLAGS_INTERRUPT_SAFE)
>     {
>         unsigned long fIntSaved = pThis->fIntSaved;
>         pThis->fIntSaved = 0;
>         spin_unlock_irqrestore(&pThis->Spinlock, fIntSaved);   // <--- Here is the freeze!
>     }
>     else
>         spin_unlock(&pThis->Spinlock);
> 
>     RT_ASSERT_PREEMPT_CPUID();
> }
> RT_EXPORT_SYMBOL(RTSpinlockRelease);
> ----------- END CODE FRAGMENT --------------------

Was it really necessary to expose us to the camel case inflicted
horror of the VirtualBox spinlock abstraction layer just a few days
before Christmas?

> It has something to do with the spin locks used in VirtualBox.

Why am I not surprised?

> Likely it does not consider the RT_PREEMPT use case here...

I don't think so. That's a genuine problem unrelated to RT.

> Is there a way to make the spin lock calls compatible to the RT_PREEMPT patch?

No. The API usage seems to be correct, but RT might expose an
otherwise hard to trigger live time issue, data corruption or whatever
problem.

You said:
> Lock debugging did not work as really everything was frozen or the PC.

That's an indicator that something is really wrong. Can you just run
the same crap on a non-rt kernel with CONFIG_PROVE_LOCKING enabled ?

Thanks,

	tglx