Re: mlx4_core probe error after applying Yinghai's patch

[Guo Chao <yan@linux.vnet.ibm.com>]

On Tue, Jan 14, 2014 at 12:25:32PM +0200, Jack Morgenstein wrote:
> I suspect one of the following scenarios:
> 
> 1. BAR 0 contains a "PPF Selection" (i.e., ownership) semaphore:  The first PF probe which
> reads the semaphore "acquires" it (i.e., the first read grabs the semaphore (the read returns zero).
> Subsequent reads return non-zero.  When the PF driver is unloaded, it calls "mlx4_free_ownership()",

The read returns 0x1000000. Does it look like a typical value from a
second read?

> which writes a zero into the semaphore dword, so that the next read will return zero.
> 
> In this scenario, initialization of the "PPF selection" semaphore to zero has been compromised somehow, so that
> even the first read attempt returns a non-zero value.  In this scenario, note that the ioremap DID succeed, or
> we would see the "Failed to obtain ownership bit" message in the error log.  Maybe pre-fetching has something
> to do with this? (i.e., maybe if the BAR is not prefetched, the initial value of the semaphore is compromised).
> 

BAR 0 itself is a 64-bit non-prefetchable BAR and not effected by the
patch. It's ROM BAR moved from prefetchable window to non-prefetchable
window. Another change can be seen is the relative position of BAR0 and
ROM BAR.

Thanks,
Guo Chao

> 2. For some reason the same PF is being probed twice by the
> kernel.  In this case the second probe attempt fails because the PF has
> already been probed once.
> 
> This is the reason that I want to see the entire log -- to see if
> indeed the device is being "double-probed"
> 
> -Jack
>