Re: [PATCH 02/11] PCI: Try to allocate mem64 above 4G at first

From: H. Peter Anvin
Date: Tue May 29 2012 - 16:51:13 EST

Next message: David Miller: "Re: [PATCH 02/11] PCI: Try to allocate mem64 above 4G at first"
Previous message: Karandeep Chahal: "[PATCH] Infiniband srp fast failover patch. Currently ib_srp doesnot do anything on receiving a DREQ from the target, itonly sends a response back. Further it also does notmonitor port (down) events. I have patched srp to removescsi devices when a port down event is received or if thetarget sends a DREQ. Currently even though the targetnotifies the initiator of its intentions of going away, theinitiator ignores that information. Later the initiatorgets upset when the devices "suddenly" disappear resultingin srp initiating an error recovery process which takes along time. This caused high failover latencies as comparedto fibre channel. In my experiments with RHEL 6.0 and 6.2 Iencountered failover time that exceeded 2 minutes and 20seconds (despite tweaking /etc/multipath.conf and/sys/block/<>/timeout). With this patch the failover takes30 seconds. I have tested this patch with and without aswitch."
In reply to: Yinghai Lu: "Re: [PATCH 02/11] PCI: Try to allocate mem64 above 4G at first"
Next in thread: David Miller: "Re: [PATCH 02/11] PCI: Try to allocate mem64 above 4G at first"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On 05/29/2012 01:46 PM, Yinghai Lu wrote:
> On Tue, May 29, 2012 at 12:03 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote:
>> On 05/29/2012 11:17 AM, Yinghai Lu wrote:
>>>
>>> pci bridge could support 16bits and 32bits io port.
>>> but we did not record if 32bits is supported.
>>>
>>
>> Okay, so this is the actual problem, no?
>
> their fw could not need kernel help to allocate io ports, or they are
> only use device that support 32bit ioport.
>

That barely parses, never mind makes sense.

>>
>>> so during allocating, could have allocated above 64k address to non
>>> 32bit bridge.
>>>
>>> but x86 is ok, because ioport.end always set to 0xffff.
>>> other arches with IO_SPACE_LIMIT with 0xffffffff or
>>> 0xffffffffffffffffUL may have problem.
>>
>> The latter is nonsense, the PCI-side address space is only 32 bits wide.
>>
> maybe they have unified io include ioport and mem io?
>

The bus-side address space should not be more than 32 bits no matter
what. As Bjorn indicates, you seem to be mixing up bus and cpu
addresses all over the place.

-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/