[Adeos-main] adeos i386 and ppc patches forward ported to 2.6.13

[Adeos-main] adeos i386 and ppc patches forward ported to 2.6.13

[Stelian Pop]

Hi,

I've forward ported
	adeos-linux-2.6.10-ppc-r8c2.patch
	adeos-linux-2.6.12-i386-r13c1.patch
to a fresh 2.6.13 kernel.

The i386 patch port was quite trivial, except for a few code changes.
However, I had to modify the ADEOS_PREEMPT_RT definition to:
+config ADEOS_PREEMPT_RT
+       def_bool PREEMPT_VOLUNTARY || PREEMPT_DESKTOP || PREEMPT_RT
+
(removed the PREEMPT_NONE from the def_bool definition) in order to make
it build on a regular, non PREEMPT_RT kernel (or else the compilation
would fail on a raw_spinlock_t undefined error). I think this problem
exists in the 2.6.12 patch as well.

The ppc patch was a bit more tricky, but I think I got all of it right.
It works ok most of the time (RTAI fusion testsuite passes for example -
on a G4 Powerbook), but it hangs the machine hard sometimes. I am not
sure if the problem is due to the port or if it is present in the 2.6.10
version as well.

The two patches are at:
	http://www.popies.net/tmp/adeos-linux-2.6.13-i386-r13c1.patch
	http://www.popies.net/tmp/adeos-linux-2.6.13-ppc-r8c2.patch

Stelian.
-- 
Stelian Pop <stelian.pop@domain.hid>

Re: [Adeos-main] adeos i386 and ppc patches forward ported to 2.6.13

[Philippe Gerum]

Quoting Stelian Pop <stelian.pop@domain.hid>:

> Hi,
>
> I've forward ported
> 	adeos-linux-2.6.10-ppc-r8c2.patch
> 	adeos-linux-2.6.12-i386-r13c1.patch
> to a fresh 2.6.13 kernel.
>

Thanks.

> The i386 patch port was quite trivial, except for a few code changes.
> However, I had to modify the ADEOS_PREEMPT_RT definition to:
> +config ADEOS_PREEMPT_RT
> +       def_bool PREEMPT_VOLUNTARY || PREEMPT_DESKTOP || PREEMPT_RT
> +
> (removed the PREEMPT_NONE from the def_bool definition) in order to make
> it build on a regular, non PREEMPT_RT kernel (or else the compilation
> would fail on a raw_spinlock_t undefined error). I think this problem
> exists in the 2.6.12 patch as well.
>

Ok. Looks like time has come to upgrade the combined Adeos/PREEMPT_RT patch to
-rt1 in order to fix the issues brought since 0.7.44, I guess.

> The ppc patch was a bit more tricky, but I think I got all of it right.
> It works ok most of the time (RTAI fusion testsuite passes for example -
> on a G4 Powerbook), but it hangs the machine hard sometimes. I am not
> sure if the problem is due to the port or if it is present in the 2.6.10
> version as well.
>

I had a report about issues involving insufficiently protected
get_mmu_context/destroy_context calls on the RTAI mailing list with
2.6.10-r8c1; I'm currently checking the proposed fix that has been sent to me
on a mpc8541. If this works, then maybe this would solve the issue you mention
too; hopefully.

> The two patches are at:
> 	http://www.popies.net/tmp/adeos-linux-2.6.13-i386-r13c1.patch
> 	http://www.popies.net/tmp/adeos-linux-2.6.13-ppc-r8c2.patch
>

I've picked them; they likely won't reach the CVS or the DL area until 
next week
since I'm temporarily behind some paranoid firewall though.

Thanks again.

> Stelian.
> --
> Stelian Pop <stelian.pop@domain.hid>
>
>
> _______________________________________________
> Adeos-main mailing list
> Adeos-main@domain.hid
> https://mail.gna.org/listinfo/adeos-main
>

Re: [Adeos-main] adeos i386 and ppc patches forward ported to 2.6.13

[Stelian Pop]

On Wed, Aug 31, 2005 at 07:37:33PM +0200, Philippe Gerum wrote:

