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 related. 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. http://www.opensubscriber.com/message/linux-ide@vger.kernel.org/7262005.html Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
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 https://bugzilla.novell.com/show_bug.cgi?id=291775 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 results- 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 suckitude). 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 livecd?
See also: https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00771.html and bug 291071
can this be closed?
Yeah, go ahead and close it. I'll reopen or refile if I notice a problem again.