if you could do these soon in the Debian package, I think we should
still be able to get it into precise.
Rioting_Pacifst,
note that we generally recommend using cgroup-lite when possible.
Quoting Rioting_Pacifst (<email address hidden>):
> This bug has quite a few nasty symptoms (breaks suspend on SMP machines,
> etc) and I guess cgroups are going to get more popular as people try the
> "superpatch" so could we get one of the following into 12.04 please:
>
> 1)do not move all tasks into a default cgroup
> comment CREATE_DEFAULT=yes out and uncomment CREATE_DEFAULT=no in /etc/default/cgconfig
>
> 2)putting the following in /etc/cgconfig.conf
> group sysdefault {
> cpu {
> cpu.rt_runtime_us = 950000;
> }
> }
>
> 3) Add a rule so that [kthreadd] is never put in the default group
>
> 4) Changing startup script to not move ktreadadd
>
> I think creating a superflous default group is stupid anyway so the
> first fix is by far the best.
>
> Upstream have also release 0.38 but nothing in the changelog seems
> relevant.
>
> --
> You received this bug notification because you are subscribed to
> libcgroup in Ubuntu.
> https://bugs.launchpad.net/bugs/693594
>
> Title:
> cgroup-bin should not move kthreadd into a default cgroup
>
> Status in “libcgroup” package in Ubuntu:
> Confirmed
>
> Bug description:
> Steps to reproduce:
> 1. Install cgroup-bin from universe on a stock Lucid machine (I've only tested amd64, but I suspect it shouldn't matter)
> 2. Load an arbitrary module (e.g. modprobe rds)
> 3. Unload the module loaded in (2) (e.g. rmmod rds)
>
> The 'rmmod' process will hang unkillably in the kernel.
>
> Here's an example `dmesg` output from the hung-task watchdog for
> rmmod:
>
> INFO: task rmmod:1608 blocked for more than 120 seconds.
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> rmmod D 0000000000000000 0 1608 1440 0x00000000
> ffff880014245c78 0000000000000082 0000000000015bc0 0000000000015bc0
> ffff880014804890 ffff880014245fd8 0000000000015bc0 ffff8800148044d0
> 0000000000015bc0 ffff880014245fd8 0000000000015bc0 ffff880014804890
> Call Trace:
> [<ffffffff81541b6d>] schedule_timeout+0x22d/0x300
> [<ffffffff812b8716>] ? rb_erase+0xd6/0x160
> [<ffffffff81052a10>] ? __dequeue_entity+0x30/0x50
> [<ffffffff8154178b>] wait_for_common+0xdb/0x180
> [<ffffffff8105a220>] ? default_wake_function+0x0/0x20
> [<ffffffff815418ed>] wait_for_completion+0x1d/0x20
> [<ffffffff8107fe55>] flush_cpu_workqueue+0x65/0xa0
> [<ffffffff8107ff10>] ? wq_barrier_func+0x0/0x20
> [<ffffffff81080754>] flush_workqueue+0x54/0x80
> [<ffffffff810b5b24>] __stop_machine+0xf4/0x120
> [<ffffffff8109d8c0>] ? __try_stop_module+0x0/0x50
> [<ffffffff810b5d7e>] stop_machine+0x3e/0x60
> [<ffffffff8109cbd4>] ? find_module+0x34/0x70
> [<ffffffff8109e1ee>] sys_delete_module+0x17e/0x270
> [<ffffffff810121b2>] system_call_fastpath+0x16/0x1b
>
> The process is waiting on kstop/0 to wake up and service the stop_cpu
> workqueue work item that it has queued. kstop/0 is marked as
> TASK_RUNNABLE, but doesn't appear to ever be getting scheduled:
>
> $ ps -f 1609
> UID PID PPID C STIME TTY STAT TIME CMD
> root 1609 2 0 14:47 ? R 0:00 [kstop/0]
>
> $ cat /proc/1609/stack
> [<ffffffff8107fb6a>] worker_thread+0xda/0x110
> [<ffffffff81084206>] kthread+0x96/0xa0
> [<ffffffff810131ea>] child_rip+0xa/0x20
> [<ffffffffffffffff>] 0xffffffffffffffff
>
> I tracked this behavior down and reported it to the upstream kernel,
> but they say it's not a bug and that it's libcgroup's fault for moving
> kthreadd into a cgroup without RT privs:
> https://lkml.org/lkml/2011/1/5/53
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/libcgroup/+bug/693594/+subscriptions
Jon,
if you could do these soon in the Debian package, I think we should
still be able to get it into precise.
Rioting_Pacifst,
note that we generally recommend using cgroup-lite when possible.
Quoting Rioting_Pacifst (<email address hidden>): cgconfig /bugs.launchpad .net/bugs/ 693594 kernel/ hung_task_ timeout_ secs" disables this message. b6d>] schedule_ timeout+ 0x22d/0x300 716>] ? rb_erase+0xd6/0x160 a10>] ? __dequeue_ entity+ 0x30/0x50 78b>] wait_for_ common+ 0xdb/0x180 220>] ? default_ wake_function+ 0x0/0x20 8ed>] wait_for_ completion+ 0x1d/0x20 e55>] flush_cpu_ workqueue+ 0x65/0xa0 f10>] ? wq_barrier_ func+0x0/ 0x20 754>] flush_workqueue +0x54/0x80 b24>] __stop_ machine+ 0xf4/0x120 8c0>] ? __try_stop_ module+ 0x0/0x50 d7e>] stop_machine+ 0x3e/0x60 bd4>] ? find_module+ 0x34/0x70 1ee>] sys_delete_ module+ 0x17e/0x270 1b2>] system_ call_fastpath+ 0x16/0x1b b6a>] worker_ thread+ 0xda/0x110 206>] kthread+0x96/0xa0 1ea>] child_rip+0xa/0x20 fff>] 0xffffffffffffffff /lkml.org/ lkml/2011/ 1/5/53 /bugs.launchpad .net/ubuntu/ +source/ libcgroup/ +bug/693594/ +subscriptions
> This bug has quite a few nasty symptoms (breaks suspend on SMP machines,
> etc) and I guess cgroups are going to get more popular as people try the
> "superpatch" so could we get one of the following into 12.04 please:
>
> 1)do not move all tasks into a default cgroup
> comment CREATE_DEFAULT=yes out and uncomment CREATE_DEFAULT=no in /etc/default/
>
> 2)putting the following in /etc/cgconfig.conf
> group sysdefault {
> cpu {
> cpu.rt_runtime_us = 950000;
> }
> }
>
> 3) Add a rule so that [kthreadd] is never put in the default group
>
> 4) Changing startup script to not move ktreadadd
>
> I think creating a superflous default group is stupid anyway so the
> first fix is by far the best.
>
> Upstream have also release 0.38 but nothing in the changelog seems
> relevant.
>
> --
> You received this bug notification because you are subscribed to
> libcgroup in Ubuntu.
> https:/
>
> Title:
> cgroup-bin should not move kthreadd into a default cgroup
>
> Status in “libcgroup” package in Ubuntu:
> Confirmed
>
> Bug description:
> Steps to reproduce:
> 1. Install cgroup-bin from universe on a stock Lucid machine (I've only tested amd64, but I suspect it shouldn't matter)
> 2. Load an arbitrary module (e.g. modprobe rds)
> 3. Unload the module loaded in (2) (e.g. rmmod rds)
>
> The 'rmmod' process will hang unkillably in the kernel.
>
> Here's an example `dmesg` output from the hung-task watchdog for
> rmmod:
>
> INFO: task rmmod:1608 blocked for more than 120 seconds.
> "echo 0 > /proc/sys/
> rmmod D 0000000000000000 0 1608 1440 0x00000000
> ffff880014245c78 0000000000000082 0000000000015bc0 0000000000015bc0
> ffff880014804890 ffff880014245fd8 0000000000015bc0 ffff8800148044d0
> 0000000000015bc0 ffff880014245fd8 0000000000015bc0 ffff880014804890
> Call Trace:
> [<ffffffff81541
> [<ffffffff812b8
> [<ffffffff81052
> [<ffffffff81541
> [<ffffffff8105a
> [<ffffffff81541
> [<ffffffff8107f
> [<ffffffff8107f
> [<ffffffff81080
> [<ffffffff810b5
> [<ffffffff8109d
> [<ffffffff810b5
> [<ffffffff8109c
> [<ffffffff8109e
> [<ffffffff81012
>
> The process is waiting on kstop/0 to wake up and service the stop_cpu
> workqueue work item that it has queued. kstop/0 is marked as
> TASK_RUNNABLE, but doesn't appear to ever be getting scheduled:
>
> $ ps -f 1609
> UID PID PPID C STIME TTY STAT TIME CMD
> root 1609 2 0 14:47 ? R 0:00 [kstop/0]
>
> $ cat /proc/1609/stack
> [<ffffffff8107f
> [<ffffffff81084
> [<ffffffff81013
> [<fffffffffffff
>
> I tracked this behavior down and reported it to the upstream kernel,
> but they say it's not a bug and that it's libcgroup's fault for moving
> kthreadd into a cgroup without RT privs:
> https:/
>
> To manage notifications about this bug go to:
> https:/