[ANNOUNCE] 2.6.33.9-rt31

[ANNOUNCE] 2.6.33.9-rt31

[Thomas Gleixner]

We are pleased to announce the next update to our new preempt-rt
series which is mostly a forward to 2.6.33.9. Thanks Greg !

RT specific patches since 2.6.33.7.2-rt30

8a97f01: arm: mxc: Add sched_clock to mxc-platform
a5a2b75: arm: mxc: Add add dummy_get_cycles()
c1d6834: trace: Add timestamp to maxlatproc data
cfe9ed2: trace: Add current task to maxlatproc data
70fdd17: trace: Add timeroffset to maxlatproc data
db2aacd: trace: timer offsets histogram consider smp same prio
3115eb2: x86, hotplug: Revert 74a6e0fd8 (x86, hotplug: Use mwait to ...)
250bf15: ARM: sched_clock: make minsec argument to clocks_calc_mult_shift() zero
c04f3a8: ARM: sched_clock: allow init_sched_clock() to be called early
4d79f92: ARM: sched_clock: provide common infrastructure for sched_clock()
7443ac2: asm-generic/percpu: fixup RT mismerge
7e1c4f9: rtmutex: Ensure only the top waiter or higher priority task can take the lock
47b3309: rtmutex: Fix comment about why new_owner can be NULL in wake_futex_pi()
2ce1161: rtmutex: Revert Optimize rt lock wakeup
9704792: rtmutex: Try to take lock early in rt_spin_lock_slowlock()
5995a44: rtmutex: Only save lock depth once in spin_slowlock

Download locations:
   
    http://www.kernel.org/pub/linux/kernel/projects/rt/

Git release branch:
    git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git rt/2.6.33
  
Gitweb:
    http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.git;a=shortlog;h=rt/2.6.33
  
Information on the RT patch can be found at:

    http://rt.wiki.kernel.org/index.php/Main_Page

to build the 2.6.33.9-rt31 tree, the following patches should be
applied:

    http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.33.9.tar.bz2
    http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.33.9-rt31.bz2

Enjoy !

      tglx

Re: [ANNOUNCE] 2.6.33.9-rt31

[Madovsky]

Hi Thomas,

the links below don't show any new kernels or
not found pages

Regards

Franck
----- Original Message ----- 
From: "Thomas Gleixner" <tglx@linutronix.de>
To: "LKML" <linux-kernel@vger.kernel.org>
Cc: "linux-rt-users" <linux-rt-users@vger.kernel.org>
Sent: Monday, April 11, 2011 11:35 AM
Subject: [ANNOUNCE] 2.6.33.9-rt31


> We are pleased to announce the next update to our new preempt-rt
> series which is mostly a forward to 2.6.33.9. Thanks Greg !
>
> RT specific patches since 2.6.33.7.2-rt30
>
> 8a97f01: arm: mxc: Add sched_clock to mxc-platform
> a5a2b75: arm: mxc: Add add dummy_get_cycles()
> c1d6834: trace: Add timestamp to maxlatproc data
> cfe9ed2: trace: Add current task to maxlatproc data
> 70fdd17: trace: Add timeroffset to maxlatproc data
> db2aacd: trace: timer offsets histogram consider smp same prio
> 3115eb2: x86, hotplug: Revert 74a6e0fd8 (x86, hotplug: Use mwait to ...)
> 250bf15: ARM: sched_clock: make minsec argument to 
> clocks_calc_mult_shift() zero
> c04f3a8: ARM: sched_clock: allow init_sched_clock() to be called early
> 4d79f92: ARM: sched_clock: provide common infrastructure for sched_clock()
> 7443ac2: asm-generic/percpu: fixup RT mismerge
> 7e1c4f9: rtmutex: Ensure only the top waiter or higher priority task can 
> take the lock
> 47b3309: rtmutex: Fix comment about why new_owner can be NULL in 
> wake_futex_pi()
> 2ce1161: rtmutex: Revert Optimize rt lock wakeup
> 9704792: rtmutex: Try to take lock early in rt_spin_lock_slowlock()
> 5995a44: rtmutex: Only save lock depth once in spin_slowlock
>
> Download locations:
>
>    http://www.kernel.org/pub/linux/kernel/projects/rt/
>
> Git release branch:
>    git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git 
> rt/2.6.33
>
> Gitweb:
> 
> http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.git;a=shortlog;h=rt/2.6.33
>
> Information on the RT patch can be found at:
>
>    http://rt.wiki.kernel.org/index.php/Main_Page
>
> to build the 2.6.33.9-rt31 tree, the following patches should be
> applied:
>
>    http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.33.9.tar.bz2
> 
> http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.33.9-rt31.bz2
>
> Enjoy !
>
>      tglx
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" 
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html 

Re: [ANNOUNCE] 2.6.33.9-rt31

[Thomas Gleixner]

On Mon, 11 Apr 2011, Madovsky wrote:

> Hi Thomas,
> 
> the links below don't show any new kernels or
> not found pages

Mirroring from the master machine to the public ones is taking some
time, but it's there now.

Thanks,

	tglx

Re: [ANNOUNCE] 2.6.33.9-rt31

[Oon-Ee Ng]

On Tue, Apr 12, 2011 at 12:06 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Mon, 11 Apr 2011, Madovsky wrote:
>
>> Hi Thomas,
>>
>> the links below don't show any new kernels or
>> not found pages
>
> Mirroring from the master machine to the public ones is taking some
> time, but it's there now.
>
> Thanks,
>
>        tglx

I think he was referring to this link, which is still empty for me:-

http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.33.9.tar.bz2

Will check again in a couple of hours, but was 2.6.33.8 just skipped
entirely? Cos that's not there either.

