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

RE: [Xen-devel] Re: [PATCH] ioemu-remote: ACPI S3 state wake up



Hi, Selander and Jean

Jiajun is reporting similar (on cs18132) error in latest cs.
I found when keeping cs18120, revert 18027, everything is just ok.
So cs18120 itself works fine, yet if cs18027 set ro-attributes, problem still 
exist.

Just did some debugging, from ITP, one cpu is in default_idle loop, other one 
is for-ever running in x86_emulate/memcpy/__hvm_copy, etc. So I think this 
might be the same problem Guyader meet before?

I am not familiar about EBDA, could somebody help me to have a look? 

Thanks& Regards,
Criping

-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Keir Fraser
Sent: 2008年7月24日 20:45
To: Jean Guyader; Trolle Selander
Cc: xen-devel; Ian Jackson
Subject: Re: [Xen-devel] Re: [PATCH] ioemu-remote: ACPI S3 state wake up

On 24/7/08 13:12, "Jean Guyader" <jean.guyader@xxxxxxxxxxxxx> wrote:

> Jean Guyader wrote:
>> I already tried to reduce the rw area, and just keep 0xe0 -> 0xef. But
>> obviously it doesn't work the device model needs to write on this frame
>> 0xf1. I still don't figure out why.
> 
> The rombios write on this page because of this flags s3_resume_flag
> (rombios.c:98883). I don't know if it's a good reason to set the
> rombios as rw. However it's bad to set the first 2 pages of the rombios
> as rw just because of that.
> Any suggestions ?

In that case the changes to ioemu-remote should be reverted. The correct fix
is to move the S3 resume flag into the EBDA. I have committed this fix as
xen-unstable.hg:18120.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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