[Fedora-xen] Xen install test: On Fedora 17, install Fedora 17. Mouse problem?

2012-10-30 Thread Marko Ristola


Hi

I don't have a bugzilla report item from this yet, maybe later.

I have now Xen Dom0 Fedora 17 configuration, no experimental packages.
Desktop computer is rather new and supports hardware virtualization, but not 
IOMMU.

Test: Install paravirtual 64 bit Xen guest, Fedora 17 with HTTP based install.

- With Virt-manager installing went flawlessly.
- After reboot, I got in Finnish with a graphical picture: Voi ei! Jotain meni 
pieleen.
This means Oh no, something got wrong.
So it seems that GDM doesn't work with Xen with default virt-manager settings.

- I can make Login screen by switching from GDM to KDM. Mouse works there:
/etc/sysconfig/desktop: DISPLAYMANAGER=KDE
- From KDM I can start Gnome. Mouse works but Mouse cursor is invisible.
- If I start, via KDM, IceWM, mouse works and is visible.

I don't know if Fedora 18 will have this issue too.
It would be nice if Fedora as Dom0 would just work for Fedora Xen DomU
with default options. Maybe plain AbsoluteAxis for paravirtual mouse
would be the best option, no relative axis enabled by default?
Maybe co-operation with Gnome people is needed to finish this issue?

Regards,
Marko Ristola

Fail case, from guest's /var/log/Xorg.0.log:

[   182.116] (II) config/udev: Adding input device Xen Virtual Pointer 
(/dev/input/event1)
[   182.116] (**) Xen Virtual Pointer: Applying InputClass evdev pointer 
catchall
[   182.116] (**) Xen Virtual Pointer: Applying InputClass Xen Virtual Pointer axis 
blacklist
[   182.116] (II) Using input driver 'evdev' for 'Xen Virtual Pointer'
[   182.116]Option XkbRules evdev
[   182.116]Option XkbModel evdev
[   182.116]Option XkbLayout us
[   182.116]Option _source server/udev
[   182.116]Option name Xen Virtual Pointer
[   182.116]Option path /dev/input/event1
[   182.116]Option device /dev/input/event1
[   182.116]Option config_info 
udev:/sys/devices/virtual/input/input1/event1
[   182.116]Option driver evdev
[   182.116]Option IgnoreAbsoluteAxes off
[   182.116]Option IgnoreRelativeAxes off
[   182.116] (**) Xen Virtual Pointer: always reports core events
[   182.116] (**) evdev: Xen Virtual Pointer: Device: /dev/input/event1
[   182.116] (--) evdev: Xen Virtual Pointer: absolute axis 0 [800..0]
[   182.116] (--) evdev: Xen Virtual Pointer: absolute axis 0x1 [600..0]
[   182.116] (--) evdev: Xen Virtual Pointer: Vendor 0x5853 Product 0xfffe
[   182.116] (**) Option IgnoreRelativeAxes off
[   182.116] (**) Option IgnoreAbsoluteAxes off
[   182.116] (--) evdev: Xen Virtual Pointer: Found 12 mouse buttons
[   182.116] (--) evdev: Xen Virtual Pointer: Found scroll wheel(s)
[   182.116] (--) evdev: Xen Virtual Pointer: Found relative axes
[   182.116] (--) evdev: Xen Virtual Pointer: Found absolute axes
[   182.116] (--) evdev: Xen Virtual Pointer: Found x and y absolute axes
[   182.116] (--) evdev: Xen Virtual Pointer: Found absolute touchscreen
[   182.116] (II) evdev: Xen Virtual Pointer: Configuring as touchscreen
[   182.116] (II) evdev: Xen Virtual Pointer: Adding scrollwheel support
[   182.116] (**) evdev: Xen Virtual Pointer: YAxisMapping: buttons 4 and 5
[   182.116] (**) evdev: Xen Virtual Pointer: EmulateWheelButton: 4, 
EmulateWheelInertia: 10, EmulateWheelTimeout: 200
[   182.116] (**) Option config_info 
udev:/sys/devices/virtual/input/input1/event1
[   182.116] (II) XINPUT: Adding extended input device Xen Virtual Pointer 
(type: TOUCHSCREEN, id 7)
[   182.116] (II) evdev: Xen Virtual Pointer: initialized for relative axes.
[   182.116] (II) evdev: Xen Virtual Pointer: initialized for absolute axes.
[   182.116] (**) Xen Virtual Pointer: (accel) keeping acceleration scheme 1
[   182.116] (**) Xen Virtual Pointer: (accel) acceleration profile 0
[   182.117] (**) Xen Virtual Pointer: (accel) acceleration factor: 2.000
[   182.117] (**) Xen Virtual Pointer: (accel) acceleration threshold: 4
[   182.117] (II) config/udev: Adding input device Xen Virtual Pointer 
(/dev/input/mouse0)
[   182.117] (**) Xen Virtual Pointer: Applying InputClass Xen Virtual Pointer axis 
blacklist
[   182.117] (II) No input driver specified, ignoring this device.
[   182.117] (II) This device may have been added with another device file.
[   182.123] (EE) FBDEV(0): FBIOBLANK: Invalid argument
--
xen mailing list
xen@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/xen