Re: [ANNOUNCE] 2.6.33.9-rt31

[Oon-Ee Ng]

On Tue, Apr 12, 2011 at 12:06 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Mon, 11 Apr 2011, Madovsky wrote:
>
>> Hi Thomas,
>>
>> the links below don't show any new kernels or
>> not found pages
>
> Mirroring from the master machine to the public ones is taking some
> time, but it's there now.
>
> Thanks,
>
>        tglx

I think he was referring to this link, which is still empty for me:-

http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.33.9.tar.bz2

Will check again in a couple of hours, but was 2.6.33.8 just skipped
entirely? Cos that's not there either.
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ANNOUNCE] 2.6.33.9-rt31

[Carsten Emde]

On 04/11/2011 06:19 PM, Oon-Ee Ng wrote:
> On Tue, Apr 12, 2011 at 12:06 AM, Thomas Gleixner<tglx@linutronix.de>  wrote:
>> On Mon, 11 Apr 2011, Madovsky wrote:
>>> the links below don't show any new kernels or
>>> not found pages
>> Mirroring from the master machine to the public ones is taking some
>> time, but it's there now.
> I think he was referring to this link, which is still empty for me:-
> http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.33.9.tar.bz2
> Will check again in a couple of hours, but was 2.6.33.8 just skipped
> entirely? Cos that's not there either.
Longterm Linux files are sitting in 
http://www.kernel.org/pub/linux/kernel/v2.6/longterm, e.g.

http://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.33/linux-2.6.33.9.tar.bz2

	-Carsten.

Re: [ANNOUNCE] 2.6.33.9-rt31

[Thomas Gleixner]

On Mon, 11 Apr 2011, Carsten Emde wrote:

> On 04/11/2011 06:19 PM, Oon-Ee Ng wrote:
> > On Tue, Apr 12, 2011 at 12:06 AM, Thomas Gleixner<tglx@linutronix.de>
> > wrote:
> > > On Mon, 11 Apr 2011, Madovsky wrote:
> > > > the links below don't show any new kernels or
> > > > not found pages
> > > Mirroring from the master machine to the public ones is taking some
> > > time, but it's there now.
> > I think he was referring to this link, which is still empty for me:-
> > http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.33.9.tar.bz2
> > Will check again in a couple of hours, but was 2.6.33.8 just skipped
> > entirely? Cos that's not there either.
> Longterm Linux files are sitting in
> http://www.kernel.org/pub/linux/kernel/v2.6/longterm, e.g.
> 
> http://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.33/linux-2.6.33.9.tar.bz2

Ooops, yes. -ENOTENOUGHCOFFEE

Re: [ANNOUNCE] 2.6.33.9-rt31

[Madovsky]

----- Original Message ----- 
From: "Thomas Gleixner" <tglx@linutronix.de>
To: "Carsten Emde" <C.Emde@osadl.org>
Cc: "Oon-Ee Ng" <ngoonee.talk@gmail.com>; "Madovsky" <infos@madovsky.org>; 
"LKML" <linux-kernel@vger.kernel.org>; "linux-rt-users" 
<linux-rt-users@vger.kernel.org>
Sent: Monday, April 11, 2011 12:46 PM
Subject: Re: [ANNOUNCE] 2.6.33.9-rt31


> On Mon, 11 Apr 2011, Carsten Emde wrote:
>
>> On 04/11/2011 06:19 PM, Oon-Ee Ng wrote:
>> > On Tue, Apr 12, 2011 at 12:06 AM, Thomas Gleixner<tglx@linutronix.de>
>> > wrote:
>> > > On Mon, 11 Apr 2011, Madovsky wrote:
>> > > > the links below don't show any new kernels or
>> > > > not found pages
>> > > Mirroring from the master machine to the public ones is taking some
>> > > time, but it's there now.
>> > I think he was referring to this link, which is still empty for me:-
>> > http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.33.9.tar.bz2
>> > Will check again in a couple of hours, but was 2.6.33.8 just skipped
>> > entirely? Cos that's not there either.
>> Longterm Linux files are sitting in
>> http://www.kernel.org/pub/linux/kernel/v2.6/longterm, e.g.
>>
>> http://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.33/linux-2.6.33.9.tar.bz2
>
> Ooops, yes. -ENOTENOUGHCOFFEE
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" 
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

tested successfully rt-31 on Fedora10 64bits
fantastic job guys ! hope 2.6.39 will be not hassle for you ;)

Re: [ANNOUNCE] 2.6.33.9-rt31

[jordan]

Hi,

> tested successfully rt-31 on Fedora10 64bits
> fantastic job guys ! hope 2.6.39 will be not hassle for you ;)

is 2.6.39 the next new rt-kernel doing to be developed?

that would be happy times ;)

jordan

Re: [ANNOUNCE] 2.6.33.9-rt31

[Jeremy Jongepier]

On 04/13/2011 08:38 PM, jordan wrote:
> Hi,
>
>> tested successfully rt-31 on Fedora10 64bits
>> fantastic job guys ! hope 2.6.39 will be not hassle for you ;)
>
> is 2.6.39 the next new rt-kernel doing to be developed?
>
> that would be happy times ;)
>
> jordan

Afaik 2.6.37: http://www.spinics.net/lists/linux-rt-users/msg06286.html
2.6.39 will integrate another very important part of the real-time 
patchset though: 
http://lists.linuxaudio.org/pipermail/linux-audio-dev/2011-March/030782.html

Best,

Jeremy

Re: [ANNOUNCE] 2.6.33.9-rt31

[jordan]

hi jeremy,

