On Mon, Apr 28, 2014 at 11:44 AM, GatoLoko gatoloko@gmail.com wrote:
It's been a while (almost two years) and there have been a lot of changes in flashrom, so I've tested this again and the same problem persists.
Here are new logs from flashrom and strace.
It's not too surprising... Flashrom does not trust OS timers and uses its own delay mechanismhttp://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%.
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.