WAS: linux-rt fails to boot on > 3.12.5.-rt7 ... NOW IS: linux-rt-3.14 boots by reverting patches + nvidia uses __rt_mutex_init [which in 3.14 has been changed to EXPORT_SYMBOL_GPL]

WAS: linux-rt fails to boot on > 3.12.5.-rt7 ... NOW IS: linux-rt-3.14 boots by reverting patches + nvidia uses __rt_mutex_init [which in 3.14 has been changed to EXPORT_SYMBOL_GPL]

[jordan]

Hey list.

1. So after finally having some time off of work [after a busy couple
of months] i have come back to trying to sort out linux-rt on my AMD
PHenom II 965 system - which had failed to boot post 3.12.5-rt7

first, i need to make a correction -rt8 DID boot fine and was stable
[after one/initial lockup, it never locked again, and obviously booted
fine.]. but i figured this out, only after doing a git-bisect on -rt7
to -rt8 ... and never got around to testing -rt8 to -rt9... However, I
decided to give 3.14-rt a run - and again - ended up with the machine
failing to boot... Next, i decided to revert all three of the patches
that you pointed out Sebastion;

| timers-do-not-raise-softirq-unconditionally.patch
| timer-Raise-softirq-if-there-s-irq_work.patch
| timer-rt-Always-raise-the-softirq-if-there-s-irq_wor.patch

well, what i actually ended up doing was reverting the first and
modifying the 1st patch to revert the other two patches (by changing
../kernel/timer.c section of the original patch). [ i reverted after
applying the linux-rt patch, not split queue];
http://pastebin.com/zwsZg9ZM

[ninez@localhost ~]$ uname -a
Linux localhost 3.14.0-rt1-1-l-pa #1 SMP PREEMPT RT Sun Apr 13
10:44:19 EDT 2014 x86_64 GNU/Linux

I've been running 3.14-rt for a couple of hours now and it appears to
be stable, thus far - without those patches/fixes applied [and
obviously doesn't boot at all with them applied...and as you know - i
am not the only AMD user affected by the boot failures...so i am
thinking those patches really need to be looked at again, as they
cause serious regressions for some of us :\

It also presents a problem because i package linux-rt and how i am
supposed to update it, when if i revert these patches, afaict - other
H/W may not boot. [wasn't it some i7 machines that failed or
something?]... So i am not sure what to do [aside from not updating my
packages until the problem is resolved upstream].

2. Nvidia [and possibly/most likely other out-of-tree drivers] make
use or __rt_mutex_init - which apparently has been changed from
EXPORT_SYMBOL to EXPORT_SYMBOL_GPL in 3.14 [or 3.13?] (and obviously
in 3.12 it was EXPORT_SYMBOL). I had to end up switching nvidia's
license to GPL in order to be able to use the driver/modules. I'm not
sure what is supposed to happen here, but nvidia should be usable
without having to change it's license [since i never had to before,
aside from similar situations where symbols where changed to gpl, only
to be reverted back, as has happened before].

anyway, I am less concerned about the nvidia issue [im just pointing
it out] and am obviously more concerned about being able to sort out
the boot failure issues, as afaict - they are caused by changes in
-rt9, not upstream.

cheerz

Jordan

Re: WAS: linux-rt fails to boot on > 3.12.5.-rt7 ... NOW IS: linux-rt-3.14 boots by reverting patches + nvidia uses __rt_mutex_init [which in 3.14 has been changed to EXPORT_SYMBOL_GPL]

[jordan]

Just an update on this;

> [ninez@localhost ~]$ uname -a
> Linux localhost 3.14.0-rt1-1-l-pa #1 SMP PREEMPT RT Sun Apr 13
> 10:44:19 EDT 2014 x86_64 GNU/Linux
>
> I've been running 3.14-rt for a couple of hours now and it appears to
> be stable, thus far - without those patches/fixes applied [and
> obviously doesn't boot at all with them applied...and as you know - i
> am not the only AMD user affected by the boot failures...so i am
> thinking those patches really need to be looked at again, as they
> cause serious regressions for some of us :\

My Phenom II 965 has uptime of two days, after being stress tested and
is running great [hackbench, cyclictest+100% load, etc] :)

All of my other machines [both Intel and AMD] also are running well,
without those three patches applied;

| timers-do-not-raise-softirq-unconditionally.patch
| timer-Raise-softirq-if-there-s-irq_work.patch
| timer-rt-Always-raise-the-softirq-if-there-s-irq_wor.patch

I did see a couple of "non-fatal" "NOHZ: local_softirq_pending 40"
messages [as expected, since i reverted those patches] but these are
harmless, when compared to my machines not being bootable with those
applied... I don't have the expertise to fix those patches to boot on
my AMD hardware, but i am hoping that someone who does; can take a
look at those patches again - and i am more than willing to test
subsequent revisions to see if we can get these troublesome AMD
machines to boot with them applied..

...regarding nvidia on PREEMPT_RT_FULL / EXPORT_SYMBOL_GPL for
__rt_mutex_init - i notified nvidia of the problem [although, it is an
upstream linux problem]. Interestingly, this problem has already
cropped up during 3.0 development cycle on PREEMPT_RT_FULL - where the
__rt_mutex_init was changed to gpl-only symbol - only to be changed
back to SYMBOL_EXPORT shortly thereafter.... and yes, i realize
'everybody hates nvidia' - but i have to imagine there might be an MIT
licensed out-of-tree module or two [or other gpl-compatible license]
that might rely on being able to use __rt_mutex_init and now can't...
meaning i doubt this is _just_ an nvidia problem :\

as it stands, one must either change nvidia's licenses to GPL [makeing
nvidia non-distibutable]...

or change 'kernel/locking/rtmutex.c' ~
EXPORT_SYMBOL_GPL(__rt_mutex_init) to EXPORT_SYMBOL(__rt_mutex_init)

...which obviously makes the kernel GPL-incompatible / non-distributable.