> Afaik 2.6.37: http://www.spinics.net/lists/linux-rt-users/msg06286.html

okay, sounds good.

> 2.6.39 will integrate another very important part of the real-time patchset
> though:
> http://lists.linuxaudio.org/pipermail/linux-audio-dev/2011-March/030782.html

I should probably be on that list, as i am on LAU, and LAA.

thanks for both links. cheerz! :)

jordan

Re: [ANNOUNCE] 2.6.33.9-rt31

[Niccolò Belli]

Il 13/04/2011 20:54, Jeremy Jongepier ha scritto:
> 2.6.39 will integrate another very important part of the real-time
> patchset though:
> http://lists.linuxaudio.org/pipermail/linux-audio-dev/2011-March/030782.html

"we sould start testing it during the rc cycle, i think.
(there will not be too many people turning force threaded handler on)

i will try to write up somthing about kernel config and boot parameters
once i have a kernel running in my kvm later this week."

I didn't find the kernel config and the boot parameters to test it. Do
you know which ones should I set?

Cheers,
Darkbasic

Re: [ANNOUNCE] 2.6.33.9-rt31

[Jeremy Jongepier]

On 04/14/2011 01:38 AM, Niccolò Belli wrote:
> Il 13/04/2011 20:54, Jeremy Jongepier ha scritto:
>> 2.6.39 will integrate another very important part of the real-time
>> patchset though:
>> http://lists.linuxaudio.org/pipermail/linux-audio-dev/2011-March/030782.html
>
> "we sould start testing it during the rc cycle, i think.
> (there will not be too many people turning force threaded handler on)
>
> i will try to write up somthing about kernel config and boot parameters
> once i have a kernel running in my kvm later this week."
>
> I didn't find the kernel config and the boot parameters to test it. Do
> you know which ones should I set?
>
> Cheers,
> Darkbasic

You could check the latest -lowlatency kernel available for Ubuntu 
Natty: https://launchpad.net/~abogani/+archive/snmp++/+packages
It contains a config that has force threaded handler enabled.

Best,

Jeremy

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ANNOUNCE] 2.6.33.9-rt31

[jordan]

> You could check the latest -lowlatency kernel available for Ubuntu Natty:
> https://launchpad.net/~abogani/+archive/snmp++/+packages
> It contains a config that has force threaded handler enabled.
>
> Best,
>
> Jeremy

Hey Jeremy, I may take a look at that. i wont be installing 2.6.39
until i see the right kernel available in Arch (AUR).
but i am quite curious, i can't wait until all of the RT features are mainline.

>From your own experience, how well does it perform??

jordan

Re: [ANNOUNCE] 2.6.33.9-rt31

[Jeremy Jongepier]

On 04/14/2011 09:26 AM, jordan wrote:
> From your own experience, how well does it perform??

Hello Jordan,

To be honest, I don't have the faintest clue. Just passing the message.

Best,

Jeremy

Re: [ANNOUNCE] 2.6.33.9-rt31

[Madovsky]

hi,

----- Original Message ----- 
From: "jordan" <triplesquarednine@gmail.com>
To: <jeremy@autostatic.com>
Cc: "Jeremy Jongepier" <autostatic@gmail.com>; 
<linux-rt-users@vger.kernel.org>
Sent: Thursday, April 14, 2011 3:26 AM
Subject: Re: [ANNOUNCE] 2.6.33.9-rt31


>> You could check the latest -lowlatency kernel available for Ubuntu Natty:
>> https://launchpad.net/~abogani/+archive/snmp++/+packages
>> It contains a config that has force threaded handler enabled.
>>
>> Best,
>>
>> Jeremy
>
> Hey Jeremy, I may take a look at that. i wont be installing 2.6.39
> until i see the right kernel available in Arch (AUR).
> but i am quite curious, i can't wait until all of the RT features are 
> mainline.
>
>>From your own experience, how well does it perform??
>
> jordan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" 
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

is anybody has the config of this lowlatency kernel ?
I'd like to compile it on my old Fedora 10 64bits

Thanks 

Re: [ANNOUNCE] 2.6.33.9-rt31

[jordan]

Hey Madovsky,

> is anybody has the config of this lowlatency kernel ?
> I'd like to compile it on my old Fedora 10 64bits

I believe Jeremy has already answered this question..? this link;

>>> You could check the latest -lowlatency kernel available for Ubuntu Natty:

>>> https://launchpad.net/~abogani/+archive/snmp++/+packages   <---

>>> It contains a config that has force threaded handler enabled.

i'm downloading the sources right now to have a look. as for
configuring it for Fedora 10, it shouldn't be very difficult
assuming it can build it okay...?

jordan

Re: [ANNOUNCE] 2.6.33.9-rt31

[Tracey Hytry]

Using Fernando's latest build for fedora14,  this one seems to work quite well.

I threw a lot at it while testing the audio, it's a very good low latency kernel.

The only problem is after waking up after a suspend to ram, the sound is hosed.
But that's not something new here because I'm using a m-audio audiophile 24/96,
and this happens on any kernel.

Tracey.

Re: [ANNOUNCE] 2.6.33.9-rt31

[Niccolò Belli]

Il 13/04/2011 20:54, Jeremy Jongepier ha scritto:
> 2.6.39 will integrate another very important part of the real-time
> patchset though:
> http://lists.linuxaudio.org/pipermail/linux-audio-dev/2011-March/030782.html

If I enable it with the "threadirqs" boot parameter, it hangs few
seconds after starting jack (using a Focusrite Saffire PRO 40) and I
have to hard reboot.
Where should I report the bug?

Darkbasic

Re: [ANNOUNCE] 2.6.33.9-rt31

[dashesy]

