headers
Hugo Silva | 25 May 02:00
Favicon

NetBSD & Xen 4 - where are we ?

Good night everyone,

My NetBSD -current + Xen 3 + lvm machines have been running pretty 
smoothly for the past few months. Now there are a few new projects and 
some new hardware available next month or so, and I've decided to stick 
with NetBSD+Xen as I'm quite satisfied with it. A huge THANK YOU for 
everyone making this possible!

Some months ago there were a few threads on the list about issues with 
Xen 4 and/or using xl to launch domains.

While I'll be setting up a test box to confirm everything for myself, 
could we make a point of the situation ?

Are HVM & PV domains working alright with Xen 4.1.2 + xl + lvm?

Is the domU SMP code ready for use ? (according to the NetBSD/Xen page 
yes, but do tell about your personal experience!)

Are there plans to implement SMP for dom0 ?

And if a developer would like to give an overview, what has been the 
target of the Xen port recently ? What are the next goals?

Best regards,

Hugo
Permalink | Reply | 3 comments |
headers
Christoph Egger | 22 May 17:27
Picon
Picon

Dom0 LOCKDEBUG panic


Hi,

when a HVM guest shut down, Dom0 crashes:

tap0: detached
Mutex error: kmem_intr_free: allocation contains active lock

lock address : 0xffffa000014b3cc8 type     :               spin
initialized  : 0xffffffff807684b0
shared holds :                  0 exclusive:                  0
shares wanted:                  0 exclusive:                  0
current cpu  :                  0 last held:                  0
current lwp  : 0xffffa000013dac00 last held: 000000000000000000
last locked  : 0xffffffff80769bac unlocked*: 0xffffffff8076a0ae
owner field  : 0x0000000000000600 wait/spin:                0/1

panic: LOCKDEBUG
fatal breakpoint trap in supervisor mode
trap type 1 code 0 rip ffffffff80211545 cs e030 rflags 246 cr2
ffffa000198814e8 cpl 0 rsp ffffa00019f2e960
Stopped in pid 0.34 (system) at netbsd:breakpoint+0x5:  leave
breakpoint() at netbsd:breakpoint+0x5
vpanic() at netbsd:vpanic+0x1f2
printf_nolog() at netbsd:printf_nolog
lockdebug_more() at netbsd:lockdebug_more
kmem_intr_free() at netbsd:kmem_intr_free+0x8f
xbdback_xenbus_destroy() at netbsd:xbdback_xenbus_destroy+0xe4
otherend_changed() at netbsd:otherend_changed+0xaf
xenwatch_thread() at netbsd:xenwatch_thread+0xa2
(Continue reading)

Permalink | Reply | 1 comment |
headers
Roger Pau Monné | 16 May 18:49
Favicon

Using vesa with Xen on NetBSD 6.0 BETA

Hello,

It's just a stupid question, but I've been trying to use the vesa
framebuffer with Xen on 6.0 BETA without luck, NetBSD is still booting
using the regular 80x25 text console, here is my bootloader line:

menu=Boot Xen:rndseed /var/db/entropy-file;vesa 1680x1050x32;load
/netbsd-XEN3_DOM0 console=pc;multiboot /xen42.gz

If anyone could give a hand with this...

Thanks!
Permalink | Reply | 3 comments |
headers
David Brownlee | 10 May 15:47
Gravatar

xen: evtchn_do_event: handler 0xffffffff8020a88f didn't lower ipl 8 7

I've jut setup xen on an i5 server, and while everything seems to be
running fine (a single
 x64 CentOS 5.8 guest so far), the console sometimes seems to show a stream of

evtchn_do_event: handler 0xffffffff8020a88f didn't lower ipl 8 7

Is this normal? anything to be worried about?

This is on a netbsd-6 BETA amd64 host
Permalink | Reply | 2 comments |
headers
Louis Guillaume | 7 May 17:04

Using logical volumes as xen disks

Hi!

On NetBSD 6.0_BETA (from March 3rd or so), amd64, XEN3_DOM0, I want to 
manage the storage for guests using LVM.

I'm able to create the logical volumes ok, but the guest domains fail to 
start, hanging after loading the balloon0 device.