Re: [Fedora-xen] Boot errors, https://bugzilla.redhat.com/show_bug.cgi?id=804347

2012-05-14 Thread Marko Ristola


Michael Young's latest Xen hypervisor build 4.1.3-rc1
seems to fix my Dom0 NFS server crash problem.
Dom0 NFS server is as stable as with vanilla kernel.
I booted Dom0 (standard Fedora 17 kernel) with serial console, with all debug 
flags turned on.

Old problematic Xen hypervisor was the current Fedora 17 one.

Regards,
Marko

On 05/13/2012 08:42 PM, Marko Ristola wrote:
...


So I took the Dom0 server as the NFS server and it has now Fedora 17.
Motherboard: FUJITSU SIEMENS A8NE-FM 1011-005, two CPUs.
On Fedora 17, without Dom0 the computer seems to work fine
(once locked up during software RAID5 resync).
While running as Dom0, using the NFSv4 kernel server (with idmap) will cause a 
kernel oops and reboot instantly.


...


Regards,
Marko


...

--
xen mailing list
xen@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/xen

Re: [Fedora-xen] Boot errors, https://bugzilla.redhat.com/show_bug.cgi?id=804347

2012-05-13 Thread Marko Ristola


Thanks for taking time for this.
I have swithced on the Dom0 server into latest Fedora 17 RC this
weekend.

I had severe problems with non-Xen i386 non-PCIE rack server
with NFS etc: IBM xSeries 306. It halted with latest Fedora 16 kernel
about two minutes after successful boot. Before these problems,
NFS server could livelock, if for example compiling or copying Kernel
over NFS.

So I took the Dom0 server as the NFS server and it has now Fedora 17.
Motherboard: FUJITSU SIEMENS A8NE-FM 1011-005, two CPUs.
On Fedora 17, without Dom0 the computer seems to work fine
(once locked up during software RAID5 resync).
While running as Dom0, using the NFSv4 kernel server (with idmap) will cause a 
kernel oops and reboot instantly.

I haven't got the kernel message log yet.

So the SELinux problem isn't now at the topmost on my list.

