Re: [Fedora-xen] Summary: Experiences setting up a debug serial port (was Re: [Xen-users] 3.1.0-rc0 git snapshot crashes as dom0 (private mail))
by Todd Deshane
(adding fedora-xen to the CC)
On Tue, Aug 30, 2011 at 5:17 PM, jim burns <jim_burn(a)bellsouth.net> wrote:
> On Tue August 23 2011, 5:12:52 PM, jim burns wrote:
>> On Tue August 16 2011, 7:46:33 PM, jim burns wrote:
>> > On Mon August 15 2011, 4:04:20 AM, jim burns wrote:
>> >> Pls cc me with responses, as I'm not subscribed.
>> >
>> > Yay! After a string of fedora rawhide 3.1.0-rc0 and -rc1's that did not
>> > boot under xen, 3.1.0-0.rc2.git0.1.fc17.x86_64 boots under xen, it has
>> > the vga patch, and xen-pciback correctly siezes my wireless device.
>> > Unfortunately, while a baremetal boot is clean, a xen boot has several
>>
>> > BUG:'s of the form:
>> Rawhide is up to 3.1.0-0.rc3.git0.0.fc17.x86_64 , and it still has the same
>> BUGS: of the form:
>>
>> BUG: scheduling while atomic: modprobe/493/0x10000002
>>
>> BUG: sleeping function called from invalid context at kernel/mutex.c:271
>>
>> BUG: scheduling while atomic: xenstored/3184/0x10000002
>>
>> both while booting up under xen, and when starting and stopping a(n hvm)
>> guest.
>
> Rawhide is up to 3.1.0-0.rc4.git0.0.fc17 , and still the same bugs, plus the
> new one 'spinlock wrong CPU':
>
> Aug 30 17:07:13 Insp6400 kernel: [ 9.657492] BUG: sleeping function called
> from invalid context at kernel/mutex.c:271
> Aug 30 17:07:13 Insp6400 kernel: [ 9.657553] in_atomic(): 1,
> irqs_disabled(): 0, pid: 254, name: modprobe
> --
> Aug 30 17:07:13 Insp6400 kernel: [ 9.714251] BUG: scheduling while atomic:
> modprobe/254/0x10000002
> Aug 30 17:07:13 Insp6400 kernel: [ 9.715224] 3 locks held by modprobe/254:
> --
> Aug 30 17:07:13 Insp6400 kernel: [ 52.675476] BUG: sleeping function called
> from invalid context at kernel/mutex.c:271
> Aug 30 17:07:13 Insp6400 kernel: [ 52.676191] in_atomic(): 1,
> irqs_disabled(): 0, pid: 511, name: modprobe
> --
> Aug 30 17:07:13 Insp6400 kernel: [ 52.682754] BUG: scheduling while atomic:
> modprobe/511/0x10000002
> Aug 30 17:07:13 Insp6400 kernel: [ 52.682754] 3 locks held by modprobe/511:
> --
> Aug 30 17:07:13 Insp6400 kernel: [ 52.867221] BUG: spinlock wrong CPU on
> CPU#1, modprobe/511
> Aug 30 17:07:13 Insp6400 kernel: [ 52.868082] lock: ffffffff81a7de60,
> .magic: dead4ead, .owner: modprobe/511, .owner_cpu: 0
> --
> Aug 30 17:07:13 Insp6400 kernel: [ 55.038559] BUG: sleeping function called
> from invalid context at kernel/mutex.c:271
> Aug 30 17:07:13 Insp6400 kernel: [ 55.039487] in_atomic(): 1,
> irqs_disabled(): 0, pid: 508, name: modprobe
> --
> Aug 30 17:07:13 Insp6400 kernel: [ 55.039487] BUG: scheduling while atomic:
> modprobe/508/0x10000002
> Aug 30 17:07:13 Insp6400 kernel: [ 55.039487] INFO: lockdep is turned off.
> --
> Aug 30 17:07:13 Insp6400 kernel: [ 55.153964] BUG: scheduling while atomic:
> modprobe/508/0x10000002
> Aug 30 17:07:13 Insp6400 kernel: [ 55.154664] INFO: lockdep is turned off.
> --
> Aug 30 17:08:04 Insp6400 kernel: [ 117.158477] BUG: sleeping function called
> from invalid context at kernel/mutex.c:271
> Aug 30 17:08:04 Insp6400 kernel: [ 117.159068] in_atomic(): 1,
> irqs_disabled(): 0, pid: 3204, name: xenstored
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users(a)lists.xensource.com
> http://lists.xensource.com/xen-users
>
--
Todd Deshane
http://www.linkedin.com/in/deshantm
http://www.xen.org/products/cloudxen.html
http://runningxen.com/
12 years
F15 kernel Xen support missing PCI passthrough?
by Hilton Day
After recently discovering 2.6.40 is secretly Kernel 3 in disguise, and
includes pvops, 5 years after my last post on Fedora-Xen, I'm back.
I've been running Xen on a home server for well, just over 5 years, the
last three of which have been on a Centos5 dom0, in the absence of dom0
support in Fedora since FC6.
I've installed a fresh machine, and can get a dom0 running in Fedora 15
using 2.6.40 and the default xen-4.1.1 packages, as well as DomU's
running Centos5, Scientific Linux 6, Fedora 15 and Solaris 11, so all
good there.
But I've hit a snag. The Fedora kernel doesn't appear to include the
xen-pciback kernel module (or indeed any module with "pciback" in its
name). I use PCI Passthrough to donate a physical NIC to one of the
domU's which runs the network gateway/firewall/transparent proxy etc.
for the network.
I've grabbed the kernel source rpm and checked out the config files, and
they appear to be completely missing the XEN_PCIDEV_BACKEND flags.
Being new to Fedora 15, Kernel 3 and Xen4.x all at once, is there some
new trick that isn't documented online, or am I right in seeing a lack
of PCI pass-through support in the Fedora kernel?
My next step is to try adding the compile flags to the .config and
rebuilding the kernel - but would appreciate anyone's input with more
experience of the Fedora environment.
Thanks,
Hilton.
12 years, 1 month
Positive experience updating Dom0 from f14/2.6.32/4.0.2 to f15/2.6.40/4.1
by Bill McGonigle
Just some notes, in case others are planning similar upgrades.
I was running 2.6.32 from M. Young's repo. My goal was to get up to
2.6.40 on Fedora 15 (mainline dom0!) with minimal downtime.
I found that f15's version of Xen (4.1) wouldn't run, even after
re-compiling on f14. So, that couldn't be staged ahead of time. As a
retreat plan, I made sure to have rpm's for Xen 4.0.2 handy, but they
wound up being unnecessary.
I knew there'd be some xend breakage during the upgrade, so I opened ssh
sessions to each VM.
I then started the yum upgrade, first with yum and rpm, then only the
fedora and updates repos, then other repos. Some package upgrade
problems needed to be solved (I have too much in dom0), but nothing
worse than usual.
Once all the upgrades were in place, I hand-edited grub.conf since the
new kernel installed a non-Xen entry.
At this point, I should have checked to see that my initramfs was made
properly (it wasn't, locally packaged zfs modules broke the scriptlet).
I had to come back in with rescue mode to re-run dracut.
Once all the updates were installed, I shut down each of the VM's using
native 'shutdown -h now' inside the vm. xm shutdown was broken at this
point.
Now, the only ugly part is that systemd wasn't yet running, but 'reboot'
is replaced. So, to reboot the system, I had to do 'sync;sync;sync
[reset button]'. I had filesystems mounted -o data=journal, so I was at
least feeling good about consistency. Some people wouldn't tolerate
this option, but it worked out OK for me.
With a working initramfs, the system came up just fine, the VM's started
as they should, and everything seemed OK from the Xen perspective. All
the domU's function, no domU updates required (Fedora 12/13/14, CentOS 5).
If I had noticed the initramfs problem properly, I would have gotten
away with only about a 4 minute outage. Quite glad to be re-united,
after many years in the Fedora/Xen exile community! Much kudos to
Michael Young, Pasi, and all the others who have helped up through the
dark times.
-Bill
--
Bill McGonigle, Owner
BFC Computing, LLC
http://bfccomputing.com/
Telephone: +1.855.SW.LIBRE
Email, IM, VOIP: bill(a)bfccomputing.com
VCard: http://bfccomputing.com/vcard/bill.vcf
Social networks: bill_mcgonigle/bill.mcgonigle
12 years, 1 month
CentOS 6 install via virt-install - "No usable disks have been found."
by Bill McGonigle
Hi, all,
I'm not seeing disks under CentOS 6 when trying to install. I'm using:
xen-4.0.2-1.fc14.x86_64
2.6.32.39-175.xendom0.fc13.x86_64
installing using:
virt-install --debug -n sully --mac=02:00:0A:01:01:10 -f
/var/lib/xen/images/sully -s 12 -r 2048 --vcpus=2 --nographics -p
--os-type=linux --os-variant=rhel6 --location
http://librescu.bfccomputing.com/cobbler/ks_mirror/centos6-x86_64/
It sounded like:
https://bugzilla.redhat.com/show_bug.cgi?id=678374
so I tried dropping the --nonsparse option, but I'm using a newer
version of python-virtinstall:
python-virtinst-0.500.6-1.fc14.noarch
than should be required, and I'm seeing this with and with the option
anyway.
I do see the disk image is created, and attached to the DomU. e.g.:
[2011-07-26 01:01:47 18534] DEBUG (DevController:97) DevController:
writing {'domain': 'sully', 'frontend':
'/local/domain/18/device/vbd/51712', 'uuid':
'3380cea8-a322-292d-cc5d-8bb084306976', 'bootable': '1', 'dev': 'xvda',
'state': '1', 'params': 'aio:/var/lib/xen/images/sully', 'mode': 'w',
'online': '1', 'frontend-id': '18', 'type': 'tap'} to
/local/domain/0/backend/tap/18/51712.
and I can see the disk image if I dump configuration from virsh.
I do see this in the DomU kernel messages:
XENBUS: Device with no driver: device/vbd/51712
XENBUS: Device with no driver: device/vif/0
XENBUS: Device with no driver: device/console/0
but I see reports online that say not to worry about those, initrd will
load the modules.
The initrd does have:
./kernel/drivers/xen
./kernel/drivers/xen/xenfs
./kernel/drivers/net/xen-netfront.ko.gz
./kernel/drivers/block/xen-blkfront.ko.gz
on it.
I tried adding:
xen_emul_unplug=never
to the kernel parameters per a previous thread here, but that didn't
seem to change anything.
It seems like others are having success with CentOS 6 in general:
http://grantmcwilliams.com/tech/virtualization/xen-howtos/538-centos-6-vi...
so I suspect it's got something to do with Xen 4.0.2, but I'm not sure
where to look right now.
Any suggestions?
-Bill
--
Bill McGonigle, Owner
BFC Computing, LLC
http://bfccomputing.com/
Telephone: +1.855.SW.LIBRE
Email, IM, VOIP: bill(a)bfccomputing.com
VCard: http://bfccomputing.com/vcard/bill.vcf
Social networks: bill_mcgonigle/bill.mcgonigle
12 years, 1 month
Re: [Fedora-xen] [Xen-devel] Re: Xl and /dev/null (no domU cfgfile)
by Ian Jackson
Ian Campbell writes ("Re: [Xen-devel] Re: [Fedora-xen] Xl and /dev/null (no domU cfgfile)"):
> On Mon, 2011-08-01 at 23:03 +0100, Pasi Kärkkäinen wrote:
> > On Mon, Aug 01, 2011 at 01:30:43PM -0500, W. Michael Petullo wrote:
> > > $ sudo xl create /dev/null
> > > libxl: error: libxl_utils.c:328:libxl_read_file_contents /dev/null is not a plain file: Success
> > > Failed to read config file: /dev/null: Inappropriate ioctl for device
>
> That's a pretty weird interface, probably more of a coincidence than a
> deliberate feature. Far better would be to just make the file optional.
> Can someone cook up such a patch?
The error message is a bit poor too.
> If we are looking to be bug/oddity compatible with xm then we could
> remove the S_ISREG check from libxl_read_file_contents. I suppose that,
> in principal at least, there is no reason to prevent people reading
> pipes, fifos, symlinks or even character devices to get the
> configuration file. (unless we might potentially read it multiple
> times?).
The reason for the S_ISREG check is that xl needs to take the config
file and store it as the userdata. That means it needs to read the
whole thing into memory, which is easier if you can stat the file to
find out its length.
It would not be impossible or unreasonable to relax this restriction.
I would be happy to take a patch that used a realloc approach in the
!S_ISREG case.
Ian.
12 years, 1 month
