[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1201399193.18590.11.camel@cmn3.stanford.edu>
Date: Sat, 26 Jan 2008 17:59:53 -0800
From: Fernando Lopez-Lezcano <nando@...ma.Stanford.EDU>
To: Ingo Molnar <mingo@...e.hu>
Cc: nando@...ma.Stanford.EDU, linux-kernel@...r.kernel.org,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>, Len Brown <lenb@...nel.org>,
Venki Pallipadi <venkatesh.pallipadi@...el.com>,
Dave Jones <davej@...hat.com>
Subject: Re: 2.6.24-rt1: timing problems (was [git pull] x86/hrtimer/acpi
fixes)
On Sat, 2007-12-08 at 10:17 +0100, Ingo Molnar wrote:
> * Fernando Lopez-Lezcano <nando@...ma.Stanford.EDU> wrote:
>
> > On Fri, 2007-12-07 at 20:59 +0100, Ingo Molnar wrote:
> > > * Fernando Lopez-Lezcano <nando@...ma.Stanford.EDU> wrote:
> > >
> > > > > Nope, it doesn't still getting "delay" and "xrun" messages galore.
> > > >
> > > > Attached: configuration and dmesg output booting with idle=poll,
> > > > reconfirmed that that makes the delay and xrun messages go away.
> > >
> > > could you try the rolled up patch of various fixlets, ontop of
> > > current -git? (it might even apply to -rc4) It includes some more
> > > stuff beyond the ones in the pull request. (still being
> > > tested/reviewed)
> >
> > I'll try but it will take me a while to figure git and do a package
> > build of it...
>
> if you want to try a vanilla kernel package then pick up the kernel
> package from Fedora rawhide - this fixlet should show up there within a
> couple of days, Dave Jones is doing a 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 xruns which means
that somehow the timing is delayed more than what jack would think
reasonable. As in the case with an old timing bug, the problem
dissapears when booting the kernel with idle=poll. Other users of Planet
CCRMA are able to replicate the behavior, which goes away with idle=poll
or booting the machine with only one core. As a workaround I have been
packaging 2.6.22.x but now I'm not able to use that as the old rt14
patch, suitably tweaked results in a non working kernel.
So it looks like, again, timing is getting skewed when the jack process
jumps between cpus and thus jack sees timing jumps that are just not
happenning.
This is with a build based on 2.6.24 using as a base the latest Fedora
rawhide source package plus 2.6.24-rt1.
-- Fernando
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists