[PlanetCCRMA] fc6/7: new rt kernel; fc6/7: updated libgig
Hector Centeno
hcengar@gmail.com
Sun Jul 22 13:39:01 2007
------=_Part_170595_30340978.1185136690194
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Thank you Fernando, I'll test the new kernel as soon as I reinstall Fedora
in my laptop. I got tired of the wireless (which I use a lot for work
reasons) being almost useless in Fedora and installed UbuntuStudio instead.
Now without any trouble everything in the laptop works fine, I can connect
to all the different wireless access points that before were impossible with
Fedora and there is even a RT kernel. I started to wish there was a CCRMA
repository for Ubuntu, and I know this has been discussed before, but it's
nice to dream :-) . The apps in UbuntuStudio are outdated and many of the
important ones are missing (something I noticed about other music/audio
distos is that they lack all the more "academic" computer music tools that
CCRMA provides).
Cheers,
Hector
On 7/18/07, Fernando Lopez-Lezcano <nando@ccrma.stanford.edu> wrote:
>
> On Sun, 2007-07-08 at 15:54 -0700, Fernando Lopez-Lezcano wrote:
> > On Sun, 2007-07-08 at 15:26 -0400, Hector Centeno wrote:
> > > Ok, so just to confirm, that 2.6.21-0182.rt19.1.fc7.ccrmart works fine
> > > on my desktop but on my laptop it makes Firefox and Tomboy to crash.
> > > On the same laptop using 2.6.21-0182.rt17.1.fc7.ccrmart there is no
> > > problem.
> >
> > Maybe this is a processor related bug. What processors do you have in
> > both machines?
> >
> > I did not manage to hang it with gmail but I have privoxy enabled, maybe
> > some flash add related stuff is being intercepted in my case and does
> > not execute.
> >
> > Turns out that since rt11 the rt patch includes a new scheduler (the
> > CFS, Completely Fair Scheduler, also by Ingo Molnar) and may be causing
> > this problem. I posted to lkml and asked Ingo if it is possible to split
> > out this added functionality... sigh...
>
> After some traces I gathered were sent to the appropriate kernel gurus
> Ingo Molnar found the problem and sent me a small patch. I just tested
> it on 2.6.22.1-rt4 and it seems to have fixed the problem with flash9.
>
> I'll test a 2.6.21 kernel with this patch shortly. And probably release
> a new kernel if that fixes the problem on that kernel as well.
>
> -- Fernando
>
> -------- Forwarded Message --------
> From: Ingo Molnar
> To: Fernando Lopez-Lezcano
> Cc: Gabriel C , Carsten Emde , jcaceres, Steven Rostedt , RT-Users ,
> LKML , Thomas Gleixner , Rui Nuno Capela , Paul E. McKenney
> Subject: Re: v2.6.21.5-rt19 (sched_getaffinity?)
> Date: Wed, 18 Jul 2007 09:18:52 +0200
>
> * Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU> wrote:
>
> > > does lockdep pinpoint anything?
> >
> > Lots of stuff, and at the end the lock report for the problem.
> > Hopefully some of this will help... I have attached the whole bootup
> > sequence as logged in /var/log/messages.
>
> yeah, it pinpointed the bug. It seems to be an interaction between
> RCU-preempt (Paul Cc:-ed) and sched_mc_power_savings_store():
> detach_destroy_domains() uses synchronize_sched() which uses
> getaffinity, which takes sched_hotcpu_mutex, and
> arch_reinit_sched_domains does it too - see the lockdep report below.
> I've added a quick workaround below as well, which should keep your box
> from hanging.
>
> Ingo
>
> =============================================
> [ INFO: possible recursive locking detected ]
> [ 2.6.22-0182.rt4.3.fc7.ccrmart #1
> ---------------------------------------------
> sched-powersave/3251 is trying to acquire lock:
> (sched_hotcpu_mutex){--..}, at: [<c0424a37>] sched_getaffinity+0x14/0x94
>
> but task is already holding lock:
> (sched_hotcpu_mutex){--..}, at: [<c04245a5>]
> arch_reinit_sched_domains+0xe/0x33
>
> other info that might help us debug this:
> 1 lock held by sched-powersave/3251:
> #0: (sched_hotcpu_mutex){--..}, at: [<c04245a5>]
> arch_reinit_sched_domains+0xe/0x33
>
> stack backtrace:
> [<c040600c>] show_trace_log_lvl+0x1a/0x2f
> [<c0406ae8>] show_trace+0x12/0x14
> [<c0406b50>] dump_stack+0x16/0x18
> [<c0446f46>] __lock_acquire+0x172/0xb67
> [<c0447d03>] lock_acquire+0x56/0x6f
> [<c061d414>] _mutex_lock+0x2b/0x38
> [<c0424a37>] sched_getaffinity+0x14/0x94
> [<c0460841>] __synchronize_sched+0x11/0x5f
> [<c0423fa8>] detach_destroy_domains+0x2c/0x30
> [<c04245af>] arch_reinit_sched_domains+0x18/0x33
> [<c0424606>] sched_power_savings_store+0x3c/0x49
> [<c0424634>] sched_mc_power_savings_store+0xe/0x10
> [<c0561f11>] sysdev_class_store+0x20/0x25
> [<c04bbc6c>] sysfs_write_file+0xaf/0xd0
> [<c048183c>] vfs_write+0xaf/0x163
> [<c0481e8a>] sys_write+0x3d/0x61
> [<c040501a>] syscall_call+0x7/0xb
> =======================
> thinkpad_acpi: ThinkPad ACPI Extras v0.14
>
> --------------------->
> Index: linux-rt.q/kernel/sched.c
> ===================================================================
> --- linux-rt.q.orig/kernel/sched.c
> +++ linux-rt.q/kernel/sched.c
> @@ -6699,7 +6699,6 @@ static void detach_destroy_domains(const
>
> for_each_cpu_mask(i, *cpu_map)
> cpu_attach_domain(NULL, i);
> - synchronize_sched();
> arch_destroy_sched_domains(cpu_map);
> }
>
>
>
>
--
===============================
http://www.hcenteno.net
------=_Part_170595_30340978.1185136690194
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Thank you Fernando, I'll test the new kernel as soon as I reinstall Fedora in my laptop. I got tired of the wireless (which I use a lot for work reasons) being almost useless in Fedora and installed UbuntuStudio instead. Now without any trouble everything in the laptop works fine, I can connect to all the different wireless access points that before were impossible with Fedora and there is even a RT kernel. I started to wish there was a CCRMA repository for Ubuntu, and I know this has been discussed before, but it's nice to dream :-) . The apps in UbuntuStudio are outdated and many of the important ones are missing (something I noticed about other music/audio distos is that they lack all the more "academic" computer music tools that CCRMA provides).
<br><br>Cheers,<br><br>Hector<br><br><br><div><span class="gmail_quote">On 7/18/07, <b class="gmail_sendername">Fernando Lopez-Lezcano</b> <<a href="mailto:nando@ccrma.stanford.edu">nando@ccrma.stanford.edu</a>> wrote:
</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On Sun, 2007-07-08 at 15:54 -0700, Fernando Lopez-Lezcano wrote:<br>> On Sun, 2007-07-08 at 15:26 -0400, Hector Centeno wrote:
<br>> > Ok, so just to confirm, that 2.6.21-0182.rt19.1.fc7.ccrmart works fine<br>> > on my desktop but on my laptop it makes Firefox and Tomboy to crash.<br>> > On the same laptop using 2.6.21-0182.rt17.1.fc7.ccrmart
there is no<br>> > problem.<br>><br>> Maybe this is a processor related bug. What processors do you have in<br>> both machines?<br>><br>> I did not manage to hang it with gmail but I have privoxy enabled, maybe
<br>> some flash add related stuff is being intercepted in my case and does<br>> not execute.<br>><br>> Turns out that since rt11 the rt patch includes a new scheduler (the<br>> CFS, Completely Fair Scheduler, also by Ingo Molnar) and may be causing
<br>> this problem. I posted to lkml and asked Ingo if it is possible to split<br>> out this added functionality... sigh...<br><br>After some traces I gathered were sent to the appropriate kernel gurus<br>Ingo Molnar found the problem and sent me a small patch. I just tested
<br>it on 2.6.22.1-rt4 and it seems to have fixed the problem with flash9.<br><br>I'll test a 2.6.21 kernel with this patch shortly. And probably release<br>a new kernel if that fixes the problem on that kernel as well.
<br><br>-- Fernando<br><br>-------- Forwarded Message --------<br>From: Ingo Molnar<br>To: Fernando Lopez-Lezcano<br>Cc: Gabriel C , Carsten Emde , jcaceres, Steven Rostedt , RT-Users ,<br>LKML , Thomas Gleixner , Rui Nuno Capela , Paul E. McKenney
<br>Subject: Re: v2.6.21.5-rt19 (sched_getaffinity?)<br>Date: Wed, 18 Jul 2007 09:18:52 +0200<br><br>* Fernando Lopez-Lezcano <<a href="mailto:nando@ccrma.Stanford.EDU">nando@ccrma.Stanford.EDU</a>> wrote:<br><br>> > does lockdep pinpoint anything?
<br>><br>> Lots of stuff, and at the end the lock report for the problem.<br>> Hopefully some of this will help... I have attached the whole bootup<br>> sequence as logged in /var/log/messages.<br><br>yeah, it pinpointed the bug. It seems to be an interaction between
<br>RCU-preempt (Paul Cc:-ed) and sched_mc_power_savings_store():<br>detach_destroy_domains() uses synchronize_sched() which uses<br>getaffinity, which takes sched_hotcpu_mutex, and<br>arch_reinit_sched_domains does it too - see the lockdep report below.
<br>I've added a quick workaround below as well, which should keep your box<br>from hanging.<br><br> Ingo<br><br>=============================================<br>[ INFO: possible recursive locking detected ]<br>
[ 2.6.22-0182.rt4.3.fc7.ccrmart #1<br>---------------------------------------------<br>sched-powersave/3251 is trying to acquire lock:<br> (sched_hotcpu_mutex){--..}, at: [<c0424a37>] sched_getaffinity+0x14/0x94<br>
<br>but task is already holding lock:<br> (sched_hotcpu_mutex){--..}, at: [<c04245a5>] arch_reinit_sched_domains+0xe/0x33<br><br>other info that might help us debug this:<br>1 lock held by sched-powersave/3251:<br> #0: (sched_hotcpu_mutex){--..}, at: [<c04245a5>] arch_reinit_sched_domains+0xe/0x33
<br><br>stack backtrace:<br> [<c040600c>] show_trace_log_lvl+0x1a/0x2f<br> [<c0406ae8>] show_trace+0x12/0x14<br> [<c0406b50>] dump_stack+0x16/0x18<br> [<c0446f46>] __lock_acquire+0x172/0xb67<br> [<c0447d03>] lock_acquire+0x56/0x6f
<br> [<c061d414>] _mutex_lock+0x2b/0x38<br> [<c0424a37>] sched_getaffinity+0x14/0x94<br> [<c0460841>] __synchronize_sched+0x11/0x5f<br> [<c0423fa8>] detach_destroy_domains+0x2c/0x30<br> [<c04245af>] arch_reinit_sched_domains+0x18/0x33
<br> [<c0424606>] sched_power_savings_store+0x3c/0x49<br> [<c0424634>] sched_mc_power_savings_store+0xe/0x10<br> [<c0561f11>] sysdev_class_store+0x20/0x25<br> [<c04bbc6c>] sysfs_write_file+0xaf/0xd0
<br> [<c048183c>] vfs_write+0xaf/0x163<br> [<c0481e8a>] sys_write+0x3d/0x61<br> [<c040501a>] syscall_call+0x7/0xb<br> =======================<br>thinkpad_acpi: ThinkPad ACPI Extras v0.14<br><br>--------------------->
<br>Index: linux-rt.q/kernel/sched.c<br>===================================================================<br>--- linux-rt.q.orig/kernel/sched.c<br>+++ linux-rt.q/kernel/sched.c<br>@@ -6699,7 +6699,6 @@ static void detach_destroy_domains(const
<br><br> for_each_cpu_mask(i, *cpu_map)<br> cpu_attach_domain(NULL, i);<br>- synchronize_sched();<br> arch_destroy_sched_domains(cpu_map);<br> }<br><br><br><br></blockquote></div><br><br clear="all">
<br>-- <br>===============================<br><a href="http://www.hcenteno.net">http://www.hcenteno.net</a>
------=_Part_170595_30340978.1185136690194--