> >However, I had to modify the ADEOS_PREEMPT_RT definition to:
> >+config ADEOS_PREEMPT_RT
> >+       def_bool PREEMPT_VOLUNTARY || PREEMPT_DESKTOP || PREEMPT_RT
> >+
> >(removed the PREEMPT_NONE from the def_bool definition) in order to make
> >it build on a regular, non PREEMPT_RT kernel (or else the compilation
> >would fail on a raw_spinlock_t undefined error). I think this problem
> >exists in the 2.6.12 patch as well.
> >
> 
> Ok. Looks like time has come to upgrade the combined Adeos/PREEMPT_RT patch 
> to
> -rt1 in order to fix the issues brought since 0.7.44, I guess.

How does this relate to the above ? I worked on the _plain_ adeos 
patch, not the combo rt one. That being said, the plain adeos patch
does contain some PREEMPT_RT bits - and those are the ones causing the
problems.

> >The ppc patch was a bit more tricky, but I think I got all of it right.
> >It works ok most of the time (RTAI fusion testsuite passes for example -
> >on a G4 Powerbook), but it hangs the machine hard sometimes. I am not
> >sure if the problem is due to the port or if it is present in the 2.6.10
> >version as well.
> >
> 
> I had a report about issues involving insufficiently protected
> get_mmu_context/destroy_context calls on the RTAI mailing list with
> 2.6.10-r8c1; I'm currently checking the proposed fix that has been sent to 
> me
> on a mpc8541. If this works, then maybe this would solve the issue you 
> mention
> too; hopefully.

I suppose you're talking about:
https://mail.rtai.org/pipermail/rtai/2005-August/012841.html

I'll try that patch too tomorrow and will let you know if it does
fix my hangs.

> >The two patches are at:
> >	http://www.popies.net/tmp/adeos-linux-2.6.13-i386-r13c1.patch
> >	http://www.popies.net/tmp/adeos-linux-2.6.13-ppc-r8c2.patch
> >
> 
> I've picked them; they likely won't reach the CVS or the DL area until 
> next week
> since I'm temporarily behind some paranoid firewall though.

np.

Thanks.

Stelian.
-- 
Stelian Pop <stelian.pop@domain.hid>
Alcove - http://www.alcove.com

Re: [Adeos-main] adeos i386 and ppc patches forward ported to 2.6.13

[Philippe Gerum]

Quoting Stelian Pop <stelian.pop@domain.hid>:

> On Wed, Aug 31, 2005 at 07:37:33PM +0200, Philippe Gerum wrote:
>
>> >However, I had to modify the ADEOS_PREEMPT_RT definition to:
>> >+config ADEOS_PREEMPT_RT
>> >+       def_bool PREEMPT_VOLUNTARY || PREEMPT_DESKTOP || PREEMPT_RT
>> >+
>> >(removed the PREEMPT_NONE from the def_bool definition) in order to make
>> >it build on a regular, non PREEMPT_RT kernel (or else the compilation
>> >would fail on a raw_spinlock_t undefined error). I think this problem
>> >exists in the 2.6.12 patch as well.
>> >
>>
>> Ok. Looks like time has come to upgrade the combined Adeos/PREEMPT_RT patch
>> to
>> -rt1 in order to fix the issues brought since 0.7.44, I guess.
>
> How does this relate to the above ? I worked on the _plain_ adeos
> patch, not the combo rt one. That being said, the plain adeos patch
> does contain some PREEMPT_RT bits - and those are the ones causing the
> problems.
>

This is exactely how this relates to the above: The PREEMPT_RT-aware bits are
out of date.

>> >The ppc patch was a bit more tricky, but I think I got all of it right.
>> >It works ok most of the time (RTAI fusion testsuite passes for example -
>> >on a G4 Powerbook), but it hangs the machine hard sometimes. I am not
>> >sure if the problem is due to the port or if it is present in the 2.6.10
>> >version as well.
>> >
>>
>> I had a report about issues involving insufficiently protected
>> get_mmu_context/destroy_context calls on the RTAI mailing list with
>> 2.6.10-r8c1; I'm currently checking the proposed fix that has been sent to
>> me
>> on a mpc8541. If this works, then maybe this would solve the issue you
>> mention
>> too; hopefully.
>
> I suppose you're talking about:
> https://mail.rtai.org/pipermail/rtai/2005-August/012841.html
>