I may hit LKML on this issue too, as something needs to happen here -
but i thought i would wait and see if i got a response from someone
here, first. [being as rt-devs have a little more direct contact with
Ingo / subsystem maintainers than i do [ and i am not even subbed to
that list].

Jordan

Re: WAS: linux-rt fails to boot on > 3.12.5.-rt7 ... NOW IS: linux-rt-3.14 boots by reverting patches + nvidia uses __rt_mutex_init [which in 3.14 has been changed to EXPORT_SYMBOL_GPL]

[Paul Gortmaker]

On Tue, Apr 15, 2014 at 12:15 PM, jordan <triplesquarednine@gmail.com> wrote:
> Just an update on this;
>
>> [ninez@localhost ~]$ uname -a
>> Linux localhost 3.14.0-rt1-1-l-pa #1 SMP PREEMPT RT Sun Apr 13
>> 10:44:19 EDT 2014 x86_64 GNU/Linux
>>
>> I've been running 3.14-rt for a couple of hours now and it appears to
>> be stable, thus far - without those patches/fixes applied [and
>> obviously doesn't boot at all with them applied...and as you know - i
>> am not the only AMD user affected by the boot failures...so i am
>> thinking those patches really need to be looked at again, as they
>> cause serious regressions for some of us :\
>
> My Phenom II 965 has uptime of two days, after being stress tested and
> is running great [hackbench, cyclictest+100% load, etc] :)
>
> All of my other machines [both Intel and AMD] also are running well,
> without those three patches applied;
>
> | timers-do-not-raise-softirq-unconditionally.patch
> | timer-Raise-softirq-if-there-s-irq_work.patch
> | timer-rt-Always-raise-the-softirq-if-there-s-irq_wor.patch
>
> I did see a couple of "non-fatal" "NOHZ: local_softirq_pending 40"
> messages [as expected, since i reverted those patches] but these are
> harmless, when compared to my machines not being bootable with those
> applied... I don't have the expertise to fix those patches to boot on
> my AMD hardware, but i am hoping that someone who does; can take a

I've got some AMD kit that has just been freed up from winter
heating duty - sometime later this week I should be able to try to
reproduce what you have seen, and knowing it works w/o the above
softirq patch monkeying around should be a good lead on this.

Paul.
--

> look at those patches again - and i am more than willing to test
> subsequent revisions to see if we can get these troublesome AMD
> machines to boot with them applied..
>
> ...regarding nvidia on PREEMPT_RT_FULL / EXPORT_SYMBOL_GPL for
> __rt_mutex_init - i notified nvidia of the problem [although, it is an
> upstream linux problem]. Interestingly, this problem has already
> cropped up during 3.0 development cycle on PREEMPT_RT_FULL - where the
> __rt_mutex_init was changed to gpl-only symbol - only to be changed
> back to SYMBOL_EXPORT shortly thereafter.... and yes, i realize
> 'everybody hates nvidia' - but i have to imagine there might be an MIT
> licensed out-of-tree module or two [or other gpl-compatible license]
> that might rely on being able to use __rt_mutex_init and now can't...
> meaning i doubt this is _just_ an nvidia problem :\
>
> as it stands, one must either change nvidia's licenses to GPL [makeing
> nvidia non-distibutable]...
>
> or change 'kernel/locking/rtmutex.c' ~
> EXPORT_SYMBOL_GPL(__rt_mutex_init) to EXPORT_SYMBOL(__rt_mutex_init)
>
> ...which obviously makes the kernel GPL-incompatible / non-distributable.
>
> I may hit LKML on this issue too, as something needs to happen here -
> but i thought i would wait and see if i got a response from someone
> here, first. [being as rt-devs have a little more direct contact with
> Ingo / subsystem maintainers than i do [ and i am not even subbed to
> that list].
>
> 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

Re: WAS: linux-rt fails to boot on > 3.12.5.-rt7 ... NOW IS: linux-rt-3.14 boots by reverting patches + nvidia uses __rt_mutex_init [which in 3.14 has been changed to EXPORT_SYMBOL_GPL]

[jordan]

Hey Paul,

> I've got some AMD kit that has just been freed up from winter
> heating duty - sometime later this week I should be able to try to
> reproduce what you have seen, and knowing it works w/o the above
> softirq patch monkeying around should be a good lead on this.

That would be awesome! IIRC, Sebastian said that he didn't have said
h/w CPU kicking around to test with, at some point in my original
thread on this subject... and i just don't have the skill set required
[so i am very appreciative of anything you can do].  I don't know if
you caught it, but slavo also saw this thread, which led him to try
reverting those patches, which also allowed his arm platform to boot;
http://www.spinics.net/lists/linux-rt-users/msg11655.html ...
Eventually, after sorting out another issue he had [possible
mis-patching, KernelStack problem], slavo posted the same reverse-rt
timer code patch that i am using [applies after unified rt patch] that
works; http://pastebin.com/MYLqbmZw ... So this isn't just an AMD
problem [and i am not sure what amd cpus are affected, other than
'positively' Phenom branded cpus - which are generally fairly decent
on -rt, in my use. likewise i am not sure what other ARM platforms are
affected - maybe someone else can speak up/take a look].

* Also, [i have had several users report this to me] NO_HZ_FULL on
3.14-rt can be problematic / lead to serious instability. [on amd
Phenom anyway]. One person i know was getting lockups just by
connecting Pulseaudio to his USB soundcard, i even had one lockup
[nothing to do with PA]. Switching to periodic timers [old tick] fixed
everything for everyone. the newer  no_hz_ code is still a little
dicey on -rt.

anyway, give it a try, when you get a chance. In my own builds, for
now - i am good to go [as far as performance / stability]. But i
obviously had to; 1). revert the rt timer changes/commits, 2). switch
to preiodic timers ...which was enough for 3.14-rt to work okay, but
3). Picked up the softirq-resurrect-threads.patch [IIRC, Steven
forward ported mingo's softirq split from 2.6.xx-rt to 3.2-rt or
3.4-rt], but i grabbed it from Mike Galbraith's post;
http://www.spinics.net/lists/linux-rt-users/msg11204.html ~ I wish
this patch was in linux-rt/upstream. [actually, both].

now 3.14-rt is a happy camper ;)

Jordan

