Bug 191237

Summary: kernel-xen0-2.6.16-1.2111_FC5 doesn't work
Product: [Fedora] Fedora Reporter: Chris Petersen <lists>
Component: kernelAssignee: Dave Jones <davej>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 5CC: bugs-redhat, hps, pfrields, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-11-24 23:10:47 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:

Description Chris Petersen 2006-05-09 23:20:10 UTC
Description of problem:

Upgraded to kernel-xen0-2.6.16-1.2111_FC5 and suddenly my xen stuff wouldn't
work.  It seems that "xend restart" hangs (stays in the process list but doesn't
go anywhere).  No errors to report.  Any attempt to do anything with xm results in:

    Error connecting to xend: Connection refused.  Is xend running? 

Reverting to 2.6.16-1.2096_FC5 fixes the problem

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

2.6.16-1.2111_FC5

How reproducible:

every time

Comment 1 Henning Schmiedehausen 2006-05-10 07:28:54 UTC
This is not exactly correct. I have two XEN hosts, one is a dual Pentium III
machine, the other a single CPU Pentium IV machine (no HT). 

The kernel works on the SMP machine. It does not work on the single CPU server
(I had to go back to 2.6.16-1.2096). So the problem seems to be related to the
number of CPUs.

RedHat: You might want to regression test your kernels not just on the latest
and greatest hardware... ;-) 

Could we please raise the severity to high? My experience with RedHat Bugzilla
is, that Severity: normal bugs are left alone for a very long time... :-( 

Comment 2 Gianluca Cecchi 2006-05-10 14:15:41 UTC
In my case it is not so.
I have a Dell PE 6650 with 4 cpus.
It fails with both HT enabled (8 cpus) and disabled from bios (4) with the same
error as Chris Petersen's one.
I upgraded from 2054 to 2111 so that I have not the 2096 one to test.
Where can I pick it?
Gianluca
BTW: can I disable HT at runtime in dom0 boot string?

Comment 3 Chris Petersen 2006-05-10 15:39:17 UTC
I can confirm the HT thing -- my box has HT enabled.

Comment 4 Gianluca Cecchi 2006-05-10 20:28:09 UTC
I could also test a dual athlon MP server and the problem is the same.
Also with xen 3.0.2 rpm from testing.
The system is configured with yum update run right today.
kernel 2111 (and devel one 2113) don't work, while 2096 is ok, in the sense that
xend starts.
So my working config is:
[root@fedora ~]# uname -r
2.6.16-1.2096_FC5xen0
[root@fedora ~]# rpm -q xen
xen-3.0.2-0.FC5.1

cat /proc/cpuinfo give  2 x:
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 8
model name      : AMD Athlon(tm) MP 2200+
stepping        : 1
cpu MHz         : 1800.111
cache size      : 256 KB

and 
[root@fedora ~]# xm list
Name                              ID Mem(MiB) VCPUs State  Time(s)
Domain-0                           0      256     2 r-----   352.1

I have no doamins configured at this moment.....
Let me know if I can help debugging things...



Comment 5 Gianluca Cecchi 2006-05-10 20:47:51 UTC
I have also to notice that still with 2096 kernel, the command 
/usr/sbin/xend start
seems to not complete as with the ko kernels....
See below; I don't know if this is correct and always happened before.
I'm just starting testing xen... 
[root@fedora ~]# ps -ef|grep xen | grep -v grep
root        12    11  0 22:40 ?        00:00:00 [xenwatch]
root        13    11  0 22:40 ?        00:00:00 [xenbus]
root      2714     1  0 22:41 ?        00:00:00 xenstored
--pid-file=/var/run/xenstore.pid
root      2717     1  0 22:41 ?        00:00:00 xenconsoled
root      2719     1  0 22:41 ?        00:00:00 python /usr/sbin/xend start
root      2721  2719  0 22:41 ?        00:00:00 python /usr/sbin/xend start
[root@fedora ~]# strace -p 2719
Process 2719 attached - interrupt to quit
waitpid(2721,  <unfinished ...>
Process 2719 detached
[root@fedora ~]# strace -p 2721
Process 2721 attached - interrupt to quit
futex(0x87b3188, FUTEX_WAIT, 0, NULL <unfinished ...>

and this process continues to stay in this state.



Comment 6 Dave Jones 2006-10-17 00:46:30 UTC
A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.

Comment 7 Dave Jones 2006-11-24 23:10:47 UTC
This bug has been mass-closed along with all other bugs that
have been in NEEDINFO state for several months.

Due to the large volume of inactive bugs in bugzilla, this
is the only method we have of cleaning out stale bug reports
where the reporter has disappeared.

If you can reproduce this bug after installing all the
current updates, please reopen this bug.

If you are not the reporter, you can add a comment requesting
it be reopened, and someone will get to it asap.

Thank you.