(With another non-PCIE AMD motherboard disabling MSI interrupts and
making motherboard use only interrupts  16, made it work with Fedora 16
without Dom0. As Dom0 it doesn't work).

Regards,
Marko

On 05/10/2012 06:42 PM, Konrad Rzeszutek Wilk wrote:

On Tue, Mar 27, 2012 at 11:07:09PM +0300, Marko Ristola wrote:

On 03/27/2012 07:07 PM, Konrad Rzeszutek Wilk wrote:

On Tue, Mar 27, 2012 at 06:42:46PM +0300, Marko Ristola wrote:

Xen paravirtual virtual guest machine works too with SELinux disabled.


Why did you need to disable SELinux? Is there a BZ for that?


BZ entry is https://bugzilla.redhat.com/show_bug.cgi?id=749172

pygrub called by Xend reads grub settings from within the
disk image. Thus xend needs for virtual disk image
xen_image_t SELinux type.

I use qemu-dm for the DomU disk access after booting.
/usr/lib/xen/bin/qemu-dm works with virt_image_t SELinux type.

I can't put those both SELinux types for the disk image.

I don't know what kind of SELinux policy / binary file
labeling change is needed to fix it.


I thought it was xen_disk_t? There are some slides by Walsh about
what your need for LVM and Xen - see if Google comes up with anything.



Regards,
Marko Ristola


--
xen mailing list
xen@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/xen

Re: [Fedora-xen] Boot errors, https://bugzilla.redhat.com/show_bug.cgi?id=804347

2012-03-27 Thread Marko Ristola

On 03/27/2012 07:07 PM, Konrad Rzeszutek Wilk wrote:

On Tue, Mar 27, 2012 at 06:42:46PM +0300, Marko Ristola wrote:

Xen paravirtual virtual guest machine works too with SELinux disabled.


Why did you need to disable SELinux? Is there a BZ for that?


BZ entry is https://bugzilla.redhat.com/show_bug.cgi?id=749172

pygrub called by Xend reads grub settings from within the
disk image. Thus xend needs for virtual disk image
xen_image_t SELinux type.

I use qemu-dm for the DomU disk access after booting.
/usr/lib/xen/bin/qemu-dm works with virt_image_t SELinux type.

I can't put those both SELinux types for the disk image.

I don't know what kind of SELinux policy / binary file
labeling change is needed to fix it.

Regards,
Marko Ristola
--
xen mailing list
xen@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/xen

Re: [Fedora-xen] Grubby fix isn't enough for Fedora 16: Fedora 16 uses Grub2

2011-08-17 Thread Marko Ristola
On 08/16/2011 09:26 PM, Pasi Kärkkäinen wrote:
 Thanks for testing!
 I need to install F16 myself aswell..


I used VESA mode with the Fedora 16 Live CD. Modesetting with Radeon didn't 
work.
Live CD install first crashed, but didn't crash at 2nd try.
After reboot, I switched into another VT, because initial welcome, add users
didn't show up. I turned off gpg checks from /etc/yum.repos.d:
GPG keys for Fedora 16 were missing under /etc/pki/...: bad soft links.

I turned off Rawhide repository.
I upgraded Fedora 16 from the command line. Then reboot.

After that Fedora 16 welcome, add users started up graphically: works as it 
should.
I could go back to modesetting from VESA by moving /etc/X11/xorg.conf away and
changing /etc/default/grub's Kernel parameters: remove nomodeset.
grub2-mkconfig -o /boot/grub2/grub.cfg will rebuild grub2 configurations.

Then basic Fedora 16 works.

Marko
--
xen mailing list
xen@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/xen


[Fedora-xen] Grubby fix isn't enough for Fedora 16: Fedora 16 uses Grub2

2011-08-16 Thread Marko Ristola

Hi

I've experimented with a fresh Fedora 16,

I've installed Fedora 16 from nightly CD.
Fedora 16 uses Grub2, so grubby fix isn't enough for dom0.
Grub2 has Xen Dom0 config script as /etc/grub.d/20_linux_xen on Fedora 16.
The script searches initrd-* files from /boot.
It should search initramfs-* files too. Thus Dom0 will not be able to boot.
I've written a bug report about that, maybe it is against Rawhide now, with
a patch to apply.

Another problem on Fedora 16 seems to be that while yum installs a new upgraded 
kernel,
Xen Dom0 rows will not get generated. I don't know why.
If /etc/grub.d/20_linux_xen works okay, grub2 config can be easilly
fixed afterwards by hand with grub2-mkconfig.

I've learned to switch from Grub1 to Grub2 with BIOS boot (not EFI).
One way is to move partitions down so that there is 1MB or more
disk space outside of partitions, just at disk start.

Switching to grub2 isn't easy. Better plan and prepare or start from
an empty hard disk before switching to grub2:
Fresh Fedora 16 install into an empty hard disk (without partitions)
does it all for you (creates a BIOS boot partition,
which is an alternative to 1MB outside partition space).

Marko
--
xen mailing list
xen@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/xen


Re: [Fedora-xen] Fedora 15 Xen Kernel Make w/Mutex Errors

2011-08-09 Thread Marko Ristola

Do you want to experiment on Fedora with the bleeding edge on Fedora 15?

xen-4.1.1-2 is the last Xen package by Michael Young, already compiled:
http://koji.fedoraproject.org/koji/buildinfo?buildID=254393

In addition I use the latest stock Fedora 15 kernel.
I don't have a Xen guest virtual machine though.

Regards,
Marko Ristola

07.08.2011 23:38, Michael J. Fuhrman wrote:
 Dear Community,
 
 Has anyone else run into this make issue. Near the end of the compile, I get 
 the 
 following errors:
 
 kernel/built-in.o: In function `.text.lock.mutex':
 mutex.c:(.sched.text+0x1a45): undefined reference to `__mutex_lock_slowpath'
 mutex.c:(.sched.text+0x1a4f): undefined reference to `__mutex_unlock_slowpath'
 
 ===
 
 Following instructions from http://wiki.xen.org/xenwiki/Xen4.0;, I reran the 
 package installs to make sure they were updated. I also downloaded an 
 installed 
 the Fedora 15 source files, following instructions from 
 http://fedoraproject.org/wiki/Building_a_custom_kernel;.
 
 Suggestions?
 
 Mike,
 
 ===
 
 [ ... xen-4.1.1]# make kernels KERNELS=linux-2.6-xen0 linux-2.6-xenU
 for i in linux-2.6-xen0 linux-2.6-xenU ; do make $i-install || exit 1; done
 make[1]: Entering directory `/tmp/xen-4.1.1'
 make -f buildconfigs/mk.linux-2.6-xen0 build
 make[2]: Entering directory `/tmp/xen-4.1.1'
 if grep ^CONFIG_MODULES= build-linux-2.6.18-xen0_x86_64/.config ; then \
 make -C build-linux-2.6.18-xen0_x86_64 ARCH=$(sh 
 buildconfigs/select-linux-arch 
 linux-2.6.18-xen.hg) modules || exit 1 ; \
 make -C build-linux-2.6.18-xen0_x86_64 ARCH=$(sh 
 buildconfigs/select-linux-arch 
 linux-2.6.18-xen.hg) INSTALL_MOD_PATH=/tmp/xen-4.1.1/dist/install 
 modules_install ; \
 fi
 CONFIG_MODULES=y
 select-linux-arch: x86_64
 make[3]: Entering directory `/tmp/xen-4.1.1/build-linux-2.6.18-xen0_x86_64'
 make -C /tmp/xen-4.1.1/linux-2.6.18-xen.hg 
 O=/tmp/xen-4.1.1/build-linux-2.6.18-xen0_x86_64 modules
 Using /tmp/xen-4.1.1/linux-2.6.18-xen.hg as source for kernel
 GEN /tmp/xen-4.1.1/build-linux-2.6.18-xen0_x86_64/Makefile
 CHK include/linux/version.h
 CHK include/linux/utsrelease.h
 Building modules, stage 2.
 MODPOST
 make[3]: Leaving directory `/tmp/xen-4.1.1/build-linux-2.6.18-xen0_x86_64'
 select-linux-arch: x86_64
 make[3]: Entering directory `/tmp/xen-4.1.1/build-linux-2.6.18-xen0_x86_64'
 make -C /tmp/xen-4.1.1/linux-2.6.18-xen.hg 
 O=/tmp/xen-4.1.1/build-linux-2.6.18-xen0_x86_64 modules_install
 INSTALL crypto/crc32c.ko
 INSTALL crypto/des.ko
 INSTALL crypto/md5.ko
 INSTALL crypto/sha1.ko
 INSTALL drivers/acpi/ac.ko
 INSTALL drivers/acpi/asus_acpi.ko
 INSTALL drivers/acpi/battery.ko
 INSTALL drivers/acpi/button.ko
 INSTALL drivers/acpi/container.ko
 INSTALL drivers/acpi/dock.ko
 INSTALL drivers/acpi/fan.ko
 INSTALL drivers/acpi/hotkey.ko
 INSTALL drivers/acpi/ibm_acpi.ko
 INSTALL drivers/acpi/processor.ko
 INSTALL drivers/acpi/thermal.ko
 INSTALL drivers/acpi/toshiba_acpi.ko
 INSTALL drivers/acpi/video.ko
 INSTALL drivers/char/agp/agpgart.ko
 INSTALL drivers/char/agp/intel-agp.ko
 INSTALL drivers/char/agp/sis-agp.ko
 INSTALL drivers/char/agp/via-agp.ko
 INSTALL drivers/char/drm/drm.ko
 INSTALL drivers/char/drm/i810.ko
 INSTALL drivers/char/drm/i830.ko
 INSTALL drivers/char/drm/i915.ko
 INSTALL drivers/char/drm/mga.ko
 INSTALL drivers/char/drm/r128.ko
 INSTALL drivers/char/drm/radeon.ko
 INSTALL drivers/char/drm/sis.ko
 INSTALL drivers/char/drm/tdfx.ko
 INSTALL drivers/net/imq.ko
 INSTALL drivers/rtc/rtc-cmos.ko
 INSTALL drivers/rtc/rtc-core.ko
 INSTALL drivers/rtc/rtc-dev.ko
 INSTALL drivers/rtc/rtc-lib.ko
 INSTALL drivers/rtc/rtc-m48t86.ko
 INSTALL drivers/rtc/rtc-proc.ko
 INSTALL drivers/rtc/rtc-sysfs.ko
 INSTALL drivers/rtc/rtc-test.ko
 INSTALL drivers/xen/scsifront/xenscsi.ko
 INSTALL fs/exportfs/exportfs.ko
 INSTALL fs/fat/fat.ko
 INSTALL fs/msdos/msdos.ko
 INSTALL fs/nfsd/nfsd.ko
 INSTALL fs/vfat/vfat.ko
 INSTALL net/ipv4/netfilter/ip_conntrack.ko
 INSTALL net/ipv4/netfilter/ip_conntrack_ftp.ko
 if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F System.map 
 -b 
 /tmp/xen-4.1.1/dist/install -r 2.6.18.8-xen0; fi
 make[3]: Leaving directory `/tmp/xen-4.1.1/build-linux-2.6.18-xen0_x86_64'
 make -C build-linux-2.6.18-xen0_x86_64 ARCH=$(sh 
 buildconfigs/select-linux-arch 
 linux-2.6.18-xen.hg) INSTALL_PATH=/tmp/xen-4.1.1/dist/install vmlinuz
 select-linux-arch: x86_64
 make[3]: Entering directory `/tmp/xen-4.1.1/build-linux-2.6.18-xen0_x86_64'
 make -C /tmp/xen-4.1.1/linux-2.6.18-xen.hg 
 O=/tmp/xen-4.1.1/build-linux-2.6.18-xen0_x86_64 vmlinuz
 Using /tmp/xen-4.1.1/linux-2.6.18-xen.hg as source for kernel
 GEN /tmp/xen-4.1.1/build-linux-2.6.18-xen0_x86_64/Makefile
 CHK include/linux/version.h
 CHK include/linux/utsrelease.h
 CHK include/linux/compile.h
 dnsdomainname: Name or service not known
 GEN usr/initramfs_data.cpio.gz
 AS usr/initramfs_data.o
 LD usr/built-in.o
 GEN .version
 CHK include/linux/compile.h
 dnsdomainname: Name or service

Re: [Fedora-xen] Another 2.6.38-rc6 dom0 kernel

2011-03-14 Thread Marko Ristola
13.03.2011 21:15, W. Michael Petullo kirjoitti:
 Here is another kernel (2.6.38-0.rc6.git6.1.xendom0.fc15) at
 http://koji.fedoraproject.org/koji/taskinfo?taskID=2874240
 The crash when a domU shuts down seems to be fixed.

 I just had a chance to test this, along with the
 xen-4.1.0-0.1.rc6.fc14.x86_64 Xen packages.

 Two notable things have been fixed by the Xen folks:

   xl now plays nicely with the vif-route script (see
   /etc/xen/xl.conf).

   xl is less picky about where the -c argument to create goes.

 Both of these issues were previously discussed on this list and the
 xen-devel list.

 I'm still having trouble with power management, as noted at:

   http://lists.fedoraproject.org/pipermail/xen/2011-January/005328.html

My computer doesn't power down either.
This has been seen all the time.

Under Xen hypervisor: power down doesn't work.
Without hypervisor power down works with the same kernel.

Regards,
Marko


 Other than that, my first impression of 2.6.38-0.rc6.git6.1.xendom0.fc15
 is good. I was able to load a PV OpenWrt guest using the QEMU-based
 network backend.


--
xen mailing list
xen@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/xen


Re: [Fedora-xen] Dom0 running dhcpd and domU dhclient won't work on the same machine

2011-03-04 Thread Marko Ristola
04.03.2011 14:16, Roberto Fichera kirjoitti:
 Hi All,

 does anyone has the same problem on the same configuration?
 Basically all the domU aren't able to get their ip address from the DHCPD
 server running under the same dom0 with kernel 
 2.6.32.26-174.xendom0.fc12.x86_64.
 I tried different domU kernels but it seems doesn't work at all.

 Any idea how to solve it?

 Thanks in advance.
 Roberto Fichera.
 --
 xen mailing list
 xen@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/xen

It should be solvable by configuring.

I use bridge device br0, a remote dnsmasq server for DHCP and DNS. sysctl.conf 
is
configured so that br0 works as expected: passes DHCP requests thrue.

Your case is different than mine, so you need different configurations.

Googling examples is a good start.
You could try to use iptables LOG rules to track down problems.

Regards,
Marko Ristola

--
xen mailing list
xen@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/xen


Re: [Fedora-xen] Dom0 running dhcpd and domU dhclient won't work on the same machine

2011-03-04 Thread Marko Ristola
04.03.2011 19:57, Roberto Fichera kirjoitti:

 I also read about setting off ethernet tx offload under dom0 via ethtool -K 
 eth0 tx off
 but it seems not helping to solve anything, at least in my case.

 Which kind of configuration you made in your side?

 I was just able to solve it right now!!! What I do is the ethtool setup like 
 above in dom0
 than afterwards I made a service dhcpd restart and it worked fine at the 
 price of loosing the
 tx offload automatically made by the network card.


Great that you solved it.

I had to modify /etc/sysctl.conf so that br0 bridge works as expected.
Here are the network related lines:

net.ipv4.ip_forward = 1

net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0

net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
net.ipv4.conf.default.arp_notify = 1

Without applying correct values into sysctl.conf network didn't work as 
expected for the DomU.
This isn't a bug though: you just need to find good documentation to get it 
right.

Regards,
Marko Ristola

 Regards,
 Marko Ristola

 --
 xen mailing list
 xen@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/xen

 --
 xen mailing list
 xen@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/xen



--
xen mailing list
xen@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/xen


Re: [Fedora-xen] 2.6.38-rc6 dom0 kernel

2011-02-28 Thread Marko Ristola
] 
ttm_bo_unref+0x38/0x45 [ttm]
Feb 28 19:48:17 kuusi kernel: [   72.543062]  [a00a0d04] 
radeon_bo_unref+0x42/0x5f [radeon]
Feb 28 19:48:17 kuusi kernel: [   72.543062]  [a001af5c] ? 
drm_gem_object_free+0x0/0x2d [drm]
Feb 28 19:48:17 kuusi kernel: [   72.543062]  [a00af87e] 
radeon_gem_object_free+0x35/0x4c [radeon]
Feb 28 19:48:17 kuusi kernel: [   72.543062]  [a001af87] 
drm_gem_object_free+0x2b/0x2d [drm]
Feb 28 19:48:17 kuusi kernel: [   72.543062]  [8122c4b3] 
kref_put+0x43/0x4d
Feb 28 19:48:17 kuusi kernel: [   72.543062]  [a001ae31] 
drm_gem_object_unreference_unlocked+0x33/0x40 [drm]
Feb 28 19:48:17 kuusi kernel: [   72.543062]  [a001af36] 
drm_gem_object_handle_unreference_unlocked.part.0+0x27/0x2c [drm]
Feb 28 19:48:17 kuusi kernel: [   72.543062]  [a001b269] 
drm_gem_close_ioctl+0x7a/0x86 [drm]
Feb 28 19:48:17 kuusi kernel: [   72.543062]  [a001985d] 
drm_ioctl+0x29e/0x37b [drm]
Feb 28 19:48:17 kuusi kernel: [   72.543062]  [811eb844] ? 
inode_has_perm+0x76/0x8c
Feb 28 19:48:17 kuusi kernel: [   72.543062]  [a001b1ef] ? 
drm_gem_close_ioctl+0x0/0x86 [drm]
Feb 28 19:48:17 kuusi kernel: [   72.543062]  [81006669] ? 
xen_force_evtchn_callback+0xd/0xf
Feb 28 19:48:17 kuusi kernel: [   72.543062]  [81006c02] ? 
check_events+0x12/0x20
Feb 28 19:48:17 kuusi kernel: [   72.543062]  [811eb8fe] ? 
file_has_perm+0xa4/0xc6
Feb 28 19:48:17 kuusi kernel: [   72.543062]  [81130094] 
do_vfs_ioctl+0x47e/0x4bf
Feb 28 19:48:17 kuusi kernel: [   72.543062]  [8113012b] 
sys_ioctl+0x56/0x7b
Feb 28 19:48:17 kuusi kernel: [   72.543062]  [8100abc2] 
system_call_fastpath+0x16/0x1b
Feb 28 19:48:17 kuusi kernel: [   72.543062] Code: 28 48 8d 75 d0 e8 80 34 1d 
e1 41 ff c5 49 63 c5 48 3b 43 28 72 95 48 8b 43 38 8b 53 20 48 8d 7d d0 8b 4b 
58 4c 8b 43 60 44 89 e6 48 8b 00 4c 8b 48 20 e8 b4 5f 00 00 48 8b 43 28 c7 43 
5c 02 00
Feb 28 19:48:17 kuusi kernel: [   72.543062] RIP  [a0064c22] 
ttm_tt_free_alloced_pages+0xbb/0xe9 [ttm]
Feb 28 19:48:17 kuusi kernel: [   72.543062]  RSP 88005350fb78
Feb 28 19:48:17 kuusi kernel: [   72.543062] CR2: 
Feb 28 19:48:17 kuusi kernel: [   72.543062] ---[ end trace fddd40bfe557a763 
]---