The disk parameter looks like this:

  'phy:/dev/vg0/lv0,0x04,w'

I also noticed that the logical volume cannot be vnconfig'd:

   # vnconfig vnd0 /dev/vg0/lv0
   vnconfig: /dev/rvnd0d: VNDIOCSET: Operation not supported

The guest boots fine without this disk, having sparse-file backed 
storage instead with "file:/....'

Am I missing something here?

Louis
Permalink | Reply | 1 comment |
headers
Jeff Rizzo | 4 May 18:04
Favicon

Crash in -current amd64 domU

I believe this has been seen before, but I just got a crash in a fairly
-current amd64 domU while building NetBSD.

The only thing in the dom0 dmesg regarding this domain was this:
(XEN) domain.c:652:d40 Attempt to change CR4 flags 00002660 -> 00000620
(XEN) domain.c:652:d40 Attempt to change CR4 flags 00002660 -> 00000620
(XEN) domain.c:652:d40 Attempt to change CR4 flags 00002660 -> 00000620

Here's the uvm_fault, backtrace, and registers.  Let me know if I should
gather anything else.

evtchn_do_event: handler 0xffffffff80120b97 didn't lower ipl 8 7
evtchn_do_event: handler 0xffffffff80120b97 didn't lower ipl 8 7
uvm_fault(0xffffa0005330a5c8, 0x7fbfdfefe000, 1) -> e
fatal page fault in supervisor mode
trap type 6 code 0 rip ffffffff802e63ee cs e030 rflags 10202 cr2 
7fbfdfefeff8 c
pl 0 rsp ffffa000c381b870
db{0}> bt
pmap_enter_ma() at netbsd:pmap_enter_ma+0x23b
pmap_enter() at netbsd:pmap_enter+0x35
uvm_fault_internal() at netbsd:uvm_fault_internal+0xee5
trap() at netbsd:trap+0x4e9
--- trap (number 6) ---
7f7ff6cf8360:
db{0}> show reg
ds          58e8
es          b928
fs          b920
gs          10
(Continue reading)

Permalink | Reply | 0 comments |
headers
Toby Karyadi | 11 Apr 19:55
Picon

netbsd dom0 + Xen 4.1 + netbsd pv domU + xl => works! (with caveat)

Hi,