> On Mon, 11 Apr 2011, Madovsky wrote:
>
>> Hi Thomas,
>>
>> the links below don't show any new kernels or
>> not found pages
>
> Mirroring from the master machine to the public ones is taking some
> time, but it's there now.
>
> Thanks,
>
>        tglx
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Thanks, works great on 64-bit Ubuntu (Selected SMP and Core i7 and
minimal ACPI), the only problem I have is with two displays and
nouveau driver.
My first experience with -rt was very enjoyable, now time to do some
heavy tests on it before going to production.

dashesy
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ANNOUNCE] 2.6.33.9-rt31

[Jeremy Jongepier]

On 04/15/2011 05:02 PM, dashesy wrote:
> Thanks, works great on 64-bit Ubuntu (Selected SMP and Core i7 and
> minimal ACPI), the only problem I have is with two displays and
> nouveau driver.

Which is exactly the same issue I am having. This is because the nouveau 
driver is crippled since rt29.

Best,

Jeremy

Re: [ANNOUNCE] 2.6.33.9-rt31

[dashesy]

On Sat, Apr 16, 2011 at 2:35 AM, Jeremy Jongepier <jeremy@autostatic.com> wrote:
> On 04/15/2011 05:02 PM, dashesy wrote:
>>
>> Thanks, works great on 64-bit Ubuntu (Selected SMP and Core i7 and
>> minimal ACPI), the only problem I have is with two displays and
>> nouveau driver.
>
> Which is exactly the same issue I am having. This is because the nouveau
> driver is crippled since rt29.
I applied this patch and now nouveau driver works fine with two monitors:
http://forums.debian.net/viewtopic.php?f=6&t=59599#p348758
>
> Best,
>
> Jeremy
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ANNOUNCE] 2.6.33.9-rt31

[Mark Knecht]

On Mon, Apr 11, 2011 at 8:35 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> We are pleased to announce the next update to our new preempt-rt
> series which is mostly a forward to 2.6.33.9. Thanks Greg !
>
> RT specific patches since 2.6.33.7.2-rt30

As always, thanks for the work you all do on this kernel.

I have a machine that requires drivers circa 2.6.37 or later, which
happened to be what was announced as the next future preempt-rt
kernel. At this point I'm using a standard 2.6.38 kernel and getting
pretty good results, and with more and more of the preempt-rt stuff
going mainline all the time, what's the roadmap for preempt-rt going
forward?

Thanks,
Mark

Re: [ANNOUNCE] 2.6.33.9-rt31

[Uwe Kleine-König]

Hello Mark,

On Mon, Apr 11, 2011 at 09:59:39AM -0700, Mark Knecht wrote:
> On Mon, Apr 11, 2011 at 8:35 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > We are pleased to announce the next update to our new preempt-rt
> > series which is mostly a forward to 2.6.33.9. Thanks Greg !
> >
> > RT specific patches since 2.6.33.7.2-rt30
> 
> As always, thanks for the work you all do on this kernel.
> 
> I have a machine that requires drivers circa 2.6.37 or later, which
> happened to be what was announced as the next future preempt-rt
> kernel. At this point I'm using a standard 2.6.38 kernel and getting
> pretty good results, and with more and more of the preempt-rt stuff
> going mainline all the time, what's the roadmap for preempt-rt going
> forward?
http://events.linuxfoundation.org/events/embedded-linux-conference/gleixner

:-)

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ANNOUNCE] 2.6.33.9-rt31

[Mark Knecht]

2011/4/11 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
> Hello Mark,
>
> On Mon, Apr 11, 2011 at 09:59:39AM -0700, Mark Knecht wrote:
>> On Mon, Apr 11, 2011 at 8:35 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
>> > We are pleased to announce the next update to our new preempt-rt
>> > series which is mostly a forward to 2.6.33.9. Thanks Greg !
>> >
>> > RT specific patches since 2.6.33.7.2-rt30
>>
>> As always, thanks for the work you all do on this kernel.
>>
>> I have a machine that requires drivers circa 2.6.37 or later, which
>> happened to be what was announced as the next future preempt-rt
>> kernel. At this point I'm using a standard 2.6.38 kernel and getting
>> pretty good results, and with more and more of the preempt-rt stuff
>> going mainline all the time, what's the roadmap for preempt-rt going
>> forward?
> http://events.linuxfoundation.org/events/embedded-linux-conference/gleixner
>
> :-)
>
> Best regards
> Uwe

How timely. (Or untimely!) ;-) I'm 50 miles away and the talk happens
in 45 minutes!

Guess I'll have to wait for the slides to be made available.

Thanks,
Mark
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ANNOUNCE] 2.6.33.9-rt31

[Jeremy Jongepier]