Yes; Looking at the code a bit more, I think the issue was more 
generally lying
in the unprotected use of activate_mm(), as called from the fs/exec stuff.

> I'll try that patch too tomorrow and will let you know if it does
> fix my hangs.
>
>> >The two patches are at:
>> >	http://www.popies.net/tmp/adeos-linux-2.6.13-i386-r13c1.patch
>> >	http://www.popies.net/tmp/adeos-linux-2.6.13-ppc-r8c2.patch
>> >
>>
>> I've picked them; they likely won't reach the CVS or the DL area until
>> next week
>> since I'm temporarily behind some paranoid firewall though.
>
> np.
>
> Thanks.
>
> Stelian.
> --
> Stelian Pop <stelian.pop@domain.hid>
> Alcove - http://www.alcove.com
>

Re: [Adeos-main] adeos i386 and ppc patches forward ported to 2.6.13

[Stelian Pop]

Le jeudi 01 septembre 2005 à 10:47 +0200, Philippe Gerum a écrit : 
> >> Ok. Looks like time has come to upgrade the combined Adeos/PREEMPT_RT patch
> >> to
> >> -rt1 in order to fix the issues brought since 0.7.44, I guess.
> >
> > How does this relate to the above ? I worked on the _plain_ adeos
> > patch, not the combo rt one. That being said, the plain adeos patch
> > does contain some PREEMPT_RT bits - and those are the ones causing the
> > problems.
> >
> 
> This is exactely how this relates to the above: The PREEMPT_RT-aware bits are
> out of date.

I was under the impression that the PREEMPT_RT bits were not supposed to
be at all in the plain (non rt combo) patch. But I suppose the current
plan is to fold those bits into the regular patch.

> >> >The ppc patch was a bit more tricky, but I think I got all of it right.
> >> >It works ok most of the time (RTAI fusion testsuite passes for example -
> >> >on a G4 Powerbook), but it hangs the machine hard sometimes. I am not
> >> >sure if the problem is due to the port or if it is present in the 2.6.10
> >> >version as well.
> >> >
> >>
> >> I had a report about issues involving insufficiently protected
> >> get_mmu_context/destroy_context calls on the RTAI mailing list with
> >> 2.6.10-r8c1; I'm currently checking the proposed fix that has been sent to
> >> me
> >> on a mpc8541. If this works, then maybe this would solve the issue you
> >> mention
> >> too; hopefully.
> >
> > I suppose you're talking about:
> > https://mail.rtai.org/pipermail/rtai/2005-August/012841.html
> >
> 
> Yes; Looking at the code a bit more, I think the issue was more 
> generally lying
> in the unprotected use of activate_mm(), as called from the fs/exec stuff.

I saw the patch you posted on the rtai list and tried it,
but unfortunately it does not solve my problems.

The bug (hard lockup without any message at all) is 100% reproductible
when running fusion's rtai-test application. It does not always hang at
the same point in execution, but it does often hang at the end of the
'latency' binary invocation.

I am also unable to reproduce this bug when running manually the 'latency'
test, even when simulating some load like 'rtai-test' does. I suppose
I could end up reproducing the bug if I tried hard enough...

I'll try testing the 2.6.10 patch, maybe this will tell if the problem
is in the adeos core or in the newer kernel changes...

Stelian.
-- 
Stelian Pop <stelian.pop@domain.hid>

Re: [Adeos-main] adeos i386 and ppc patches forward ported to 2.6.13

[Philippe Gerum]

Quoting Stelian Pop <stelian@domain.hid>:

> Le jeudi 01 septembre 2005 à 10:47 +0200, Philippe Gerum a écrit :
>> >> Ok. Looks like time has come to upgrade the combined
>> Adeos/PREEMPT_RT patch
>> >> to
>> >> -rt1 in order to fix the issues brought since 0.7.44, I guess.
>> >
>> > How does this relate to the above ? I worked on the _plain_ adeos
>> > patch, not the combo rt one. That being said, the plain adeos patch
>> > does contain some PREEMPT_RT bits - and those are the ones causing the
>> > problems.
>> >
>>
>> This is exactely how this relates to the above: The PREEMPT_RT-aware
>> bits are
>> out of date.
>
> I was under the impression that the PREEMPT_RT bits were not supposed to
> be at all in the plain (non rt combo) patch. But I suppose the current
> plan is to fold those bits into the regular patch.
>