> Paul.
> --
>
>> look at those patches again - and i am more than willing to test
>> subsequent revisions to see if we can get these troublesome AMD
>> machines to boot with them applied..
>>
>> ...regarding nvidia on PREEMPT_RT_FULL / EXPORT_SYMBOL_GPL for
>> __rt_mutex_init - i notified nvidia of the problem [although, it is an
>> upstream linux problem]. Interestingly, this problem has already
>> cropped up during 3.0 development cycle on PREEMPT_RT_FULL - where the
>> __rt_mutex_init was changed to gpl-only symbol - only to be changed
>> back to SYMBOL_EXPORT shortly thereafter.... and yes, i realize
>> 'everybody hates nvidia' - but i have to imagine there might be an MIT
>> licensed out-of-tree module or two [or other gpl-compatible license]
>> that might rely on being able to use __rt_mutex_init and now can't...
>> meaning i doubt this is _just_ an nvidia problem :\
>>
>> as it stands, one must either change nvidia's licenses to GPL [makeing
>> nvidia non-distibutable]...
>>
>> or change 'kernel/locking/rtmutex.c' ~
>> EXPORT_SYMBOL_GPL(__rt_mutex_init) to EXPORT_SYMBOL(__rt_mutex_init)
>>
>> ...which obviously makes the kernel GPL-incompatible / non-distributable.
>>
>> I may hit LKML on this issue too, as something needs to happen here -
>> but i thought i would wait and see if i got a response from someone
>> here, first. [being as rt-devs have a little more direct contact with
>> Ingo / subsystem maintainers than i do [ and i am not even subbed to
>> that list].
>>
>> 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

Re: WAS: linux-rt fails to boot on > 3.12.5.-rt7 ... NOW IS: linux-rt-3.14 boots by reverting patches + nvidia uses __rt_mutex_init [which in 3.14 has been changed to EXPORT_SYMBOL_GPL]

[Paul Gortmaker]

On 14-04-19 10:42 AM, jordan wrote:
> Hey Paul,
> 
>> I've got some AMD kit that has just been freed up from winter
>> heating duty - sometime later this week I should be able to try to
>> reproduce what you have seen, and knowing it works w/o the above
>> softirq patch monkeying around should be a good lead on this.
> 
> That would be awesome! IIRC, Sebastian said that he didn't have said
> h/w CPU kicking around to test with, at some point in my original
> thread on this subject... and i just don't have the skill set required

So I stuck the -rt patches onto 3.14.1 last night;  made a defconfig
and then enabled RT_FULL in the resulting .config and that booted
right up on a 1090T six core phenom, which kind of surprised me.

I should be able to dig up an athlon quad and see what it does...

Paul.
--

> [so i am very appreciative of anything you can do].  I don't know if
> you caught it, but slavo also saw this thread, which led him to try
> reverting those patches, which also allowed his arm platform to boot;
> http://www.spinics.net/lists/linux-rt-users/msg11655.html ...
> Eventually, after sorting out another issue he had [possible
> mis-patching, KernelStack problem], slavo posted the same reverse-rt
> timer code patch that i am using [applies after unified rt patch] that
> works; http://pastebin.com/MYLqbmZw ... So this isn't just an AMD
> problem [and i am not sure what amd cpus are affected, other than
> 'positively' Phenom branded cpus - which are generally fairly decent
> on -rt, in my use. likewise i am not sure what other ARM platforms are
> affected - maybe someone else can speak up/take a look].
> 
> * Also, [i have had several users report this to me] NO_HZ_FULL on
> 3.14-rt can be problematic / lead to serious instability. [on amd
> Phenom anyway]. One person i know was getting lockups just by
> connecting Pulseaudio to his USB soundcard, i even had one lockup
> [nothing to do with PA]. Switching to periodic timers [old tick] fixed
> everything for everyone. the newer  no_hz_ code is still a little
> dicey on -rt.
> 
> anyway, give it a try, when you get a chance. In my own builds, for
> now - i am good to go [as far as performance / stability]. But i
> obviously had to; 1). revert the rt timer changes/commits, 2). switch
> to preiodic timers ...which was enough for 3.14-rt to work okay, but
> 3). Picked up the softirq-resurrect-threads.patch [IIRC, Steven
> forward ported mingo's softirq split from 2.6.xx-rt to 3.2-rt or
> 3.4-rt], but i grabbed it from Mike Galbraith's post;
> http://www.spinics.net/lists/linux-rt-users/msg11204.html ~ I wish
> this patch was in linux-rt/upstream. [actually, both].
> 
> now 3.14-rt is a happy camper ;)
> 
> Jordan
> 
>> Paul.
>> --
>>
>>> look at those patches again - and i am more than willing to test
>>> subsequent revisions to see if we can get these troublesome AMD
>>> machines to boot with them applied..
>>>
>>> ...regarding nvidia on PREEMPT_RT_FULL / EXPORT_SYMBOL_GPL for
>>> __rt_mutex_init - i notified nvidia of the problem [although, it is an
>>> upstream linux problem]. Interestingly, this problem has already
>>> cropped up during 3.0 development cycle on PREEMPT_RT_FULL - where the
>>> __rt_mutex_init was changed to gpl-only symbol - only to be changed
>>> back to SYMBOL_EXPORT shortly thereafter.... and yes, i realize
>>> 'everybody hates nvidia' - but i have to imagine there might be an MIT
>>> licensed out-of-tree module or two [or other gpl-compatible license]
>>> that might rely on being able to use __rt_mutex_init and now can't...
>>> meaning i doubt this is _just_ an nvidia problem :\
>>>
>>> as it stands, one must either change nvidia's licenses to GPL [makeing
>>> nvidia non-distibutable]...
>>>
>>> or change 'kernel/locking/rtmutex.c' ~
>>> EXPORT_SYMBOL_GPL(__rt_mutex_init) to EXPORT_SYMBOL(__rt_mutex_init)
>>>
>>> ...which obviously makes the kernel GPL-incompatible / non-distributable.
>>>
>>> I may hit LKML on this issue too, as something needs to happen here -
>>> but i thought i would wait and see if i got a response from someone
>>> here, first. [being as rt-devs have a little more direct contact with
>>> Ingo / subsystem maintainers than i do [ and i am not even subbed to
>>> that list].
>>>
>>> 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

Re: WAS: linux-rt fails to boot on > 3.12.5.-rt7 ... NOW IS: linux-rt-3.14 boots by reverting patches + nvidia uses __rt_mutex_init [which in 3.14 has been changed to EXPORT_SYMBOL_GPL]

[jordan]

On Fri, Apr 25, 2014 at 10:43 AM, Paul Gortmaker
<paul.gortmaker@windriver.com> wrote:
> On 14-04-19 10:42 AM, jordan wrote:
>> Hey Paul,
>>
>>> I've got some AMD kit that has just been freed up from winter
>>> heating duty - sometime later this week I should be able to try to
>>> reproduce what you have seen, and knowing it works w/o the above
>>> softirq patch monkeying around should be a good lead on this.
>>
>> That would be awesome! IIRC, Sebastian said that he didn't have said
>> h/w CPU kicking around to test with, at some point in my original
>> thread on this subject... and i just don't have the skill set required
>
> So I stuck the -rt patches onto 3.14.1 last night;  made a defconfig
> and then enabled RT_FULL in the resulting .config and that booted
> right up on a 1090T six core phenom, which kind of surprised me.

that surprises me too - maybe 3.14.1 fixed something? ...anyway, I am
only home for a short while [lunch] but i will try building 3.14.1-rt
when i get home and see what happens / report back.

> I should be able to dig up an athlon quad and see what it does...

worth a look, i suppose.

thanks Paul for the update

Jordan Johnston

Re: WAS: linux-rt fails to boot on > 3.12.5.-rt7 ... NOW IS: linux-rt-3.14 boots by reverting patches + nvidia uses __rt_mutex_init [which in 3.14 has been changed to EXPORT_SYMBOL_GPL]

[Paul Gortmaker]

On 14-04-25 01:23 PM, jordan wrote:
> On Fri, Apr 25, 2014 at 10:43 AM, Paul Gortmaker
> <paul.gortmaker@windriver.com> wrote:
>> On 14-04-19 10:42 AM, jordan wrote:
>>> Hey Paul,
>>>
>>>> I've got some AMD kit that has just been freed up from winter
>>>> heating duty - sometime later this week I should be able to try to
>>>> reproduce what you have seen, and knowing it works w/o the above
>>>> softirq patch monkeying around should be a good lead on this.
>>>
>>> That would be awesome! IIRC, Sebastian said that he didn't have said
>>> h/w CPU kicking around to test with, at some point in my original
>>> thread on this subject... and i just don't have the skill set required
>>
>> So I stuck the -rt patches onto 3.14.1 last night;  made a defconfig
>> and then enabled RT_FULL in the resulting .config and that booted
>> right up on a 1090T six core phenom, which kind of surprised me.
> 
> that surprises me too - maybe 3.14.1 fixed something? ...anyway, I am
> only home for a short while [lunch] but i will try building 3.14.1-rt
> when i get home and see what happens / report back.

I had to drop one ipv6 patch that was now in stable, but otherwise
it was straight forward to make a 3.14.1-rt

P.
--

> 
>> I should be able to dig up an athlon quad and see what it does...
> 
> worth a look, i suppose.
> 
> thanks Paul for the update
> 
> Jordan Johnston
> 

Re: WAS: linux-rt fails to boot on > 3.12.5.-rt7 ... NOW IS: linux-rt-3.14 boots by reverting patches + nvidia uses __rt_mutex_init [which in 3.14 has been changed to EXPORT_SYMBOL_GPL]

[Kimmo Taskinen]

On 25.04.2014 20:39, Paul Gortmaker wrote:
> On 14-04-25 01:23 PM, jordan wrote:
>> On Fri, Apr 25, 2014 at 10:43 AM, Paul Gortmaker
>> <paul.gortmaker@windriver.com> wrote:
>>> On 14-04-19 10:42 AM, jordan wrote:
>>>> Hey Paul,
>>>>
>>>>> I've got some AMD kit that has just been freed up from winter
>>>>> heating duty - sometime later this week I should be able to try to
>>>>> reproduce what you have seen, and knowing it works w/o the above
>>>>> softirq patch monkeying around should be a good lead on this.
>>>> That would be awesome! IIRC, Sebastian said that he didn't have said
>>>> h/w CPU kicking around to test with, at some point in my original
>>>> thread on this subject... and i just don't have the skill set required
>>> So I stuck the -rt patches onto 3.14.1 last night;  made a defconfig
>>> and then enabled RT_FULL in the resulting .config and that booted
>>> right up on a 1090T six core phenom, which kind of surprised me.
>> that surprises me too - maybe 3.14.1 fixed something? ...anyway, I am
>> only home for a short while [lunch] but i will try building 3.14.1-rt
>> when i get home and see what happens / report back.
> I had to drop one ipv6 patch that was now in stable, but otherwise
> it was straight forward to make a 3.14.1-rt
>
> P.
> --
>
>>> I should be able to dig up an athlon quad and see what it does...
>> worth a look, i suppose.
>>
>> thanks Paul for the update
>>
>> Jordan Johnston
I had not been able to boot my Phenom II X4 910e PC with any of the 
latest RT kernels (3.12 after 3.12.5-rt7 or 3.14 or not even the latest 
3.10 versions) until I today disabled AMD C1E from BIOS. An other way to 
get it to boot was "acpi=off" as a parameter to kernel but I need 
"button". I tried many others "processor.max_cstate=0", 
"processor.nocst", etc...

Without RT patch the "AMD C1E" is not a problem.

Cheers
Kimmo

> --
> 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: WAS: linux-rt fails to boot on > 3.12.5.-rt7 ... NOW IS: linux-rt-3.14 boots by reverting patches + nvidia uses __rt_mutex_init [which in 3.14 has been changed to EXPORT_SYMBOL_GPL]

[Kimmo Taskinen]

On 25.04.2014 20:39, Paul Gortmaker wrote:
> On 14-04-25 01:23 PM, jordan wrote:
>> On Fri, Apr 25, 2014 at 10:43 AM, Paul Gortmaker
>> <paul.gortmaker@windriver.com> wrote:
>>> On 14-04-19 10:42 AM, jordan wrote:
>>>> Hey Paul,
>>>>
>>>>> I've got some AMD kit that has just been freed up from winter
>>>>> heating duty - sometime later this week I should be able to try to
>>>>> reproduce what you have seen, and knowing it works w/o the above
>>>>> softirq patch monkeying around should be a good lead on this.
>>>> That would be awesome! IIRC, Sebastian said that he didn't have said
>>>> h/w CPU kicking around to test with, at some point in my original
>>>> thread on this subject... and i just don't have the skill set required
>>> So I stuck the -rt patches onto 3.14.1 last night;  made a defconfig
>>> and then enabled RT_FULL in the resulting .config and that booted
>>> right up on a 1090T six core phenom, which kind of surprised me.
>> that surprises me too - maybe 3.14.1 fixed something? ...anyway, I am
>> only home for a short while [lunch] but i will try building 3.14.1-rt
>> when i get home and see what happens / report back.
> I had to drop one ipv6 patch that was now in stable, but otherwise
> it was straight forward to make a 3.14.1-rt
>
> P.
> -- 
>
>>> I should be able to dig up an athlon quad and see what it does...
>> worth a look, i suppose.
>>
>> thanks Paul for the update
>>
>> Jordan Johnston
I had not been able to boot my Phenom II X4 910e PC with any of the 
latest RT kernels (3.12 after 3.12.5-rt7 or 3.14 or not even the latest 
3.10 versions) until I today disabled AMD C1E from BIOS. An other way to 
get it to boot was "acpi=off" as a parameter to kernel but I need 
"button". I tried many others "processor.max_cstate=0", 
"processor.nocst", etc...

Without RT patch the "AMD C1E" is not a problem.

Cheers
Kimmo

> -- 
> 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: WAS: linux-rt fails to boot on > 3.12.5.-rt7 ... NOW IS: linux-rt-3.14 boots by reverting patches + nvidia uses __rt_mutex_init [which in 3.14 has been changed to EXPORT_SYMBOL_GPL]

[Paul Gortmaker]

[Re: WAS: linux-rt fails to boot on > 3.12.5.-rt7 ... NOW IS: linux-rt-3.14 boots by reverting patches + nvidia uses __rt_mutex_init [which in 3.14 has been changed to EXPORT_SYMBOL_GPL]] On 14/05/2014 (Wed 03:38) Kimmo Taskinen wrote:

> On 25.04.2014 20:39, Paul Gortmaker wrote:
> >On 14-04-25 01:23 PM, jordan wrote:
> >>On Fri, Apr 25, 2014 at 10:43 AM, Paul Gortmaker
> >><paul.gortmaker@windriver.com> wrote:
> >>>On 14-04-19 10:42 AM, jordan wrote:
> >>>>Hey Paul,
> >>>>
> >>>>>I've got some AMD kit that has just been freed up from winter
> >>>>>heating duty - sometime later this week I should be able to try to
> >>>>>reproduce what you have seen, and knowing it works w/o the above
> >>>>>softirq patch monkeying around should be a good lead on this.
> >>>>That would be awesome! IIRC, Sebastian said that he didn't have said
> >>>>h/w CPU kicking around to test with, at some point in my original
> >>>>thread on this subject... and i just don't have the skill set required
> >>>So I stuck the -rt patches onto 3.14.1 last night;  made a defconfig
> >>>and then enabled RT_FULL in the resulting .config and that booted
> >>>right up on a 1090T six core phenom, which kind of surprised me.
> >>that surprises me too - maybe 3.14.1 fixed something? ...anyway, I am
> >>only home for a short while [lunch] but i will try building 3.14.1-rt
> >>when i get home and see what happens / report back.
> >I had to drop one ipv6 patch that was now in stable, but otherwise
> >it was straight forward to make a 3.14.1-rt
> >
> >P.
> >--
> >
> >>>I should be able to dig up an athlon quad and see what it does...
> >>worth a look, i suppose.
> >>
> >>thanks Paul for the update
> >>
> >>Jordan Johnston
> I had not been able to boot my Phenom II X4 910e PC with any of the
> latest RT kernels (3.12 after 3.12.5-rt7 or 3.14 or not even the
> latest 3.10 versions) until I today disabled AMD C1E from BIOS. An
> other way to get it to boot was "acpi=off" as a parameter to kernel
> but I need "button". I tried many others "processor.max_cstate=0",
> "processor.nocst", etc...
> 
> Without RT patch the "AMD C1E" is not a problem.

OK, so I never got back to finding a system that could reproduce this,
but it sounds like it is still worthwhile; thanks for the reminder and
I'll go see if I can reproduce this on a quad since the six core was OK.

P.
--

> 
> Cheers
> Kimmo
> 
> >--
> >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: WAS: linux-rt fails to boot on > 3.12.5.-rt7 ... NOW IS: linux-rt-3.14 boots by reverting patches + nvidia uses __rt_mutex_init [which in 3.14 has been changed to EXPORT_SYMBOL_GPL]

[jordan]

>> I had not been able to boot my Phenom II X4 910e PC with any of the
>> latest RT kernels (3.12 after 3.12.5-rt7 or 3.14 or not even the
>> latest 3.10 versions) until I today disabled AMD C1E from BIOS. An
>> other way to get it to boot was "acpi=off" as a parameter to kernel
>> but I need "button". I tried many others "processor.max_cstate=0",
>> "processor.nocst", etc...
>>
>> Without RT patch the "AMD C1E" is not a problem.

Kimmo, have you tried reverting the 3 patches that some of us have had
success in using to get a booting system?

you can get the patch here; http://pastebin.com/VG7X5WjK ... it
applies over 3.14.3-rt5 [after you've already applied the -rt patch,
you apply it]. It's yielded working AMD Phenom systems for me
[although, i don't have the exact same H/W as you]. it might be worth
a try, just to see if it works.

> OK, so I never got back to finding a system that could reproduce this,
> but it sounds like it is still worthwhile; thanks for the reminder and
> I'll go see if I can reproduce this on a quad since the six core was OK.

Hey Paul, I also forgot to get back to you ;) ... I had been carrying
over my .config - so i tried using defconfig too [just to see] and it
was no different. I was astonished that yours booted up just fine,
because i know of other AMD users [aside from Kimmo] who can't boot on
vainlla-rt... Again, 3.14.x-rtX boot and work just fine for me, by
reverting those patches. I had thought maybe -rt5 would boot [it
looked to have some substantial changes], but alas -rt5 also required
the patch for a working system.

Jordan

> P.
> --
>
>>
>> Cheers
>> Kimmo
>>
>> >--
>> >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: WAS: linux-rt fails to boot on > 3.12.5.-rt7 ... NOW IS: linux-rt-3.14 boots by reverting patches + nvidia uses __rt_mutex_init [which in 3.14 has been changed to EXPORT_SYMBOL_GPL]

[Kimmo Taskinen]

On 14.05.2014 05:47, jordan wrote:
>>> I had not been able to boot my Phenom II X4 910e PC with any of the
>>> latest RT kernels (3.12 after 3.12.5-rt7 or 3.14 or not even the
>>> latest 3.10 versions) until I today disabled AMD C1E from BIOS. An
>>> other way to get it to boot was "acpi=off" as a parameter to kernel
>>> but I need "button". I tried many others "processor.max_cstate=0",
>>> "processor.nocst", etc...
>>>
>>> Without RT patch the "AMD C1E" is not a problem.
> Kimmo, have you tried reverting the 3 patches that some of us have had
> success in using to get a booting system?
>
> you can get the patch here; http://pastebin.com/VG7X5WjK ... it
> applies over 3.14.3-rt5 [after you've already applied the -rt patch,
> you apply it]. It's yielded working AMD Phenom systems for me
> [although, i don't have the exact same H/W as you]. it might be worth
> a try, just to see if it works.
I can confirm that applying the patch in http://pastebin.com/VG7X5WjK to 
3.14.3-rt5 makes my system bootable even with AMD C1E enabled.
To clarify my previous email, those other tricks 
"processor.max_cstate=0", "processor.nocst", etc... did not help.

Kimmo
>
>> OK, so I never got back to finding a system that could reproduce this,
>> but it sounds like it is still worthwhile; thanks for the reminder and
>> I'll go see if I can reproduce this on a quad since the six core was OK.
> Hey Paul, I also forgot to get back to you ;) ... I had been carrying
> over my .config - so i tried using defconfig too [just to see] and it
> was no different. I was astonished that yours booted up just fine,
> because i know of other AMD users [aside from Kimmo] who can't boot on
> vainlla-rt... Again, 3.14.x-rtX boot and work just fine for me, by
> reverting those patches. I had thought maybe -rt5 would boot [it
> looked to have some substantial changes], but alas -rt5 also required
> the patch for a working system.
>
> Jordan
>
>> P.
>> --
>>
>>> Cheers
>>> Kimmo
>>>
>>>> --
>>>> 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: WAS: linux-rt fails to boot on > 3.12.5.-rt7 ... NOW IS: linux-rt-3.14 boots by reverting patches + nvidia uses __rt_mutex_init [which in 3.14 has been changed to EXPORT_SYMBOL_GPL]

[jordan]

Hey Kimmo,

>> you can get the patch here; http://pastebin.com/VG7X5WjK ... it
>> applies over 3.14.3-rt5 [after you've already applied the -rt patch,
>> you apply it]. It's yielded working AMD Phenom systems for me
>> [although, i don't have the exact same H/W as you]. it might be worth
>> a try, just to see if it works.
>
> I can confirm that applying the patch in http://pastebin.com/VG7X5WjK to
> 3.14.3-rt5 makes my system bootable even with AMD C1E enabled.
> To clarify my previous email, those other tricks "processor.max_cstate=0",
> "processor.nocst", etc... did not help.

Well, it looks like you are another person who's system is unstable
when those 3 upstream -rt patches are applied. Reverting [as you have
done now] should result in a usable/stable system for you [its worked
for myself and others for a few releases now. Maybe you can post back
on how that goes for you?]. Although, depending on config; ie: if you
are using no_hz_idle/full you may see "NOHZ: softirq pending 40"
[which one of the patches we reverted fixes, IIRC]. Myself, I don't
use NO_HZ_* and use the 'periodic timers' in the kernel, instead.

anyway, I am not sure how to fix this, beyond reverting / using that
patch. I know that some of the devs have had a hard time reproducing
the problem - maybe Paul will have better luck on another AMD system
[here is hoping]. But at least for now, you should be able to use that
patch.

jordan

> Kimmo
>>
>>
>>> OK, so I never got back to finding a system that could reproduce this,
>>> but it sounds like it is still worthwhile; thanks for the reminder and
>>> I'll go see if I can reproduce this on a quad since the six core was OK.
>>
>> Hey Paul, I also forgot to get back to you ;) ... I had been carrying
>> over my .config - so i tried using defconfig too [just to see] and it
>> was no different. I was astonished that yours booted up just fine,
>> because i know of other AMD users [aside from Kimmo] who can't boot on
>> vainlla-rt... Again, 3.14.x-rtX boot and work just fine for me, by
>> reverting those patches. I had thought maybe -rt5 would boot [it
>> looked to have some substantial changes], but alas -rt5 also required
>> the patch for a working system.
>>
>> Jordan
>>
>>> P.
>>> --
>>>
>>>> Cheers
>>>> Kimmo
>>>>
>>>>> --
>>>>> 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: WAS: linux-rt fails to boot on > 3.12.5.-rt7 ... NOW IS: linux-rt-3.14 boots by reverting patches + nvidia uses __rt_mutex_init [which in 3.14 has been changed to EXPORT_SYMBOL_GPL]

[Kimmo Taskinen]

On 14.05.2014 16:18, jordan wrote:
> Hey Kimmo,
>
>>> you can get the patch here; http://pastebin.com/VG7X5WjK ... it
>>> applies over 3.14.3-rt5 [after you've already applied the -rt patch,
>>> you apply it]. It's yielded working AMD Phenom systems for me
>>> [although, i don't have the exact same H/W as you]. it might be worth
>>> a try, just to see if it works.
>> I can confirm that applying the patch in http://pastebin.com/VG7X5WjK to
>> 3.14.3-rt5 makes my system bootable even with AMD C1E enabled.
>> To clarify my previous email, those other tricks "processor.max_cstate=0",
>> "processor.nocst", etc... did not help.
> Well, it looks like you are another person who's system is unstable
> when those 3 upstream -rt patches are applied. Reverting [as you have
> done now] should result in a usable/stable system for you [its worked
> for myself and others for a few releases now. Maybe you can post back
> on how that goes for you?]. Although, depending on config; ie: if you
> are using no_hz_idle/full you may see "NOHZ: softirq pending 40"
> [which one of the patches we reverted fixes, IIRC]. Myself, I don't
> use NO_HZ_* and use the 'periodic timers' in the kernel, instead.
I use also the "periodic timers". There are quite many more who have the 
system effected by this problem. It's the feedback from Daphile users. 
Daphile is my "distro" using the RT kernel (www.daphile.com).

Actually I'm not able give you feedback on the longterm stability of the 
reverted version because the Phenom PC is my home server and I can use 
it only for quick testing. I'm hoping too that Paul or someone else 
finds a better solutions for this :-).

Kimmo
>
> anyway, I am not sure how to fix this, beyond reverting / using that
> patch. I know that some of the devs have had a hard time reproducing
> the problem - maybe Paul will have better luck on another AMD system
> [here is hoping]. But at least for now, you should be able to use that
> patch.
>
> jordan
>
>> Kimmo
>>>
>>>> OK, so I never got back to finding a system that could reproduce this,
>>>> but it sounds like it is still worthwhile; thanks for the reminder and
>>>> I'll go see if I can reproduce this on a quad since the six core was OK.
>>> Hey Paul, I also forgot to get back to you ;) ... I had been carrying
>>> over my .config - so i tried using defconfig too [just to see] and it
>>> was no different. I was astonished that yours booted up just fine,
>>> because i know of other AMD users [aside from Kimmo] who can't boot on
>>> vainlla-rt... Again, 3.14.x-rtX boot and work just fine for me, by
>>> reverting those patches. I had thought maybe -rt5 would boot [it
>>> looked to have some substantial changes], but alas -rt5 also required
>>> the patch for a working system.
>>>
>>> Jordan
>>>
>>>> P.
>>>> --
>>>>
>>>>> Cheers
>>>>> Kimmo
>>>>>
>>>>>> --
>>>>>> 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: WAS: linux-rt fails to boot on > 3.12.5.-rt7 ... NOW IS: linux-rt-3.14 boots by reverting patches + nvidia uses __rt_mutex_init [which in 3.14 has been changed to EXPORT_SYMBOL_GPL]

