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 http://tracker.coreboot.org/trac/flashrom/browser/trunk/udelay.c#L33 (a busy 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.