Yep. This is so in order to reduce the number of adaptations needed to
make the
combo patches, as an attempt to reduce the number of code conflicts between
Adeos and PREEMPT_RT.

>> >> >The ppc patch was a bit more tricky, but I think I got all of it right.
>> >> >It works ok most of the time (RTAI fusion testsuite passes for example -
>> >> >on a G4 Powerbook), but it hangs the machine hard sometimes. I am not
>> >> >sure if the problem is due to the port or if it is present in the 2.6.10
>> >> >version as well.
>> >> >
>> >>
>> >> I had a report about issues involving insufficiently protected
>> >> get_mmu_context/destroy_context calls on the RTAI mailing list with
>> >> 2.6.10-r8c1; I'm currently checking the proposed fix that has
>> been sent to
>> >> me
>> >> on a mpc8541. If this works, then maybe this would solve the issue you
>> >> mention
>> >> too; hopefully.
>> >
>> > I suppose you're talking about:
>> > https://mail.rtai.org/pipermail/rtai/2005-August/012841.html
>> >
>>
>> Yes; Looking at the code a bit more, I think the issue was more
>> generally lying
>> in the unprotected use of activate_mm(), as called from the fs/exec stuff.
>
> I saw the patch you posted on the rtai list and tried it,
> but unfortunately it does not solve my problems.
>
> The bug (hard lockup without any message at all) is 100% reproductible
> when running fusion's rtai-test application. It does not always hang at
> the same point in execution, but it does often hang at the end of the
> 'latency' binary invocation.
>

Would be very lucky so I guess it's unlikely, but anyway, does enabling the
fusion watchdog in the nucleus menu trigger something?

> I am also unable to reproduce this bug when running manually the 'latency'
> test, even when simulating some load like 'rtai-test' does. I suppose
> I could end up reproducing the bug if I tried hard enough...
>
> I'll try testing the 2.6.10 patch, maybe this will tell if the problem
> is in the adeos core or in the newer kernel changes...
>
> Stelian.
> --
> Stelian Pop <stelian.pop@domain.hid>
>
>

Re: [Adeos-main] adeos i386 and ppc patches forward ported to 2.6.13

[Stelian Pop]

Le jeudi 01 septembre 2005 à 14:44 +0200, Philippe Gerum a écrit :

> 
> Would be very lucky so I guess it's unlikely, but anyway, does enabling the
> fusion watchdog in the nucleus menu trigger something?

Already tried this, as well as enable 'debug support' in the nucleus
menu. No effect.

Stelian.
-- 
Stelian Pop <stelian@domain.hid>

Re: [Adeos-main] adeos i386 and ppc patches forward ported to 2.6.13

[Stelian Pop]

Le jeudi 01 septembre 2005 à 14:20 +0200, Stelian Pop a écrit :

> I'll try testing the 2.6.10 patch, maybe this will tell if the problem
> is in the adeos core or in the newer kernel changes...

Okay, it also hangs with the 2.6.10 patch (even with the fix for
activate_mm()). It took two invocations of 'rtai-test' but it ended up
hanging just like before.

Stelian.
-- 
Stelian Pop <stelian@domain.hid>

Re: [Adeos-main] adeos i386 and ppc patches forward ported to 2.6.13

[Heikki Lindholm]

Stelian Pop kirjoitti:
> Le jeudi 01 septembre 2005 à 14:20 +0200, Stelian Pop a écrit :
> 
> 
>>I'll try testing the 2.6.10 patch, maybe this will tell if the problem
>>is in the adeos core or in the newer kernel changes...
> 
> 
> Okay, it also hangs with the 2.6.10 patch (even with the fix for
> activate_mm()). It took two invocations of 'rtai-test' but it ended up
> hanging just like before.

Are you sure this is not the same I was experiencing, eg. missed 
decrementer interrupt that stalls the machine (looks like hard lock-up) 
for two minutes. It only happens on the more "advanced" PPCs, like 6xx 
and 7xxx.

-- Heikki Lindholm

Re: [Adeos-main] adeos i386 and ppc patches forward ported to 2.6.13

