El 28/04/14 21:02, David Hendricks escribió:
It's not too surprising... Flashrom does not trust
OS timers and uses
its own delay mechanism
loop). It can be argued whether or not it should, but this approach is
deemed more acceptable in the general case. This also has the
side-effect of pegging a CPU at 100%.
To be fair, the problem isn't that flashrom uses 100% CPU, but that it
does nothing while using 100% CPU.
If it failed (with a proper fail message) or complete it's task I
wouldn't care about the CPU usage. The real problem is that it gets
stuck doing nothing.
More specifically, the timeout periods in the chips
and host controllers
which flashrom is often used on tends to be very tight, and usleep() or
nanosleep() only guarantee will wait for a minimum amount of time but
make no guarantees about a maximum amount of time. Obviously it's very
bad if flashrom goes to sleep for too long and a transaction is aborted
because it took the OS a bit too long to wake flashrom up.
I don't know how long of a delay this may impose, but I doubt this
amounts to 15 minutes doing nothing. The logs attached in my previous
message are from a 16 minutes runtime where only the first few seconds
did something. The last 15 minutes the logs got nothing new, and the
program did nothing.
The same thing happens if I don't specify the chip, it just gets stuck
on the first chip it tries.