From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [Xen-users] kernel 3.9.2 - xen 4.2.2/4.3rc1 => BUG unable to handle kernel paging request netif_poll+0x49c/0xe8 Date: Fri, 17 May 2013 11:45:19 +0100 Message-ID: <5196265F02000078000D6FA0@nat28.tlf.novell.com> References: <8511913.uMAmUdIO30@eistomin.edss.local> <20130517085923.GC14401@zion.uk.xensource.com> <4438396.YM609lG6nT@eistomin.edss.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4438396.YM609lG6nT@eistomin.edss.local> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Eugene Istomin Cc: Wei Liu , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org >>> On 17.05.13 at 11:37, Eugene Istomin wrote: > [ 38.447860] BUG: unable to handle kernel paging request at > ffff88007928b000 > [ 38.447898] IP: [] netif_poll+0x49c/0xe80 [xennet] > [ 38.447927] PGD a83067 PUD a93067 PMD 7fc28067 PTE > 801000007928b065 > [ 38.447955] Oops: 0003 [#1] SMP > [ 38.447970] Modules linked in: af_packet hwmon domctl crc32_pclmul > crc32c_intel ghash_clmulni_intel aesni_intel ablk_helper cryptd lrw > aes_x86_64 xts gf128mul joydev autofs4 scsi_dh_emc scsi_dh_alua > scsi_dh_rdac scsi_dh_hp_sw scsi_dh xenblk cdrom xennet ata_generic > ata_piix > [ 38.448091] CPU 0 > [ 38.448100] Pid: 0, comm: swapper/0 Not tainted 3.9.2-4.756ee56-xen > #1 > [ 38.448125] RIP: e030:[] [] > netif_poll+0x49c/0xe80 [xennet] > [ 38.448158] RSP: e02b:ffff88007b403d18 EFLAGS: 00010286 > [ 38.448176] RAX: ffff88007da68cd0 RBX: ffff88007928aec0 RCX: > ffff88007928b000 > > > > > This trace is viewed only using xl console, DomUs had no records in logs. > You are right, may be this is Dom0 trace. Output of "xl console" can hardly be Dom0 kernel output. The fact that various modules (most prominently domctl) are present here that would normally only be expected in Dom0 may be confusing us. Init scripts might be loading those for no reason... But - you still didn't give us a full guest kernel log, so we're still left in the dark as to what may have gone wrong earlier, and what the call stack is that got us here. Nor did you tell us what kernel version you used last without seeing that issue. Plus, should in depth analysis of the stack turn out necessary, using a random build will make this more complicated than necessary (as those builds vanish as newer ones appear). Jan