[Ralf Mardorf]

On Wed, 2014-05-14 at 03:38 +0300, Kimmo Taskinen wrote:
> I had not been able to boot my Phenom II X4 910e PC with any of the 
> latest RT kernels (3.12 after 3.12.5-rt7 or 3.14 or not even the latest 
> 3.10 versions)

For my AMD Athlon X2 BE-2350 CPU on an ASUS M2A-VM HDMI <= 3.8.x-rt
kernels work, >= 3.10-rt kernels don't work.

Re: WAS: linux-rt fails to boot on > 3.12.5.-rt7 ... NOW IS: linux-rt-3.14 boots by reverting patches + nvidia uses __rt_mutex_init [which in 3.14 has been changed to EXPORT_SYMBOL_GPL]

[Ralf Mardorf]

On Mon, 2014-05-19 at 15:14 +0200, Ralf Mardorf wrote:
> On Wed, 2014-05-14 at 03:38 +0300, Kimmo Taskinen wrote:
> > I had not been able to boot my Phenom II X4 910e PC with any of the 
> > latest RT kernels (3.12 after 3.12.5-rt7 or 3.14 or not even the latest 
> > 3.10 versions)
> 
> For my AMD Athlon X2 BE-2350 CPU on an ASUS M2A-VM HDMI <= 3.8.x-rt
> kernels work, >= 3.10-rt kernels don't work.

