From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Rostedt Subject: Re: AW: VirtualBox 4.2.4 freezes PC using RT_PREEMPT kernel Date: Fri, 21 Dec 2012 09:55:45 -0500 Message-ID: <1356101745.5896.102.camel@gandalf.local.home> References: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit Cc: Thomas Gleixner , Jan Kiszka , "linux-rt-users@vger.kernel.org" To: "Koehrer Mathias (ETAS/ESS2)" Return-path: Received: from hrndva-omtalb.mail.rr.com ([71.74.56.122]:5796 "EHLO hrndva-omtalb.mail.rr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751238Ab2LUOzr (ORCPT ); Fri, 21 Dec 2012 09:55:47 -0500 In-Reply-To: Sender: linux-rt-users-owner@vger.kernel.org List-ID: On Fri, 2012-12-21 at 08:23 +0000, Koehrer Mathias (ETAS/ESS2) wrote: > > 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 ? > > I did. It shows actually an error. > Here is the relevant dmesg output: > > --------------- BEGIN dmesg output ----------------- > vboxdrv: Found 4 processor cores. > vboxdrv: fAsync=0 offMin=0x50c offMax=0x5940 > > ================================= > [ INFO: inconsistent lock state ] > 3.2.34-2 #1 > --------------------------------- > inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. > swapper/1/0 [HC1[1]:SC0[0]:HE0:SE1] takes: > (&(&pThis->Spinlock)->rlock){?.+...}, at: [] VBoxHost_RTSpinlockAcquire+0x15/0x24 [vboxdrv] > {HARDIRQ-ON-W} state was registered at: > [] __lock_acquire+0x509/0x1337 > [] lock_acquire+0x42/0x59 > [] _raw_spin_lock+0x25/0x34 > [] VBoxHost_RTSpinlockAcquire+0x1f/0x24 [vboxdrv] > [] VBoxHost_RTMpNotificationRegister+0x36/0x11a [vboxdrv] > [] supdrvInitDevExt+0x4f4/0x65c [vboxdrv] > [] VBoxDrvLinuxInit+0x53/0xcd [vboxdrv] > [] do_one_initcall+0x6b/0x10c > [] sys_init_module+0x122f/0x13fa > [] sysenter_do_call+0x12/0x36 > irq event stamp: 278096 > hardirqs last enabled at (278093): [] mwait_idle+0x57/0x7c > hardirqs last disabled at (278094): [] call_function_interrupt+0x28/0x34 > softirqs last enabled at (278096): [] _local_bh_enable+0xd/0xf > softirqs last disabled at (278095): [] irq_enter+0x29/0x4e > > other info that might help us debug this: > Possible unsafe locking scenario: > > CPU0 > ---- > lock(&(&pThis->Spinlock)->rlock); > > lock(&(&pThis->Spinlock)->rlock); > > *** DEADLOCK *** So this is an obvious bug in virtualbox. No need to send us a config. This bug has nothing to do with RT. It's just that RT can expose bugs in mainline (or anything added to mainline) much easier. Funny thing is, this deadlock isn't even possible in RT, so there's probably many more bugs in the virtualbox driver. -- Steve > > no locks held by swapper/1/0. > > stack backtrace: > Pid: 0, comm: swapper/1 Tainted: G O 3.2.34-2 #1 > Call Trace: > [] print_usage_bug.part.27+0x1f0/0x1fa > [] mark_lock+0x334/0x4b2 > [] ? check_usage_backwards+0xce/0xce > [] __lock_acquire+0x49c/0x1337 > [] lock_acquire+0x42/0x59 > [] ? VBoxHost_RTSpinlockAcquire+0x15/0x24 [vboxdrv] > [] _raw_spin_lock_irqsave+0x2e/0x3e > [] ? VBoxHost_RTSpinlockAcquire+0x15/0x24 [vboxdrv] > [] VBoxHost_RTSpinlockAcquire+0x15/0x24 [vboxdrv] > [] ? supdrvGipMpEventOnline+0x14d/0x14d [vboxdrv] > [] supdrvGipMpEventOnline+0x5b/0x14d [vboxdrv] > [] ? supdrvGipMpEventOnline+0x14d/0x14d [vboxdrv] > [] supdrvGipInitOnCpu+0xe/0x10 [vboxdrv] > [] rtmpLinuxWrapper+0x22/0x2d [vboxdrv] > [] ? VBoxHost_RTMpCpuId+0xa/0xa [vboxdrv] > [] generic_smp_call_function_interrupt+0x6b/0x112 > [] smp_call_function_interrupt+0x20/0x2e > [] call_function_interrupt+0x2f/0x34 > [] ? __run_hrtimer.isra.28+0x33/0x9e > [] ? mwait_idle+0x5f/0x7c > [] cpu_idle+0x4d/0x76 > [] start_secondary+0x1ab/0x1b2 > vboxdrv: TSC mode is 'synchronous', kernel timer mode is 'normal'. > vboxdrv: Successfully loaded version 4.2.4 (interface 0x001a0004). > vboxpci: pci-stub module not available, cannot detach PCI devices > vboxpci: IOMMU not found (not compiled) > --------------- END dmesg output ----------------- > > I attached the kernel configuration used for this test. > > Thanks for the support. > > Regards and merry Christmas. > > Mathias >