On 04/11/2011 05:35 PM, Thomas Gleixner wrote:
> We are pleased to announce the next update to our new preempt-rt
> series which is mostly a forward to 2.6.33.9. Thanks Greg !
> 
> RT specific patches since 2.6.33.7.2-rt30
> 
> 8a97f01: arm: mxc: Add sched_clock to mxc-platform
> a5a2b75: arm: mxc: Add add dummy_get_cycles()
> c1d6834: trace: Add timestamp to maxlatproc data
> cfe9ed2: trace: Add current task to maxlatproc data
> 70fdd17: trace: Add timeroffset to maxlatproc data
> db2aacd: trace: timer offsets histogram consider smp same prio
> 3115eb2: x86, hotplug: Revert 74a6e0fd8 (x86, hotplug: Use mwait to ...)
> 250bf15: ARM: sched_clock: make minsec argument to clocks_calc_mult_shift() zero
> c04f3a8: ARM: sched_clock: allow init_sched_clock() to be called early
> 4d79f92: ARM: sched_clock: provide common infrastructure for sched_clock()
> 7443ac2: asm-generic/percpu: fixup RT mismerge
> 7e1c4f9: rtmutex: Ensure only the top waiter or higher priority task can take the lock
> 47b3309: rtmutex: Fix comment about why new_owner can be NULL in wake_futex_pi()
> 2ce1161: rtmutex: Revert Optimize rt lock wakeup
> 9704792: rtmutex: Try to take lock early in rt_spin_lock_slowlock()
> 5995a44: rtmutex: Only save lock depth once in spin_slowlock
> 
> Download locations:
>    
>     http://www.kernel.org/pub/linux/kernel/projects/rt/
> 
> Git release branch:
>     git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git rt/2.6.33
>   
> Gitweb:
>     http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.git;a=shortlog;h=rt/2.6.33
>   
> Information on the RT patch can be found at:
> 
>     http://rt.wiki.kernel.org/index.php/Main_Page
> 
> to build the 2.6.33.9-rt31 tree, the following patches should be
> applied:
> 
>     http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.33.9.tar.bz2
>     http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.33.9-rt31.bz2
> 
> Enjoy !
> 
>       tglx

Thanks for this! Still can't use my two displays with the nouveau kernel
module though :(

Best,

Jeremy

Re: [ANNOUNCE] 2.6.33.9-rt31

[Jan Kiszka]

On 2011-04-13 13:02, Jeremy Jongepier wrote:
> On 04/11/2011 05:35 PM, Thomas Gleixner wrote:
>> We are pleased to announce the next update to our new preempt-rt
>> series which is mostly a forward to 2.6.33.9. Thanks Greg !
>>
>> RT specific patches since 2.6.33.7.2-rt30
>>
>> 8a97f01: arm: mxc: Add sched_clock to mxc-platform
>> a5a2b75: arm: mxc: Add add dummy_get_cycles()
>> c1d6834: trace: Add timestamp to maxlatproc data
>> cfe9ed2: trace: Add current task to maxlatproc data
>> 70fdd17: trace: Add timeroffset to maxlatproc data
>> db2aacd: trace: timer offsets histogram consider smp same prio
>> 3115eb2: x86, hotplug: Revert 74a6e0fd8 (x86, hotplug: Use mwait to ...)
>> 250bf15: ARM: sched_clock: make minsec argument to clocks_calc_mult_shift() zero
>> c04f3a8: ARM: sched_clock: allow init_sched_clock() to be called early
>> 4d79f92: ARM: sched_clock: provide common infrastructure for sched_clock()
>> 7443ac2: asm-generic/percpu: fixup RT mismerge
>> 7e1c4f9: rtmutex: Ensure only the top waiter or higher priority task can take the lock
>> 47b3309: rtmutex: Fix comment about why new_owner can be NULL in wake_futex_pi()
>> 2ce1161: rtmutex: Revert Optimize rt lock wakeup
>> 9704792: rtmutex: Try to take lock early in rt_spin_lock_slowlock()
>> 5995a44: rtmutex: Only save lock depth once in spin_slowlock
>>
>> Download locations:
>>    
>>     http://www.kernel.org/pub/linux/kernel/projects/rt/
>>
>> Git release branch:
>>     git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git rt/2.6.33
>>   
>> Gitweb:
>>     http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.git;a=shortlog;h=rt/2.6.33
>>   
>> Information on the RT patch can be found at:
>>
>>     http://rt.wiki.kernel.org/index.php/Main_Page
>>
>> to build the 2.6.33.9-rt31 tree, the following patches should be
>> applied:
>>
>>     http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.33.9.tar.bz2
>>     http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.33.9-rt31.bz2
>>
>> Enjoy !
>>
>>       tglx
> 
> Thanks for this! Still can't use my two displays with the nouveau kernel
> module though :(

A nouveau hacker recently explained to me that it's fairly hard to
backport their improvements to older kernels as they heavily depend on
infrastructure changes. That likely explains why you don't see many
stable fixes or a nouveau-compat package.

If you can live with the nvidia driver, I can share a patch that makes
it build&work for me (Quadro FX 880M).

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [ANNOUNCE] 2.6.33.9-rt31

[Jeremy Jongepier]

On 04/13/2011 03:39 PM, Jan Kiszka wrote:
> A nouveau hacker recently explained to me that it's fairly hard to
> backport their improvements to older kernels as they heavily depend on
> infrastructure changes. That likely explains why you don't see many
> stable fixes or a nouveau-compat package.
> 
> If you can live with the nvidia driver, I can share a patch that makes
> it build&work for me (Quadro FX 880M).
> 
> Jan

Hello Jan,

2.6.33-rt29 worked just fine for me, the trouble started with
2.6.33-rt30. Apparently it lacks nouveau code compared to rt29. Luckily
a maintainer of a multimedia distro picked this up and fixed this issue
by reintegrating the missing nouveau code from rt29 into rt30. He's
preparing a rt31 kernel so hopefully he manages to pull this off again.
Thanks for the offer though, but I prefer using the nouveau driver.

Best,

Jeremy

Re: [ANNOUNCE] 2.6.33.9-rt31

[Clark Williams]

[-- Attachment #1: Type: text/plain, Size: 644 bytes --]

On Wed, 13 Apr 2011 15:39:18 +0200
Jan Kiszka <jan.kiszka@siemens.com> wrote:

> A nouveau hacker recently explained to me that it's fairly hard to
> backport their improvements to older kernels as they heavily depend on
> infrastructure changes. That likely explains why you don't see many
> stable fixes or a nouveau-compat package.
> 
> If you can live with the nvidia driver, I can share a patch that makes
> it build&work for me (Quadro FX 880M).
> 
> Jan


I'd like to see that patch. Looking at fixing the nvidia wrapper
locking for -rt has been on my list for a while, it just hasn't bubbled
up to the top :).

Clark

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [ANNOUNCE] 2.6.33.9-rt31

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 14159 bytes --]

On 2011-04-18 17:08, Clark Williams wrote:
> On Wed, 13 Apr 2011 15:39:18 +0200
> Jan Kiszka <jan.kiszka@siemens.com> wrote:
> 
>> A nouveau hacker recently explained to me that it's fairly hard to
>> backport their improvements to older kernels as they heavily depend on
>> infrastructure changes. That likely explains why you don't see many
>> stable fixes or a nouveau-compat package.
>>
>> If you can live with the nvidia driver, I can share a patch that makes
>> it build&work for me (Quadro FX 880M).
>>
>> Jan
> 
> 
> I'd like to see that patch. Looking at fixing the nvidia wrapper
> locking for -rt has been on my list for a while, it just hasn't bubbled
> up to the top :).