PS: Without the RT patch, the new kernels do work.

Re: WAS: linux-rt fails to boot on > 3.12.5.-rt7 ... NOW IS: linux-rt-3.14 boots by reverting patches + nvidia uses __rt_mutex_init [which in 3.14 has been changed to EXPORT_SYMBOL_GPL]

[Joakim Hernberg]

On Mon, 19 May 2014 15:15:58 +0200
Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:

> On Mon, 2014-05-19 at 15:14 +0200, Ralf Mardorf wrote:
> > On Wed, 2014-05-14 at 03:38 +0300, Kimmo Taskinen wrote:
> > > I had not been able to boot my Phenom II X4 910e PC with any of
> > > the latest RT kernels (3.12 after 3.12.5-rt7 or 3.14 or not even
> > > the latest 3.10 versions)
> > 
> > For my AMD Athlon X2 BE-2350 CPU on an ASUS M2A-VM HDMI <= 3.8.x-rt
> > kernels work, >= 3.10-rt kernels don't work.
> 
> PS: Without the RT patch, the new kernels do work.

If you are still on archlinux, try the new 3.14.3-rt5 kernel that I've
uploaded to the AUR and to the binary archaudio-production repo.  This
one has 3 patches reverted, and all of NO_HZ disabled. Apparently this
makes it work on some AMD cpus that have had problem booting recent -rt
kernels.

