[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E939E5D.3010208@jp.fujitsu.com>
Date: Tue, 11 Oct 2011 10:39:41 +0900
From: Kenji Kaneshige <kaneshige.kenji@...fujitsu.com>
To: Abdelghani Ouchabane <abdelghani@...no.com>
CC: Bjorn Helgaas <bhelgaas@...gle.com>, linux-kernel@...r.kernel.org,
linux-pci@...r.kernel.org
Subject: Re: PCIe can not rescan for new PCIe device ( FPGA board )
(2011/10/08 1:36), Bjorn Helgaas wrote:
> On Fri, Oct 7, 2011 at 10:22 AM, Abdelghani Ouchabane
> <abdelghani@...no.com> wrote:
>> Bjorn Helgaas wrote:
>>>
>>> [added cc: linux-pci@...r.kernel.org]
>>>
>>> On Fri, Oct 7, 2011 at 1:16 AM, Abdelghani Ouchabane
>>> <abdelghani@...no.com> wrote:
>>>
>>>>
>>>> Hallo,
>>>>
>>>> We are developing a FPGA board connected to a Fedora 15 PC host over
>>>> PCIe.
>>>> Right now, in the implementation and debug phase, I often need to power
>>>> off
>>>> and
>>>> power on the device or try different boards. This causes a problem with
>>>> the
>>>> Fedora 15 running on the AMD PC.
>>>>
>>>> Typically the PC is booted when I need to insert the device under test.
>>>> As
>>>> expected, the Linux doesn't find the device and the software app cannot
>>>> talk
>>>> to it.
>>>>
>>>> * If I do "lspci -v" then it does not list our device.
>>>>
>>>
>>> Do you have pciehp enabled and loaded? I would think a PCIe hot-add
>>> should automatically rescan the bus. Does dmesg say anything when you
>>> do the hot-add?
>>>
>>
>> Thanks Bjorn,
>>
>> Yes, I have them :
>>
>> ****************************************************************************************************
>> lsmod :
>>
>> pciehp 20282 0
>> cgosdrv 17632 0
>> ****************************************************************************************************
>> /etc/modprobe.d/pciehp.conf
>> alias pci:v00001234d00000002sv00001234sd00000001bc11sc80i00 pciehp
>> options pciehp pciehp_force=1 pciehp_debug=1
>> ****************************************************************************************************
>>
>> After I plug my board in, I executed echo 1> /sys/bus/pci/rescan
>
Can you try echo 1 > /sys/bus/pci/slots/XXX/power?
(XXX: slot number)
> It seems like a pciehp bug that you have to rescan explicitly. But
> I'm not a pciehp expert and I haven't looked at the code.
The pciehp automatically scans the bus on presence changed event
(e.g. board is pluged in) if the hot-plug controller supports
surprise removal. Otherwise, you need to power on slot explicitly
by "echo 1 > /sys/bus/pci/slots/XXX/power". So one possibility is
that your controller doesn't support surprise removal. We can
check it by looking at the pciehp's debug output. Can you send
whole dmesg output?
Regards,
Kenji Kaneshige
>
>>>> * But our software returns : 0xFFFFFFFF
>
> This is reading from your device's memory region. It looks like the
> device is configured correctly (BAR values are reasonable and memory
> decoding is enabled) and I assume the bridges leading to it are
> configured correctly (if you posted the complete dmesg log we could
> tell for sure). After that point, Linux is out of the way and it's
> just a question of whether your device responds correctly to the
> memory access.
>
> Are you sure the device is supposed to return something other than
> 0xFFFFFFFF? If it's memory, can you write to it and read the new
> value back? Can you use a PCIe analyzer and see if the device is
> responding correctly on the bus?
>
> Other than the possible pciehp rescan problem, this just looks like a
> problem with your FPGA.
>
> Bjorn
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists