Hide Forgot
Description of problem: Start a RHEL6.1 PV guest with "file:iso" virtual cdrom cause guest crash. Version-Release number of selected component (if applicable): Host: xen-3.0.3-126.el5 also xen-3.0.3-120.el5 kernel-xen-2.6.18-250.el5 Guest: RHEL-Server-6.1-32-20110317.1 PV guest. How reproducible: 100% Steps to Reproduce: 1. Edit guest configure file with: disk = ['file:/path/your_vm.raw,xvda,w','file:/path/test.iso,hdc:cdrom,r'] 2. Start the guest with 'xm cr your.conf' Actual results: VM crashed. Expected results: VM should boot and run successfully.
Created attachment 487522 [details] xend log
Created attachment 487524 [details] dmesg log
Created attachment 487527 [details] xm dmesg log
Created attachment 487528 [details] qemu log
Addition Info: Start a RHEL5 PV guest with "file:iso" virtual cdrom in the same environment do not cause guest crash.
Just a note - PV guest do not support cdroms so it is visible as normal disk. It should not be used for PV guest.
Does the crash happen with file:/path/test.iso,hdc,r (i.e. without ":cdrom"?)
Hi, Paolo no matter :cdrom option specified or not, but the hdc make the case different, guest boot up successfully with hdb and hdd. Another bug 691339 may be relevant.
Created attachment 488417 [details] guest console log while crashing
One thing different with bug 691339 is 'xen_emul_unplug=never' didn't work in this case, guest still crash with xen_emul_unplug=never specified.
Reassigning to rhel6 kernel as this problem is experienced only with rhel6 guests (tested RHEL 6 GA, RHEL6.1-20110317.1)
This is a dup of bug 691339. The WARNING and then eventual BUG match exactly with the -125 kernel. dracut: Starting plymouth daemon dracut: rd_NO_DM: removing DM RAID activation dracut: rd_NO_MD: removing MD RAID activation xlblk_init: register_blkdev major: 202 blkfront: xvda: barriers disabled xvda: xvda1 xvda2 xvda3 blkfront: xvda: barriers disabled ------------[ cut here ]------------ WARNING: at fs/sysfs/dir.c:491 sysfs_add_one+0xc9/0x130() (Not tainted) ... kernel BUG at fs/sysfs/group.c:65! *** This bug has been marked as a duplicate of bug 691339 ***