Red Hat Bugzilla – Bug 251263
fedora livecd is dog slow under qemu
Last modified: 2013-01-09 23:23:38 EST
Description of problem:
This may be a qemu bug, and maybe it is even fixed under the f8t1 qemu. But it
is really annoying and I want to make sure there is at least one bug filed
I don't know if this is ATA related, kernel related, qemu related, udev or hal
The observable problem is that on ~50% of qemu boots of fedora7/8t1 livecd, the
starting udev phase will take >60s. Sometimes even times out. Usually when it
is high, the later starting hal phase fails. There are also spurious HSM
violation warnings thrown by the kernel. See this post, and the various
spanning of fedora-devel, qemu-devel, debian-bugs, and linux-ide mailinglists.
Maybe this has been fixed, and the fix just needs to propogate. Did I mention
it was really annoying.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
I've seen it booting a real system, too and on non-live CDs. I just think that
qemu triggers it more frequently...
This bug is on its way to closed
I verified that this does get rid of all the ata HSM emask violation warnings.
I also did several timing tests under qemu of the f7 livecd, and I got these
stock f7 qemu: time to fully logged in - 199s (198, 199, 201)
(did 4 runs, 3 before the next test, then 1 after the next test)
(this is hitting enter immediately at isolinux, and at gdm timeout=59s (immed))
patched stock f7 qemu: time to fully logged in - 187s (189, 185)
conclusion- 6+% boot speedup. I was hoping for more. udev in all cases
consistently takes on the order of 15-20 seconds, and there was that
fedora-devel thread at one point about fedora's udev being bad because of custom
rules. I don't remember any major fallout from that.
For fun, I tried ubuntu-7.04, and got 227s and 218s. So that is nice on
Unfortunately I also tried f8t1, and instead of 3m, got on the order of 15m,
with hal failing to start. (and udev consistently taking about 65s to start,
versus the 20 for f7).
I may file a different bug against f8t1 for the hal failure. (and 5X slowdown
qemu list still hasn't accepted above patch...
qemu patch is applied upstream; filed bug 253542 to get it into our qemu
packages and added it to the kvm packages already
still a problem?
yes and no.
As jeremy mentioned, he filed another bug to get it into fedora's qemu asap.
Personally I have rebuilt and am using the patch, so I'm no longer bothered, but
the rest of fedora qemu users still are.
And then there is the seperate issue, which perhaps I should open a seperate bug
for, that f8t1 took 5X the time to start up as the f7 livecd, under qemu.
Though since this existing bug's title and target(f8t1) match that...
Can anyone reading this confirm the horrendous performance of f8t1 livecd vs f7
and bug 291071
can this be closed?
Yeah, go ahead and close it. I'll reopen or refile if I notice a problem again.