Bug 810471
Summary: | boot fails while starting guest with sockets>62 and cores=1 and threads=1 option and 10 virtio disks | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | FuXiangChun <xfu> | ||||
Component: | qemu-kvm | Assignee: | Gleb Natapov <gleb> | ||||
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | high | ||||||
Version: | 6.3 | CC: | acathrow, areis, bsarathy, chayang, dyasny, flang, juzhang, knoel, michen, minovotn, mkenneth, qzhang, shuang, shu, sluo, tburke, virt-maint, wdai, xigao | ||||
Target Milestone: | rc | Keywords: | Reopened | ||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | seabios-0.6.1.2-19.el6 | Doc Type: | Bug Fix | ||||
Doc Text: |
No documentation needed
|
Story Points: | --- | ||||
Clone Of: | Environment: | ||||||
Last Closed: | 2012-06-20 11:46:12 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
FuXiangChun
2012-04-06 09:57:34 UTC
Created attachment 575691 [details]
no bootable device
So this is just a variation of BZ06797. BIOS runs out of memory and cannot initialize boot disk. Amount of CPU matters since MPC table size depends on it. Bios create an entry for each socket, so number of sockets is really what matters here. (In reply to comment #3) > So this is just a variation of BZ06797. BIOS runs out of memory and cannot > initialize boot disk. Amount of CPU matters since MPC table size depends on it. > Bios create an entry for each socket, so number of sockets is really what > matters here. Gleb: you mean Bug 706797, right? If that's the case, the bug was closed as NOTABUG, but this one is devel_ack'ed, so I assume it's indeed valid and I'll keep it AS IS. (In reply to comment #4) > (In reply to comment #3) > > So this is just a variation of BZ06797. BIOS runs out of memory and cannot > > initialize boot disk. Amount of CPU matters since MPC table size depends on it. > > Bios create an entry for each socket, so number of sockets is really what > > matters here. > > Gleb: you mean Bug 706797, right? If that's the case, the bug was closed as Yes, I do. Sorry. > NOTABUG, but this one is devel_ack'ed, so I assume it's indeed valid and I'll > keep it AS IS. Why devel_ack is relevant? However sets devel_ack does it without investigating the problem usually, so it mostly meaningless before developer actually looks at the bug. I am sure that one was devel_ack'ed too before been closed as NOTABUG. But I see that large number of virtio disks causes troubles in real life scenarios, so I will try to optimize that use case. I will try to implement the hack that I descried in Bug 706797 [1] and see how bad it is. But that would be the fix for 706797, not this bug. There is nothing that can be done for system with to many sockets. Of course if virtio disk will not consume a lot of low memory, more memory will be available for MPC tables. Hope this will push max amount of sockets we can support high enough for us to not care. [1] Another fix would be to have only one vq for all virtio devices and reinitialize it on each disk access. This is hackish and may slow down BIOS access to virtio disk though. I'll close the bug since there is a work around which is actually the desired path (using less sockets and more cores per sockets) (In reply to comment #6) > I'll close the bug since there is a work around which is actually the desired > path (using less sockets and more cores per sockets) That's good because actually moving to one vq for all vritio disks will not help this BZ. The reason is that vqs are allocated not from the same memory pool as MPC tables. There are small, per disk structure that is allocated from the same pool and in the case of this BZ this small allocations start to fail. I am looking into moving this allocation out of this memory pool, but the assumption goes pretty dip into the code. This problem is more or less solved on upstream Seabios. The memory allocation that fails is from f-segment pool. Upstream Seabios relocates 32bit init code from f-segment to high memory before execution and adds freed memory to f-segment pool. In the end the pool contains ~20K bytes instead of 2K (of course it depend on how much memory 16bit code occupies in f-segment. 16bit code has to be there and cannot be relocated). Backporting all the patches that do reallocation is not trivial. Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: No documentation needed Reproduced this issue with seabios-0.6.1.2-12.el6.x86_64 1.Boot guest with the same qemu-kvm command line in Comment 0 Boot failed, VNC console prompts "no bootable device" . Verified this issue with seabios-0.6.1.2-19.el6.x86_64 1.Boot guest with the same qemu-kvm command line in Comment 0 Guest normal start, also test with " -smp 160 " can boot guest successfully. So, this bug has been fixed. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0746.html |