[Stelian Pop]

Le jeudi 01 septembre 2005 à 16:09 +0300, Heikki Lindholm a écrit :
> Stelian Pop kirjoitti:
> > Le jeudi 01 septembre 2005 à 14:20 +0200, Stelian Pop a écrit :
> > 
> > 
> >>I'll try testing the 2.6.10 patch, maybe this will tell if the problem
> >>is in the adeos core or in the newer kernel changes...
> > 
> > 
> > Okay, it also hangs with the 2.6.10 patch (even with the fix for
> > activate_mm()). It took two invocations of 'rtai-test' but it ended up
> > hanging just like before.
> 
> Are you sure this is not the same I was experiencing, eg. missed 
> decrementer interrupt that stalls the machine (looks like hard lock-up) 
> for two minutes.

I tried waiting (at least 5 minutes) and nothing happened.

>  It only happens on the more "advanced" PPCs, like 6xx 
> and 7xxx.

This _is_ an advanced PPC, it's a (fairly recent) Powerbook:

processor	: 0
cpu		: 7447A, altivec supported
clock		: 1499MHz
revision	: 0.2 (pvr 8003 0102)
bogomips	: 1495.04
machine		: PowerBook5,6
motherboard	: PowerBook5,6 MacRISC3 Power Macintosh 
detected as	: 287 (PowerBook G4 15")
pmac flags	: 0000001b
L2 cache	: 512K unified
memory		: 512MB
pmac-generation	: NewWorld

Stelian.
-- 
Stelian Pop <stelian@domain.hid>

Re: [Adeos-main] adeos i386 and ppc patches forward ported to 2.6.13

[Philippe Gerum]

Quoting Stelian Pop <stelian@domain.hid>:

> Le jeudi 01 septembre 2005 à 16:09 +0300, Heikki Lindholm a écrit :
>> Stelian Pop kirjoitti:
>> > Le jeudi 01 septembre 2005 à 14:20 +0200, Stelian Pop a écrit :
>> >
>> >
>> >>I'll try testing the 2.6.10 patch, maybe this will tell if the problem
>> >>is in the adeos core or in the newer kernel changes...
>> >
>> >
>> > Okay, it also hangs with the 2.6.10 patch (even with the fix for
>> > activate_mm()). It took two invocations of 'rtai-test' but it ended up
>> > hanging just like before.
>>
>> Are you sure this is not the same I was experiencing, eg. missed
>> decrementer interrupt that stalls the machine (looks like hard lock-up)
>> for two minutes.
>
> I tried waiting (at least 5 minutes) and nothing happened.
>

Here is a revisited version of Heikki's patch applicable against an
Adeos-patched kernel, and which is expected to solve the lagging
interrupt sync
issue; tested on a mpc8541 board. I'd be interested to know if this
still fixes
the issue discovered on ppc64, and maybe on the G4.

--- linuxppc-mpc52xx-adeos/kernel/adeos.c	2005-08-21 11:44:52.000000000 +0200
+++ linux-2.6.10-ppc-adeos/kernel/adeos.c	2005-09-01 00:19:58.000000000 +0200
@@ -173,6 +173,13 @@
		break;
		}
	    }
+	else if (next_domain != this_domain &&
+		 next_domain->cpudata[cpuid].irq_pending_hi != 0 &&
+		 !test_bit(IPIPE_STALL_FLAG,&next_domain->cpudata[cpuid].status))
+	    {
+	    __adeos_switch_to(this_domain,next_domain,cpuid);
+	    adeos_load_cpuid(); /* Processor might have changed. */
+	    }

	if (next_domain == this_domain)
	    break;
@@ -223,6 +230,13 @@

	    propagate = evinfo.propagate;
	    }
+	else if (next_domain != this_domain &&
+		 next_domain->cpudata[cpuid].irq_pending_hi != 0 &&
+		 !test_bit(IPIPE_STALL_FLAG,&next_domain->cpudata[cpuid].status))
+	    {
+	    __adeos_switch_to(this_domain,next_domain,cpuid);
+	    adeos_load_cpuid(); /* Processor might have changed. */
+	    }

	if (next_domain == this_domain || !propagate)
	    break;

Re: [Adeos-main] adeos i386 and ppc patches forward ported to 2.6.13

