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 > -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
