Raymond Lai <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> I remember there's a kernel pcmcia bug preventing the development for
> the Audigy2 pcmcia notebook sound card driver.
>
> See
> http://www.alsa-project.org/alsa-doc/index.php?vendor=vendor-Creative_Labs#matrix
>
> Is there any new update
Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
>
> if you're scared that there are too many cond_resched (I'm not scared
> and people should enable them anyways if they make a difference, they
> still should be less than the number of spin_unlocks with preempt
> enabled), then you should add a con
Lee Revell <[EMAIL PROTECTED]> wrote:
>
> discovered I can reliably produce a large XRUN by toggling Caps Lock,
> Scroll Lock, or Num Lock. This is with 2.6.8-rc1-mm1 + voluntary
> preempt
That's odd. I wonder if the hardware is sick. What is the duration is the
underrun? The info you sent d
Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
>
> I'm missing where cond_resched is needed inside lock_kernel though,
Anywhere where we do lots of work inside lock_kernel(). Various ioctls and
ext3 journal recovery are instances.
Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
>
> > And it's currently OK to add a might_sleep() to (say) an inline path which
> > is expended a zillion times because we know it'll go away for production
> > builds. If those things become cond_resched() calls instead, the code
> > increase will be p
Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
>
> What I'm doing is basically to replace all might_sleep with cond_resched
I cannot see a lot of point in that. They are semantically different
things and should look different in the source.
And it's currently OK to add a might_sleep() to (say) an i
Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
>
> On Tue, Jul 13, 2004 at 03:25:32PM -0700, Andrew Morton wrote:
> > local_irq_disable();
> >
> > function_which_calls_cond_resched();
> >
> > local_irq_enable();
> >
>
Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
>
> > Sleeping with local interrupts disabled is usually a bug, so we should
> > prefer to keep that check in might_sleep().
>
> either it's _always_ a bug including for entry.S or sched_yield, or it's
> _never_ a bug. I don't understand the "usually".
Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
>
> On Tue, Jul 13, 2004 at 11:48:29AM -0700, Andrew Morton wrote:
> > sys_sched_yield() also calls schedule() with local interrupts disabled.
> > It's a bit grubby, but saves a few cycles. Nick and Ingo prefer it tha
Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
>
> On Mon, Jul 12, 2004 at 05:08:44PM -0700, Andrew Morton wrote:
> > of code then it's pretty obvious what's happening. If the trace is due to
> > a long irq-off time then it will point up into the offending
>
Lee Revell <[EMAIL PROTECTED]> wrote:
>
> Would this explain these? When running JACK with settings that need
> sub-millisecond latencies, I get them when I generate any load at all on
> the system (typing, switching windows, etc). I also get lots of these
> if I run JACK from an X terminal, but
Thomas Charbonnel <[EMAIL PROTECTED]> wrote:
>
> On my system xruns seem related to the keyboard. I get xruns on ~8.079
> seconds boundaries when the keyboard is in use, regardless of the load.
> My usual test is running jack with 2 periods of 64 samples and no
> client, and keep a key pressed.
Takashi Iwai <[EMAIL PROTECTED]> wrote:
>
> > You can do unlock_kernel()/lock_kernel() in soundcore_open().
>
> I remember ioctl() is also in lock_kernel()?
yes, you'll need to do unlock_kernel/lock_kernel there too. If someone
changes the rules, or otherwise calls your ioctl withoht lock_kerne
Lee Revell <[EMAIL PROTECTED]> wrote:
>
> On Tue, 2004-07-13 at 05:00, Andrew Morton wrote:
> > Lee Revell <[EMAIL PROTECTED]> wrote:
> > >
> > > > framebuffer scrolling inside lock_kernel(). Tricky. Suggest you use X or
> > > > v
Takashi Iwai <[EMAIL PROTECTED]> wrote:
>
> t Tue, 13 Jul 2004 02:00:25 -0700,
> Andrew Morton wrote:
> >
> > Lee Revell <[EMAIL PROTECTED]> wrote:
> > >
> > > Here are some more. These result from using mplayer with ALSA OSS
> &g
Lee Revell <[EMAIL PROTECTED]> wrote:
>
> > framebuffer scrolling inside lock_kernel(). Tricky. Suggest you use X or
> > vgacon. You can try removing the lock_kernel() calls from do_tty_write(),
> > but make sure you're wearing ear protection.
> >
>
> OK, I figured this was not an easy one
Lee Revell <[EMAIL PROTECTED]> wrote:
>
> Jul 13 04:27:50 mindpipe kernel: ALSA
> /usr/src/alsa-cvs-1.0.5/alsa-driver/alsa-kernel/core/pcm_lib.c:169: XRUN: pcmC0D0p
> Jul 13 04:27:50 mindpipe kernel: [__crc_totalram_pages+1387264/5353478]
> snd_pcm_period_elapsed+0x2ca/0x410 [snd_pcm]
> Jul 13
Lee Revell <[EMAIL PROTECTED]> wrote:
>
> Here are a few more:
>
> Jul 12 22:20:41 mindpipe kernel: ALSA
> /usr/src/alsa-cvs-1.0.5/alsa-driver/alsa-kernel/core/pcm_lib.c:169: XRUN: pcmC0D0p
> Jul 12 22:20:41 mindpipe kernel: [__crc_totalram_pages+1387264/5353478]
> snd_pcm_period_elapsed+0x2c
(please don't top-post)
Jan Depner <[EMAIL PROTECTED]> wrote:
>
> Is this problem strictly with reiserfs in 2.6 or is it also a problem
> with 2.4. I actually experienced fewer xruns with reiserfs vs ext3 on
> 2.4 (preempt/ll) but I have no hard numbers to back that up.
Actually, the 2.4 low-la
Lee Revell <[EMAIL PROTECTED]> wrote:
>
> > resierfs: yes, it's a problem. I "fixed" it multiple times in 2.4, but the
> > fixes ended up breaking the fs in subtle ways and I eventually gave up.
> >
>
> Interesting. There is an overwhelming consensus amongst Linux audio
> folks that you sho
Paul Davis <[EMAIL PROTECTED]> wrote:
>
> >It's too bad that the multimedia community didn't participate
> >much during the 2.5.xx development leading up to 2.6.0. If they
> >had done so, the situation might be different today. Fortunately,
> >fixing up the multimedia problems isn't too risky to do
Paul Davis <[EMAIL PROTECTED]> wrote:
>
> >OK, thanks. The problem areas there are the timer-based route cache
> >flushing and reiserfs.
> >
> >We can probably fix the route caceh thing by rescheduling the timer after
> >having handled 1000 routes or whatever, although I do wonder if this is a
> >
Paul Davis <[EMAIL PROTECTED]> wrote:
>
> >resierfs: yes, it's a problem. I "fixed" it multiple times in 2.4, but the
> >fixes ended up breaking the fs in subtle ways and I eventually gave up.
>
> andrew, this is really helpful. should we conclude that until some
> announcement from reiser that t
Lee Revell <[EMAIL PROTECTED]> wrote:
>
> On Sun, 2004-07-11 at 01:25, Andrew Morton wrote:
> > What we need to do is to encourage audio testers to use ALSA drivers, to
> > enable CONFIG_SND_DEBUG in the kernel build and to set
> > /proc/asound/*/*/xrun_debug and to s
Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>
> On Sun, Jul 11, 2004 at 03:42:58AM -0700, Andrew Morton wrote:
> > > We do not want to enable preempt for Fedora yet because it
> > > breaks just too much stuff
> >
> > What stuff?
>
> just look ov
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
>
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > OK, but most of the new ones are unneeded with CONFIG_PREEMPT=y. I'm
> > still failing to see why a non-preempt, voluntary preemption kernel
> > even ne
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
>
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > >
> > > For all the
> > > other 200 might_sleep() points it doesnt matter much.
> >
&g
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> For all the
> other 200 might_sleep() points it doesnt matter much.
Sorry, but an additional 100 might_sleep()s is surely excessive for
debugging purposes, and unneeded for latency purposes: all these sites are
preemptible anyway.
Let me repeat that I a
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> I took a
> look at latencies and indeed 2.6.7 is pretty bad - latencies up to 50
> msec (!) can be easily triggered using common workloads, on fast 2GHz+
> x86 system - even when using the fully preemptible kernel!
What were those workloads?
Certainly
C.L. Tien - _ <[EMAIL PROTECTED]> wrote:
>
>
> Hi,
>
> I made serveral changes for 6.64, the change are as following:
To what kernel do these patches apply? Certainly not current 2.6.
If you intend to raise 2.6 patches, please ensure that they are against the
latest kernel.org kernel.
Florian Schmidt <[EMAIL PROTECTED]> wrote:
>
>
> Hi Andrew,
>
> i'm a user of a 2.4.22 kernel patched with the preemption patches plus
> your Low Latency patches. It works very nicely for audio applications
> [like jackd, ardour, etc...].
Cool.
> Looking into the config menu of the 2.6.0 kernel
Fernando Pablo Lopez-Lezcano wrote:
>
> ...
> 4)
> schedule +1ab
> sleep_on +45
> bread +20
> __mark_inode_dirty +d9
> pipe_write +1b9
> poll_freewait +44
> sys_write +9f
> system_call +33
>
> So the system seems to be stuck in __mark_inode_dirty, whatever that is.
No, that's just stack gunk.
T
At http://www.zip.com.au/~akpm/linux/2.4.20-low-latency.patch.gz
Very much in sustaining mode. It includes a fix for a livelock
problem in fsync() from Stephen Tweedie.
Joern Nettingsmeier wrote:
>
> some new interesting results with 2.5.42:
>
> http://spunk.dnsalias.org/latencytest/2.5.42/2x256.html
>
> overall much worse, *but* greatly reduced latency peaks (max. 6 ms) as
> compared to 2.5.41:
>
> http://spunk.dnsalias.org/latencytest/2.5.41/2x256.html
>
>
Paul Davis wrote:
>
> from kernel traffic:
>
> Linus agreed that if the VM is as good as it seems to be, indeed
> the upcoming release deserves to be called 3.0. But he also pointed
> out that there are many silent users who tend not to speak up until
> there is an official release. He a
Roger Larsson wrote:
>
> ...
> An alternative would be Andrew Mortons amlat - it is simpler, possibly better
> in an automated environment.
That would require a kernel patch.
I always use a mucked-with version of Mark Hahn's `realfeel'
application. Simple, accurate.
Attached here.
/*
* This
jfm3 wrote:
>
> I can't get latencytest-0.42 to run on Redhat 7.3. I would like to make
> sure that the kernels I've been building are doing what I want. Does
> anybody have this working, or are there other audio latency measuring
> tools around?
>
Grab http://www.zip.com.au/~akpm/linux/amlat.t
Enrique Robledo Arnuncio wrote:
>
> ...
> diff -urN linux-2.4.19-pre7/drivers/char/drm/mga_dma.c
> linux-2.4.19-pre7-jl1-ll/drivers/char/drm/mga_dma.c
> --- linux-2.4.19-pre7/drivers/char/drm/mga_dma.cWed Aug 8 19:42:15 2001
> +++ linux-2.4.19-pre7-jl1-ll/drivers/char/drm/mga_dma.c Mon A
Enrique Robledo Arnuncio wrote:
>
> ...
> > fragment latency = 2.902494 ms
> > cpu latency = 2.321995 ms
> > 3.3ms ( 0)|
> > 1MS num_time_samples=21477 num_times_within_1ms=21477 factor=100.00
> > 2MS num_time_samples=21477 num_times_within_2ms=21477 factor=100.00
>
> Or in other word
"Richard C. Burnett" wrote:
>
> I am looking for a product similar to Purify to use in Linux, any ideas?
>
Everyone says valgrind is the hottest thing...
http://developer.kde.org/~sewardj/
-
Steve Harris wrote:
>
> On Mon, Feb 11, 2002 at 01:05:41 -0800, Andrew Morton wrote:
> > Steve Harris wrote:
> > >
> > > On Mon, Feb 11, 2002 at 01:11:07 -0800, Andrew Morton wrote:
> > > > There is hope - at present, RedHat's rawhide kernel, a
Kai Vehmanen wrote:
>
> This is great news. Linus has now added Robert Love's kernel preemption
> patch to the 2.5 tree!
>
> http://www.linuxdevices.com/news/NS3989618385.html
>
> --cut--
> "The addition of kernel preemption to the 2.5 tree is a substantial
> feature which will provide benefit
Jussi Laako wrote:
>
> Hi,
>
> I've done some changes to lowlatency patched kernel. Mainly "fixes" to DRM
> drivers and few network drivers. Most probably I have done something really
> stupid, but those work here(tm). Especially the Radeon driver patch has got
> a lot of testing and seems to ha
Tim Goetze wrote:
>
> Today Maarten de Boer wrote:
>
> >starts slowing down (notable the mouse movement gets very sluggish)
> >and finally freezes. I did not experience these problems with
> >kernel 2.5.15-pre5
> >
> >Any suggestions?
>
> have you already checked if a certain process is consumi
44 matches
Mail list logo
