Bug 205940 - Kernel panic while graphically installing paravirt on x86_64
Summary: Kernel panic while graphically installing paravirt on x86_64
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel-xen   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Eduardo Habkost
QA Contact: Virtualization Bugs
Keywords: Reopened
Depends On:
TreeView+ depends on / blocked
Reported: 2006-09-10 15:54 UTC by Jesse Keating
Modified: 2013-01-10 02:33 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-26 23:20:34 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Jesse Keating 2006-09-10 15:54:20 UTC
Installation starts fine, but once file system has been created and anaconda
moves to preparing install packages the kernel panics.  Unable to get panic text
right now, xen system went offline due to smp errors.

Comment 1 Jeremy Katz 2006-09-11 14:52:08 UTC
Need more details -- if the host crashed just afterwards, then I'm willing to
believe that there's something related there and this isn't going to be
something "real"

Comment 2 Jesse Keating 2006-09-11 16:56:42 UTC
Here is the output from the console at crash time.

Initializing IPsec netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
XENBUS: Device with no driver: device/vbd/51712
XENBUS: Device with no driver: device/vif/0
Write protecting the kernel read-only data: 449k
general protection fault: 0000 [1] SMP 
last sysfs file: /block/ram0/dev
CPU 0 
Modules linked in: dm_emc dm_round_robin dm_multipath dm_snapshot dm_mirror
dm_zero dm_mod xfs jfs reiserfs lock_nolock gfs2 ext3 jbd msdos raid456 xor
raid1 raid0 xenblk xennet iscsi_tcp libiscsi scsi_transport_iscsi sr_mod sd_mod
scsi_mod ide_cd cdrom ipv6 squashfs pcspkr loop nfs nfs_acl fscache lockd sunrpc
vfat fat cramfs
Pid: 467, comm: anaconda Not tainted 2.6.17-1.2630.fc6xen #1
RIP: e030:[<ffffffff80316c71>]  [<ffffffff80316c71>]
RSP: e02b:ffff88001d243aa8  EFLAGS: 00010286
RAX: 0000000000000001 RBX: b4d2bb5441444900 RCX: ffff88001eaa0030
RDX: 000000000000005a RSI: ffff88001397b3c8 RDI: ffff88001d460e48
RBP: ffff88001d243b94 R08: ffff88001d243b94 R09: ffff88001ef53d00
R10: ffff88001d243cb8 R11: 0000000000000048 R12: ffff88001d449c80
R13: 0000000000000000 R14: 0000000000000006 R15: 000000000000005b
FS:  00002aaaabbec120(0000) GS:ffffffff8064e000(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000
Process anaconda (pid: 467, threadinfo ffff88001d242000, task ffff88001fb56820)
Stack:  ffff88001e5533d8  ffff88001397b3c8  ffff88001d460e48  ffff88001d955780 
 ffff88001eaa2f00  ffff88001eaa0030  0007000600000005  ffff88001fb56820 
 ffff88001e5533d8  ffff88001d243b94 
Call Trace:
 [<ffffffff80316eba>] security_compute_av+0xba/0xd7
 [<ffffffff803093a1>] avc_has_perm_noaudit+0x136/0x371
 [<ffffffff803177e4>] security_context_to_sid_core+0x240/0x251
 [<ffffffff8030a193>] avc_has_perm+0x26/0x55
 [<ffffffff8030f0fa>] selinux_inode_setxattr+0x17c/0x1d3
 [<ffffffff802098e0>] __d_lookup+0xd3/0x110
 [<ffffffff802d4184>] vfs_setxattr+0x79/0x1da
 [<ffffffff802d43a5>] setxattr+0xc0/0xdd
 [<ffffffff8022ce8b>] mntput_no_expire+0x19/0x8d
 [<ffffffff80223e30>] filp_close+0x5c/0x64
 [<ffffffff8020cd52>] do_path_lookup+0x274/0x2f0
 [<ffffffff80207138>] kmem_cache_free+0x77/0xca
 [<ffffffff80223b2c>] __user_walk_fd+0x41/0x4c
 [<ffffffff802d440c>] sys_lsetxattr+0x4a/0x68
 [<ffffffff8022ce8b>] mntput_no_expire+0x19/0x8d
 [<ffffffff80223e30>] filp_close+0x5c/0x64
 [<ffffffff8021d8b0>] sys_close+0x8f/0xaa
 [<ffffffff8025d816>] system_call+0x86/0x8b
 [<ffffffff8025d790>] system_call+0x0/0x8b
Code: 44 8b 2b e9 ac 00 00 00 44 89 e9 2b 0b 48 8b 43 08 48 d3 e8 
RIP  [<ffffffff80316c71>] context_struct_compute_av+0x12b/0x2ba
 RSP <ffff88001d243aa8>

Comment 3 Jeremy Katz 2006-09-11 17:38:20 UTC
Not reproducing this here on my test box.  

Is the oops from dom0 or domU?

Comment 4 Jesse Keating 2006-09-11 17:50:13 UTC
I think its from domU.  I'll try to replicate on the system I have that does it.

Comment 5 Jesse Keating 2006-09-11 19:13:04 UTC
Now I can't replicate it after a reboot.  NOTABUG.

Comment 6 Jesse Keating 2006-09-12 02:56:22 UTC
Hrm, I can reproduce it again.  Strange.  Same panic as before.

Comment 7 Red Hat Bugzilla 2007-07-24 23:57:02 UTC
change QA contact

Comment 8 Chris Lalancette 2008-02-26 23:20:34 UTC
This report targets FC6, which is now end-of-life.

Please re-test against Fedora 7 or later, and if the issue persists, open a new bug.


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