[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2] Fix scheduler crash after s3 resume



>>> On 24.01.13 at 15:26, Tomasz Wroblewski <tomasz.wroblewski@xxxxxxxxxx> 
>>> wrote:
>@@ -212,6 +213,8 @@
>             BUG_ON(error == -EBUSY);
>             printk("Error taking CPU%d up: %d\n", cpu, error);
>         }
>+        if (system_state == SYS_STATE_resume)
>+            cpumask_set_cpu(cpu, cpupool0->cpu_valid);

This can't be right: What tells you that all CPUs were in pool 0?

Also, for the future - generating patches with -p helps quite
a bit in reviewing them.

>--- a/xen/common/schedule.c    Mon Jan 21 17:03:10 2013 +0000
>+++ b/xen/common/schedule.c    Thu Jan 24 13:40:31 2013 +0000
>@@ -545,7 +545,7 @@
>     int    ret = 0;
> 
>     c = per_cpu(cpupool, cpu);
>-    if ( (c == NULL) || (system_state == SYS_STATE_suspend) )
>+    if ( c == NULL )
>         return ret;
> 
>     for_each_domain_in_cpupool ( d, c )
>@@ -556,7 +556,8 @@
> 
>             cpumask_and(&online_affinity, v->cpu_affinity, c->cpu_valid);
>             if ( cpumask_empty(&online_affinity) &&
>-                 cpumask_test_cpu(cpu, v->cpu_affinity) )
>+                 cpumask_test_cpu(cpu, v->cpu_affinity) &&
>+                 system_state != SYS_STATE_suspend )
>             {
>                 printk("Breaking vcpu affinity for domain %d vcpu %d\n",
>                         v->domain->domain_id, v->vcpu_id);

I doubt this is correct, as you don't restore any of the settings
during resume that you tear down here.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.