Samuel Ortiz | 1 May 2007 02:53

Re: [irda-users] [BUG] 2.6.20.1-rt8 irnet + pppd recursive spinlock...

On Mon, Apr 30, 2007 at 03:24:05PM +0200, Guennadi Liakhovetski wrote:
> On Tue, 10 Apr 2007, Samuel Ortiz wrote:
> 
> > Hi Guennadi,
> > 
> > The patch below schedules irnet_flow_indication() asynchronously. Could
> > you please give it a try (it builds, but I couldn't test it...) ? :
> 
> Ok, your patch (still below) works too (now that I fixed that state 
> machine race, btw, we still have to decide on the final form how it goes 
> in the mainline) __after__ you also add the line
> 
> +	INIT_WORK(&new->irnet_flow_work, irttp_flow_restart);
> 
> in irttp_dup() (remember spinlock_init()?:-)), otherwise it oopses.
good catch, again...Yes, I do remember the irttp_dup bug ;-)

 
> Generally, I like your patch better than mine to ppp_generic.c, where I 
> explicitly check if a recursion is occurring. Still, I am a bit concerned 
> about introducing yet another execution context into irda... We have seen 
> a couple of locking issues there already in the last 2-3 months especially 
> under rt-preempt... Would you be able to run some tests too? 
I think I can run some tests here as well, but probably not as many as you:
I'm not doing IrDA stuff full time while it seems you currently are.
But I will definitely spend some time this week running my IrDA stack with this
patch applied. I didn't bother to do that earlier as you first reported some
oops with this patch applied.

> I will be 
(Continue reading)

Alessio Igor Bogani | 2 May 2007 11:59
Picon

pagefault_enable & pagefault_disable

Hi,

What is the reason for declare pagefault_enable and pagefault_disable
as only GPL symbols in mm/memory.c (obviously with Ingo's
realtime patch applied)? 

I violate license if i change those two EXPORT_SYMBOL_GPL in EXPORT_SYMBOL?

Thanks in advance!

Ciao,
Alessio

Guennadi Liakhovetski | 2 May 2007 13:05
Picon
Favicon

Re: [irda-users] [BUG] 2.6.20.1-rt8 irnet + pppd recursive spinlock...

On Tue, 1 May 2007, Samuel Ortiz wrote:
> But I will definitely spend some time this week running my IrDA stack 
> with this patch applied. I didn't bother to do that earlier as you first 
> reported some oops with this patch applied.

I think, what I reported was not an Oops, but the race that we're also 
fixing ATM - the one in the state machine. So, unrelated.

> On Mon, Apr 30, 2007 at 03:24:05PM +0200, Guennadi Liakhovetski wrote:

> > in irttp_dup() (remember spinlock_init()?:-)), otherwise it oopses.
> good catch, again...Yes, I do remember the irttp_dup bug ;-)

I've put a tsap_init() function that does those common initialisation 
calls, so we have a smaller chance of forgetting the dup() path next 
time...

> > I will be 
> > testing it too, but don't know how much longer and how intensively. Do you 
> > think we might get some new problems with this new context?
> It seems quite safe to me. But more importantly, I thing we do want to call
> the flow indication routine asynchronously in that specific case. 
> There is one thing that this patch is missing though: we should probably
> clean the worqueue right before we destroy the TTP instance. The work routine
> checks for NULL pointer, but still...

I thought about it too, but the only thing you can do is 
flush_scheduled_work(), is this what you mean?

The test with your patch stopped inside a ftp transfer - the ftp client 
(Continue reading)

Steven Rostedt | 2 May 2007 17:03
Gravatar

Re: pagefault_enable & pagefault_disable

Ingo,

Looks like setting pagefault_enable and pagefault_disable as export GPL
only has broken those evil video modules.  So I guess until we can make
the daemons of NVidia and ATI into angels, we probably want to keep
those exports non-GPL. :-(

-- Steve

On Wed, 2007-05-02 at 11:59 +0200, Alessio Igor Bogani wrote:
> Hi,
> 
> What is the reason for declare pagefault_enable and pagefault_disable
> as only GPL symbols in mm/memory.c (obviously with Ingo's
> realtime patch applied)? 
> 
> I violate license if i change those two EXPORT_SYMBOL_GPL in EXPORT_SYMBOL?
> 
> Thanks in advance!

Tim Bird | 3 May 2007 21:16
Picon

Re: v2.6.21-rt1 - bug in asm-mips/atomic.h

Ingo Molnar wrote:
> i have released the v2.6.20-rt1 kernel...
Ingo,

There appears to be a bug in the patch for include/asm-mips/atomic.h
In the hunk for line 554, it has 2 #endifs.
I think it should only have one.

A portion of the patch reads:

Index: new-linux/include/asm-mips/atomic.h
===================================================================
--- new-linux.orig/include/asm-mips/atomic.h	2007-04-25 20:08:32.000000000 -0700
+++ new-linux/include/asm-mips/atomic.h	2007-04-26 16:15:14.000000000 -0700
 <at>  <at>  -545,7 +554,9  <at>  <at> 
 		: "=&r" (result), "=&r" (temp), "=m" (v->counter)
 		: "Ir" (i), "m" (v->counter)
 		: "memory");
