On Thu, 21 Feb 2008, Mark Hounschell wrote:
> >
> > To prove this is the problem, boot with noapic in the kernel command line.
> > 1) the problem should disappear.
> > 2) (I'm betting) you see that the eth and EMU10K1 share the same
> >interrupt line.
> >
>
> Yep, you were right. They do share
Steven Rostedt wrote:
> [CC'd Thomas and Jon]
>
> Thomas, Jon, looks like the someone has the funny interrupt controller.
>
> On Thu, 21 Feb 2008, Mark Hounschell wrote:
>
>> According to /proc/interrupts, every interrupt received by eth1 is also
>> being received by the sound card EMU10K1. The
[CC'd Thomas and Jon]
Thomas, Jon, looks like the someone has the funny interrupt controller.
On Thu, 21 Feb 2008, Mark Hounschell wrote:
> According to /proc/interrupts, every interrupt received by eth1 is also
> being received by the sound card EMU10K1. The problem showed itself
> first with t
According to /proc/interrupts, every interrupt received by eth1 is also
being received by the sound card EMU10K1. The problem showed itself
first with this. The sound system was quiet BTW.
It does not happen with 2.6.24 vanilla.
kernel: irq 19: nobody cared (try booting with the "irqpoll" option)
On Wed, 13 Feb 2008, Kevin Hilman wrote:
> The smc_special_locks should also be used when either softIRQs or hard
> IRQs are preempted which may lead to the same problems as under SMP.
>
> Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]>
Acked-by: Nicolas Pitre <[EMAIL PROTECTED]>
>
> ---
> dr
On Thu, 14 Feb 2008, Shi Weihua wrote:
> Fix the following compile warning without CONFIG_PREEMPT_RT:
> kernel/timer.c:937: warning: ‘count_active_rt_tasks’ defined but not used
>
> Signed-off-by: Shi Weihua <[EMAIL PROTECTED]>
Thanks, applied.
-- Steve
--
To unsubscribe from this list: send
Fix the following compile warning without CONFIG_PREEMPT_RT:
kernel/timer.c:937: warning: ‘count_active_rt_tasks’ defined but not used
Signed-off-by: Shi Weihua <[EMAIL PROTECTED]>
---
diff -urpN linux-2.6.24-rt1.orig/kernel/timer.c linux-2.6.24-rt1/kernel/timer.c
--- linux-2.6.24-rt
The smc_special_locks should also be used when either softIRQs or hard
IRQs are preempted which may lead to the same problems as under SMP.
Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]>
---
drivers/net/smc91x.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/
>>> On Tue, Feb 5, 2008 at 4:58 PM, in message
<[EMAIL PROTECTED]>, Daniel Walker
<[EMAIL PROTECTED]> wrote:
> On Tue, Feb 05, 2008 at 11:25:18AM -0700, Gregory Haskins wrote:
>> @@ -6241,7 +6242,7 @@ static void rq_attach_root(struct rq *rq, struct
> root_domain *rd)
>> cpu_clea
On Tue, Feb 05, 2008 at 11:25:18AM -0700, Gregory Haskins wrote:
> @@ -6241,7 +6242,7 @@ static void rq_attach_root(struct rq *rq, struct
> root_domain *rd)
> cpu_clear(rq->cpu, old_rd->online);
>
> if (atomic_dec_and_test(&old_rd->refcount))
> -
>>> On Tue, Feb 5, 2008 at 11:59 AM, in message
<[EMAIL PROTECTED]>, Daniel Walker
<[EMAIL PROTECTED]> wrote:
>
> I looked at the code a bit, and I'm not sure you need this complexity..
> Once you have replace the old_rq, there is no reason it needs to
> protection of the run queue spinlock .. S
>>> On Tue, Feb 5, 2008 at 11:59 AM, in message
<[EMAIL PROTECTED]>, Daniel Walker
<[EMAIL PROTECTED]> wrote:
> On Mon, Feb 04, 2008 at 10:02:12PM -0700, Gregory Haskins wrote:
>> >>> On Mon, Feb 4, 2008 at 9:51 PM, in message
>> <[EMAIL PROTECTED]>, Daniel Walker
>> <[EMAIL PROTECTED]> wrote:
>
On Mon, Feb 04, 2008 at 10:02:12PM -0700, Gregory Haskins wrote:
> >>> On Mon, Feb 4, 2008 at 9:51 PM, in message
> <[EMAIL PROTECTED]>, Daniel Walker
> <[EMAIL PROTECTED]> wrote:
> > I get the following when I tried it,
> >
> > BUG: sleeping function called from invalid context bash(5126) at
>
a
rt_mutex, so I turned on lockdep and it found:
===
[ INFO: possible circular locking dependency detected ]
[ 2.6.24-rt1-rt #3
---
bash/4604 is trying to acquire lock:
(events){--..}, at: [] cleanup_workqueue_thread+0x16/0x80
but
>>> On Mon, Feb 4, 2008 at 9:51 PM, in message
<[EMAIL PROTECTED]>, Daniel Walker
<[EMAIL PROTECTED]> wrote:
> I get the following when I tried it,
>
> BUG: sleeping function called from invalid context bash(5126) at
> kernel/rtmutex.c:638
> in_atomic():1 [0001], irqs_disabled():1
Hi Daniel
Daniel Walker wrote:
> On Mon, Feb 04, 2008 at 03:35:13PM -0800, Max Krasnyanskiy wrote:
>> This is just an FYI. As part of the "Isolated CPU extensions" thread Daniel
>> suggest for me
>> to check out latest RT kernels. So I did or at least tried to and
>> immediately spotted a couple
>> of is
>> Thread IRQ-23 is on CPU1 ...
>
> I get the following when I tried it,
>
> BUG: sleeping function called from invalid context bash(5126) at
> kernel/rtmutex.c:638
> in_atomic():1 [0001], irqs_disabled():1
> Pid: 5126, comm: bash Not tainted 2.6.24-rt1 #1
>
mething like:
> CPU1 is now off-line
> Thread IRQ-23 is on CPU1 ...
I get the following when I tried it,
BUG: sleeping function called from invalid context bash(5126) at
kernel/rtmutex.c:638
in_atomic():1 [0001], irqs_disabled():1
Pid: 5126, comm: bash Not tainted 2.6.24-rt1
This is just an FYI. As part of the "Isolated CPU extensions" thread Daniel
suggest for me
to check out latest RT kernels. So I did or at least tried to and immediately
spotted a couple
of issues.
The machine I'm running it on is:
HP xw9300, Dual Opteron, NUMA
It looks like with -rt ke
ley kernel: BUG: using smp_processor_id() in
preemptible [] code: IRQ-16/533
Feb 2 06:51:08 harley kernel: caller is dxb_lock_poller+0x40/0x57 [dgdm]
Feb 2 06:51:08 harley kernel: Pid: 533, comm: IRQ-16 Not tainted
2.6.24-rt1 #1
Feb 2 06:51:08 harley kernel: []
debug_smp_processor_id+0xa
gt;
> > > 2.6.23.x + rt has not been very usable for audio applications.
> > > 2.6.24-rt1: same so far.
> > >
> > > Why: Jack keeps printing "delayed..." messages and has xruns which means
> > > that somehow the timing is delayed mor
On Sun, 2008-01-27 at 05:46 +0100, Mike Galbraith wrote:
> On Sat, 2008-01-26 at 17:59 -0800, Fernando Lopez-Lezcano wrote:
>
> > Hi Ingo... back to testing.
> > History:
> >
> > 2.6.23.x + rt has not been very usable for audio applications.
> > 2.6.24-r
On Sat, 2008-01-26 at 17:59 -0800, Fernando Lopez-Lezcano wrote:
> Hi Ingo... back to testing.
> History:
>
> 2.6.23.x + rt has not been very usable for audio applications.
> 2.6.24-rt1: same so far.
>
> Why: Jack keeps printing "delayed..." messages and has x
really nice job of keeping up with
> latest -git. (and the Fedora kernel has hrtimers and dynticks enabled.)
Hi Ingo... back to testing.
History:
2.6.23.x + rt has not been very usable for audio applications.
2.6.24-rt1: same so far.
Why: Jack keeps printing "delayed..." messages and has xr
On Fri, 25 Jan 2008, Steven Rostedt wrote:
>
> *** NOTICE ***
>
> This still has the old version of the latency tracer. I'll try to
> release a -rt2 soon that has the new version. This way we can see what
> kind of regressions the new version might give.
>
This is taking longer than expected. Rem
We are pleased to announce the 2.6.24-rt1 tree, which can be
downloaded from the location:
http://rt.et.redhat.com/download/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
Changes since 2.6.24-rc8-rt1
- ported to 2.6.24
to build a 2.6.24-rt1
26 matches
Mail list logo
