1:14 p.m.
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
1:51 p.m.
On Mon, 01 Aug 2011 13:14:56 +0200
GatoLoko <gatoloko(a)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
8:38 a.m.
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/
11:12 a.m.
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
7:14 p.m.
-----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-----
4:34 p.m.
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
6:44 p.m.
On Fri, 10 Aug 2012 16:34:47 +0200
GatoLoko <gatoloko(a)gmail.com> wrote:
El 06/08/11 19:14, GatoLoko escribió:
have you tried with carldani's patch?
http://patchwork.coreboot.org/patch/3426/
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
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.
4:15 p.m.
-----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(a)gmail.com>
wrote:
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
El 06/08/11 19:14, GatoLoko escribió:
have you tried with carldani's patch?
http://patchwork.coreboot.org/patch/3426/
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. -----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-----
4:24 p.m.
On Tue, 14 Aug 2012 16:15:08 +0200
GatoLoko <gatoloko(a)gmail.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
El 13/08/12 18:44, Stefan Tauner escribió:
is the log of that public somewhere? it seems like it was not posted on
the mailing list.
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.
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
5:22 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
El 14/08/12 16:24, Stefan Tauner escribió:
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/at…
- --
GatoLoko
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. -----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-----
8:44 p.m.
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
9:02 p.m.
New subject: Flashrom stuck using 100% cpu while probing for a chip
On Mon, Apr 28, 2014 at 11:44 AM, GatoLoko <gatoloko(a)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…
(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.
2265
days inactive
3266
days old
11 comments
4 participants
participants (4)
-
Carl-Daniel Hailfinger -
David Hendricks -
GatoLoko -
Stefan Tauner