|
Bugzilla – Full Text Bug Listing |
| Summary: | It takes ages to start second stage installation in XEN kernel | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Lukas Ocilka <locilka> |
| Component: | Kernel | Assignee: | Jan Beulich <jbeulich> |
| Status: | VERIFIED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | lslezak, ms |
| Version: | RC 1 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
Complete hwinfo output
The attachement contains the logs test hypervisor |
||
|
Description
Lukas Ocilka
2005-09-12 13:47:22 UTC
Kurt, my guess is that the problem may be in TLS emulation. I'm not sure whether that big slowdown could be caused by the emulation. Yast is started from 'boot' inits script, TLS is checked in 'boot.xen'. If boot is called as the first init script (as it's written in its header) we have a problem. Added Marcus (maintainer of the yast start scripts) to CC Hmm, we have disabled the TLS optimizations that make Xen crawl for SL10.0, so I don't think this is the issue here. This also means that the boot.xen script is not needed any more. I'll remove it in future versions ... Xen does have a a slightly larger performance hit on x86_64 than on i386, but the way you describe it sounds horrible. The problem seems to be hardware dependent -- on my machines, I can't see a difference in system startup times compared between native and Xen. I have not tested installation though. assuming this problem still exists in RC2: Can you check for any peculiarities in xm demsg and the kernel syslog? Hmm, I cannot reproduce the slow booting in the newest RC 4(?) It's only a bit slower now than a normal Kernel... But after YaST starts, every key-press, every action is very slow :( Which logs do you need? I have observed the same problem - it seems that even some key presses are lost. On my test machine 'acpi=off' helps, keyboard and mouse then work correctly. Also my network card seems to work properly - I had problems with the network before. It's strange because I don't need to turn ACPI off when I use the default kernel. Can you check whether there's any improvement with the update packages for SL10.0? I just have checked SL10.0 + updates and also SLES10 pre3 with the same result - acpi=off is required on the test machine to be able to use kbd&mouse without problems. No improvements so far. Could you please try this again on SLES10 Beta3? If you still have the same issue then please post the hardware you are using because we are having trouble reproducing the problem here. Thx Created attachment 66728 [details]
Complete hwinfo output
This is output of 'hwinfo' command.
It's strange that Xen kernel requires acpi=off, while standard kernel (kernel-default) doesn't require the option.
It still happens in Beta3.
/etc/init.d/boot.xen still present in SLES 10 beta3 (part of xen-tools.rpm -> maintainer Clyde Griffin). Created "Bug 152726 - remove /etc/init.d/boot.xen from package xen-tools" It seems like acpi=off was the last thing mentioned here so I am marking this as a duplicate of bug 153189. *** This bug has been marked as a duplicate of 153189 *** This may not be a duplicate 153189 as there are many different issues that can be resolved with acpi=off. Reopening for further investigation. Please provide, for a matching pair of recent SLES10 beta kernels, /var/log/boot.msg for both a native and a Xen boot. Additionally, check whether /var/log/messages has any entries saying "irq XX: nobody cared" (XX being some number). If not, please provide, from an otherwise idle Xen kernel (preferably with any network cables unplugged), the output from /proc/interrupts taken twice with a time delta of approximately a minute. Not my bugreport anymore... Created attachment 76617 [details]
The attachement contains the logs
I tested SLES10 beta9 kernel, the problem still exists.
With default kernel everything is OK.
With Xen kernel the network card doesn't work at all and mouse/keyborad losses input.
When I use Xen with acpi=off the keyboard and mouse mork properly, but the network is still broken - the interface got an IP address via DHCP but after some time it stopped working.
Files:
boot.msg - kernel 2.6.16-8-default
boot.msg-xen - kernel 2.6.16-8-xen
boot.msg-xen-acpi-off - kernel 2.6.16-8-xen with acpi=off option
/proc/interrupts file doesn't contain any "irq" error message
interrupts - /proc/interrupts - Xen kernel
interrupts2 - the same file after ~4 minutes
interrupts-acpi-off - Xen kernel with acpi off
interrupts2-acpi-off - the same file after ~7 minutes
Created attachment 78327 [details]
test hypervisor
Please test the hypervisor in above attachment (should work with either beta 9 or 10), to determine if the machine needs a workaround that Linux provides but Xen so far doesn't. I just have tested the new xen package in Beta10 and it seems that it works correctly! Network, mouse and keyboard are working properly, thanks! Does this mean we need to apply a patch before this bug can be resolved? Yes, but that patch is already in 3.0-testing. I was just waiting for what exact version makes it into beta 11 before requesting another re-testing round from the originator. I just have tested Xen in SL 10.1 Build 1009 (xen-3.0.2_09640-3) and it works correctly. I think the bug can be closed. Thanks. |