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

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

  • To: "Martin Goldstone" <m.j.goldstone@xxxxxxxxxxxxxxx>
  • From: "Nathan Widmyer" <lighthousej@xxxxxxxxx>
  • Date: Wed, 18 Jul 2007 06:23:16 -0400
  • Cc: xen-users@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 18 Jul 2007 03:21:07 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=eHFiLL5z1OD1VCPdLkx8LIjmypzN85e4T43EUWN63Uoqir8gloFQEgmu9X9d6feZANrAguSaCRzwLgmLvei0kZJYWd5O+eG4FoW+Me5aICnu6Ya4ld8Zf/qBpaEE+mclnU7LT0I5J6cJPW1gFFdhxv004olp5wHtUbGulUNHEHI=
  • List-id: Xen user discussion <xen-users.lists.xensource.com>


Replies are spaced below.

On 7/18/07, Martin Goldstone <m.j.goldstone@xxxxxxxxxxxxxxx> wrote:
Hash: SHA1

Nathan Widmyer wrote:
> 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:

I think to use a 32 bit PV domU with a 64 bit hypervisor, you need a
kernel compiled with Xen 3.1 patches (I'm not sure on this, but it has
worked for me, as I had to use a Xen 3.1 kernel with a Centos 4.5 domU
instead of its domU kernel, which was panicking, thought I can't
remember if it was similar to your's).  RHEL5's xen is 3.0.3, so my
first question is, have you tried booting the domU with F7's xen kernel
(or alternatively, a kernel from the Xen site)?

I didn't know kernels were mix-and-match like that.  I found the RHEL5
32-bit xen files on xensource.com so I'll probably try to manually
build a guest with that kernel/initrd, then boot from the RHEL 5 CD
for the install.
> ----------
> .....
> 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]
> 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?

You might want to take a look at the Centos mirrors for that.  You
should be able to figure it out there.  I think it's more than a matter
of having the files organized correctly though, there'll be xml files
describing the repo.

I originally had the http server set up wrong and saw the different
paths the installer was trying to use to read files with but I'll do
it the right way and examine how others have done it like you suggest.
> 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?

You could do this (though see above about 32 bit on 64 bit, you may not
need to bother installing one inside it, though you will probably want
to copy the modules in), but you'll also need to check things like fstab
etc to make sure they are still pointing to the right devices.

I kind of did this when I took a real RHEL 3 install on a machine,
dd'd the contents to disk, then PV that.  But you're right, I don't
think I needed to install xen inside of it but that was when I thought
Xen was extracting the kernel from the partition that held boot.
> Thanks,
> Nathan

Hope this helps,


That's going to give me a lot of fresh things to try, thanks.


Xen-users mailing list



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