Re: [Xen-devel] dump with xen-unstable & linux 3.2.17

[Ben Guthro <ben@xxxxxxxxxx>]

Just to follow up on this - it appears I was running into two issues
with all of this.

1. The changeset mentioned below needed to be reverted, as it was
removing the CPUS at suspend time.

2. The linux xen watchdog driver (drivers/watchdog/xen_wdt.c) seems to
be enabling itsself on resume, even if you tell it not to.
I worked around this by just turning off watchdogs in my kernel
config...because I wasn't using them anyhow.

After making these 2 changes - S3 works again.



On Fri, May 25, 2012 at 9:20 AM, Ben Guthro <ben@xxxxxxxxxx> wrote:
> It seems to be related to the hunk in xen/common/schedule.c
>
> If I remove the part below - I get further in the resume process, in
> that the machine seems to wake up, but not be responsive.
> Eventually - the watchdog fires, and reboots the machine.
>
>
> Any thoughts?
>
> /btg
>
> Changed parts:
>
> diff --git a/xen/common/schedule.c b/xen/common/schedule.c
> index 0854f55..95cb2b4 100644
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -543,7 +543,7 @@ int cpu_disable_scheduler(unsigned int cpu)
>     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 )
>
>
>
>
>
>
> On Wed, May 23, 2012 at 7:00 AM, Juergen Gross
> <juergen.gross@xxxxxxxxxxxxxx> wrote:
>> On 05/23/2012 11:39 AM, Jan Beulich wrote:
>>>>>>
>>>>>> On 22.05.12 at 23:00, Ben Guthro<ben@xxxxxxxxxx>  wrote:
>>>>
>>>> I've bisected this to the following commit in the xen-unstable git tree.
>>>>
>>>> I'll be able to dive in a little deeper tomorrow.
>>>> If you see anything here that looks suspicious to the crash
>>>> referenced... let me know.
>>>
>>> As the change was really a re-write of a submission by Jürgen,
>>> I'm adding him to Cc.
>>>
>>> Unless he has an immediate idea, we definitely want to
>>> understand why "cpus" is empty - hence we'd want to see
>>> *online, *vc->cpu_affinity, vc->cpu_id, and maybe
>>> vc->processor. (Printing them is probably not a good idea
>>> here, so I'd instead suggest just copying them to [additional]
>>> on-stack variables, making sure the compiler doesn't optimize
>>> them away.)
>>>
>>> Probably it would be good to also know what each active
>>> vCPU's ->cpu_affinity was right before suspend and/or right
>>> after resume (perhaps in freeze_domains() and/or
>>> thaw_domains(). That way we'd at least know whether the
>>> affinity - despite the offending changeset's inverse intention -
>>> did get changed during the resume process.
>>
>>
>> No idea, sorry.
>> I tested the patch only against a problem with power_off, so I never hit the
>> resume path.
>>
>>
>> Juergen
>>
>> --
>> Juergen Gross                 Principal Developer Operating Systems
>> PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
>> Fujitsu Technology Solutions              e-mail:
>> juergen.gross@xxxxxxxxxxxxxx
>> Domagkstr. 28                           Internet: ts.fujitsu.com
>> D-80807 Muenchen                 Company details:
>> ts.fujitsu.com/imprint.html
>>

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