Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-R0

[Lee Revell <rlrevell@joe-job.com>]

On Fri, 2004-09-03 at 03:50, Free Ekanayaka wrote:
>   LR> As far as I am concerned the VP patches are stable enough for the
>   LR> audio-centric distros to start distributing VP kernel packages, these
>   LR> will certainly be using the vanilla kernel.  I think the PlanetCCRMA and
>   LR> AGNULA people are planning to start distributing test VP-kernel packages
>   LR> as soon as the patches stabilize.  IIRC Nando is on vacation this week.
> 
>   LR> I will make an announcement on LAD that as of R0 the VP patches should
>   LR> be stable and are ready for wider testing.  You may want to wait until
>   LR> after the initial slew of bug reports before rebasing VP against MM.  I
>   LR> suspect most of the problems with be driver specific, and most of the
>   LR> fixes will apply equally to -mm and vanilla.
> 
>   LR> I have added Luke (AudioSlack), Free (AGNULA), and Nando (CCRMA) to the
>   LR> cc: list.  They would be in the best position to answer your question.
> 
> Yes, you're right. We plan to  provide test 2.6.x  packages as soon as
> patches stabilise. Please let me  know if you have some recommendation
> (configuration flags, additional patches, etc.).
> 

As of -R0 it's definitely stable on UP and SMP users are reporting the
same.  All known problems should be fixed, and there are no known
regressions.  You should probably post a UP version and have your users
test that before posting SMP packages, the latter are not quite as well
tested.

No other patches (ie various scheduler tweaks, CK) should be necessary,
and in fact are not recommended because they might mask latency issues
that we would rather fix.

I use Debian unstable which should be pretty close to AGNULA, and for
several weeks now I have been unable to produce an xrun in jack at 32
frames no matter what I throw at the machine.  I actually have not had
xrun debugging enabled in weeks because I don't get any xruns.

Any problems at this point are most likely going to involve less common
hardware, stuff the LKML testers don't have.

Lee