Re: PCI device driver broken between 4.2 and 4.3

["Олег Мороз" <oleg.moroz@mcc.vniiem.ru>]

Ohhh. It's not my driver from scratch. I'm just trying to maintain it in 
working state.
Could you please advice me some correct and small and simple (I know I 
ask a lot) PCI driver as example. Maybe it will be not so hard to fix 
this 1553b driver.

02.02.2016 19:13, Bjorn Helgaas пишет:
> On Tue, Feb 02, 2016 at 08:04:39AM +0300, Олег Мороз wrote:
>> it looks much better with pci=routeirq
>>
>> [  100.896723] *Before pci_enable_device IRQ 20*
>> [  100.896735] *After pci_enable_device IRQ 20*
>> [  100.896745] *Before pci_enable_device IRQ 21*
>> [  100.896752] *After pci_enable_device IRQ 21*
> If pci=routeirq makes a difference, it usually means your driver is
> looking at dev->irq before it calls pci_enable_device().  I looked at
> what I think is your driver
> (https://github.com/qmor/elcus-1553-driver-linux/blob/master/driver/tmk1553.c),
> but I didn't *see* that problem.  It does use a highly unconventional
> strategy of calling pci_get_device() to locate devices, instead of
> using pci_register_driver() like normal drivers do.
>
> You should not have to use pci=routeirq, and I've even considered
> removing the option.
>
>> On Monday 01 of February 2016 15:08:23 Bjorn Helgaas wrote:
>>> [+cc Yinghai]
>>>
>>> On Mon, Feb 01, 2016 at 08:18:35AM +0300, Олег Мороз wrote:
>>>> Okay. I've started from driver level printk
>>>> results are:
>>>>
>>>> On 4.2
>>>>
>>>> [414006.575989] Before pci_enable_device IRQ 20
>>>>
>>>> [414006.575991] After pci_enable_device IRQ 20
>>>>
>>>> [414006.575997] Before pci_enable_device IRQ 21
>>>>
>>>> [414006.575999] After pci_enable_device IRQ 21
>>>>
>>>> on 4.3
>>>>
>>>> [  114.862289] Before pci_enable_device IRQ 5
>>>>
>>>> [  114.862303] After pci_enable_device IRQ 5
>>>>
>>>> [  114.862316] Before pci_enable_device IRQ 5
>>>>
>>>> [  114.862326] After pci_enable_device IRQ 5
>>>>
>>>> I've got two cards, because of that pci_enable_device() calls twice.
>>> Did you try booting with pci=routeirq as Yinghai suggested?  That's
>>> not a fix, but if it does make things work, it may give us an idea for
>>> how to fix it correctly.
>>>
>>>> On Friday 29 of January 2016 10:31:59 Bjorn Helgaas wrote:
>>>>> On Thu, Jan 28, 2016 at 10:28:14PM +0300, Мороз Олег wrote:
>>>>>> What i need to print out at first order?
>>>>> Jiang, can you chime in here?
>>>>>
>>>>> 991de2e59090 is related to IRQs, so I'd start by printing dev->irq in
>>>>> your
>>>>> driver before and after you call pci_enable_device().  Add some printks
>>>>> in
>>>>> pcibios_alloc_irq() and pcibios_enable_device() just to confirm that we
>>>>> got
>>>>>
>>>>> there and when, e.g., add lines like this:
>>>>>    dev_info(&dev->dev, "%s\n", __func__);
>>>>>
>>>>> Bjorn
>>>>>
>>>>>> 27 янв. 2016 г. 16:22 пользователь Bjorn Helgaas <helgaas@kernel.org>
>>>> написал:
>>>>>>> On Wed, Jan 27, 2016 at 12:38:06PM +0300, Мороз Олег wrote:
>>>>>>>> Also, my drive has no
>>>>>>>>
>>>>>>>> pcibios_enable_device()
>>>>>>>> pcibios_alloc_irq()
>>>>>>>>
>>>>>>>> calls.
>>>>>>> Those are internal interfaces used by the PCI core.  Drivers
>>>>>>> shouldn't
>>>>>>> call them directly.  Drivers normally call pci_enable_device(), and
>>>>>>> those internal interfaces are used in that path.
>>>>>>>
>>>>>>>> 26.01.2016 22:05, Олег Мороз пишет:
>>>>>>>>> I confirmed it works in
>>>>>>>>>
>>>>>>>>> 890e4847587f
>>>>>>>>>
>>>>>>>>> and do not works in
>>>>>>>>>
>>>>>>>>> 991de2e59090
>>>>>>>>>
>>>>>>>>> 26.01.2016 18:32, Bjorn Helgaas пишет:
>>>>>>>>>> [+cc Jiang]
>>>>>>>>>>
>>>>>>>>>> On Mon, Jan 25, 2016 at 03:52:51PM -0600, Bjorn Helgaas wrote:
>>>>>>>>>>> Hi Олег,
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Jan 24, 2016 at 04:50:08PM +0300, Олег Мороз wrote:
>>>>>>>>>>>> Okay. I've sent logs (dmesg and lspci) from both 4.2 and 4.3
>>>>>>>>>>>> to bugzilla
>>>>>>>>>>> I don't see anything wrong in either log.  Both v4.2 and v4.3
>>>>>>>>>>> enumerate the device the same way, and the driver seems to
>>>>>>>>>>> claim it
>>>>>>>>>>>
>>>>>>>>>>> the same way:
>>>>>>>>>>>    pci 0000:0d:00.0: [10b5:9030] type 00 class 0x078000
>>>>>>>>>>>    pci 0000:0d:00.0: reg 0x14: [io  0x2100-0x217f]
>>>>>>>>>>>    pci 0000:0d:00.0: reg 0x18: [io  0x2380-0x239f]
>>>>>>>>>>>    pci 0000:0d:00.0: PME# supported from D0 D3hot
>>>>>>>>>>>    pci 0000:0d:01.0: [10b5:9030] type 00 class 0x078000
>>>>>>>>>>>    pci 0000:0d:01.0: reg 0x14: [io  0x2180-0x21ff]
>>>>>>>>>>>    pci 0000:0d:01.0: reg 0x18: [io  0x23a0-0x23bf]
>>>>>>>>>>>    pci 0000:0d:01.0: PME# supported from D0 D3hot
>>>>>>>>>>>    pci 0000:0d:02.0: [10b5:9030] type 00 class 0x078000
>>>>>>>>>>>    pci 0000:0d:02.0: reg 0x14: [io  0x2200-0x227f]
>>>>>>>>>>>    pci 0000:0d:02.0: reg 0x18: [io  0x2280-0x22ff]
>>>>>>>>>>>    pci 0000:0d:02.0: reg 0x1c: [io  0x2300-0x237f]
>>>>>>>>>>>    pci 0000:0d:02.0: PME# supported from D0 D3hot
>>>>>>>>>>>    
>>>>>>>>>>>    sja1000_plx_pci 0000:0d:02.0: Detected "Eclus CAN-200-PCI"
>>>>>>>>>>>
>>>>>>>>>>> card at slot #2
>>>>>>>>>>>
>>>>>>>>>>>    sja1000_plx_pci 0000:0d:02.0: Channel #1 at
>>>>>>>>>>>
>>>>>>>>>>> 0x0000000000012280, irq 22 registered as can0
>>>>>>>>>>>
>>>>>>>>>>>    sja1000_plx_pci 0000:0d:02.0: Channel #2 at
>>>>>>>>>>>
>>>>>>>>>>> 0x0000000000012300, irq 22 registered as can1
>>>>>>>>>>>
>>>>>>>>>>>    sja1000_plx_pci 0000:0d:02.0 can0: setting BTR0=0x03
>>>>>>>>>>>    BTR1=0x37
>>>>>>>>>>>
>>>>>>>>>>> One option is always to bisect between v4.2 and v4.3 to see
>>>>>>>>>>> which
>>>>>>>>>>> commit made it stop working.  See
>>>>>>>>>>> https://git-scm.com/docs/git-bisect
>>>>>>>>>> Jiang, Олег bisected this to 991de2e59090 ("PCI, x86: Implement
>>>>>>>>>> pcibios_alloc_irq() and pcibios_free_irq()").
>>>>>>>>>>
>>>>>>>>>> Олег, please double-check and confirm that 890e4847587f works
>>>>>>>>>> and
>>>>>>>>>> 991de2e59090 fails.
>>>>>>>>>>
>>>>>>>>>> Then please add some printks in the pcibios_enable_device() and
>>>>>>>>>> pcibios_alloc_irq() paths and in your driver to see exactly what
>>>>>>>>>> changed
>>>>>>>>>> between 890e4847587f and 991de2e59090
>>>>>>>>>>
>>>>>>>>>> Bjorn
>>>>>>>>>>
>>>>>>>>>>>> 23.01.2016 17:54, Bjorn Helgaas пишет:
>>>>>>>>>>>>> [+cc linux-kernel]
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Олег,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sat, Jan 23, 2016 at 1:08 AM, Олег Мороз
>>>>>>>>>>>>>
>>>>>>>>>>>>> <oleg.moroz@mcc.vniiem.ru> wrote:
>>>>>>>>>>>>>> Hello. I've got a device driver for MIL-1553b card
>>>>>>>>>>>>>> called TA1-PCI, which
>>>>>>>>>>>>>> could be found at
>>>>>>>>>>>>>> https://github.com/qmor/elcus-1553-driver-linux
>>>>>>>>>>>>>> Card is using PLX_PCI9030 PCI controller.
>>>>>>>>>>>>>> Today i've found that this driver compiles, installes,
>>>>>>>>>>>>>> but is not working as
>>>>>>>>>>>>>> it should.
>>>>>>>>>>>>>> Looks like it not receives any interrupts from PCI. I've
>>>>>>>>>>>>>> test it again with
>>>>>>>>>>>>>> kernel
>>>>>>>>>>>>>> 4.2 and it works okay. What changes was made in PCI
>>>>>>>>>>>>>> subsystem from 4.2 to
>>>>>>>>>>>>>> 4.3
>>>>>>>>>>>>>> which could have impact this driver work.
>>>>>>>>>>>>> Thank you very much for this problem report.  There were many
>>>>>>>>>>>>> PCI
>>>>>>>>>>>>> changes between v4.2 and v4.3, and without more information,
>>>>>>>>>>>>> I
>>>>>>>>>>>>> can't
>>>>>>>>>>>>> guess what might be causing this problem.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I opened a bug report at
>>>>>>>>>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=111211
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please attach complete dmesg logs for both v4.2 and v4.3 to
>>>>>>>>>>>>> that
>>>>>>>>>>>>> bug
>>>>>>>>>>>>> report.  Also, please attach the complete "lspci -vv" output
>>>>>>>>>>>>> (as
>>>>>>>>>>>>> root).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>
>>>>>>>>>>>>> Bjorn
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> -- 
>> С уважением,
>> Олег Мороз
>> Заместитель начальника отдела разработки ПО БВС КА
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html