On 05.10.2010 18:31, Iain Paton wrote:
Carl-Daniel Hailfinger wrote:
your Intel 82540EM which hangs on a flashrom run should spew "Timeout!"
messages with this patch. It would be nice if you could tell us how long
it waits for each chip probe so I can adjust the timeout value.
Please note that this patch will _not_ fix the underlying issue, but I
believe that an endless loop on possibly broken hardware is worse than
Ok, but it's pretty much instant. Just running "time ./flashrom -p
nicintel_spi -V" gets me the following time for the whole thing:
full log at the end of the mail..
Not really sure what's the best way to get more accurate data if you
need it, I'm certainly not getting it with a stopwatch :)
Can you edit nicintel_spi.c and change
#define MAX_REQUEST_LOOPS 10000
#define MAX_REQUEST_LOOPS 1000000
One million loops should be slow enough.
I think you're right in thinking there's some
other tweaking needed
for this card, after running the probe a couple of times I started
root@p7fe-64:~/flashrom# ./flashrom -p nicintel_spi -V
flashrom v0.9.2-r1186 on Linux 2.6.35-dt (x86_64), built with libpci
3.1.4, GCC 4.4.3, little endian
Initializing nicintel_spi programmer
Found "Intel 82540EM Gigabit Ethernet Controller" (8086:100e, BDF
Requested BAR is IO
Mapping Intel Gigabit NIC w/ SPI flash, 0x1000 bytes at unaligned
WTF? Looks like the PCI device stopped responding to config space
accesses, and thus we read 0xffffffff which is then masked to 0xfffffffc
which is not a valid base address for 4 kB mapping.
Error accessing Intel Gigabit NIC w/ SPI flash, 0x1000
/dev/mem mmap failed: Invalid argument
In Linux this error can be caused by the CONFIG_NONPROMISC_DEVMEM
CONFIG_STRICT_DEVMEM (>=2.6.27) and CONFIG_X86_PAT kernel options.
Please check if either is enabled in your kernel before reporting a
You can override CONFIG_X86_PAT at boot with the nopat kernel
disabling the other option unfortunately requires a kernel recompile.
and after a reboot the card vanished from lspci too :) hard power
cycle to get it back which is a bit interesting
This was sort of obvious from the point where the card returned
0xffffffff from a config space access.
The really interesting question is why the card died in the first place.