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

[Xen-users] Repetitive Kernel oops (and two smaller questions)


  • To: xen-users@xxxxxxxxxxxxxxxxxxx
  • From: "Nathan Widmyer" <lighthousej@xxxxxxxxx>
  • Date: Tue, 17 Jul 2007 18:27:25 -0400
  • Delivery-date: Tue, 17 Jul 2007 15:25:17 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=TZnOycz86qDeo/H9zqKGAVrsnCPKT6BmrJUWxnWajkiAS6SlADLpEi2UHfj2TGRHDzIsm2MRjEy6ciMq2OxNqL59NxSq19hW+DiD1PplEdJYqwUNXpV1c+L5R5jUMlM+2TMm1tO6IF9tT9MmBD4ucxEtX4VQOr3xKB/iDXAPjVM=
  • List-id: Xen user discussion <xen-users.lists.xensource.com>

I have an F7 host that's running the 2.6.20-2925.11.fc7xen 64-bit
kernel on a Dell 2950 using the latest 64-bit Xen packages in F7,
3.1.0-2.f7.  I'm trying to install RHEL 5 386 as a guest which I hear
is possible.  64-bit RHEL5 isn't available to use anyway.  When I try
to paravirtualize the install and only utilize 1 CPU, I always get a
kernel oops right before the boot launches anaconda:
----------
.....
NET: Registered protocol family 1
NET: Registered protocol family 17
Using IPI No-Shortcut mode
XENBUS: Device with no driver: device/vbd/51712
XENBUS: Device with no driver: device/vif/0
Freeing unused kernel memory: 172k freed
Write protecting the kernel read-only data: 355k
Oops: 0000 [#1]
SMP
last sysfs file: /class/graphics/fb0/name
Modules linked in: xenblk xennet iscsi_tcp libiscsi scsi_transport_iscsi sr_mod
sd_mod scsi_mod ide_cd cdrom ipv6 squashfs pcspkr loop nfs nfs_acl fscache lockd
sunrpc vfat fat cramfs
CPU:    0
EIP:    0061:[<ee2febc3>]    Not tainted VLI
EFLAGS: 00010046   (2.6.18-8.el5xen #1)
EIP is at blkif_int+0xca/0x16b [xenblk]
eax: 00000000   ebx: c0e5e000   ecx: c07e5e3c   edx: 00000000
esi: 00000000   edi: ca000100   ebp: c0e410ac   esp: c071bfa4
ds: 007b   es: 007b   ss: 0069
Process init (pid: 235, ti=c071b000 task=c07e2550 task.ti=c07e5000)
Stack: 00000000 00000001 00000002 00000000 d8e67c7c c0f9c720 00000000 00000000
      00000108 c043ec9b c07e5e3c c06bb828 c06bb800 00000108 fffffffe c043ed58
.... (cut for the sake of brevity)
-----------------------
Which is strange because I tell it to only use 1 CPU so I don't know
why SMP shows up.  Booting an SMP kernel on a single-processor CPU
shouldn't cause problems.

If I increase the VCPU's up to 2, I get an additional section below
what I pasted above.

.....
[<c046271b>] vfs_write+0xa1/0x143
[<c0462d0d>] sys_write+0x3c/0x63
[<c0404cff>] syscall_call+0x7/0xb
=======================
Code: 00 c7 80 84 00 00 00 00 00 00 00 c7 80 e8 00 00 00 00 00 00 00 89 bb fc 13
00 00 80 7d 08 01 77 35 8b 04 24 31 d2 66 83 7d 0a 00 <8b> 48 2c 0f 94 c2 e8 7a
99 1c d2 85 c0 74 08 0f 0b ac 02 08 f3
EIP: [<ee2febc3>] blkif_int+0xca/0x16b [xenblk] SS:ESP 0069:c071bfa4
<0>Kernel panic - not syncing: Fatal exception in interrupt
BUG: warning at arch/i386/kernel/smp-xen.c:529/smp_call_function() (Not tainted
)
[<c040db7f>] smp_call_function+0x59/0xfe
[<c040dc37>] smp_send_stop+0x13/0x1e
[<c041b470>] panic+0x45/0x16d
.......

I also cut out the stack in this one too.  If somebody needs
information I've cut out, I can email the entire text file.

I tried googe'ing on some of the keywords but I either found no help
at all or people saying some bug was already fixed a year ago.

A smaller question:
I'm able to boot a fully-virtualized install but the install process
is getting hung possibly at how the RHEL files are organized.  If I
have 5 CD's, how would I organize them all into one place on an http
server so I don't have to change discs?

Even smaller:
If I fully-virtualize an install, is it easy to paravirtualize it?
Should I just install xen inside of it, extract the kernel and initrd,
dump the VM xml, then add a kernel section?

Thanks,
Nathan

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


 


Rackspace

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