-- 

   Joakim

Re: WAS: linux-rt fails to boot on > 3.12.5.-rt7 ... NOW IS: linux-rt-3.14 boots by reverting patches + nvidia uses __rt_mutex_init [which in 3.14 has been changed to EXPORT_SYMBOL_GPL]

[Ralf Mardorf]

On Mon, 2014-05-19 at 17:16 +0200, Joakim Hernberg wrote:
> If you are still on archlinux, try the new 3.14.3-rt5 kernel that I've
> uploaded to the AUR and to the binary archaudio-production repo.  This
> one has 3 patches reverted, and all of NO_HZ disabled. Apparently this
> makes it work on some AMD cpus that have had problem booting recent -rt
> kernels.

I tried both rt-lts and rt from the repo, not from AUR, for a x86_64
install.

$ pacman -Q linux-rt-lts
linux-rt-lts 3.10.39_rt40-1

I only tried to boot it one time.
Startup finished with a black screen, the display manager wasn't
visible.

$ pacman -Q linux-rt
linux-rt 3.14.3_rt5-1

The first time I booted it, a restart happened during startup.
The second time I booted it, startup hung.

Re: WAS: linux-rt fails to boot on > 3.12.5.-rt7 ... NOW IS: linux-rt-3.14 boots by reverting patches + nvidia uses __rt_mutex_init [which in 3.14 has been changed to EXPORT_SYMBOL_GPL]

