Florian Schmidt wrote:
> On Mon, 11 Oct 2004 06:52:50 -0700
> Mark Knecht <markknecht@xxxxxxxxx> wrote:
>
>
>>On Sun, 10 Oct 2004 19:56:35 -0600, thewade <pdman@xxxxxxxxxxxxxxxx> wrote:
>>
>>>As Lee Revell has pointed out, there are bugs with
>>>voluntary-preempt-2.6.9-rc3-mm2-S9 as I have posted them on this list.
>>
>>You - 2.6.9-rc3-mm2-S9 (some problems?)
>>Me - 2.6.9-rc2-mm4-S7 (good on laptop for 3-4 days now)
>>Me - Planetedge on desktop (HDSP driver won't allow -p less than 64)
>>Lee - 2.6.9-xxx-xxx-T3 (seems happy)
>>Florian - X.X.X-xxx-xxx-T3 (problems)
>>Florian - X.X.X-xxx.xxx-T1 (stable)
>>
>>Nobody is really testing the same thing. (Much less the same code with
>>different compile time options...) Different machines, different
>>chipsets. Probably different sample rates, diffeent sound cards,
>>different p and n settings. I think results are hard to compare.
>
>
> This is the _current_ state of affairs. Of course Lee, me and others have
> tested other versions of the VP kernels, too. I'd suggest reading through
> the relevant lkml threads to see if someone reported problems with each
> particular version.
>
> One interesting thing i observed was that ingo decided to put VP ontop of mm
> when it started to get really useful. But of course mm kernels themselfes
> are experimental kernels, so when testing a newer VP kernel one actually is
> kind of involuntarily used as a tester for experimental mm features, making
> it even harder to suggest a "stable" VP kernel to anyone. Especially since
> mm kernels often seem to be really really b0rk3n. Dunno if it's ever gonna
> change again. Lee, you got more details on plans of getting VP into vanilla?
>
> flo
>
>
Florian,
Sure. I understand the basic picture. I don't see any of these
kernels as 'stable' but rather a way to address issues we run into at
given times.
I guess that without really saying it, and understanding that audio
does not drive every single requirement on this set of machines, it
makes me wonder if we wouldn't be better off as a group to have a
current 'LAU testing configuration' for the group of us that wants and
needs this stuff? If we all tested the same kernel and the same patches,
wouldn't our inputs back to lkml be possibly more relavant?
For instance, someone paying attention to lkml would post a specific
configuration via an LAU web page every so often. (1/week? 1/month?
etc...) We as a group would build it ourselves and then report back
results here. One of us would collect together the results (if required)
and report back.
I'm just sensing that everyone doing their own thing makes it harder
to know why things happen.
- Mark
