Bug 251263 - fedora livecd is dog slow under qemu
Summary: fedora livecd is dog slow under qemu
Alias: None
Product: Fedora
Classification: Fedora
Component: udev   
(Show other bugs)
Version: 8
Hardware: All Linux
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-08-07 23:21 UTC by Jane Dogalt
Modified: 2013-01-10 04:23 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-21 07:09:25 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 Jane Dogalt 2007-08-07 23:21:16 UTC
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
against it.

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):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 1 Jeremy Katz 2007-08-07 23:42:13 UTC
I've seen it booting a real system, too and on non-live CDs.  I just think that
qemu triggers it more frequently...

Comment 2 Jane Dogalt 2007-08-19 08:35:40 UTC
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
fedora's part.

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...

Comment 3 Jeremy Katz 2007-08-21 19:29:53 UTC
qemu patch is applied upstream; filed bug 253542 to get it into our qemu
packages and added it to the kvm packages already

Comment 4 Harald Hoyer 2007-08-24 10:33:33 UTC
still a problem?

Comment 5 Jane Dogalt 2007-08-27 05:35:08 UTC
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

Comment 7 Harald Hoyer 2008-02-20 11:30:43 UTC
can this be closed?

Comment 8 Jane Dogalt 2008-02-20 21:01:03 UTC
Yeah, go ahead and close it.  I'll reopen or refile if I notice a problem again.

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