[Joakim Hernberg]

On Mon, 19 May 2014 21:02:09 +0200
Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:

> On Mon, 2014-05-19 at 17:16 +0200, Joakim Hernberg wrote:
> > If you are still on archlinux, try the new 3.14.3-rt5 kernel that
> > I've uploaded to the AUR and to the binary archaudio-production
> > repo.  This one has 3 patches reverted, and all of NO_HZ disabled.
> > Apparently this makes it work on some AMD cpus that have had
> > problem booting recent -rt kernels.
> 
> I tried both rt-lts and rt from the repo, not from AUR, for a x86_64
> install.
> 
> $ pacman -Q linux-rt-lts
> linux-rt-lts 3.10.39_rt40-1
> 
> I only tried to boot it one time.
> Startup finished with a black screen, the display manager wasn't
> visible.
> 
> $ pacman -Q linux-rt
> linux-rt 3.14.3_rt5-1
> 
> The first time I booted it, a restart happened during startup.
> The second time I booted it, startup hung.
> 

If so I have no idea...  Maybe ask Jordan, as he has been having a
similar problem with AMD.  Maybe try his linux-l-pa kernel from the AUR.

-- 

   Joakim

Re: WAS: linux-rt fails to boot on > 3.12.5.-rt7 ... NOW IS: linux-rt-3.14 boots by reverting patches + nvidia uses __rt_mutex_init [which in 3.14 has been changed to EXPORT_SYMBOL_GPL]

