Flashrom stuck using 100% cpu while probing for a chip
I've tried to run flashrom -V to see if it could identify the chip on my new board (AsRock M3A-GLAN), and it got stuck while probing for the first chip. I've tried commenting out that specific chip (AMIC A25L05PT) and then it gets stuck on the next one. Then commented out all AMIC chips, and it got stuck on the next one (the first ATMEL on the list) I've tried with an older flashrom (0.9.2-r1141). It skipped some AMD chips, then got stuck on AMIC again. Talked with "tlt" and "stefanct" on irc and they asked for a strace and a gdb backtrace. Strace produced no results. Gdb log is attached. "stefanct" tried and reproduced it on a machine with nicintel_spi, but warned it was with an unsupported nic: http://paste.flashrom.org/view.php?id=738 -- GatoLoko
On Mon, 01 Aug 2011 13:14:56 +0200 GatoLoko <gatoloko@gmail.com> wrote:
"stefanct" tried and reproduced it on a machine with nicintel_spi, but warned it was with an unsupported nic: http://paste.flashrom.org/view.php?id=738
i am playing with a 82545GM fiber GbE pci-x nic. (name in the log above is wrong). i have added the pci id to nicintel_spi.c which is wrong... because it supports parallel flashes (not sure if it does *not* support SPI at all though) and has an SST39VF020 attached. so mostly ignore my log regarding this bug please and see the other thread about my nicintel problems instead :) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner
Am 01.08.2011 13:14 schrieb GatoLoko:
I've tried to run flashrom -V to see if it could identify the chip on my new board (AsRock M3A-GLAN), and it got stuck while probing for the first chip.
I've tried commenting out that specific chip (AMIC A25L05PT) and then it gets stuck on the next one. Then commented out all AMIC chips, and it got stuck on the next one (the first ATMEL on the list)
I've tried with an older flashrom (0.9.2-r1141). It skipped some AMD chips, then got stuck on AMIC again.
It seems there is a problem with the SPI bus/controller on your machine. Can you run flashrom -c A25L05PT -VVV and attach/paste the output? I have a debugging patch somewhere which checks for timeouts. Maybe I can dig it up again. Regards, Carl-Daniel -- http://www.hailfinger.org/
El 02/08/11 08:38, Carl-Daniel Hailfinger escribió:
Can you run
flashrom -c A25L05PT -VVV
and attach/paste the output?
Done. It stops there until break/kill it. After contacting the mail list, I did a "flashrom -VV" as suggested by "royshosh" on irc, and with got a similar output than this one. His conclusion was that sb600spi lacks a proper timeout. <roysjosh> we need a timeout in sb600spi.c:execute_command() <stefanct> (and nicintel_spi's equivalent ;) -- GatoLoko
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 02/08/11 11:12, GatoLoko escribió:
El 02/08/11 08:38, Carl-Daniel Hailfinger escribió:
Can you run
flashrom -c A25L05PT -VVV
and attach/paste the output?
I've identified the chip as "Macronix MX25L4005APC-12G", so I tried the command "flashrom -c MX25L4005 -VVV" but I got the same result than before. - -- GatoLoko -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk49dnoACgkQMF2GslzCSEujlgEAgTv0mXva9ztLZ54er6LN6hXK uC6wjzpjSb55tewXKWoA/RvHwKH8FkuEgs2J/R+K1hPs1yxjOlwGqAo5xRjvspub =3yr/ -----END PGP SIGNATURE-----
El 06/08/11 19:14, GatoLoko escribió:
I've identified the chip as "Macronix MX25L4005APC-12G", so I tried the command "flashrom -c MX25L4005 -VVV" but I got the same result than before.
A year has passed, and i've tried again to see whether any of the fixes done in the time being changed anything, but it still does the same thing. $ sudo strace -o strace.log ./flashrom -c MX25L4005 -VVV --programmer internal flashrom v0.9.6.1-r1567 on Linux 3.2.0-27-generic (x86_64) flashrom is free software, get the source code at http://www.flashrom.org flashrom was built with libpci 3.1.8, GCC 4.6.3, little endian Command line (5 args): ./flashrom -c MX25L4005 -VVV --programmer internal Calibrating delay loop... OS timer resolution is 2 usecs, 1194M loops per second, 10 myus = 11 us, 100 myus = 101 us, 1000 myus = 1009 us, 10000 myus = 9997 us, 8 myus = 9 us, OK. Initializing internal programmer No coreboot table found. DMI string system-manufacturer: "To Be Filled By O.E.M." DMI string system-product-name: "To Be Filled By O.E.M." DMI string system-version: "To Be Filled By O.E.M." DMI string baseboard-manufacturer: "ASRock" DMI string baseboard-product-name: "M3A-GLAN" DMI string baseboard-version: " " DMI string chassis-type: "Desktop" Found chipset "AMD SB600" with PCI ID 1002:438d. Enabling flash write... SPI base address is at 0xfec00100 AltSpiCSEnable=0, SpiRomEnable=0, AbortEnable=0 PrefetchEnSPIFromIMC=0, PrefetchEnSPIFromHost=0, SpiOpEnInLpcMode=0 SpiArbEnable=1, SpiAccessMacRomEn=1, SpiHostAccessRomEn=1, ArbWaitCount=4, SpiBridgeDisable=0, DropOneClkOnRd=0 NormSpeed is 16.5 MHz GPIO11 used for SPI_DO GPIO12 used for SPI_DI GPIO31 used for SPI_HOLD GPIO32 used for SPI_CS GPIO47 used for SPI_CLK SB700 IMC is not active. ROM strap override is not active OK. The following protocols are supported: LPC, FWH, SPI. Probing for Macronix MX25L4005, 512 kB: sb600_spi_send_command, cmd=9f, writecnt=0, readcnt=3 Writing: SB600 FIFO pointer is 0, wanted 0 Executing: And stops there until I kill it. But this time strace DID output a log. -- GatoLoko
On Fri, 10 Aug 2012 16:34:47 +0200 GatoLoko <gatoloko@gmail.com> wrote:
El 06/08/11 19:14, GatoLoko escribió:
I've identified the chip as "Macronix MX25L4005APC-12G", so I tried the command "flashrom -c MX25L4005 -VVV" but I got the same result than before.
A year has passed, and i've tried again to see whether any of the fixes done in the time being changed anything, but it still does the same thing.
have you tried with carldani's patch? http://patchwork.coreboot.org/patch/3426/ -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 13/08/12 18:44, Stefan Tauner escribió:
On Fri, 10 Aug 2012 16:34:47 +0200 GatoLoko <gatoloko@gmail.com> wrote:
El 06/08/11 19:14, GatoLoko escribió:
I've identified the chip as "Macronix MX25L4005APC-12G", so I tried the command "flashrom -c MX25L4005 -VVV" but I got the same result than before.
A year has passed, and i've tried again to see whether any of the fixes done in the time being changed anything, but it still does the same thing.
have you tried with carldani's patch? http://patchwork.coreboot.org/patch/3426/
I did, a year ago, when he suggested it could help my case. The timeout seemed to work (a little too long, around 30 seconds, but worked), it skipped through the list of supported chips, but skipped the MX25L4005 too. I would try it again, but right now it doesn't apply cleanly on current svn and I don't know how to fix it. If somebody tells me how to apply it I would test it (or any new patches) as many times as needed. - -- GatoLoko -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAlAqXWwACgkQMF2GslzCSEvqPwD9EOs+8SrcoxQ32NnZ+sCsr2MV spoFuX02dSXzI51kUbkA/1t4sLvf/Wb5E7QTtZ9ZX5vPRHaaVdA3uvAHBDBB+Hui =mIZT -----END PGP SIGNATURE-----
On Tue, 14 Aug 2012 16:15:08 +0200 GatoLoko <gatoloko@gmail.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
El 13/08/12 18:44, Stefan Tauner escribió:
have you tried with carldani's patch? http://patchwork.coreboot.org/patch/3426/
I did, a year ago, when he suggested it could help my case. The timeout seemed to work (a little too long, around 30 seconds, but worked), it skipped through the list of supported chips, but skipped the MX25L4005 too.
is the log of that public somewhere? it seems like it was not posted on the mailing list.
I would try it again, but right now it doesn't apply cleanly on current svn and I don't know how to fix it. If somebody tells me how to apply it I would test it (or any new patches) as many times as needed.
thanks a lot for the offer! ill try to nag carl-daniel about this to find out if it makes sense to test the existing patch. in that case i can rebase it, but i dont plan to work on the issue directly myself. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 14/08/12 16:24, Stefan Tauner escribió:
I did, a year ago, when he suggested it could help my case. The timeout seemed to work (a little too long, around 30 seconds, but worked), it skipped through the list of supported chips, but skipped the MX25L4005 too.
is the log of that public somewhere? it seems like it was not posted on the mailing list.
My answer to Carl-Daniel was this: http://www.flashrom.org/pipermail/flashrom/2011-October/008046.html And the direct link to download the log (3.6kb gzip, expands to 51.5kb txt) is here: http://www.flashrom.org/pipermail/flashrom/attachments/20111011/24c6d4b6/att... - -- GatoLoko -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAlAqbVMACgkQMF2GslzCSEsj2QEAx7ypWRtuU4ojcIhHJUWOY8gp cmLO65lRMaFw3MhsynkA/3Wf7LBbAHRVvVfWVXZXW10xgSd7SATr3A9q61VrTn0J =noQe -----END PGP SIGNATURE-----
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. -- GatoLoko
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 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%. 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. -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.
participants (4)
-
Carl-Daniel Hailfinger -
David Hendricks -
GatoLoko -
Stefan Tauner