gmane.os.netbsd.ports.xen

Re: Dom0 LOCKDEBUG panic

Christoph Egger — 2012-05-23T10:03:24


[...]

Fixed in sys/arch/xen/xen/xbdback_xenbus.c rev. 1.56.

Christoph

Dom0 LOCKDEBUG panic

Christoph Egger — 2012-05-22T15:27:38

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

Re: Using vesa with Xen on NetBSD 6.0 BETA

Manuel Bouyer — 2012-05-21T10:38:06

No idea, sorry. I've not looked at this at all.

Re: Using vesa with Xen on NetBSD 6.0 BETA

Roger Pau Monné — 2012-05-16T17:02:09

That's what I though, that NetBSD/Xen didn't have support for vesa,
could you elaborate how to add support for it? Shouldn't it need some
kind of memory access to be able to connect to the video card?

Thanks!

Re: Using vesa with Xen on NetBSD 6.0 BETA

Manuel Bouyer — 2012-05-16T16:54:08

Unless I missed something, vesa is not supported for NetBSD/Xen.
It may not be very hard to add support, it should just be a matter
of making the command line option known.

Using vesa with Xen on NetBSD 6.0 BETA

Roger Pau Monné — 2012-05-16T16:49:58

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!

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

David Brownlee — 2012-05-13T18:50:04

Thanks - I'll ignore :)

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

Michael L. Hitch — 2012-05-10T14:36:31


   Well, it's 'normal' in that it always seems to occur.  It does not 
appear to be causing any problems, as the evtchn_do_event resets the ipl 
to what it expects.

   The only handler I've seen doing that is xen_timer_handler(), which 
calls hardclock(), and I think that's where the ipl may get raised and not 
lowered.  I've tried looking at it to figure out why, but haven't gotten 
very far.

   There's a PR open for this:  port-xen/46313.

Mike

--
Michael L. Hitchmhitch< at >montana.edu
Computer Consultant
Information Technology Center
Montana State UniversityBozeman, MTUSA

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

David Brownlee — 2012-05-10T13:47:05

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

Re: Using logical volumes as xen disks

John Nemeth — 2012-05-07T17:41:19

} 
} 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'

     Reading the Xen logs on the dom0 would have given you a strong
hint.  Anyways, the Xen stuff doesn't seem to like symbolic links, so
you need to give the physical paths, i.e.:

disk = [ 'phy:/dev/mapper/vg0-domu--ns1,0x1,w' ]
#disk = [ 'phy:/dev/mapper/vg0-domu--ns1,0x1,w', 'file:/usr/local/isos/NetBSD-5.1,0x2,r' ]

} I also noticed that the logical volume cannot be vnconfig'd:
} 
}    # vnconfig vnd0 /dev/vg0/lv0
}    vnconfig: /dev/rvnd0d: VNDIOCSET: Operation not supported

     You can't do that.  vnd is for files, not devices.

}-- End of excerpt from Louis Guillaume

Using logical volumes as xen disks

Louis Guillaume — 2012-05-07T15:04:27

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

Crash in -current amd64 domU

Jeff Rizzo — 2012-05-04T16:04:55

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) ---

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

Toby Karyadi — 2012-04-11T17:55:26

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

Re: NetBSD-6.0_Beta - No X11 with Xen

Sad Clouds — 2012-04-10T19:28:41

On Mon, 09 Apr 2012 17:11:35 -0500
eric< at >cirr.com (Eric Schnoebelen) wrote:


Hmm... 

atom510$ pwd
/opt/src/sys/arch/amd64/conf
atom510$ grep 'INSECURE' XEN3_DOM0
options         INSECURE        # disable kernel security levels - X
needs this atom510$ 

well two more bits of info in case someone knows what is going on:

1. X11 was built and installed from pkgsrc, and not from NetBSD base
system. Are there specific Xen patches in NetBSD X11 source tree??

2. The only interesting info in log file I see is

(II) LoadModule: "int10"
(II) Loading /opt/pkg/lib/xorg/modules//libint10.so
(II) Module int10: vendor="X.Org Foundation"
        compiled for 1.6.5, module version = 1.0.0
        ABI class: X.Org Video Driver, version 5.0
(II) VESA(0): initializing int10
(WW) VESA(0): remove MTRR a0000 - c0000
(WW) VESA(0): remove MTRR c0000 - 100000
(EE) VESA(0): V_BIOS address 0x0 out of range
(II) UnloadModule: "vesa"
(II) UnloadModule: "int10"
(II) Unloading /opt/pkg/lib/xorg/modules//libint10.so
(II) UnloadModule: "vb

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

Jeff Rizzo — 2012-04-03T23:22:29

I believe a block device is expected, hence the problems you're seeing.  
I'm using LVM with Xen just fine:

disk = [ 'phy:/dev/mapper/vg0-peerroot,hda,w',
         'phy:/dev/mapper/vg0-peerswap,hdb,w',
]

+j

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

Toby Karyadi — 2012-04-01T03:40:50

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

Re: XenServer virtual disks attach in wrong order

Manuel Bouyer — 2012-03-30T13:04:10

Not really, it's just a matter of writing code :)

Re: XenServer virtual disks attach in wrong order

Stephen Borrill — 2012-03-30T12:43:14

Indeed:
[root< at >xenserver2 ~]# xenstore-ls /local/domain/38/device/vbd
51728 = ""
  backend = "/local/domain/0/backend/vbd/38/51728"
  protocol = "x86_64-abi"
  state = "4"
  backend-id = "0"
  device-type = "disk"
  virtual-device = "51728"
  ring-ref = "511"
  event-channel = "8"
51712 = ""
  backend = "/local/domain/0/backend/vbd/38/51712"
  protocol = "x86_64-abi"
  state = "4"
  backend-id = "0"
  device-type = "disk"
  virtual-device = "51712"
  ring-ref = "510"
  event-channel = "9"

Any reason not to sort on id in xenbus_probe_device_type()?

Re: XenServer virtual disks attach in wrong order

Manuel Bouyer — 2012-03-29T17:35:27

yes, that's the same problem. I guess it's because XenCenter puts the
VBD configs in reverse order ...

XenServer virtual disks attach in wrong order

Stephen Borrill — 2012-03-29T15:45:02

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.

Re: NetBSD/i386 6.0_BETA HVM won't boot

Stephen Borrill — 2012-03-19T11:02:57

I used the same ISO and repeated the procedure twice. I used a 10GB 
virtual disk and accepted 508MB for swap in the installer. The only change 
I made from the defaults was to switch the root filesystem to FFSv1 
(because pygrub doesn't like FFSv2).

Odd.