On 07/14/2009 09:09 AM, Eric Kerin wrote:
> I think the approval queue ate my first email, let's try this again...
>
>
> ---------- Forwarded message ----------
> From: Eric Kerin <eric_kerin@xxxxxxxxxxxx>
> Date: Thu, Jul 9, 2009 at 4:18 PM
> Subject: Installing livecd from USB stick - Bug #502771 -
> Investigation and patch
> To: anaconda-devel-list@xxxxxxxxxx
> Cc: clumens@xxxxxxxxxx
>
>
> I put this in bugzilla in the closed bug - it was marked as a
> duplicate of another, it was suggested that I post it here.
>
> Quick summary - mke2fs will finish it's work quickly, and anaconda
> will spend quite sometime reading in the output, and updating the
> progress dialog in certain cases - the attached patch adds a check to
> the read/progress loop to check to see if the process has finished,
> and jumps out early if that's the case.
>
>
> Long story - I'm working on a netbook livecd install for Fedora. With
> the screen size of the machine I have to test on, anaconda goes into
> full-screen mode, the progress dialog goes full-screen as well (and
> remains hidden too, have not checked into this yet), it looks like
> because of this, it takes a long time for the progress pulses to
> return. (FYI - my machine also happens to be running maximus, but
> anaconda is excluded from it's maximizing effects)
>
> I ran into the same problem as others have, where you can hit next
> early, and applied the patch to make the progress dialog modal, but
> still ran into long periods of time where it was "formatting" with no
> disk IO. A quick check, and mke2fs was defunct, and anaconda was
> using up CPU nicely. I did some digging, and found that it was still
> reading the stdout data from mke2fs (it was printed very slowly, one
> character at a time to /dev/tty5)
>
> What I found, was that since iutil.py's execWithPulseProgress method
> reads one character at a time, in cases where the progress.pulse()
> method takes a long time to return, it slows up the reading of data,
> and the eventual reaping of the process. Which manifests as a defunct
> mke2fs process. If you give it long enough, it will
> continue the install. Long enough being 10 minutes or so, depending
> on your system.
>
> There's a loop in gui.py that smooths the pulses if it took a long
> time between calls, that's where a lot of the delay is spent, doing
> processEvents(), and because of the loop and smoothing it can start to
> take even longer - the first call to pulse that waits is is for <1s,
> next one smoothing a delta of 5 seconds, the next call is for 20 s
> delta, then 80 s delta...Eventually, it reads every character, after
> this exponentially increasing wait state.
>
> The attached patch does two things, only the change to iutil.py is
> really necessary - it just checks to see if the child process has
> exited already, and breaks if it is, since we don't need the output of
> the child process anyway. The patch for gui.py just keeps the delay
> from getting exponentially longer.
Looks good to me, modulo some formatting issues. Thanks!
--
Peter
Any connection between your reality and mine is purely coincidental.
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