Regards,
Marko Ristola
--
xen mailing list
xen@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/xen


Re: [Fedora-xen] New xen RCs

2011-02-11 Thread Marko Ristola
11.02.2011 15:01, M A Young wrote:
 I have some new xen release candidate packages for you to test. They are
 xen-4.0.2-0.rc2.fc14 at
 http://koji.fedoraproject.org/koji/taskinfo?taskID=2830813 and
 xen-4.1.0-0.1.rc4.fc14 at
 http://koji.fedoraproject.org/koji/taskinfo?taskID=2830883

I tried xen-4.1.0 rc4.  

Just as with xen-4.1.0 rc3, using same bleeding edge
kernel 2.6.38-0.rc3.git0.1.xendom0.fc15.x86_64 in both dom0
and in 32 bit Ubuntu 10.10 guest, mouse move doesn't work but
mouse clicks work. I don't know where the problem is (kernel / xen / other ).

I need to restore the following row after upgrading into xen 4.1.0 rc4, to
avoid oopses with the bleeding edge kernel.

Michel Young: Edit /etc/sysconfig/modules/xen.modules to remove xen-netback 
from the
list of modules in the for loop then add
modprobe xen-netback netback_kthread=1


Regards,
Marko Ristola


   Michael Young
 --
 xen mailing list
 xen@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/xen