-	} else {
+	}
+#if !defined(CONFIG_NO_SPINLOCK) && !defined(CONFIG_PREEMPT_RT)
+	else {
 		unsigned long flags;

 		raw_local_irq_save(flags);
 <at>  <at>  -554,6 +565,8  <at>  <at> 
 		v->counter = result;
 		raw_local_irq_restore(flags);
 	}
+#endif
(Continue reading)

Tim Bird | 3 May 2007 21:35
Picon

Re: v2.6.21-rt1 - mips compile bugs

Ingo Molnar wrote:
> i have released the v2.6.20-rt1 kernel...

There was also a problem with the patch for arch/mips/kernel/entry.S
Some kind of cruft was in the patch.

Below is a patch which fixes both issues.  It at least allows compilation.
I haven't turned anything on, or looked at runtime yet.

Index: alp-linux/arch/mips/kernel/entry.S
===================================================================
--- alp-linux.orig/arch/mips/kernel/entry.S	2007-05-03 12:28:38.000000000 -0700
+++ alp-linux/arch/mips/kernel/entry.S	2007-05-03 12:21:47.000000000 -0700
 <at>  <at>  -21,8 +21,6  <at>  <at> 
 #endif

 #ifndef CONFIG_PREEMPT
-<<<<<<< delete 	local_irq_disable
-	raw_local_irq_disable
 #define resume_kernel	restore_all
 #else
 #define __ret_from_irq	ret_from_exception
 <at>  <at>  -32,7 +30,7  <at>  <at> 
 	.align	5
 #ifndef CONFIG_PREEMPT
 FEXPORT(ret_from_exception)
-	local_irq_disable			# preempt stop
+	raw_local_irq_disable			# preempt stop
 	b	__ret_from_irq
 #endif
(Continue reading)

Alessio Igor Bogani | 7 May 2007 17:20
Picon

Geode GX1 + RT-Preempt + ACPI

Hi,

I have this same problem
(http://www.mail-archive.com/linux-rt-users <at> vger.kernel.org/msg00333.html).

Someone can give me some suggestions?

Ciao,
Alessio

Juergen Beisert | 7 May 2007 19:07
Picon
Favicon
Gravatar

Re: Geode GX1 + RT-Preempt + ACPI

On Monday 07 May 2007 17:20, Alessio Igor Bogani wrote:
> I have this same problem
> (http://www.mail-archive.com/linux-rt-users <at> vger.kernel.org/msg00333.html).
>
> Someone can give me some suggestions?

First of all, running a realtime OS on such a machine is no good idea, as it 
is full of system management software that steals you the CPU.

Try to run your kernel with "clocksource=pit" as this hardware has no usefull 
other timer with interrupt capability.

Hope it helps
Juergen

--

-- 
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
    Handelsregister: Amtsgericht Hildesheim, HRA 2686
         Vertretung Sued/Muenchen, Germany
   Phone: +49-5121-206917-7 |  Fax: +49-5121-206917-9
Peter Feuerer | 15 May 2007 13:26

Re: Geode GX1 + RT-Preempt + ACPI

Hi Juergen,

On Mon, 2007-05-07 at 19:07 +0200, Juergen Beisert wrote:
> On Monday 07 May 2007 17:20, Alessio Igor Bogani wrote:
> > I have this same problem
> > (http://www.mail-archive.com/linux-rt-users <at> vger.kernel.org/msg00333.html).
> >
> > Someone can give me some suggestions?
> 
> First of all, running a realtime OS on such a machine is no good idea, as it 
> is full of system management software that steals you the CPU.

What do you mean by "system management software"? The only software
running on my gx1 hardware is my linux system with kernel 2.6.18 using
rt preempt patch and compiled for x86.

> Try to run your kernel with "clocksource=pit" as this hardware has no usefull 
> other timer with interrupt capability.

I tried this for rt-preempt patched kernels > 2.6.18 (where acpi is
needed for the highres timer) but still no hard realtime capability.

--peter

Alessio Igor Bogani | 15 May 2007 13:32
Picon

Re: Geode GX1 + RT-Preempt + ACPI

Hi Peter,

On Tue, 2007-05-15 at 13:26 +0200, Peter Feuerer wrote:
[...]
> > First of all, running a realtime OS on such a machine is no good idea, as it 
> > is full of system management software that steals you the CPU.
> 
> What do you mean by "system management software"? The only software
> running on my gx1 hardware is my linux system with kernel 2.6.18 using
> rt preempt patch and compiled for x86.

This type of software is implemented into BIOS.

[...]
> I tried this for rt-preempt patched kernels > 2.6.18 (where acpi is
> needed for the highres timer) but still no hard realtime capability.

I'm trying 2.6.21-rt1 and it _seems_ works (not tested yet).

Ciao,
Alessio


Gmane