From: Thomas Schauss <schauss@tum.de>
To: Javier Sanz <jsanza@gmail.com>
Cc: RT <linux-rt-users@vger.kernel.org>
Subject: Re: 3.2-rc1 and nvidia drivers
Date: Wed, 16 Nov 2011 10:40:13 +0100 [thread overview]
Message-ID: <4EC384FD.1040106@tum.de> (raw)
In-Reply-To: <CAOLSsAysHCVAHsSRMTXUpXm_qjK5D5DRagHCS0ZYrxGQ8mDkfw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5761 bytes --]
Hello,
actually I have wanted to write to this list about NVIDIA-drivers for
some time and will use this opportunity.
Generally, it is obviously preferable to use the nouveau-driver if
possible which is working just fine. At our institute however, we need
to use the rt-patch in combination with the proprietary NVIDIA driver as
we need CUDA-support combined with low-latency control (e.g. for visual
servoing). And I am sure we are not the only ones requiring this
combination.
We have been using the 2.6.33-rt29 for some time now without any issues
and with very satisfactory latency. This required a small patch to the
NVIDIA-driver (there is a check for PREEMPT_RT) as atomic_spin* was
renamed to raw_spin* in one of the 2.6-rt-patches.
3.0-rt requires an additional slight modification as CONFIG_PREEMPT_RT
is not defined anymore and we must check instead for
CONFIG_PREEMPT_RT_FULL to decide whether to use raw spin_locks. Using
this patch it is then not necessary to change any EXPORT_SYMBOL_GPL to
EXPORT_SYMBOL in the kernel as was proposed in some other threads here.
You can find the patches for the nvidia-driver for 2.6.33-rt and 3.0-rt
below.
Unfortunately, with 3.0-rt and the nvidia-driver we get complete system
freezes when starting X on several different hardware setups (a few
systems work fine). This is certainly caused by this combination. When
using the nouveau-driver everything works fine.
I tested this with rt13 through rt20 and will check with the current
version tomorrow. If it still fails I will put together a list of
working vs. non-working hardware setups.
Unfortunately, apart from that I am not sure how to debug this issue, as
the complete system freezes (including the serial console) and I can't
find any suspicious messages in the logs. Any ideas?
Btw, changing EXPORT_SYMBOL_GPL to EXPORT_SYMBOL for
migrate_enable/disable, ... and then using the non-raw spinlocks results
in exactly the same behavior.
Best Regards,
Thomas Schauss
====================================================================
Patch for 3.0-rt:
--- a/nv-linux.h 2011-10-26 13:35:32.866579965 +0200
+++ b/nv-linux.h 2011-10-26 13:35:47.265117607 +0200
@@ -262,17 +262,17 @@
#endif
#endif
-#if defined(CONFIG_PREEMPT_RT)
-typedef atomic_spinlock_t nv_spinlock_t;
-#define NV_SPIN_LOCK_INIT(lock) atomic_spin_lock_init(lock)
-#define NV_SPIN_LOCK_IRQ(lock) atomic_spin_lock_irq(lock)
-#define NV_SPIN_UNLOCK_IRQ(lock) atomic_spin_unlock_irq(lock)
-#define NV_SPIN_LOCK_IRQSAVE(lock,flags)
atomic_spin_lock_irqsave(lock,flags)
+#if defined(CONFIG_PREEMPT_RT_FULL)
+typedef raw_spinlock_t nv_spinlock_t;
+#define NV_SPIN_LOCK_INIT(lock) raw_spin_lock_init(lock)
+#define NV_SPIN_LOCK_IRQ(lock) raw_spin_lock_irq(lock)
+#define NV_SPIN_UNLOCK_IRQ(lock) raw_spin_unlock_irq(lock)
+#define NV_SPIN_LOCK_IRQSAVE(lock,flags) raw_spin_lock_irqsave(lock,flags)
#define NV_SPIN_UNLOCK_IRQRESTORE(lock,flags) \
- atomic_spin_unlock_irqrestore(lock,flags)
-#define NV_SPIN_LOCK(lock) atomic_spin_lock(lock)
-#define NV_SPIN_UNLOCK(lock) atomic_spin_unlock(lock)
-#define NV_SPIN_UNLOCK_WAIT(lock) atomic_spin_unlock_wait(lock)
+ raw_spin_unlock_irqrestore(lock,flags)
+#define NV_SPIN_LOCK(lock) raw_spin_lock(lock)
+#define NV_SPIN_UNLOCK(lock) raw_spin_unlock(lock)
+#define NV_SPIN_UNLOCK_WAIT(lock) raw_spin_unlock_wait(lock)
#else
typedef spinlock_t nv_spinlock_t;
#define NV_SPIN_LOCK_INIT(lock) spin_lock_init(lock)
@@ -854,8 +854,8 @@
return ret;
}
-#if defined(CONFIG_PREEMPT_RT)
-#define NV_INIT_MUTEX(mutex) semaphore_init(mutex)
+#if defined(CONFIG_PREEMPT_RT_FULL)
+#define NV_INIT_MUTEX(mutex) sema_init(mutex,1)
#else
#if !defined(__SEMAPHORE_INITIALIZER) &&
defined(__COMPAT_SEMAPHORE_INITIALIZER)
#define __SEMAPHORE_INITIALIZER __COMPAT_SEMAPHORE_INITIALIZER
====================================================================
Patch for 2.6.33-rt:
--- a/nv-linux.h 2011-10-28 10:31:47.416915958 +0200
+++ b/nv-linux.h 2011-10-28 10:32:48.592195509 +0200
@@ -263,16 +263,16 @@
#endif
#if defined(CONFIG_PREEMPT_RT)
-typedef atomic_spinlock_t nv_spinlock_t;
-#define NV_SPIN_LOCK_INIT(lock) atomic_spin_lock_init(lock)
-#define NV_SPIN_LOCK_IRQ(lock) atomic_spin_lock_irq(lock)
-#define NV_SPIN_UNLOCK_IRQ(lock) atomic_spin_unlock_irq(lock)
-#define NV_SPIN_LOCK_IRQSAVE(lock,flags)
atomic_spin_lock_irqsave(lock,flags)
+typedef raw_spinlock_t nv_spinlock_t;
+#define NV_SPIN_LOCK_INIT(lock) raw_spin_lock_init(lock)
+#define NV_SPIN_LOCK_IRQ(lock) raw_spin_lock_irq(lock)
+#define NV_SPIN_UNLOCK_IRQ(lock) raw_spin_unlock_irq(lock)
+#define NV_SPIN_LOCK_IRQSAVE(lock,flags) raw_spin_lock_irqsave(lock,flags)
#define NV_SPIN_UNLOCK_IRQRESTORE(lock,flags) \
- atomic_spin_unlock_irqrestore(lock,flags)
-#define NV_SPIN_LOCK(lock) atomic_spin_lock(lock)
-#define NV_SPIN_UNLOCK(lock) atomic_spin_unlock(lock)
-#define NV_SPIN_UNLOCK_WAIT(lock) atomic_spin_unlock_wait(lock)
+ raw_spin_unlock_irqrestore(lock,flags)
+#define NV_SPIN_LOCK(lock) raw_spin_lock(lock)
+#define NV_SPIN_UNLOCK(lock) raw_spin_unlock(lock)
+#define NV_SPIN_UNLOCK_WAIT(lock) raw_spin_unlock_wait(lock)
#else
typedef spinlock_t nv_spinlock_t;
#define NV_SPIN_LOCK_INIT(lock) spin_lock_init(lock)
@@ -855,7 +855,7 @@
}
#if defined(CONFIG_PREEMPT_RT)
-#define NV_INIT_MUTEX(mutex) semaphore_init(mutex)
+#define NV_INIT_MUTEX(mutex) sema_init(mutex,1)
#else
#if !defined(__SEMAPHORE_INITIALIZER) &&
defined(__COMPAT_SEMAPHORE_INITIALIZER)
#define __SEMAPHORE_INITIALIZER __COMPAT_SEMAPHORE_INITIALIZER
[-- Attachment #2: schauss.vcf --]
[-- Type: text/x-vcard, Size: 342 bytes --]
begin:vcard
fn:Thomas Schauss
n:Schauss;Thomas
org:Technische Universitaet Muenchen (TUM);Institute of Automatic Control Engineering (LSR)
adr:;;Theresienstr. 90;Munich;;80333;Germany
email;internet:schauss@tum.de
title:Dipl.-Ing. (Univ.)
tel;work:+49 89 289 23406
tel;fax:+49 89 289 28340
url:http://www.lsr.ei.tum.de
version:2.1
end:vcard
next prev parent reply other threads:[~2011-11-16 9:56 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-16 9:10 3.2-rc1 and nvidia drivers Javier Sanz
2011-11-16 9:40 ` Thomas Schauss [this message]
2011-11-16 15:06 ` Thomas Gleixner
2011-11-28 10:08 ` Thomas Schauss
2011-11-28 11:31 ` John Kacur
2011-11-29 14:31 ` John Kacur
2011-11-30 2:36 ` Steven Rostedt
2011-11-30 8:23 ` John Kacur
2011-11-30 11:14 ` Peter Zijlstra
2011-11-30 14:14 ` Steven Rostedt
2011-11-30 14:16 ` Peter Zijlstra
2011-11-30 14:28 ` Steven Rostedt
2011-11-30 14:31 ` Steven Rostedt
2011-11-30 14:34 ` Peter Zijlstra
2011-11-30 15:07 ` Thomas Schauss
2011-11-30 15:20 ` Steven Rostedt
2011-12-02 17:41 ` Thomas Schauss
2011-12-02 19:37 ` Steven Rostedt
2011-11-30 13:34 ` Steven Rostedt
2011-11-30 13:39 ` John Kacur
2011-11-30 13:49 ` Steven Rostedt
2011-11-30 13:53 ` John Kacur
2011-11-30 9:06 ` Thomas Schauss
2011-11-16 9:52 ` Mike Galbraith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EC384FD.1040106@tum.de \
--to=schauss@tum.de \
--cc=jsanza@gmail.com \
--cc=linux-rt-users@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).