[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4D26B608.2060500@oracle.com>
Date: Fri, 07 Jan 2011 14:43:20 +0800
From: Joe Jin <joe.jin@...cle.com>
To: Joe Jin <joe.jin@...cle.com>
CC: Ian Campbell <Ian.Campbell@...citrix.com>,
"jeremy@...p.org" <jeremy@...p.org>,
"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
"gurudas.pai@...cle.com" <gurudas.pai@...cle.com>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
"guru.anbalagane@...cle.com" <guru.anbalagane@...cle.com>,
"greg.marsden@...cle.com" <greg.marsden@...cle.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-fbdev@...r.kernel.org" <linux-fbdev@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [Xen-devel] Re: [patch] xenfb: fix xenfb suspend/resume race
On 01/06/11 16:14, Joe Jin wrote:
>
>>
>> No, it papers over the issue, the code should never have been allowed to
>> get this far if the connection to the backend is not yet fully resumed
>> (i.e. when irq == -1).
>>
>> The call to xenfb_send_event should have been gated further up the call
>> chain, AFAICT by the check of info->update_wanted in xenfb_refresh. This
>> suggests that the correct fix is to set info->update_wanted = 0 in
>> xenfb_resume.
>>
>> I said all this in my previous mail and you ignored it. Did you try this
>> approach?
>
Disable xenfb refresh flag before suspend will fix this issue, sent new patch
to you by another mail, please review it.
Thanks,
Joe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists