lkml.org 
[lkml]   [2004]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1

* Florian Schmidt <mista.tapas@gmx.net> wrote:

> > i have released the -U1 PREEMPT_REALTIME patch:
> >
> > http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U1
>
> Ok,
>
> with the help of Paul Davis i think i have found what's causing the jackd
> FP exception. It seems to be a bug in the kernel when PREEMPT_REALTIME is
> enabled:
>
> ~$ cat /proc/cpuinfo|grep cpu
> cpu family : 6
> cpu MHz : 0.001
> cpuid level : 1
>
> Mhz == 0.001? Hrmm. No wonder jackd was freaking out in its timing code..
> The real cpu speed is 1.2ghz.
>
> flo
>
> P.S.: Will retry with U3, to see if this persists.

ah ... good eyes. Seems to be working fine here:

saturn:~> cat /proc/cpuinfo | grep -i mhz
cpu MHz : 2051.126
saturn:~> uname -a
Linux saturn 2.6.9-rc4-mm1-VP-U4 #288 SMP Fri Oct 15 12:31:38 CEST 2004

but it could easily be happening on some CPUs only. Let me know if that
problem persists. Fortunately i think it will be at most a detection
problem, not some FPU breakage that i initially suspected.

it could be the following thing: if you got an smp_processor_id()
warning _in the CPU detection code_ in earlier PREEMPT_REALTIME kernels
then the kernel could easily see that the CPU is extremely slow, because
it didnt manage to do much work (due to the long printout...). So i'd
say if this happens again it's most likely a debug printout in the
'calibrating delay loop' phase.

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:07    [W:0.664 / U:2.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site