[ BUG: circular locking deadlock detected! ]
udev_run_hotplu/720 is deadlocking current task modprobe/690
1) modprobe/690 is trying to acquire this lock:
[f7019558] {&info->lock}
.. ->owner: f6e52032
.. hel
Hello,
On an ARM XSCALE running on a gumstix platform I get the following BUG report
at startup
after applying the -rt8 patches.
BUG: at kernel/sched.c:4031 __schedule()
[] (dump_stack+0x0/0x24) from [] (__schedule+0x714/0x764)
[] (__schedule+0x0/0x764) from [] (schedule+0xcc/0x114)
[] (schedul
On Mon, 2007-04-23 at 10:03 +0200, John Sigler wrote:
> > Can you create an entry in the rt-wiki, so people can find your
> > patches ?
>
> Sure.
>
> Should I add a link to my patch on the "CONFIG PREEMPT RT Patch" page?
> http://rt.wiki.kernel.org/index.php/CONFIG_PREEMPT_RT_Patch#Download
>
>
Thomas Gleixner wrote:
On Fri, 2007-04-20 at 15:15 +0200, John Sigler wrote:
I've tweaked patch-2.6.20-rt8(*) so that it applies to 2.6.20.7
(*) http://rt.wiki.kernel.org/index.php/Main_Page
The original patch can be found here:
http://people.redhat.com/mingo/realtime-preempt/older/
John,
On Fri, 2007-04-20 at 15:15 +0200, John Sigler wrote:
> I've tweaked patch-2.6.20-rt8(*) so that it applies to 2.6.20.7
> (*) http://rt.wiki.kernel.org/index.php/Main_Page
>
> The original patch can be found here:
> http://people.redhat.com/mingo/realtime-preempt/ol
Hello,
I've tweaked patch-2.6.20-rt8(*) so that it applies to 2.6.20.7
(*) http://rt.wiki.kernel.org/index.php/Main_Page
The original patch can be found here:
http://people.redhat.com/mingo/realtime-preempt/older/patch-2.6.20-rt8
http://linux.kernel.free.fr/patch-2.6.20-rt8
diff t
Ingo Molnar wrote:
John wrote:
Great! Can you tell me how you generate the original -rt patch, so I
can provide an updated version when a new 2.6.20 kernel is released?
they should be generated the way you did: apply the 2.6.20 baseline -rt
kernel patch to the later patches and fix up rejec
ine -rt
kernel patch to the later patches and fix up rejects. For later kernels
just do the same.
> If I understand correctly, removing that specific patch from
> patch-2.6.20-rt8 is the appropriate course of action then?
yes.
Ingo
-
To unsubscribe from this list: send the lin
so no need to do any change there.
If I understand correctly, removing that specific patch from
patch-2.6.20-rt8 is the appropriate course of action then?
Regards.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
* John <[EMAIL PROTECTED]> wrote:
> I'd be happy to generate a clean patch!
> (Would you agree to host it in your directory?)
> http://people.redhat.com/mingo/realtime-preempt/older/
sure, i can put it there.
> 3. linux/kernel/futex.c
> [ I'm not sure I've made the appropriate changes here ]
>
Ingo Molnar wrote:
John wrote:
I've tweaked patch-2.6.20-rt8 so that it applies to 2.6.20.5
The unified diff is attached to this message.
thanks - this is useful to those who are not that much on the bleeding
edge.
I'd be happy to hear comments on what I've done wrong.
* John <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I've tweaked patch-2.6.20-rt8 so that it applies to 2.6.20.5
>
> The unified diff is attached to this message.
thanks - this is useful to those who are not that much on the bleeding
edge.
> I'd be happy to hea
Hello,
I've tweaked patch-2.6.20-rt8 so that it applies to 2.6.20.5
The unified diff is attached to this message.
I'd be happy to hear comments on what I've done wrong.
78 hunks had to be offset and 3 hunks had to be fuzzed.
$ grep -B1 fuzz patch.log
patching file arch/ia64/k
John wrote:
I've tweaked patch-2.6.20-rt8 so that it applies to 2.6.20.3
The unified diff is attached to this message.
I'd be happy to hear comments on what I've done wrong!
Would anybody care to comment on the patch? :-)
I made 4 simple edits.
linux/Makefile
Hi,
At Fri, 16 Mar 2007 22:20:27 +0300,
Sergei Shtylyov wrote:
> Argh, I've missed this one! :-(
> But shouldn't we also add !need_resched_delayed() to another place below?
>
> if (ppc_md.power_save) {
> [...]
> if (!need_resched() && !cpu_should_die())
Thanks for pointing it o
Hello.
Tsutomu OWA wrote:
To add preemption checks for the NEED_RESCHED_DELAYED flag.
diff -rup linux-rt8/arch/powerpc/kernel/idle.c rt/arch/powerpc/kernel/idle.c
--- linux-rt8/arch/powerpc/kernel/idle.c2007-02-20 14:30:38.0
+0900
+++ rt/arch/powerpc/kernel/idle.c 200
Hello,
I've tweaked patch-2.6.20-rt8 so that it applies to 2.6.20.3
The unified diff is attached to this message.
I'd be happy to hear comments on what I've done wrong!
Regards.
--- patch-2.6.20-rt82007-02-16 10:48:03.0 +0100
+++ patch-2.6.20.3-rt8 2007-03-14 18:
On Thu, Mar 08, 2007 at 02:26:47PM +1100, Paul Mackerras wrote:
> Bill Huey (hui) writes:
>
> > The places that need to be reverted to raw spinlocks are generally either
> > acquired by function calls that allocate the spinlock at a terminal of the
> > kernel's lock graph or isolated from other ca
Bill Huey (hui) writes:
> The places that need to be reverted to raw spinlocks are generally either
> acquired by function calls that allocate the spinlock at a terminal of the
> kernel's lock graph or isolated from other callers completely (parts of the
> timer for logic for instance). It's all a
At Wed, 07 Mar 2007 17:26:50 +0300,
Sergei Shtylyov wrote:
>
> Tsutomu OWA wrote:
> > CONFIG_MCOUNT, CONFIG_LATENCY_TRACE and other tracing options nor
> > CONFIG_GENERIC_TIME,
>
> There is PowerPC genTOD patch and it's incorporated into -rt (don't know
> it works for Cell) but it breaks
On Thu, Mar 08, 2007 at 08:30:43AM +1100, Paul Mackerras wrote:
> Sergei Shtylyov writes:
>
> > I've floowed up to my patch with such explanation. In the context of
> > an-rt
> > patch itself, it was just too clear, hence I didn't go into explanations in
> > the patch itself. :-)
>
> Well,
Sergei Shtylyov writes:
> I've floowed up to my patch with such explanation. In the context of
> an-rt
> patch itself, it was just too clear, hence I didn't go into explanations in
> the patch itself. :-)
Well, it might be clear, to you, now, with the context in your head.
But if such a pa
Hello.
Tsutomu OWA wrote:
To fix the following boot time error by removing ack member added by
the rt patch.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processor 1 found.
Brought up 2 CPUs
[ cut here ]
kernel BUG at arch/powerpc/platforms
Hello.
Paul Mackerras wrote:
As I said, this was intended for the -rt patch, hence the question was for
Ingo. I CC'ed the list just to keep people here in a loop.
OK, fair enough, but I still think the patch description was
inadequate. In the -rt context, I would at least expect to see s
Sergei Shtylyov writes:
> As I said, this was intended for the -rt patch, hence the question was
> for
> Ingo. I CC'ed the list just to keep people here in a loop.
OK, fair enough, but I still think the patch description was
inadequate. In the -rt context, I would at least expect to see so
Hello.
Paul Mackerras wrote:
I've already sent a patch fixing this one (along with many others) a month
ago:
http://ozlabs.org/pipermail/linuxppc-dev/2007-February/031164.html
I wonder iof it was ever considered... :-/
The entire patch description was just this:
Convert the sp
Sergei Shtylyov writes:
> I've already sent a patch fixing this one (along with many others) a
> month
> ago:
>
> http://ozlabs.org/pipermail/linuxppc-dev/2007-February/031164.html
>
> I wonder iof it was ever considered... :-/
The entire patch description was just this:
> Convert th
Hello.
Benjamin Herrenschmidt wrote:
--- linux-rt8/arch/powerpc/kernel/irq.c 2007-02-20 14:30:38.0 +0900
+++ rt/arch/powerpc/kernel/irq.c2007-03-05 18:54:34.0 +0900
@@ -392,7 +392,7 @@ EXPORT_SYMBOL(do_softirq);
#ifdef CONFIG_PPC_MERGE
static LIST_HEAD(irq_hosts);
-stat
On Wed, 2007-03-07 at 17:38 +0300, Sergei Shtylyov wrote:
> Hello.
>
> Tsutomu OWA wrote:
>
> > --- linux-rt8/arch/powerpc/kernel/irq.c 2007-02-20 14:30:38.0
> > +0900
> > +++ rt/arch/powerpc/kernel/irq.c2007-03-05 18:54:34.0 +0900
> > @@ -392,7 +392,7 @@ EXPORT_SYMBOL(do
Hello.
Tsutomu OWA wrote:
--- linux-rt8/arch/powerpc/kernel/irq.c 2007-02-20 14:30:38.0 +0900
+++ rt/arch/powerpc/kernel/irq.c2007-03-05 18:54:34.0 +0900
@@ -392,7 +392,7 @@ EXPORT_SYMBOL(do_softirq);
#ifdef CONFIG_PPC_MERGE
static LIST_HEAD(irq_hosts);
-static spin
Tsutomu OWA wrote:
Hi Ingo,
Please consider for inclusion in your rt tree.
This series of patches fixes boot and runntime errors/warnings for
powerpc (esp. 64 bit). This applies to linux-2.6.20, patch-2.6.20-rt8
and previous my patch set;
http://ozlabs.org/pipermail/linuxppc-dev
On Wednesday 07 March 2007, Ingo Molnar wrote:
> i'm not an xmon expert, but maybe it might make more sense to first
> disable preemption, then interrupts - otherwise you could be preempted
> right after having disabled these interrupts (and be scheduled to
> another CPU, etc.). What is the diff
At Wed, 07 Mar 2007 11:10:59 +0100,
Benjamin Herrenschmidt wrote:
>
> On Wed, 2007-03-07 at 10:16 +0100, Ingo Molnar wrote:
> > * Tsutomu OWA <[EMAIL PROTECTED]> wrote:
> >
> > > @@ -342,6 +342,7 @@ static int xmon_core(struct pt_regs *reg
> > >
> > > msr = mfmsr();
> > > mtmsr(msr & ~MSR_
On Wed, 2007-03-07 at 10:16 +0100, Ingo Molnar wrote:
> * Tsutomu OWA <[EMAIL PROTECTED]> wrote:
>
> > @@ -342,6 +342,7 @@ static int xmon_core(struct pt_regs *reg
> >
> > msr = mfmsr();
> > mtmsr(msr & ~MSR_EE); /* disable interrupts */
> > + preempt_disable();
>
> i'm not an xmon
* Tsutomu OWA <[EMAIL PROTECTED]> wrote:
> @@ -342,6 +342,7 @@ static int xmon_core(struct pt_regs *reg
>
> msr = mfmsr();
> mtmsr(msr & ~MSR_EE); /* disable interrupts */
> + preempt_disable();
i'm not an xmon expert, but maybe it might make more sense to first
disable pree
* Tsutomu OWA <[EMAIL PROTECTED]> wrote:
>
> Hi Ingo,
>
> Please consider for inclusion in your rt tree.
>
> This series of patches fixes boot and runntime errors/warnings for
> powerpc (esp. 64 bit). This applies to linux-2.6.20, patch-2.6.20-rt8
> and p
* Tsutomu OWA <[EMAIL PROTECTED]> wrote:
>
> Hi Ingo,
>
> Please apply.
>
> This series of patches fixes build breakage on arch/powerpc with
> realtime preempt patch. This applies on top of linux-2.6.20 and
> patch-2.6.20-rt8.
thanks, applied - these fixe
To fix the following boot time warnings by setting soft_enabled and
hard_enabled.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Freeing unused kernel memory: 248k freed
BUG: scheduling with irqs disabled: rc.sysinit/0x/373
caller is user_work+0x14/0x2c
Call Tr
To fix the following boot time error by removing ack member added by
the rt patch.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processor 1 found.
Brought up 2 CPUs
[ cut here ]
kernel BUG at arch/powerpc/platforms/cell/interrupt.c:86!
pu 0x1:
To fix the following runtime warnings when entering xmon.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Entering xmon
BUG: using smp_processor_id() in preemptible [] code: khvcd/280
caller is .xmon_core+0xb8/0x8ec
Call Trace:
[CFD737C0] [C000FA
To fix the following runtime warning.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
BUG: using smp_processor_id() in preemptible [] code: init/371
caller is .pgtable_free_tlb+0x2c/0x14c
Call Trace:
[CFF6B770] [C000FAAC] .show_stack+0x68/0x1b0 (
To convert the spinlocks into the raw onces to fix the following
warnings/errors.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Badness at arch/powerpc/kernel/entry_64.S:651
Call Trace:
[C06133E0] [C000FAAC] show_stack+0x68/0x1b0 (unreliable)
[C00
To add preemption checks for the NEED_RESCHED_DELAYED flag.
Signed-off-by: Tsutomu Owa <[EMAIL PROTECTED]>
-- owa
diff -rup linux-rt8/include/asm-powerpc/thread_info.h
rt/include/asm-powerpc/thread_info.h
--- linux-rt8/include/asm-powerpc/thread_info.h 2007-02-20 14:30:40.0
+0900
+++
Hi Ingo,
Please consider for inclusion in your rt tree.
This series of patches fixes boot and runntime errors/warnings for
powerpc (esp. 64 bit). This applies to linux-2.6.20, patch-2.6.20-rt8
and previous my patch set;
http://ozlabs.org/pipermail/linuxppc-dev/2007-March/032640.html
Hi Ingo,
Please apply.
This series of patches fixes build breakage on arch/powerpc with realtime
preempt patch. This applies on top of linux-2.6.20 and patch-2.6.20-rt8.
Although there has been some efforts to port realtime-preempt patch to
powerpc, build breakage still exists for
To fix the following compile error by adding necessary macro definitions
(mostly taken from asm-generic/percpu.h).
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
include/asm-powerpc/percpu.h
In file included from include/asm/tlb.h:52,
from arch
To fix the following compile error by changing local_irq_restore()
to raw_local_irq_restore().
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
include/asm-powerpc/hw_irq.h
In file included from include/asm/system.h:9,
from include/linux/list.h:9
To fix the following compile error by adding dummy functions for now.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
include/asm-powerpc/futex.h
kernel/built-in.o: In function `fixup_pi_state_owner64':
kernel/futex.c:2380: undefined reference to `.futex_atomic_cm
To fix the following compile error by changing names from
__{read,write}_trylock to ___raw_{read,write}_trylock in asm-powerpc/spinlock.h
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
include/asm-powerpc/spinlock.h
include/linux/spinlock_api_smp.h:49: error: c
To fix the following compile error.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
kernel/irq/manage.c: In function 'irq_set_affinity':
kernel/irq/manage.c:81: error: invalid type argument of '->'
kernel/irq/manage.c:82: error: invalid type argument of '->'
- - -
To fix the following compile error by replacing the deleted structure
member "is_continuous" with "flags".
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
arch/powerpc/kernel/time.c
arch/powerpc/kernel/time.c:938: error: unknown field 'is_continuous' specified
in
To fix the following compile error by enclosing it in ifndef
__ASSEMBLY__/endif.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
include/asm-generic/bug.h
include/asm-generic/bug.h: Assembler messages:
include/asm-generic/bug.h:7: Error: Unrecognized opcode: `e
David Miller wrote:
From: "Paul E. McKenney" <[EMAIL PROTECTED]>
Date: Sun, 25 Feb 2007 17:52:30 -0800
Why doesn't the traditional hash table of locks work here? Use the
cache-line address as input to the hash function, take the corresponding
lock, do the compare-and-exchange by hand, and the
From: "Paul E. McKenney" <[EMAIL PROTECTED]>
Date: Sun, 25 Feb 2007 17:52:30 -0800
> Why doesn't the traditional hash table of locks work here? Use the
> cache-line address as input to the hash function, take the corresponding
> lock, do the compare-and-exchange by hand, and then release the lock
On Sat, Feb 24, 2007 at 10:37:44PM -0800, David Miller wrote:
> From: Ingo Molnar <[EMAIL PROTECTED]>
> Date: Sun, 25 Feb 2007 07:27:47 +0100
>
> >
> > * Paul E. McKenney <[EMAIL PROTECTED]> wrote:
> >
> > > I got the following running stock
On Sun, Feb 25, 2007 at 07:27:47AM +0100, Ingo Molnar wrote:
>
> * Paul E. McKenney <[EMAIL PROTECTED]> wrote:
>
> > I got the following running stock 2.6.20-rt8 on an 4-CPU 1.8GHz
> > Opteron box. The machine continued to run a few rounds of kernbench
> >
From: Ingo Molnar <[EMAIL PROTECTED]>
Date: Sun, 25 Feb 2007 07:27:47 +0100
>
> * Paul E. McKenney <[EMAIL PROTECTED]> wrote:
>
> > I got the following running stock 2.6.20-rt8 on an 4-CPU 1.8GHz
> > Opteron box. The machine continued to run a few rounds of ke
* Paul E. McKenney <[EMAIL PROTECTED]> wrote:
> I got the following running stock 2.6.20-rt8 on an 4-CPU 1.8GHz
> Opteron box. The machine continued to run a few rounds of kernbench
> and LTP. Looks a bit scary -- a tasklet was "stolen" from
> __tasklet_acti
On Sat, Feb 24, 2007 at 09:02:12PM -0800, Paul E. McKenney wrote:
> Hello!
>
> I got the following running stock 2.6.20-rt8 on an 4-CPU 1.8GHz Opteron
> box. The machine continued to run a few rounds of kernbench and LTP.
> Looks a bit scary -- a tasklet was "stolen&qu
Hello!
I got the following running stock 2.6.20-rt8 on an 4-CPU 1.8GHz Opteron
box. The machine continued to run a few rounds of kernbench and LTP.
Looks a bit scary -- a tasklet was "stolen" from __tasklet_action().
Thoughts? In the meantime, kicking it off again to see if
Hi Ingo,
Test scenario:
- normal boot
- echo shutdown > /sys/power/disk; echo disk > /sys/power/state
- echo platform > /sys/power/disk; echo disk > /sys/power/state
==
[ INFO: hard-safe -> hard-unsafe lock order detected ]
61 matches
Mail list logo