--
xen mailing list
xen@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/xen


[Fedora-xen] 2.6.37 dom0 kernel

2011-01-07 Thread Marko Ristola

Hi

I tried M A Young's precompiled 2.6.37 XEN kernel (under 
xen-4.0.1-6.fc14.x86_64, grub.conf modified.

I have a Radeon card.
I booted with and without modesetting, without success.
I booted successfully with Radeon driver without acceleration.
I'm sending this email from Dom0 :) Speed is as expected.


Here is the bug report:

Plain Radeon without any xorg.conf modifications on Fedora 14:
Initially there was a graphical modesetting based startup.
I switched from graphical startup progress graphics into text mode during boot: 
I could see textual progress messages during bootup.
When X tried to start, Radeon kernel driver caused a page fault, that it 
couldn't handle.
Full kernel stack trace was visible on the screen, and it could be looked up 
with Shift + page up / page down.
Unfortunately I don't have time to take a log via serial port this weekend.

With nomodeset, booting up progressed (disk IO heard), but the screen was blank 
all the time. I initiated a reboot from the keyboard.
With modesetting with the bug, keyboard didn't work. I initiated a reboot via 
reset button.

Here is the xorg.conf's part as a workaround for Radeon driver problem, 
/etc/xorg.conf.d/00-radeon.conf for Fedora 14:

Section Device

   Identifier UseRadeon

   Driver radeon
   Option NoAccel true
   Option DRI false
EndSection

Section Monitor

   Identifier MyMonitor

   Option DPMS true

EndSection

Section Screen

   Identifier MyScreen

   Device UseRadeon
   Monitor MyMonitor

EndSection

Regards,
Marko Ristola



--
xen mailing list
xen@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/xen