1. 11 Sep, 2008 2 commits
    • Hiroshi Shimamoto's avatar
      sched: fix deadlock in setting scheduler parameter to zero · ec5d4989
      Hiroshi Shimamoto authored
      Andrei Gusev wrote:
      
      > I played witch scheduler settings. After doing something like:
      > echo -n 1000000 >sched_rt_period_us
      >
      > command is locked. I found in kernel.log:
      >
      > Sep 11 00:39:34 zaratustra
      > Sep 11 00:39:34 zaratustra Pid: 4495, comm: bash Tainted: G        W
      > (2.6.26.3 #12)
      > Sep 11 00:39:34 zaratustra EIP: 0060:[<c0213fc7>] EFLAGS: 00210246 CPU: 0
      > Sep 11 00:39:34 zaratustra EIP is at div64_u64+0x57/0x80
      > Sep 11 00:39:34 zaratustra EAX: 0000389f EBX: 00000000 ECX: 00000000
      > EDX: 00000000
      > Sep 11 00:39:34 zaratustra ESI: d9800000 EDI: d9800000 EBP: 0000389f
      > ESP: ea7a6edc
      > Sep 11 00:39:34 zaratustra DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
      > Sep 11 00:39:34 zaratustra Process bash (pid: 4495, ti=ea7a6000
      > task=ea744000 task.ti=ea7a6000)
      > Sep 11 00:39:34 zaratustra Stack: 00000000 000003e8 d9800000 0000389f
      > c0119042 00000000 00000000 00000001
      > Sep 11 00:39:34 zaratustra 00000000 00000000 ea7a6f54 00010000 00000000
      > c04d2e80 00000001 000e7ef0
      > Sep 11 00:39:34 zaratustra c01191a3 00000000 00000000 ea7a6fa0 00000001
      > ffffffff c04d2e80 ea5b2480
      > Sep 11 00:39:34 zaratustra Call Trace:
      > Sep 11 00:39:34 zaratustra [<c0119042>] __rt_schedulable+0x52/0x130
      > Sep 11 00:39:34 zaratustra [<c01191a3>] sched_rt_handler+0x83/0x120
      > Sep 11 00:39:34 zaratustra [<c01a76a6>] proc_sys_call_handler+0xb6/0xd0
      > Sep 11 00:39:34 zaratustra [<c01a76c0>] proc_sys_write+0x0/0x20
      > Sep 11 00:39:34 zaratustra [<c01a76d9>] proc_sys_write+0x19/0x20
      > Sep 11 00:39:34 zaratustra [<c016cc68>] vfs_write+0xa8/0x140
      > Sep 11 00:39:34 zaratustra [<c016cdd1>] sys_write+0x41/0x80
      > Sep 11 00:39:34 zaratustra [<c0103051>] sysenter_past_esp+0x6a/0x91
      > Sep 11 00:39:34 zaratustra =======================
      > Sep 11 00:39:34 zaratustra Code: c8 41 0f ad f3 d3 ee f6 c1 20 0f 45 de
      > 31 f6 0f ad ef d3 ed f6 c1 20 0f 45 fd 0f 45 ee 31 c9 39 eb 89 fe 89 ea
      > 77 08 89 e8 31 d2 <f7> f3 89 c1 89 f0 8b 7c 24 08 f7 f3 8b 74 24 04 89
      > ca 8b 1c 24
      > Sep 11 00:39:34 zaratustra EIP: [<c0213fc7>] div64_u64+0x57/0x80 SS:ESP
      > 0068:ea7a6edc
      > Sep 11 00:39:34 zaratustra ---[ end trace 4eaa2a86a8e2da22 ]---
      
      fix the boundary condition.
      
      sysctl_sched_rt_period=0 makes exception at to_ratio().
      Signed-off-by: default avatarHiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      ec5d4989
    • Zhang, Yanmin's avatar
      sched: fix 2.6.27-rc5 couldn't boot on tulsa machine randomly · baf25731
      Zhang, Yanmin authored
      On my tulsa x86-64 machine, kernel 2.6.25-rc5 couldn't boot randomly.
      
      Basically, function __enable_runtime forgets to reset rt_rq->rt_throttled
      to 0. When every cpu is up, per-cpu migration_thread is created and it runs
      very fast, sometimes to mark the corresponding rt_rq->rt_throttled to 1 very
      quickly. After all cpus are up, with below calling chain:
      
         sched_init_smp => arch_init_sched_domains => build_sched_domains => ...
      => cpu_attach_domain => rq_attach_root => set_rq_online => ...
      => _enable_runtime
      
      _enable_runtime is called against every rt_rq again, so rt_rq->rt_time is
      reset to 0, but rt_rq->rt_throttled might be still 1. Later on function
      do_sched_rt_period_timer couldn't reset it, and all RT tasks couldn't be
      scheduled to run on that cpu. here is RT task migration_thread which is
      woken up when a task is migrated to another cpu.
      
      Below patch fixes it against 2.6.27-rc5.
      Signed-off-by: default avatarZhang Yanmin <yanmin_zhang@linux.intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      baf25731
  2. 06 Sep, 2008 2 commits
  3. 05 Sep, 2008 2 commits
  4. 04 Sep, 2008 6 commits
  5. 03 Sep, 2008 28 commits