Here comes the hack to make -rt work. It obviously break kernels
< 2.6.16 -- I really wonder why NVIDIA is still trying to support them.

Once you applied it and force-enabled (tainted kernel...) lockdep:
surprise, surprise! The driver has an ABBA locking bug (mmap_sem vs.
sp_lock). At least a theoretical one, not sure if something prevents
that this can bite in reality.

Also, I was not able to find a solution for that as the code paths and
callbacks the blob takes are hidden from "ordinary" people. NVIDIA
should be aware of it, but it looks they are not reading their public
bug tracker.

HTH,
Jan -- who wishes nouveau would already have the same low-power profile
       as the blob...

---
 nv-linux.h |   45 +++++++++++-------------------------
 nv.c       |   72 ++++++++++++++++++++++++++++++------------------------------
 2 files changed, 50 insertions(+), 67 deletions(-)

diff --git a/nv-linux.h b/nv-linux.h
index 38f7620..45942b9 100644
--- a/nv-linux.h
+++ b/nv-linux.h
@@ -127,11 +127,6 @@
 #endif
 
 #include <linux/spinlock.h>
-#if defined(NV_LINUX_SEMAPHORE_H_PRESENT)
-#include <linux/semaphore.h>
-#else
-#include <asm/semaphore.h>
-#endif
 #include <linux/completion.h>
 #include <linux/highmem.h>
 
@@ -242,16 +237,16 @@ extern int nv_pat_mode;
 #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)
@@ -822,19 +817,7 @@ static inline int nv_execute_on_all_cpus(void (*func)(void *info), void *info)
     return ret;
 }
 
-#if defined(CONFIG_PREEMPT_RT)
-#define NV_INIT_MUTEX(mutex) semaphore_init(mutex)
-#else
-#if !defined(__SEMAPHORE_INITIALIZER) && defined(__COMPAT_SEMAPHORE_INITIALIZER)
-#define __SEMAPHORE_INITIALIZER __COMPAT_SEMAPHORE_INITIALIZER
-#endif
-#define NV_INIT_MUTEX(mutex)                       \
-    {                                              \
-        struct semaphore __mutex =                 \
-            __SEMAPHORE_INITIALIZER(*(mutex), 1);  \
-        *(mutex) = __mutex;                        \
-    }
-#endif
+#define NV_INIT_MUTEX(mutex) mutex_init(mutex)
 
 #if defined (KERNEL_2_4)
 #  define NV_IS_SUSER()                 suser()