I just found out you can run a netbsd pv domU using the 'xl' command (vs 
'xm'). hvm domu + xl has never been a problem. The caveat is this: the 
disk(s) has to be of 'phy' type, as opposed to 'file' type. That is, in 
the domU config file, instead of defining disk as such:
     disk = [ 'file:/mnt/v01/vhosts/dadomu01/dadomu01.disk0.img,hda,w ]
the disk can be defined as such:
     disk = [ 'phy:/dev/vnd0d,hda,w' ]
where vnd0 has been vnconfiged to point to the dadomu01.disk0.img file 
above. I've also tested the config using an lvm logical volume and it 
worked fine, and I would assume that any other physical device, like a 
dk wedge would work as well.

I'm probably not the first one to find this out, however, I think it is 
important to bring this up, especially since the last information that 
I'm aware of on Xen 4, domU, and xl was this: 
http://mail-index.netbsd.org/port-xen/2011/04/01/msg006575.html.

My understanding on the problem with netbsd dom0 + file based disk image 
+ xl is that we don't have support for blktap and in that case xl will 
start qemu-dm. In my case qemu-dm wasn't able to setup the disk image 
file as a device (don't know why). The domU was shown to be in the 'b' 
state, but I was unable to connect via console and the network was not 
up either. This thread at the Xen ml gave me the idea of using phy disk 
type: 
http://lists.xen.org/archives/html/xen-devel/2010-12/msg01217.html. But 
this is from Dec of 2010, I wonder what has changed since then.

Also, AFAIK, with xm and netbsd, the xenbackendd will use the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Toby Karyadi | 1 Apr 05:40
Picon

PV domU boot hung when using an lvm logical volume as a disk

Hi,

I've got a netbsd 6.99.4 dom0 on top of Xen 4.1.2. I also had a PV domU 
that was also running netbsd of the same build as the dom0 and had a 
disk referring to a raw LVM logical volume (LV). It would hang during 
boot (see DETAILS below). The boot up process hung just after setup of 
the balloon driver (see DETAILS below). When I removed the raw LV disk 
definition from the domU configuration file, the domU booted up fine, 
that is using a wedge (/dev/rdk*) as a disk for the domU worked properly.

When I excluded the raw LV from the domU config so that it could boot up 
and did 'xm block-attach <domname> phy:/dev/vg00/rlv1 hdc w', the disk 
will appear in the domU as xbd2. I noticed however that the dom0 console 
reported something like below:

   xbdback backend/vbd/2/5632: unknown device 0x7665642f

With vnd or dk based disk, it would actually refer to the name of the 
block device, e.g. vnd0d, or dk1, instead of 'unknown device'.

DomU console, on the other hand, reported:
   xbd2 at xenbus0 id 5632: Xen Virtual Block Device Interface

However, if  I did a 'disklabel xbd2' (in the domU, obviously), I'll get 
an error from disklabel:

   disklabel: ioctl DIOCGDINFO: Device not configured

I'm guessing, the hang occurred because the boot process couldn't get 
disk geometry info when encountering the xbd that was backed by a raw
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stephen Borrill | 29 Mar 17:45
Picon
Favicon

XenServer virtual disks attach in wrong order

I'm running a 6.0_BETA PV guest in XenServer and have added a second 
virtual disk. In XenCenter this is shown as (approx):
pos name size device
0 root 10GB  /dev/xvda
1 test 1GB /dev/xvdb

However, the 1GB (/dev/xvdb) disk is mapped to /dev/xbd0 and 10GB 
(/dev/xvda) is mapped to /dev/xbd1.
xbd0 at xenbus0 id 51728: Xen Virtual Block Device Interface
xbd1 at xenbus0 id 51712: Xen Virtual Block Device Interface
[snip]
boot device: xbd0
root on xbd0a dumps on xbd0b

I guess this is related to:
http://mail-index.netbsd.org/port-xen/2012/02/09/msg007127.html

The id figures are 0xca10 and 0xca00 respectively.

--

-- 
Stephen
Permalink | Reply | 3 comments |
headers
Benny Siegert | 18 Mar 15:15
Picon
Gravatar

6.0_BETA Dom0 does not start X any more

Hi!

First of all, I sent this twice to this list already but it never
showed up -- I am guessing that this is because the other mail
contained MIME attachments. I am sending them as links instead.

I am running a NetBSD Dom0 with several HVM DomUs on a Dell Zino HD,
which has all AMD/ATI components. The setup was working fine under
5.99.51 with Xen 3.3. I had a custom Dom0 kernel that included an alc
network driver and used no ACPI drivers. The xen and NetBSD kernel is
loaded from grub2.

Now I upgraded to the latest xenkernel33 and 6.0_BETA. Contrary to
5.99.51, the kernel only boots _with_ ACPI (even GENERIC). So my Dom0
kernel only contains alc in addition to XEN3_DOM0.
However, when booting this kernel, X does not start, while it does
under GENERIC.

The DMESG of the two kernels can be found at:
http://miros.s3.amazonaws.com/dmesg/dmesg.old.txt (5.99.51)
http://miros.s3.amazonaws.com/dmesg/dmesg.6.txt (6.0_BETA)

The error message from X is:

X.Org X Server 1.6.3
Release Date: 2009-7-7
X Protocol Version 11, Revision 0
Build Operating System: NetBSD/amd64  - Current Operating System:
NetBSD edamame 6.0_BETA NetBSD 6.0_BETA (EDAMAME_DOM0) #1: Sat Mar  3
17:56:35 CET 2012
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephen Borrill | 15 Mar 13:35
Picon
Favicon

NetBSD/i386 6.0_BETA HVM won't boot

I've been installing 6.0_BETA (i386 and amd64) on XenServer 6.0.2 by doing 
a HVM install and then converting to PV. amd64 was fine (as was netbsd-6 
i386), but after installing, i386 will not boot. The bootloader loads 
relevant modules and the kernel, but as soon as the kernel is entered the 
VM powers off. No errors are seen.

--

-- 
Stephen
Permalink | Reply | 2 comments |

Gmane