[flashrom] Add timeout check to SPI bitbang bus request

[Carl-Daniel Hailfinger]

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 at 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

-- 
http://www.hailfinger.org/