[jordan]

Hey guys,

>> I tried both rt-lts and rt from the repo, not from AUR, for a x86_64
>> install.
>>
>> $ pacman -Q linux-rt-lts
>> linux-rt-lts 3.10.39_rt40-1
>>
>> I only tried to boot it one time.
>> Startup finished with a black screen, the display manager wasn't
>> visible.
>>
>> $ pacman -Q linux-rt
>> linux-rt 3.14.3_rt5-1
>>
>> The first time I booted it, a restart happened during startup.
>> The second time I booted it, startup hung.
>>
>
> If so I have no idea...  Maybe ask Jordan, as he has been having a
> similar problem with AMD.  Maybe try his linux-l-pa kernel from the AUR.

No, what Ralf is describing sounds different to me, for a couple of reasons;

1). I've never had a restart during startup.
2). I never had a blank screen on startup
3). I never had a problem with 3.10-rt [although, i suppose if the 3
RT patches have been backported, then 3.10-lts wouldn't boot for me,
either. - haven't used 3.10-rt since 3.12-rt came out.]

My Phenom just doesn't boot on -rt [3.12.x-rt9+], unless i revert the
3 problematic patches. Ralf seems to have something else happening.  I
know that a couple of weeks ago, Pawel [on this list] also tried
reverting the same patches on one of his problematic AMD systems,
which did not yield a working system for him, either. IIRC, he could
only boot into that kernel by passing some kernel paramters, disabling
SMP, etc. [and like Ralf, the symptoms didn't seem quite the same as
mine, or other AMD users who's systems don't work, without reverting
said patches.].

but everyone [that i know] who couldn't boot on 3.12.x-rt9+ can boot
just fine, when ditching those 3 rt patches. - So again, i think it is
likely that Pawel and Ralf's problem[s] may not be the same, as the
"revert_timers-dont_raise_softirq_unconditionally_and_fixes.patch"
resolves.

Jordan

> --
>
>    Joakim

Re: WAS: linux-rt fails to boot on > 3.12.5.-rt7 ... NOW IS: linux-rt-3.14 boots by reverting patches

[Stanislav Meduna]

On 19.04.2014 15:48, Paul Gortmaker wrote:

> I've got some AMD kit that has just been freed up from winter
> heating duty - sometime later this week I should be able to try to
> reproduce what you have seen, and knowing it works w/o the above
> softirq patch monkeying around should be a good lead on this.

After reverting the patches my box experiencing
  http://www.spinics.net/lists/linux-rt-users/msg11655.html
was stable with no more BUGs running for some 2,5 days with
our application plus a cyclictest.

Note: my configuration is an embedded ARM (i.MX28) using periodic
ticks, so this is probably neither nohz nor AMD stuff only.

Thanks
-- 
                                                 Stano

Re: WAS: linux-rt fails to boot on > 3.12.5.-rt7 ... NOW IS: linux-rt-3.14 boots by reverting patches + nvidia uses __rt_mutex_init [which in 3.14 has been changed to EXPORT_SYMBOL_GPL]

[Pavel Vasilyev]

13.04.2014 19:50, jordan пишет:
> Hey list.
>
> 1. So after finally having some time off of work [after a busy couple
> of months] i have come back to trying to sort out linux-rt on my AMD
> PHenom II 965 system - which had failed to boot post 3.12.5-rt7
>
> first, i need to make a correction -rt8 DID boot fine and was stable
> [after one/initial lockup, it never locked again, and obviously booted
> fine.]. but i figured this out, only after doing a git-bisect on -rt7
> to -rt8 ... and never got around to testing -rt8 to -rt9... However, I
> decided to give 3.14-rt a run - and again - ended up with the machine
> failing to boot... Next, i decided to revert all three of the patches
> that you pointed out Sebastion;
>
> | timers-do-not-raise-softirq-unconditionally.patch
> | timer-Raise-softirq-if-there-s-irq_work.patch
> | timer-rt-Always-raise-the-softirq-if-there-s-irq_wor.patch
>
> well, what i actually ended up doing was reverting the first and
> modifying the 1st patch to revert the other two patches (by changing
> ../kernel/timer.c section of the original patch). [ i reverted after
> applying the linux-rt patch, not split queue];
> http://pastebin.com/zwsZg9ZM

Please show patch between 3.14-rt1 and 3.14-rt1-you-version



-- 

                                                          Pavel.
--
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: WAS: linux-rt fails to boot on > 3.12.5.-rt7 ... NOW IS: linux-rt-3.14 boots by reverting patches + nvidia uses __rt_mutex_init [which in 3.14 has been changed to EXPORT_SYMBOL_GPL]

[Pavel Vasilyev]

24.04.2014 01:09, Pavel Vasilyev пишет:
> 13.04.2014 19:50, jordan пишет:
>> Hey list.
>>
>> 1. So after finally having some time off of work [after a busy couple
>> of months] i have come back to trying to sort out linux-rt on my AMD
>> PHenom II 965 system - which had failed to boot post 3.12.5-rt7
>>
>> first, i need to make a correction -rt8 DID boot fine and was stable
>> [after one/initial lockup, it never locked again, and obviously booted
>> fine.]. but i figured this out, only after doing a git-bisect on -rt7
>> to -rt8 ... and never got around to testing -rt8 to -rt9... However, I
>> decided to give 3.14-rt a run - and again - ended up with the machine
>> failing to boot... Next, i decided to revert all three of the patches
>> that you pointed out Sebastion;
>>
>> | timers-do-not-raise-softirq-unconditionally.patch
>> | timer-Raise-softirq-if-there-s-irq_work.patch
>> | timer-rt-Always-raise-the-softirq-if-there-s-irq_wor.patch
>>
>> well, what i actually ended up doing was reverting the first and
>> modifying the 1st patch to revert the other two patches (by changing
>> ../kernel/timer.c section of the original patch). [ i reverted after
>> applying the linux-rt patch, not split queue];
>> http://pastebin.com/zwsZg9ZM
>
> Please show patch between 3.14-rt1 and 3.14-rt1-you-version
>
>

Well, no matter. I revert these three patches, and did not help.
Since September 2013 and until now, my system no longer operates in RT_FULL and 
SMP mode. Only SOFT_RT or maxcpus=0.


-- 

                                                          Pavel.
--
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