From mboxrd@z Thu Jan 1 00:00:00 1970 From: Teck Choon Giam Subject: Re: kernel BUG at arch/x86/xen/mmu.c:1872 Date: Wed, 13 Apr 2011 00:08:04 +0800 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: MaoXiaoyun Cc: jeremy@goop.org, xen devel , keir@xen.org, ian.campbell@citrix.com, konrad.wilk@oracle.com, dave@ivt.com.au List-Id: xen-devel@lists.xenproject.org If it is possible, please try not to top-post as this make reading more confusing for me at least. Thanks ;) 2011/4/12 MaoXiaoyun : > Hi: > > =A0=A0=A0=A0=A0=A0 I=A0have just kicked off cpuidle=3D0 "cpufreq=3Dnone"= =A0tests. Let see whether are you able to reproduce the tlb BUG with the above. > > =A0=A0=A0=A0=A0=A0=A0What is your Xen version?=A0=A0Do you use the backen= d driver of > 2.6.32.36? You are asking me? xen-4.0.2-rc3-pre latest changeset and also xen-4.1.1-rc1-pre. What do you mean backend driver? My testing are mostly on PV domU and HVM on windows with LVM as storage. I do not use VDH or any PV drivers for windows. > > =A0=A0=A0=A0=A0=A0 Beside the "TLB BUG ", I've met at least two other iss= ues > =A0=A0=A0=A0=A0=A0 1)Xen4.0.1 + 2.6.32.36 kernel=A0+ backend driver from = 2.6.31=A0 =3D=3D> will > cause=A0"Bad grant reference " log in serial output > =A0=A0=A0=A0=A0=A0=A02)Xen4.0.1 +=A02.6.32.36 kernel with its owen backen= d driver=A0=A0 =3D=3D> will > cause disk error like belows. > > sd=A00:0:0:0:=A0rejecting=A0I/O=A0to=A0offline=A0device > sd=A00:0:0:0:=A0rejecting=A0I/O=A0to=A0offline=A0device > sd=A00:0:0:0:=A0rejecting=A0I/O=A0to=A0offline=A0device > sd=A00:0:0:0:=A0rejecting=A0I/O=A0to=A0offline=A0device > sd=A00:0:0:0:=A0rejecting=A0I/O=A0to=A0offline=A0device > sd=A00:0:0:0:=A0rejecting=A0I/O=A0to=A0offline=A0device > sd=A00:0:0:0:=A0rejecting=A0I/O=A0to=A0offline=A0device > sd=A00:0:0:0:=A0rejecting=A0I/O=A0to=A0offline=A0device > sd=A00:0:0:0:=A0rejecting=A0I/O=A0to=A0offline=A0device > sd=A00:0:0:0:=A0rejecting=A0I/O=A0to=A0offline=A0device > sd=A00:0:0:0:=A0rejecting=A0I/O=A0to=A0offline=A0device > sd=A00:0:0:0:=A0rejecting=A0I/O=A0to=A0offline=A0device > sd=A00:0:0:0:=A0rejecting=A0I/O=A0to=A0offline=A0device > end_request:=A0I/O=A0error,=A0dev=A0tdb,=A0sector=A028699593 > end_request:=A0I/O=A0error,=A0dev=A0tdb,=A0sector=A028699673 > end_request:=A0I/O=A0error,=A0dev=A0tdb,=A0sector=A028699753 > end_request:=A0I/O=A0error,=A0dev=A0tdb,=A0sector=A028699833 > end_request:=A0I/O=A0error,=A0dev=A0tdb,=A0sector=A028699913 > end_request:=A0I/O=A0error,=A0dev=A0tdb,=A0sector=A028699993 > end_request:=A0I/O=A0error,=A0dev=A0tdb,=A0sector=A028700073 Is this related to VDH? What is the specific backend driver? These started to surface after you applied my backport patch or regardless the patch applied it is already there? Thanks. Kindest regards, Giam Teck Choon