[Stelian Pop]

Le jeudi 01 septembre 2005 à 15:52 +0200, Philippe Gerum a écrit :

> >> Are you sure this is not the same I was experiencing, eg. missed
> >> decrementer interrupt that stalls the machine (looks like hard lock-up)
> >> for two minutes.
> >
> > I tried waiting (at least 5 minutes) and nothing happened.
> >
> 
> Here is a revisited version of Heikki's patch applicable against an
> Adeos-patched kernel, and which is expected to solve the lagging 
> interrupt sync
> issue; tested on a mpc8541 board. I'd be interested to know if this 
> still fixes
> the issue discovered on ppc64, and maybe on the G4.

Does not change a thing on the G4.

Stelian.
-- 
Stelian Pop <stelian@domain.hid>

Re: [Adeos-main] adeos i386 and ppc patches forward ported to 2.6.13

[Philippe Gerum]

Quoting Stelian Pop <stelian@domain.hid>:

> Le jeudi 01 septembre 2005 à 15:52 +0200, Philippe Gerum a écrit :
>
>> >> Are you sure this is not the same I was experiencing, eg. missed
>> >> decrementer interrupt that stalls the machine (looks like hard lock-up)
>> >> for two minutes.
>> >
>> > I tried waiting (at least 5 minutes) and nothing happened.
>> >
>>
>> Here is a revisited version of Heikki's patch applicable against an
>> Adeos-patched kernel, and which is expected to solve the lagging
>> interrupt sync
>> issue; tested on a mpc8541 board. I'd be interested to know if this
>> still fixes
>> the issue discovered on ppc64, and maybe on the G4.
>
> Does not change a thing on the G4.
>

Of, so if Heikki confirms that this patch works on ppc64, I guess that
we have a
brand new shiny bug to chase, with lots of headbanging sessions ahead. And I'm
not talking about dance style here...

Ok, question #1: does this lockup only happen with latency, or is it also
experienced with klatency?

> Stelian.
> --
> Stelian Pop <stelian@domain.hid>
>
>

Re: [Adeos-main] adeos i386 and ppc patches forward ported to 2.6.13

[Stelian Pop]

Le jeudi 01 septembre 2005 à 16:46 +0200, Philippe Gerum a écrit :

> Of, so if Heikki confirms that this patch works on ppc64, I guess that 
> we have a
> brand new shiny bug to chase, with lots of headbanging sessions ahead. And I'm
> not talking about dance style here...

:)

> Ok, question #1: does this lockup only happen with latency, or is it also
> experienced with klatency?

I think I saw it only with latency.

Stelian.
-- 
Stelian Pop <stelian@domain.hid>

Re: [Adeos-main] adeos i386 and ppc patches forward ported to 2.6.13

[Heikki Lindholm]

Stelian Pop kirjoitti:
> Le jeudi 01 septembre 2005 à 16:46 +0200, Philippe Gerum a écrit :
> 
> 
>>Of, so if Heikki confirms that this patch works on ppc64, I guess that 
>>we have a
>>brand new shiny bug to chase, with lots of headbanging sessions ahead. And I'm
>>not talking about dance style here...
> 
> 
> :)
> 
> 
>>Ok, question #1: does this lockup only happen with latency, or is it also
>>experienced with klatency?
> 
> 
> I think I saw it only with latency.

Did this happen mid-way while executing or only at the end, eg. modules 
unload phase? On the ppc64 port, I got an easily reproducible access 
exception after unloading rtai_native while unloading rtai_nucleus.

-- Heikki Lindholm

Re: [Adeos-main] adeos i386 and ppc patches forward ported to 2.6.13

[Stelian Pop]

Le samedi 03 septembre 2005 à 09:47 +0300, Heikki Lindholm a écrit :
> Stelian Pop kirjoitti:
> > Le jeudi 01 septembre 2005 à 16:46 +0200, Philippe Gerum a écrit :
> > 
> > 
> >>Of, so if Heikki confirms that this patch works on ppc64, I guess that 
> >>we have a
> >>brand new shiny bug to chase, with lots of headbanging sessions ahead. And I'm
> >>not talking about dance style here...
> > 
> > 
> > :)
> > 
> > 
> >>Ok, question #1: does this lockup only happen with latency, or is it also
> >>experienced with klatency?
> > 
> > 
> > I think I saw it only with latency.
> 
> Did this happen mid-way while executing or only at the end, eg. modules 
> unload phase? 

I'd say yes, it only happens at the end of the execution of latency.

However, having already thought of such an issue I also tried preloading
the modules (thus making rtai-load not remove the modules at the end of
its run). And it made no difference.

Stelian.
-- 
Stelian Pop <stelian@domain.hid>

Re: [Adeos-main] adeos i386 and ppc patches forward ported to 2.6.13

[Heikki Lindholm]

Philippe Gerum kirjoitti:
> Quoting Stelian Pop <stelian@domain.hid>:
> 
>> Le jeudi 01 septembre 2005 à 15:52 +0200, Philippe Gerum a écrit :
>>
>>> >> Are you sure this is not the same I was experiencing, eg. missed
>>> >> decrementer interrupt that stalls the machine (looks like hard 
>>> lock-up)
>>> >> for two minutes.
>>> >
>>> > I tried waiting (at least 5 minutes) and nothing happened.
>>> >
>>>
>>> Here is a revisited version of Heikki's patch applicable against an
>>> Adeos-patched kernel, and which is expected to solve the lagging
>>> interrupt sync
>>> issue; tested on a mpc8541 board. I'd be interested to know if this
>>> still fixes
>>> the issue discovered on ppc64, and maybe on the G4.
>>
>>
>> Does not change a thing on the G4.
>>
> 
> Of, so if Heikki confirms that this patch works on ppc64, I guess that 
> we have a
> brand new shiny bug to chase, with lots of headbanging sessions ahead. 
> And I'm
> not talking about dance style here...

I've now tried both 32- and 64-bit kernels on the G5 with and without 
the patch and the results seem consistent with the G4. Without the 
patch, stalls happen always with nucleus loaded, but I didn't observe 
any with the patch. However, I'm still not happy with how the patch 
handles the !threaded case: If everyone had handlers like
my_handler(...);
{
    traps++;
    return PROPAGATE;
}
the patch wouldn't help at all. I'd prefer something more along the 
lines of my original posting.

-- Heikki Lindholm

Re: [Adeos-main] adeos i386 and ppc patches forward ported to 2.6.13

[Heikki Lindholm]

Heikki Lindholm kirjoitti:
> Philippe Gerum kirjoitti:
> 
>> Quoting Stelian Pop <stelian@domain.hid>:
>>
>>> Le jeudi 01 septembre 2005 à 15:52 +0200, Philippe Gerum a écrit :
>>>
>>>> >> Are you sure this is not the same I was experiencing, eg. missed
>>>> >> decrementer interrupt that stalls the machine (looks like hard 
>>>> lock-up)
>>>> >> for two minutes.
>>>> >
>>>> > I tried waiting (at least 5 minutes) and nothing happened.
>>>> >
>>>>
>>>> Here is a revisited version of Heikki's patch applicable against an
>>>> Adeos-patched kernel, and which is expected to solve the lagging
>>>> interrupt sync
>>>> issue; tested on a mpc8541 board. I'd be interested to know if this
>>>> still fixes
>>>> the issue discovered on ppc64, and maybe on the G4.
>>>
>>>
>>>
>>> Does not change a thing on the G4.
>>>
>>
>> Of, so if Heikki confirms that this patch works on ppc64, I guess that 
>> we have a
>> brand new shiny bug to chase, with lots of headbanging sessions ahead. 
>> And I'm
>> not talking about dance style here...
> 
> 
> I've now tried both 32- and 64-bit kernels on the G5 with and without 
> the patch and the results seem consistent with the G4. Without the 
> patch, stalls happen always with nucleus loaded, but I didn't observe 
> any with the patch. However, I'm still not happy with how the patch 
> handles the !threaded case: If everyone had handlers like
> my_handler(...);
> {
>    traps++;
>    return PROPAGATE;
> }
> the patch wouldn't help at all. I'd prefer something more along the 
> lines of my original posting.

Baah. Didn't notice the CVS is already updated. The changes in CVS look 
good to me. Scrap the previous comment.

-- Heikki Lindholm