Description of problem: Panic while installing pv rawhide guest attempting to start vnc Version-Release number of selected component (if applicable): kernel-xen-2.6.25-0.2.rc4.fc9.x86_64 How reproducible: 100% Steps to Reproduce: 1. Boot a pv guest with the 'vnc' cmdline option Actual results: kernel panic (see http://jlaska.fedorapeople.org/f9-pv-install-panic-vnc.txt for full log). Running anaconda 11.4.0.55, the Fedora system installer - please wait... Probing for video card: Unable to probe 17:07:05 No video hardware found, assuming headless 17:07:08 Starting VNC... 17:07:09 The VNC server is now running. 17:07:09 WARNING!!! VNC server running with NO PASSWORD! You can use the self.password=<password> boot option if you would like to secure the server. 17:07:09 Please manually connect your vnc client to test1130.test.redhat.com:1 (192.168.34.130) to begin the install. Press <enter> for a shell 17:07:10 Starting graphical installation... Couldn't interpret _XKB_RULES_NAMES property Use defaults: rules - 'xorg' model - 'pc105' layout - 'us' sh-3.2# BUG: unable to handle kernel NULL pointer dereference at 0000000000000100 IP: [<ffffffff8029d004>] kmem_cache_alloc+0x33/0xc6 PGD a09c067 PUD a09d067 PMD 0 Oops: 0000 [1] DEBUG_PAGEALLOC CPU 0 Modules linked in: sha256_generic aes_generic cbc dm_crypt crypto_blkcipher dm_emc dm_round_robin dm_multipath dm_snapshot dm_mirror dm_zero dm_mod xfs jfs reiserfs lock_nolock gfs2 msdos linear raid10 raid456 async_xor async_memcpy async_tx xor raid1 raid0 xen_netfront xen_blkfront ipv6 iscsi_tcp libiscsi scsi_transport_iscsi scsi_mod ext2 ext3 jbd ext4dev jbd2 mbcache crc16 squashfs pcspkr edd loop nfs lockd nfs_acl sunrpc vfat fat cramfs Pid: 966, comm: lvm Not tainted 2.6.25-0.2.rc4.fc9xen #1 RIP: e030:[<ffffffff8029d004>] [<ffffffff8029d004>] kmem_cache_alloc+0x33/0xc6 RSP: e02b:ffff88000e891958 EFLAGS: 00010046 RAX: ffffffffff516000 RBX: 00000000000800d0 RCX: 00000000000000d0 RDX: 000000000000463b RSI: 00000000000800d0 RDI: 0000000000000000 RBP: ffff88000e891988 R08: 0000000000000000 R09: 0000000180252d5a R10: 000000000000001b R11: 0000000000000001 R12: 0000000000000000 R13: 0000000000000200 R14: ffffffff8032ea2e R15: 00000000000800d0 FS: 00007fe93ed74780(0000) GS:ffffffff80612000(0000) knlGS:0000000000000000 CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000100 CR3: 000000001018e000 CR4: 0000000000002620 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000000 Process lvm (pid: 966, threadinfo ffff88000e890000, task ffff88000a080000) Stack: ffffffff805e1448 00000000000800d0 0000000000000000 000000000000463b ffff880003f2b178 000000000000463b ffff88000e8919a8 ffffffff8032ea2e ffff880003e532c0 ffff88001b6cd538 ffff88000e8919e8 ffffffff80278b1f Call Trace: [<ffffffff8032ea2e>] radix_tree_preload+0x3c/0x8a [<ffffffff80278b1f>] add_to_page_cache+0x24/0xc1 [<ffffffff80278bcb>] add_to_page_cache_lru+0xf/0x24 [<ffffffff80279342>] grab_cache_page_nowait+0x94/0xae [<ffffffff880a9cca>] :squashfs:squashfs_readpage+0x263/0x452 [<ffffffff80252d5a>] ? lock_acquired+0x273/0x283 [<ffffffff80253324>] ? lock_release+0x176/0x186 [<ffffffff8049383e>] ? _write_unlock_irq+0x32/0x38 [<ffffffff80278bad>] ? add_to_page_cache+0xb2/0xc1 [<ffffffff8027fd10>] __do_page_cache_readahead+0x1b1/0x1e4 [<ffffffff80253324>] ? lock_release+0x176/0x186 [<ffffffff80493901>] ? _read_unlock_irq+0x32/0x38 [<ffffffff8027fd99>] do_page_cache_readahead+0x56/0x63 [<ffffffff802790cc>] filemap_fault+0x14f/0x331 [<ffffffff80253324>] ? lock_release+0x176/0x186 [<ffffffff802852fd>] __do_fault+0x6b/0x4af [<ffffffff80252d5a>] ? lock_acquired+0x273/0x283 [<ffffffff80253324>] ? lock_release+0x176/0x186 [<ffffffff80287c74>] handle_mm_fault+0x41b/0x899 [<ffffffff80493a70>] ? _spin_unlock+0x26/0x2a [<ffffffff80290546>] ? __vunmap+0xcd/0xd6 [<ffffffff8029b447>] ? check_object+0x159/0x23c [<ffffffff8028845e>] get_user_pages+0x36c/0x457 [<ffffffff8049340b>] ? trace_hardirqs_on_thunk+0x35/0x3a [<ffffffff80211631>] ? restore_args+0x0/0x30 [<ffffffff80288772>] make_pages_present+0x93/0xa9 [<ffffffff8028a122>] mlock_fixup+0xff/0x12b [<ffffffff8028a1d7>] do_mlockall+0x89/0x9f [<ffffffff8028a2d4>] sys_mlockall+0x93/0xbd [<ffffffff80211179>] tracesys+0xbe/0xc3 Expected results: No panic
Tried running virt-install with "-x vnc" and I can connect to the vnc server on both x86_32 and x86_64 with 2.6.25-0.4.rc4.fc9xen based 2008-03-24 install trees. Please re-open if you see the same issue with a newer install tree.
Reopening per recommendation from markmc Still seeing this in rawhide-20080325/x86_64 (kernel-xen-2.6.25-0.4.rc4.fc9) Dom0 is running F8 * 2.6.21.7-2.fc8xen * xen-3.1.2-2.fc8 The virt-install cmdline used was: # virt-install -p --nographics -l http://porkchop.redhat.com/rawhide/nightly/rawhide-20080325/x86_64/os -b eth0 -f /var/lib/xen/images/test1-disk1.img --vcpus=2 -n test1 -r 512 -m "00:16:3e:7f:c9:93" -x "lang=en keymap=us vnc ksdevice=link ip=dhcp method=http://porkchop.redhat.com/rawhide/nightly/rawhide-20080325/x86_64/os" The failure log is *long* and is available at: http://jlaska.fedorapeople.org/f9-pv-install-panic-vnc.txt
Is it reproducible with --vcpus=1 ? How about with kernel-xen-2.6-2.6.21.7-3.fc8 in Dom0 ? How about doing a 32 bit guest install on the same Dom0 ?
Result dom0 domU VPUS ================================================================= FAILED 2.6.21.7-3.fc8xen/x86_64 rawhide-20080325/x86_64 2 FAILED 2.6.21.7-3.fc8xen/x86_64 rawhide-20080325/x86_64 1 PASSED 2.6.21.7-3.fc8xen/x86_64 rawhide-20080325/i386 1 PASSED 2.6.21.7-3.fc8xen/x86_64 rawhide-20080325/i386 2
Thanks, that's helpful - so it's x86_64 specific Re-assigning to Eduardo for now
Probably memory corruption with same cause of bug #438000. A fix should go to Rawhide soon.
Should be fixed with kernel-xen-2.6.25-0.15.rc8.fc9