Bug 438392 - F-9 pv_ops xen: vnc install panic on x86_64
Summary: F-9 pv_ops xen: vnc install panic on x86_64
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel-xen
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Eduardo Habkost
QA Contact: Virtualization Bugs
Depends On:
Blocks: PvOpsTracker
TreeView+ depends on / blocked
Reported: 2008-03-20 18:27 UTC by James Laska
Modified: 2013-09-02 06:24 UTC (History)
2 users (show)

Fixed In Version: kernel-xen-2.6.25-0.15.rc8.fc9
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-04-04 08:25:54 UTC
Type: ---

Attachments (Terms of Use)

Description James Laska 2008-03-20 18:27:07 UTC
Description of problem:

Panic while installing pv rawhide guest attempting to start vnc

Version-Release number of selected component (if applicable):


How reproducible:

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, 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.

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
( 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
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

Comment 1 Mark McLoughlin 2008-03-25 17:33:56 UTC
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.

Comment 2 James Laska 2008-03-26 15:24:24 UTC
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
 * 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

The failure log is *long* and is available at: 

Comment 3 Mark McLoughlin 2008-03-26 15:29:55 UTC
Is it reproducible with --vcpus=1 ?

How about with kernel-xen-2.6- in Dom0 ?

How about doing a 32 bit guest install on the same Dom0 ? 

Comment 4 James Laska 2008-03-26 16:07:15 UTC
Result   dom0                      domU                    VPUS
FAILED  rawhide-20080325/x86_64 2
FAILED  rawhide-20080325/x86_64 1
PASSED  rawhide-20080325/i386   1
PASSED  rawhide-20080325/i386   2

Comment 5 Mark McLoughlin 2008-03-26 16:16:18 UTC
Thanks, that's helpful - so it's x86_64 specific

Re-assigning to Eduardo for now

Comment 6 Eduardo Habkost 2008-04-03 22:29:04 UTC
Probably memory corruption with same cause of bug #438000. A fix should go to 
Rawhide soon.

Comment 7 Mark McLoughlin 2008-04-04 08:25:54 UTC
Should be fixed with kernel-xen-2.6.25-0.15.rc8.fc9

Note You need to log in before you can comment on or make changes to this bug.