On 05.10.2010 18:31, Iain Paton wrote:
Carl-Daniel Hailfinger wrote:
Hi Iain,
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 aborting.
Ok, but it's pretty much instant. Just running "time ./flashrom -p nicintel_spi -V" gets me the following time for the whole thing:
real 0m2.109s user 0m2.106s sys 0m0.012s
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 to #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 getting this:
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 06:02.0). Requested BAR is IO Mapping Intel Gigabit NIC w/ SPI flash, 0x1000 bytes at unaligned 0xfffffffc.
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 bytes at 0xfffffffc /dev/mem mmap failed: Invalid argument In Linux this error can be caused by the CONFIG_NONPROMISC_DEVMEM (<2.6.27), CONFIG_STRICT_DEVMEM (>=2.6.27) and CONFIG_X86_PAT kernel options. Please check if either is enabled in your kernel before reporting a failure. You can override CONFIG_X86_PAT at boot with the nopat kernel parameter but disabling the other option unfortunately requires a kernel recompile. Sorry!
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.
Regards, Carl-Daniel