Skip to contentSkip to conversation

PCI device driver broken between 4.2 and 4.3

DISCUSSION Олег Мороз 3 participants 9 messages Jan 23, 2016 – Feb 5, 2016 PCI

lore
Share & tools
lore
#0 lore raw

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.

maintainer
#1 lore raw

[+cc linux-kernel]

Hi Олег,

Quoted 11 lines · Олег Мороз

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

#2 lore raw

Okay. I've sent logs (dmesg and lspci) from both 4.2 and 4.3 to bugzilla

23.01.2016 17:54, Bjorn Helgaas пишет:

Quoted 29 lines

[+cc linux-kernel]

Hi Олег,

Quoted 11 lines · Олег Мороз

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

#3 lore raw

Hi Олег,

Quoted 1 line · Олег Мороз

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

Quoted 35 lines

23.01.2016 17:54, Bjorn Helgaas пишет:

Quoted 22 lines

[+cc linux-kernel]

Hi Олег,

Quoted 11 lines · Олег Мороз

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

Quoted 7 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#4 lore raw

[+cc Jiang]

Quoted 23 lines · Bjorn Helgaas

Hi Олег,

Quoted 1 line · Олег Мороз

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

Quoted 7 lines

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

Quoted 39 lines
Quoted 27 lines

23.01.2016 17:54, Bjorn Helgaas пишет:

Quoted 26 lines

[+cc linux-kernel]

Hi Олег,

Quoted 11 lines · Олег Мороз

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).

Quoted 8 lines
Quoted 3 lines

Thanks!

Bjorn

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

#5 lore raw

I confirmed it works in

890e4847587f

and do not works in

991de2e59090

26.01.2016 18:32, Bjorn Helgaas пишет:

Quoted 82 lines

[+cc Jiang]

Quoted 27 lines · Bjorn Helgaas

Hi Олег,

Quoted 1 line · Олег Мороз

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
Quoted 2 lines

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

Quoted 38 lines
Quoted 27 lines

23.01.2016 17:54, Bjorn Helgaas пишет:

Quoted 26 lines

[+cc linux-kernel]

Hi Олег,

Quoted 11 lines · Олег Мороз

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).

Quoted 7 lines
Quoted 3 lines

Thanks!

Bjorn

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

#6 lore raw

Also, my drive has no

pcibios_enable_device()
pcibios_alloc_irq()

calls.

26.01.2016 22:05, Олег Мороз пишет:

Quoted 95 lines

I confirmed it works in

890e4847587f

and do not works in

991de2e59090

26.01.2016 18:32, Bjorn Helgaas пишет:

Quoted 85 lines

[+cc Jiang]

Quoted 30 lines · Bjorn Helgaas

Hi Олег,

Quoted 1 line · Олег Мороз

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

Quoted 2 lines

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

Quoted 38 lines
Quoted 34 lines

23.01.2016 17:54, Bjorn Helgaas пишет:

Quoted 29 lines

[+cc linux-kernel]

Hi Олег,

Quoted 11 lines · Олег Мороз

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

Signature · 3 lines
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 3 lines
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
#7 lore raw
Quoted 6 lines · Мороз Олег

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.

Quoted 109 lines

26.01.2016 22:05, Олег Мороз пишет:

Quoted 103 lines

I confirmed it works in

890e4847587f

and do not works in

991de2e59090

26.01.2016 18:32, Bjorn Helgaas пишет:

Quoted 93 lines

[+cc Jiang]

Quoted 31 lines · Bjorn Helgaas

Hi Олег,

Quoted 2 lines · Олег Мороз

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

Quoted 2 lines

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

Quoted 45 lines
Quoted 41 lines

23.01.2016 17:54, Bjorn Helgaas пишет:

Quoted 35 lines

[+cc linux-kernel]

Hi Олег,

Quoted 7 lines · Олег Мороз

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

Quoted 8 lines

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

Signature · 4 lines
To unsubscribe from this list: send the line "unsubscribe
linux-pci" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 3 lines
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#8 lore raw
In reply to Олег Мороз

[+cc Jiang, Yinghai, Sunjin, linux-kernel]

Quoted 11 lines · Олег Мороз

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.

Sunjin reported another driver, RocketRAID 272x, with the same problem. "pci=routeirq" is a workaround:
https://bugzilla.kernel.org/show_bug.cgi?id=111211#c7

Олег bisected the problem with his driver to Jiang's patch, 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()") and found that "pci=routeirq" was a workaround.

I don't think Sunjin has bisected this, but the RocketRAID driver stopped working at the same time and the same workaround works, so we assume it is the same problem.

Prior to 991de2e59090, we called pcibios_enable_irq() in the pci_enable_device() path, which recursively called pcibios_enable_irq() for upstream bridges via pci_enable_bridge().

After 991de2e59090, we call pcibios_enable_irq() from the pci_device_probe() path instead of the pci_enable_device() path. This does *not* call pcibios_enable_irq() for upstream bridges.

I think this is what Yinghai meant in his response, but I didn't understand the connection.

This is a pretty serious problem that should affect many devices behind bridges, so I think we need a PCI or ACPI core fix. Jiang?

Bjorn