I was using OpenBSD guests on Fedora 9 for many months without any issues. I've updated F9 to F10, and then to F11 today, and all my OpenBSD guests stopped to work.

Please include qemu command line (from /var/log/libvirt/qemu)

At first I have no idea what can be possibly going on, but it might have something to do with the kind of discs you are using.

Also, I'm having a hard time reproducing this (I'm not that much skilled on OpenBSD). If you can share your image (plus the log I've already asked for), I'll happily try to debug it

I'm not using libvirt. Here is part of kvm starting scripts:

exec qemu-kvm \
        \
        -name mirror1 \
        -daemonize \
        -serial mon:telnet:127.0.0.1:15906,server,nowait \
        -net nic,vlan=0,model=e1000,macaddr=52:54:00:12:34:76 \
        -net tap,vlan=0,script=/srv/kvm1/qemu-ifup \
        -smp 1 \
        -usb \
        -usbdevice tablet \
        -vnc :6 \
        -m 128 \
        -boot c \
        -hda $DSK \
        -pidfile $PID

# file -sL /var/log/libvirt
/var/log/libvirt: cannot open `/var/log/libvirt' (No such file or directory)

Disk is a regular file.

# grep -e ^DSK mirror1.sh
DSK=/srv/kvm2/mirror1.dsk

# file -sL /srv/kvm2/mirror1.dsk
/srv/kvm2/mirror1.dsk: x86 boot sector; partition 4: ID=0xa6, active, starthead 1, startsector 63, 838849977 sectors, code offset 0x5

From monitor when starting qemu-kvm as paused (added -S option to above script):

(qemu) info block
ide0-hd0: type=hd removable=0 file=/srv/kvm2/mirror1.dsk ro=0 drv=raw encrypted=0
ide1-cd0: type=cdrom removable=1 locked=0 [not inserted]
floppy0: type=floppy removable=1 locked=0 [not inserted]
sd0: type=floppy removable=1 locked=0 [not inserted]

Mikolaj: could you try booting with the host kernel with oos_shadow=0 ?

If that works, this could be the fix:

  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c2d0ee46e6

You could try the rawhide 2.6.31 kernel without oos_shadow=0 to see if it is fixed?

Hmm, it looks like that problem is fixed in 2.6.29.3:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.29.y.git;a=commitdiff;h=d595990048

Still, it's worth trying oos_shadow=0 and/or 2.6.31

Linux 2.6.29.5-191.fc11.i686.PAE with oos_shadow=0

# cat /etc/modprobe.d/kvm.conf
options kvm oos_shadow=0
# reboot

After Fedora reboot started OpenBSD with script as shown in comment#4 in this bug report. CPU utilization goes up to 100% [from top(1): 62.1%us, 37.9%sy] and after a while OpenBSD panics with kernel page fault trap.

2.6.31-0.39.rc1.git9.fc12.i686.PAE without oos_shadow=0

% cat /etc/modprobe.d/kvm.conf
#options kvm oos_shadow=0
% reboot

After reboot symptoms the same like in comment#9 also with kernel page fault trap on OpenBSD.

2.6.31-0.39.rc1.git9.fc12.i686.PAE with oos_shadow=0

% cat /etc/modprobe.d/kvm.conf
options kvm oos_shadow=0
% reboot

After reboot results the same like in comment#9 and comment#10.

In comment#9, #10 and #11 only one message in dmesg(8) related to kvm

kvm: emulating exchange as write

I've done more tests with different versions of kernel and qemu-kvm from Fedora 9, 10 and 11.

OpenBSD on kernel-PAE-2.6.27.25-78.2.56.fc9.i686 and kvm-65-15.fc9.i386 from Fedora 9 obviously works.

I've got OpenBSD working with 2.6.29.5-191.fc11.i686.PAE and kvm-65-15.fc9.i386. Problem seems to me not only related to kernel but also to userland tool.

Everything else doesn't work (or was not tested).

All my tests where done _without_ oos_shadow=0, to save some time, but I can perform more tests if requested.

2.6.29.5-191.fc11.i686.PAE without oos_shadow=0 and kvm rebuild from rawhide.

% uname -r
2.6.29.5-191.fc11.i686.PAE
% cat /etc/modprobe.d/local.conf
#options kvm oos_shadow=0
% rpm -qf `which qemu-kvm`
qemu-system-x86-0.10.50-8.kvm87.fc11.i386
% reboot



2.6.29.5-191.fc11.i686.PAE with oos_shadow=0 and kvm rebuild from rawhide.

% uname -r
2.6.29.5-191.fc11.i686.PAE
% cat /etc/modprobe.d/local.conf
options kvm oos_shadow=0
% rpm -qf `which qemu-kvm`
qemu-system-x86-0.10.50-8.kvm87.fc11.i386
% reboot



Same results in both situations, like in comment #9, #10, and #11. OpenBSD panics with kernel page fault trap. No messages in Fedora's dmesg(8) except usual "kvm: emulating exchange as write".

It's failing on 'push %ds':
   0:	1e                   	push   %ds
   1:	06                   	push   %es
   2:	0f a8                	push   %gs

for the record: pvmmu also fails on 32-bit hosts.

Disabling mpbios as described here: http://scie.nti.st/2009/10/4/running-openbsd-4-5-in-kvm-on-ubuntu-linux-9-04 worked for me.

Installed F12 on spare drive, on the same machine. Problem is still present with:

# rpm -q qemu
qemu-0.11.0-11.fc12.i686

Tested kvm with oos_shadow=0 and without oos_shadow=0 on 2.6.31.6-162.fc12.i686.PAE kernel. That didn't help.

This issue exists also on Fedora 12, so I'm changing version to 12.

Can somebody try latest kvm.git modules. Emulation of "push   %ds" was added recently.

Is it okay to test it with rebuild of kernel-2.6.32.2-14.fc13.src.rpm for Fedora 12?

(In reply to comment #21)
> Can somebody try latest kvm.git modules. Emulation of "push   %ds" was added
> recently.  

Is it okay to use git://git.kernel.org/pub/scm/virt/kvm/kvm-kmod.git for latest kvm modules?

I already tested it and OpenBSD still doesn't work. The problem was not "push   %ds" emulation, this was just a side effect of the real problem, so now OpenBSD crashes in different place. Looking into it.

For some strange reason openbsd configures gsi 4 (com0) and gsi 12 (i8042) to be level triggered active high in ioapic. That causes KVM to send endless stream of interrupts into the guest, so guest's stack overflows into framebuffer area. At this point KVM start to emulate instructions and fails. I don't know why openbsd configures those interrupts incorrectly. It also ignores my attempts to override interrupt polarity/type with ACPI tables.

Gleb,

The PIIX PM driver thinks IRQ10 is connected to IOAPIC pin 4. Should be IRQ9.

IRQ11 (e1000) is connected to IOAPIC pin 12. See screenshot.

I think it misreads the ACPI tables (no idea why).

Created attachment 379854 [details]
dmesg output of OpenBSD 4.6

Looking at my comment #13 is it possible, that the problem can be with user-land part of kvm (qemu-kvm)? At the time I wrote that comment I could ran any recent OpenBSD version with default kernels from F11 but only with old kvm-65 (which is from F9).

I've just rebuilt kvm-74-11.fc10.src.rpm on Fedora 12 with 2.6.31.6-166.fc12.i686.PAE, OpenBSD is freezing.

Rebuild from cvs.fedoraproject.org of kvm-68-1 on Fedora 12 with 2.6.31.6-166.fc12.i686.PAE, OpenBSD works!

Rebuild of kvm-69-1 on 2.6.31.6-166.fc12.i686.PAE, OpenBSD works.
Rebuild of kvm-71-2 on 2.6.31.6-166.fc12.i686.PAE, OpenBSD does *not* work.

(In reply to comment #31)
> Rebuild of kvm-69-1 on 2.6.31.6-166.fc12.i686.PAE, OpenBSD works.
> Rebuild of kvm-71-2 on 2.6.31.6-166.fc12.i686.PAE, OpenBSD does *not* work.  

Try kvm-69-1 with -smp 2 and be surprised :) The problem is with mptable KVM BIOS creates and older KVM BIOS does not create mptable if there is only 1 cpu.
Apparently no other OS uses mptable irq routing at least not in a way OpenBSD does. It looks like mptable irq routing is static, so not very useful.

Yes, with kvm-69-1 with -smp 2 on 2.6.31.6-166.fc12.i686.PAE OpenBSD is freezing as well.

Does that mean you know where the problem is? I'm not a developer, but can I help somehow to get this ticket resolved?

I posted patch to provide correct PCI irq routing info in mptable to kvm mailing list. It works for all devices except for SCI interrupt. BIOS programs SCI interrupt to be 9 as spec requires, but OpenBSD thinks that it is smarter and moves it to interrupts 10. Qemu will still send it on vector 9 and OpenBSD will enter the same infinity recursion. This can be triggered by issuing system_powerdown on qemu monitor.

Sorry, against which version this patch is for? I cannot find anywhere in qemu-kvm-0.11.1 and in qemu-kvm-0.12.1.1 sources file named mptable.c

The problem is in the BIOS so the patch is against seabios (git://git.linuxtogo.org/home/kevin/seabios.git), but I am not sure that the head of seabios git will work with head of qemu-kvm, so may be you'll have to wait for qemu-kvm-0.12.2.

Does that mean Fedora 12 wont get an update for qemu-kvm-0.11 branch? What package has seabios in Fedora?

qemu-kvm-0.11 is SOL unless someone backports the fix to bochs bios. Seabios is used by qemu starting from version 0.12.

What means SOL?

Simply out of luck

The virt-preview repository has seabios and qemu-kvm-0.12.1.2 available for F12 hosts.  Testing there would be great.

Is this correct location: http://jforbes.fedorapeople.org/virt-preview/f12/ ?

Indeed it is, https://fedoraproject.org/wiki/Virtualization_Preview_Repository has yum setup details.

Got spare machine. Installed F12. Added Virtualization Preview repo, and yum updated the OS.

Updating:
 bochs-bios        noarch   2.4.2-1.fc12                        rawvirt    41 k
 gpxe-roms-qemu    noarch   1.0.0-1.fc12                        rawvirt   229 k
 libvirt           i686     0.7.6-1.fc12                        rawvirt   635 k
 libvirt-client    i686     0.7.6-1.fc12                        rawvirt   1.7 M
 libvirt-python    i686     0.7.6-1.fc12                        rawvirt   135 k
 python-virtinst   noarch   0.500.2-1.fc12                      rawvirt   439 k
 qemu-common       i686     2:0.12.2-6.fc12                     rawvirt   242 k
 qemu-img          i686     2:0.12.2-6.fc12                     rawvirt   148 k
 qemu-kvm          i686     2:0.12.2-6.fc12                     rawvirt    20 k
 qemu-system-x86   i686     2:0.12.2-6.fc12                     rawvirt   2.2 M
Installing for dependencies:
 seabios           i686     0.5.1-0.1.20100108git669c991.fc12   rawvirt    57 k

Downloaded ISO from ftp://ftp.esat.net/pub/OpenBSD/snapshots/i386/install47.iso and placed it in /var/lib/libvirt/boot/openbsd-install47.iso

But virt-install fails:


# restorecon -R /var/lib/libvirt/ /etc/libvirt/

# virt-install \
        --connect qemu:///system \
        --name ocurrent1 \
        --ram 128 \
        --disk path=/var/lib/libvirt/images/ocurrent1.dsk,cache=writeback,size=4 \
        --network network=default,model=e1000 \
        --cdrom /var/lib/libvirt/boot/openbsd-install47.iso \
        --vnc \
        --vnclisten=0.0.0.0 \
        --noautoconsole


Starting install...
Allocating 'ocurrent1.dsk'                                                                                                                                                                 |    0 B     00:00
ERROR    internal error unable to start guest: char device redirected to /dev/pts/1
Warning: vlan 0 with no nics
qemu: could not open disk image /var/lib/libvirt/images/ocurrent1.dsk: Permission denied

Domain installation may not have been
 successful.  If it was, you can restart your domain
 by running 'virsh start ocurrent1'; otherwise, please
 restart your installation.
ERROR    internal error unable to start guest: char device redirected to /dev/pts/1
Warning: vlan 0 with no nics
qemu: could not open disk image /var/lib/libvirt/images/ocurrent1.dsk: Permission denied
Traceback (most recent call last):
  File "/usr/sbin/virt-install", line 972, in <module>
    main()
  File "/usr/sbin/virt-install", line 834, in main
    start_time, guest.start_install)
  File "/usr/sbin/virt-install", line 896, in do_install
    dom = install_func(conscb, progresscb, wait=(not wait))
  File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 795, in start_install
    return self._do_install(consolecb, meter, removeOld, wait)
  File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 896, in _do_install
    self.domain = self.conn.createLinux(install_xml, 0)
  File "/usr/lib/python2.6/site-packages/libvirt.py", line 1098, in createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: internal error unable to start guest: char device redirected to /dev/pts/1
Warning: vlan 0 with no nics
qemu: could not open disk image /var/lib/libvirt/images/ocurrent1.dsk: Permission denied




Did I do something wrong?

From /var/log/libvirt/qemu/ocurrent1.log:

LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-kvm -S -M pc-0.12 -enable-kvm -m 128 -smp 1,sockets=1,cores=1,threads=1 -name ocurrent1 -uuid 2d278f10-5ee3-9fd9-2556-608285136283 -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/ocurrent1.monitor,server,nowait -mon chardev=monitor,mode=readline -no-reboot -boot d -drive file=/var/lib/libvirt/images/ocurrent1.dsk,if=none,id=drive-ide0-0-0,format=raw,cache=writeback -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive file=/var/lib/libvirt/boot/openbsd-install47.iso,if=none,media=cdrom,id=drive-ide0-1-0 -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -device e1000,vlan=0,id=net0,mac=52:54:00:a3:be:ea,bus=pci.0,addr=0x4 -net tap,fd=18,vlan=0,name=hostnet0 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -vnc 0.0.0.0:0 -k en-us -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3
char device redirected to /dev/pts/1
Warning: vlan 0 with no nics
qemu: could not open disk image /var/lib/libvirt/images/ocurrent1.dsk: Permission denied

# id qemu
uid=107(qemu) gid=107(qemu) groups=107(qemu),36(kvm)

# ls -lh /var/lib/libvirt/images/
total 0
-rw-------. 1 root root 4.0G 2010-02-25 12:51 ocurrent1.dsk

I don't think we should debug libvirt in this bz. Can you use qemu directly?

Went through installation of OpenBSD and then started system with uni-processor OpenBSD kernel (/bsd). Virtual guest booted fine, I've logged in. Executed some basic unix commands, uptime 5 minutes, so far so good.

# qemu-kvm \
        \
        -name qemu-test2 \
        -serial mon:telnet:127.0.0.1:15900,server,nowait \
        -net nic,vlan=0,model=e1000,macaddr=52:54:00:77:34:76 \
        -net tap,vlan=0,script=/root/qemu-ifup,downscript=no \
        -smp 1 \
        -usb \
        -usbdevice tablet \
        -vnc 0.0.0.0:1 \
        -m 128 \
        -boot c \
        -hda /var/lib/libvirt/images/ocurrent1.dsk \
        -pidfile /root/qemu-test2.pid

On the same qemu-kvm process (-smp 1) started muti-processor OpenBSD kernel (/bsd.mp) and guest os booted fine. Quick and simple tests and here seems to be good as well. It's nice that 'reboot' and 'halt -p' are working as expected in guest OS and qemu doesn't die.

Started qemu-kvm with same parameters like in comment#49 but with -smp 2 and booted OpenBSD with /bsd.mp kernel. All looks good.

Is there anything more what I can help with?

For the records:

OpenBSD 4.7-beta (GENERIC) #537: Tue Feb 23 12:16:07 MST 2010
    deraadt.org:/usr/src/sys/arch/i386/compile/GENERIC

OpenBSD 4.7-beta (GENERIC.MP) #423: Tue Feb 23 12:24:22 MST 2010
    deraadt.org:/usr/src/sys/arch/i386/compile/GENERIC.MP

Just noticed those messages in dmesg on the host machine:

KVM_APIC_READ: alignment error fee00004 4
KVM_APIC_READ: alignment error fee00008 4
KVM_APIC_READ: alignment error fee0000c 4
KVM_APIC_READ: alignment error fee00014 4
KVM_APIC_READ: alignment error fee00018 4
KVM_APIC_READ: alignment error fee0001c 4
KVM_APIC_READ: alignment error fee00024 4
KVM_APIC_READ: alignment error fee00028 4
KVM_APIC_READ: alignment error fee0002c 4
KVM_APIC_READ: alignment error fee00034 4
KVM_APIC_READ: alignment error fee00038 4
KVM_APIC_READ: alignment error fee0003c 4
KVM_APIC_READ: alignment error fee00044 4
KVM_APIC_READ: alignment error fee00048 4
KVM_APIC_READ: alignment error fee0004c 4
KVM_APIC_READ: alignment error fee00054 4
KVM_APIC_READ: alignment error fee00058 4
KVM_APIC_READ: alignment error fee0005c 4
KVM_APIC_READ: alignment error fee00064 4
KVM_APIC_READ: alignment error fee00068 4
KVM_APIC_READ: alignment error fee0006c 4
KVM_APIC_READ: alignment error fee00074 4
KVM_APIC_READ: alignment error fee00078 4
KVM_APIC_READ: alignment error fee0007c 4
KVM_APIC_READ: alignment error fee00084 4
KVM_APIC_READ: alignment error fee00088 4
KVM_APIC_READ: alignment error fee0008c 4
Access APIC ARBPRI register which is for P6
KVM_APIC_READ: alignment error fee00094 4
KVM_APIC_READ: alignment error fee00098 4
KVM_APIC_READ: alignment error fee0009c 4
KVM_APIC_READ: alignment error fee000a4 4
KVM_APIC_READ: alignment error fee000a8 4
KVM_APIC_READ: alignment error fee000ac 4
KVM_APIC_READ: alignment error fee000b4 4
KVM_APIC_READ: alignment error fee000b8 4
KVM_APIC_READ: alignment error fee000bc 4
KVM_APIC_READ: alignment error fee000c4 4
KVM_APIC_READ: alignment error fee000c8 4


FYI

(In reply to comment #51)
> Started qemu-kvm with same parameters like in comment#49 but with -smp 2 and
> booted OpenBSD with /bsd.mp kernel. All looks good.
> 
> Is there anything more what I can help with?    
I guess this bug can be closed then?

(In reply to comment #53)
> Just noticed those messages in dmesg on the host machine:
> 
> KVM_APIC_READ: alignment error fee00004 4
...
> KVM_APIC_READ: alignment error fee000c8 4
> 
> 

For some reason OpenBSD tries to read APIC registers that should never be read. May be it just lazy and
does memcpy(apic_mem_ptr, somewere, 0xd0).

What about virt-install, should I cut separate ticket, or is  it known issue?

Fix for virt-install was rather simple:

# chmod 0711 /var/lib/libvirt/images

dunno why this directory had permissions 0700:

# rpm -qV `rpm -qf /var/lib/libvirt/images`
.M.......    /var/cache/libvirt/qemu

(In reply to comment #57)
> Fix for virt-install was rather simple:
> 
> # chmod 0711 /var/lib/libvirt/images
> 
> dunno why this directory had permissions 0700:
> 
> # rpm -qV `rpm -qf /var/lib/libvirt/images`
> .M.......    /var/cache/libvirt/qemu    

I think it is worth opening a bug about it. Thank you for testing.

I've updated qemu to the latest available version from virt preview repo:

# rpm -qa --last | head -n5
qemu-kvm-0.12.3-3.fc12                        Tue 02 Mar 2010 11:25:54 AM GMT
qemu-img-0.12.3-3.fc12                        Tue 02 Mar 2010 11:25:54 AM GMT
qemu-system-x86-0.12.3-3.fc12                 Tue 02 Mar 2010 11:25:53 AM GMT
qemu-common-0.12.3-3.fc12                     Tue 02 Mar 2010 11:25:52 AM GMT
libvorbis-1.2.3-4.fc12                        Sat 27 Feb 2010 10:44:35 AM GMT


suddenly my server is resetting at exactly the same time:

# grep imklog /var/log/messages
Feb 28 03:15:01 localhost kernel: imklog 4.4.2, log source = /proc/kmsg started.
Mar  2 16:32:00 localhost kernel: imklog 4.4.2, log source = /proc/kmsg started.
Mar  2 17:32:08 localhost kernel: imklog 4.4.2, log source = /proc/kmsg started.
Mar  2 18:32:25 localhost kernel: imklog 4.4.2, log source = /proc/kmsg started.
Mar  2 19:32:43 localhost kernel: imklog 4.4.2, log source = /proc/kmsg started.


Nothing interesting in logs though.

Machine was resetting exactly after 1 hour of uptime, however it looks that issue was not related to qemu update, so please ignore my last comment.

I've used F12 with virt preview repo for about month now and that works fine. However, today I've installed RHEL 5.5 x86_64 as a virtual host:

# rpm -q kvm libvirt kmod-kvm kernel
kvm-83-164.el5
libvirt-0.6.3-33.el5
kmod-kvm-83-164.el5
kernel-2.6.18-194.el5

and OpenBSD/i386 is freezing after successful install as quest OS. Do you think RHEL5 could be fixed, or kvm-83 is too old for the fix?

Technically it is possible. RHEL5.5 KVM uses BOCHS bios while latest KVM uses Seabios. The problem was fixed in Seabios, so patch is not directly applicable
to BOCHS bios. Whether such fix will be approved from RHEL5 is another matter.

Well, that would be *awesome* \o/ to get that fix for RHEL5. For me anyway. Does anyone from RedHat is considering to make that happened? Just curious do I need to wait for RHEL6.

(In reply to comment #63)
> Well, that would be *awesome* \o/ to get that fix for RHEL5. For me anyway.
> Does anyone from RedHat is considering to make that happened?
Don't think so since OpenBSD is on on the list of supported guests for RHEL5.
But if you'll submit tested patch here... :)
>                                                               Just curious do I
> need to wait for RHEL6.    

I'll make sure the upstream fix is included in RHEL6 if it is not already.

FYI: I've installed just released OpenBSD/i386 4.7 on RHEL6 beta. Works nice so far.

# rpm -q redhat-release
redhat-release-6-6.0.0.24.el6.x86_64 

# uname -a
OpenBSD openbsd47.home.lan 4.7 GENERIC#558 i386

# sysctl -n kern.version
OpenBSD 4.7 (GENERIC) #558: Wed Mar 17 20:46:15 MDT 2010
    deraadt.org:/usr/src/sys/arch/i386/compile/GENERIC

Since tests show that latest KVM works fine with OpenBSD I am closing the bug. Mikolaj thanks again for testing!

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

On Fedora 13 (fedora-release-13-1.noarch x86_64) and RHEL6 beta (redhat-release-6-6.0.0.24.el6.x86_64) all works perfectly fine for months now. Thank you for your help.