@@ -1351,17 +1334,17 @@ typedef struct nv_linux_state_s {
     struct timer_list rc_timer;
 
     /* lock for linux-specific data, not used by core rm */
-    struct semaphore ldata_lock;
+    struct mutex ldata_lock;
 
     /* lock for linux-specific alloc queue */
-    struct semaphore at_lock;
+    struct mutex at_lock;
 
 #if defined(NV_USER_MAP)
     /* list of user mappings */
     struct nv_usermap_s *usermap_list;
 
     /* lock for VMware-specific mapping list */
-    struct semaphore mt_lock;
+    struct mutex mt_lock;
 #endif /* defined(NV_USER_MAP) */
 
 #if defined(NV_PM_SUPPORT_OLD_STYLE_APM)
@@ -1417,7 +1400,7 @@ typedef struct nvidia_event
 typedef struct
 {
     nv_stack_t *sp;
-    struct semaphore sp_lock;
+    struct mutex sp_lock;
     void *nvptr;
     nvidia_event_t *event_head;
     nvidia_event_t *event_tail;
diff --git a/nv.c b/nv.c
index d3d2097..a0c8cfb 100644
--- a/nv.c
+++ b/nv.c
@@ -876,10 +876,10 @@ static int nvl_add_alloc(
     nv_alloc_t *at
 )
 {
-    down(&nvl->at_lock);
+    mutex_lock(&nvl->at_lock);
     at->next = nvl->alloc_queue;
     nvl->alloc_queue = at;
-    up(&nvl->at_lock);
+    mutex_unlock(&nvl->at_lock);
     return 0;
 }
 
@@ -2144,7 +2144,7 @@ int nv_kern_open(
     nv = NV_STATE_PTR(nvl);
 
     nv_printf(NV_DBG_INFO, "NVRM: nv_kern_open on device %d\n", devnum);
-    down(&nvl->ldata_lock);
+    mutex_lock(&nvl->ldata_lock);
 
     NV_CHECK_PCI_CONFIG_SPACE(sp, nv, TRUE, TRUE, NV_MAY_SLEEP());
 
@@ -2315,7 +2315,7 @@ done:
     NV_ATOMIC_INC(nvl->usage_count);
 
 failed:
-    up(&nvl->ldata_lock);
+    mutex_unlock(&nvl->ldata_lock);
 
     if (rc != 0)
     {
@@ -2377,7 +2377,7 @@ int nv_kern_close(
 
     NV_RELEASE_USERMAP_LIST(nv,nvfp);
 
-    down(&nvl->at_lock);
+    mutex_lock(&nvl->at_lock);
     if (nvl->alloc_queue != NULL)
     {
         nv_alloc_t *at = nvl->alloc_queue, *next;
@@ -2388,7 +2388,7 @@ int nv_kern_close(
             if ((NV_ATOMIC_READ(at->usage_count) == 0) && (at->file == NV_FILE_REFERENCE(file)))
             {
                 NV_ATOMIC_INC(at->usage_count);
-                up(&nvl->at_lock);
+                mutex_unlock(&nvl->at_lock);
                 if (at->pid == os_get_current_process())
                     NV_PRINT_AT(NV_DBG_MEMINFO, at);
                 nv_free_pages(nv, at->num_pages,
@@ -2396,15 +2396,15 @@ int nv_kern_close(
                               NV_ALLOC_MAPPING_CONTIG(at->flags),
                               NV_ALLOC_MAPPING(at->flags),
                               (void *)at);
-                down(&nvl->at_lock);
+                mutex_lock(&nvl->at_lock);
                 next = nvl->alloc_queue; /* start over */
             }
             at = next;
         }
     }
-    up(&nvl->at_lock);
+    mutex_unlock(&nvl->at_lock);
 
-    down(&nvl->ldata_lock);
+    mutex_lock(&nvl->ldata_lock);
     if (NV_ATOMIC_DEC_AND_TEST(nvl->usage_count))
     {
         if (NV_IS_GVI_DEVICE(nv))
@@ -2461,7 +2461,7 @@ int nv_kern_close(
         /* leave INIT flag alone so we don't reinit every time */
         nv->flags &= ~NV_FLAG_OPEN;
     }
-    up(&nvl->ldata_lock);
+    mutex_unlock(&nvl->ldata_lock);
 
     if (NV_GET_FILE_PRIVATE(file) != NULL)
     {
@@ -2580,7 +2580,7 @@ int nv_kern_mmap(
 
     NV_PRINT_VMA(NV_DBG_MEMINFO, vma);
 
-    down(&nvfp->sp_lock);
+    mutex_lock(&nvfp->sp_lock);
     sp = nvfp->sp;
 
     NV_CHECK_PCI_CONFIG_SPACE(sp, nv, TRUE, TRUE, NV_MAY_SLEEP());
@@ -2676,7 +2676,7 @@ int nv_kern_mmap(
     {
         unsigned int i;
 
-        down(&nvl->at_lock);
+        mutex_lock(&nvl->at_lock);
         at = nvl_find_alloc(nvl, NV_VMA_OFFSET(vma), NV_ALLOC_TYPE_AGP);
 
         if (at == NULL)
@@ -2688,7 +2688,7 @@ int nv_kern_mmap(
                     "NVRM: nv_kern_mmap: invalid offset: 0x%08x @ 0x%016llx (AGP)\n",
                     NV_VMA_SIZE(vma), NV_VMA_OFFSET(vma));
             }
-            up(&nvl->at_lock);
+            mutex_unlock(&nvl->at_lock);
             status = -EINVAL;
             goto done;
         }
@@ -2697,14 +2697,14 @@ int nv_kern_mmap(
                               NV_MEMORY_WRITECOMBINED,
                               NV_MEMORY_TYPE_AGP))
         {
-            up(&nvl->at_lock);
+            mutex_unlock(&nvl->at_lock);
             status = -ENXIO;
             goto done;
         }
 
         NV_VMA_PRIVATE(vma) = at;
         NV_ATOMIC_INC(at->usage_count);
-        up(&nvl->at_lock);
+        mutex_unlock(&nvl->at_lock);
 
         if (NV_IO_REMAP_PAGE_RANGE(vma->vm_start, NV_VMA_OFFSET(vma),
                     NV_VMA_SIZE(vma), vma->vm_page_prot))
@@ -2730,13 +2730,13 @@ int nv_kern_mmap(
         unsigned long start = 0;
         unsigned int i, j;
 
-        down(&nvl->at_lock);
+        mutex_lock(&nvl->at_lock);
         at = nvl_find_alloc(nvl, NV_VMA_OFFSET(vma), NV_ALLOC_TYPE_PCI);
 
         if (at == NULL)
         {
             static int count = 0;
-            up(&nvl->at_lock);
+            mutex_unlock(&nvl->at_lock);
             if (count++ < NV_MAX_RECURRING_WARNING_MESSAGES)
             {
                 nv_printf(NV_DBG_ERRORS,
@@ -2756,7 +2756,7 @@ int nv_kern_mmap(
 
         if (i == at->num_pages) /* sanity check */
         {
-            up(&nvl->at_lock);
+            mutex_unlock(&nvl->at_lock);
             status = -EINVAL;
             goto done;
         }
@@ -2765,7 +2765,7 @@ int nv_kern_mmap(
         {
             nv_printf(NV_DBG_ERRORS,
                 "NVRM: requested mapping exceeds allocation's boundary!\n");
-            up(&nvl->at_lock);
+            mutex_unlock(&nvl->at_lock);
             status = -EINVAL;
             goto done;
         }
@@ -2774,14 +2774,14 @@ int nv_kern_mmap(
                               NV_ALLOC_MAPPING(at->flags),
                               NV_MEMORY_TYPE_SYSTEM))
         {
-            up(&nvl->at_lock);
+            mutex_unlock(&nvl->at_lock);
             status = -ENXIO;
             goto done;
         }
 
         NV_VMA_PRIVATE(vma) = at;
         NV_ATOMIC_INC(at->usage_count);
-        up(&nvl->at_lock);
+        mutex_unlock(&nvl->at_lock);
 
         nv_printf(NV_DBG_INFO,
             "NVRM: remapping %d system pages, index %d, for 'at' 0x%p\n", pages, i, at);
@@ -2825,7 +2825,7 @@ int nv_kern_mmap(
     NV_VMA_FILE(vma) = NV_FILE_REFERENCE(file);
 
 done:
-    up(&nvfp->sp_lock);
+    mutex_unlock(&nvfp->sp_lock);
     return status;
 }
 #endif /* NV_USER_MAP */
@@ -2904,7 +2904,7 @@ int nv_kern_ioctl(
     nv_printf(NV_DBG_INFO, "NVRM: ioctl(0x%x, 0x%x, 0x%x)\n",
         _IOC_NR(cmd), (unsigned int) i_arg, _IOC_SIZE(cmd));
 
-    down(&nvfp->sp_lock);
+    mutex_lock(&nvfp->sp_lock);
     sp = nvfp->sp;
 
     NV_CHECK_PCI_CONFIG_SPACE(sp, nv, TRUE, TRUE, NV_MAY_SLEEP());
@@ -3050,7 +3050,7 @@ int nv_kern_ioctl(
     }
 
 done:
-    up(&nvfp->sp_lock);
+    mutex_unlock(&nvfp->sp_lock);
     if (arg_copy != NULL)
     {
         if (copy_to_user(arg_ptr, arg_copy, arg_size))
@@ -3226,7 +3226,7 @@ int nv_kern_ctl_open(
 
     nv_printf(NV_DBG_INFO, "NVRM: nv_kern_ctl_open\n");
 
-    down(&nvl->ldata_lock);
+    mutex_lock(&nvl->ldata_lock);
 
     /* save the nv away in file->private_data */
     nvfp->nvptr = nvl;
@@ -3246,7 +3246,7 @@ int nv_kern_ctl_open(
     }
 
     NV_ATOMIC_INC(nvl->usage_count);
-    up(&nvl->ldata_lock);
+    mutex_unlock(&nvl->ldata_lock);
 
     return 0;
 }
@@ -3268,7 +3268,7 @@ int nv_kern_ctl_close(
 
     nv_printf(NV_DBG_INFO, "NVRM: nv_kern_ctl_close\n");
 
-    down(&nvl->ldata_lock);
+    mutex_lock(&nvl->ldata_lock);
     if (NV_ATOMIC_DEC_AND_TEST(nvl->usage_count))
     {
         nv->flags &= ~NV_FLAG_OPEN;
@@ -3280,7 +3280,7 @@ int nv_kern_ctl_close(
                 "NVRM: failed to unregister from the ACPI subsystem!\n");
         }
     }
-    up(&nvl->ldata_lock);
+    mutex_unlock(&nvl->ldata_lock);
 
     rm_free_unused_clients(sp, nv, NV_FILE_REFERENCE(file));
 
@@ -3748,7 +3748,7 @@ void* NV_API_CALL nv_alloc_kernel_mapping(
     nv_linux_state_t *nvl = NV_GET_NVL_FROM_NV_STATE(nv);
     NvU32 i, offset, page_idx=0;
 
-    down(&nvl->at_lock);
+    mutex_lock(&nvl->at_lock);
     at = nvl_find_alloc(nvl, address, NV_ALLOC_TYPE_PCI);
     if (at != NULL)
     {
@@ -3767,7 +3767,7 @@ void* NV_API_CALL nv_alloc_kernel_mapping(
 
         if (i == at->num_pages) /* not found */
         {
-            up(&nvl->at_lock);
+            mutex_unlock(&nvl->at_lock);
             return NULL;
         }
     }
@@ -3782,17 +3782,17 @@ void* NV_API_CALL nv_alloc_kernel_mapping(
 
             if (at->page_table[i]->virt_addr == 0)
             {
-                up(&nvl->at_lock);
+                mutex_unlock(&nvl->at_lock);
                 return NULL;
             }
         }
         else
         {
-            up(&nvl->at_lock);
+            mutex_unlock(&nvl->at_lock);
             return NULL; /* not found */
         }
     }
-    up(&nvl->at_lock);
+    mutex_unlock(&nvl->at_lock);
 
     if (((size + offset) <= PAGE_SIZE) && !NV_ALLOC_MAPPING_GUEST(at->flags))
     {
@@ -4121,7 +4121,7 @@ RM_STATUS NV_API_CALL nv_free_pages(
         at->key_mapping, page_count);
 
     /* only lock ldata while removing 'at' from the list */
-    down(&nvl->at_lock);
+    mutex_lock(&nvl->at_lock);
 
     NV_PRINT_AT(NV_DBG_MEMINFO, at);
 
@@ -4136,12 +4136,12 @@ RM_STATUS NV_API_CALL nv_free_pages(
      */
     if (!NV_ATOMIC_DEC_AND_TEST(at->usage_count))
     {
-        up(&nvl->at_lock);
+        mutex_unlock(&nvl->at_lock);
         return RM_OK;
     }
 
     nvl_remove_alloc(nvl, at);
-    up(&nvl->at_lock);
+    mutex_unlock(&nvl->at_lock);
 
     if (NV_ALLOC_MAPPING_GUEST(at->flags))
     {
-- 
1.7.1


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]