Bug 484295
Summary: | F11 alpha boots ugly (after install) on xen paravirt | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Mike McGrath <mmcgrath> |
Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | high | ||
Version: | rawhide | CC: | berrange, clalance, joropo, kernel-maint, kmcmartin, kraxel, markmc, m.a.young, mschmidt, quintela, virt-maint, xen-maint |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-02-25 10:31:24 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 480594 |
Description
Mike McGrath
2009-02-05 22:28:10 UTC
After the box comes up, and after doing a service network restart, the host seems like its in ok shape. I'm going to try actually using it. Thanks, posted the oops to xen-devel (In reply to comment #2) > Thanks, posted the oops to xen-devel here: http://lists.xensource.com/archives/html/xen-devel/2009-02/msg00196.html Removing from the F11Alpha blockers list, adding to F11VirtTracker (Trying to) boot F11-Aplha-i686-Live but I am left with w/final message "Fixing recursive fault but reboot is needed!" Getting (only) as far as seeing load graphic fill across bottom of screen then OOPS. :( Any options available? Magic key press during initial countdown, maybe? Someplace, when back in F10, to look at trace? This bug killed an attempted update from Fedora 10 to Fedora 11, so it is more serious than just an ugly boot message. Oops: 0000 [#1] SMP DEBUG_PAGEALLOC last sysfs file: /sys/devices/vbd-768/block/xvda/devcts | <F12> next screen Modules linked in: xts lrw gf128mul sha256_generic cbc dm_crypt dm_round_robin dm_multipath btrfs zlib_deflate libcrc32c xfs exportfs jfs reiserfs gfs2 msdos linear raid10 raid456 async_xor async_memcpy async_tx xor raid1 raid0 xen_netfront xen_blkfront iscsi_ibft iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ext2 ext4 jbd2 crc16 squashfs pcspkr nfs lockd nfs_acl auth_rpcgss sunrpc vfat fat cramfs Pid: 1144, comm: lvm Tainted: G W (2.6.29-0.66.rc3.fc11.i686.PAE #1) EIP: 0061:[<c04a2a42>] EFLAGS: 00010246 CPU: 0 EIP is at grab_swap_token+0x1f/0x105 EAX: 00000000 EBX: 00000001 ECX: c0484635 EDX: 00000001 ESI: 00000000 EDI: 00000000 EBP: c824bc98 ESP: c824bc90 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069 Process lvm (pid: 1144, ti=c824b000 task=c0142a40 task.ti=c824b000) Stack: 00267020 00000000 c824bd18 c04967c8 c824bcd8 00181000 cf6bbe58 cd011500 00267020 00000000 00000c08 cce75000 cd166c08 00000001 00000000 c824bcd8 c05484f8 c32593f4 c824bce4 c04267ed cd166000 c824bd1c c0495637 0d166067 Call Trace: [<c04967c8>] ? handle_mm_fault+0x3ae/0x7dd [<c05484f8>] ? _raw_spin_unlock+0x74/0x78 [<c04267ed>] ? kunmap_atomic+0x68/0x84 [<c0495637>] ? follow_page+0x273/0x2cc [<c0496e8b>] ? __get_user_pages+0x294/0x377 [<c049898a>] ? __mlock_vma_pages_range+0xaa/0x1dc [<c0498fba>] ? munlock_vma_pages_range+0x11/0x14 [<c04999e7>] ? exit_mmap+0x4e/0x111 [<c042fcb5>] ? __might_sleep+0x1e/0xef [<c0433e6d>] ? mmput+0x3c/0x8f [<c04374c0>] ? exit_mm+0xe5/0xed [<c0438de1>] ? do_exit+0x18d/0x75a [<c0406063>] ? xen_force_evtchn_callback+0xf/0x14 [<c0441e47>] ? get_signal_to_deliver+0x1d6/0x296 [<c04067be>] ? check_events+0x8/0xe [<c0441e47>] ? get_signal_to_deliver+0x1d6/0x296 [<c0406727>] ? xen_restore_fl_direct_end+0x0/0x1 [<c043940c>] ? do_group_exit+0x5e/0x85 [<c0441ef0>] ? get_signal_to_deliver+0x27f/0x296 [<c0496e66>] ? __get_user_pages+0x26f/0x377 [<c0408351>] ? do_notify_resume+0x69/0x629 [<c0406063>] ? xen_force_evtchn_callback+0xf/0x14 [<c04067be>] ? check_events+0x8/0xe [<c06efb7b>] ? down_write+0x4f/0x74 [<c0406727>] ? xen_restore_fl_direct_end+0x0/0x1 [<c0456457>] ? lock_acquired+0x2b7/0x2c1 [<c06efb7b>] ? down_write+0x4f/0x74 [<c0406063>] ? xen_force_evtchn_callback+0xf/0x14 [<c0498dcf>] ? sys_mlockall+0x9d/0xaa [<c04067be>] ? check_events+0x8/0xe [<c04b466c>] ? path_put+0x15/0x18 [<c04540cf>] ? trace_hardirqs_off_caller+0x18/0xa3 [<c0409078>] ? work_notifysig+0x13/0x1b Code: 68 cf 85 c0 e8 04 df 24 00 5b 5d c3 a1 80 c2 ef c0 55 89 e5 56 53 8d 58 01 89 1d 80 c2 ef c0 64 a1 80 8c 92 c0 8b 80 c0 01 00 00 <8b> b0 18 02 00 00 b8 68 cf 85 c0 e8 1e dc 24 00 85 c0 0f 84 c7 EIP: [<c04a2a42>] grab_swap_token+0x1f/0x105 SS:ESP 0069:c824bc90 ---[ end trace 4eaa2a86a8e2da24 ]--- Fixing recursive fault but reboot is needed! install exited abnormally [1/1] Patch from Jeremy here: http://lists.xensource.com/archives/html/xen-devel/2009-02/msg00234.html http://lkml.org/lkml/2009/2/4/692 http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.git;a=commitdiff;h=b534816 If I am following this http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9ce04f9238cafcfd09a502f2bc8c13b5f44ec590 correctly, the patch will be in 2.6.29-rc4-git4. (In reply to comment #8) > the patch will be in 2.6.29-rc4-git4. Confirmed by comparing: $ git log --pretty=oneline $(curl http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.29-rc4-git4.id 2>/dev/null)..b534816b552d35bbd3c60702139ed5c7da2f55c2 $ git log --pretty=oneline $(curl http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.29-rc4-git3.id 2>/dev/null)..b534816b552d35bbd3c60702139ed5c7da2f55c2 i.e. it isn't in git3, but is in git4 Does the fact that it's in -rc4-git4 mean it's fixed and the bug can be closed? (In reply to comment #10) > Does the fact that it's in -rc4-git4 mean it's fixed and the bug can be closed? Yep, at the time -git4 wasn't in rawhide I haven't managed to get recent kernels to boot at all as a xen guest, but that is presumably a different bug. It turns out my problem with booting was simply that xen-blkfront wasn't being loaded, so the xen guest is now working correctly for me. |