* Regression in v4.4.124 due to 'genirq: Use irqd_get_trigger_type to compare ..'
@ 2018-03-28 21:59 Guenter Roeck
2018-03-29 6:32 ` Greg Kroah-Hartman
0 siblings, 1 reply; 8+ messages in thread
From: Guenter Roeck @ 2018-03-28 21:59 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Marc Zyngier, stable, Hans de Goede
Hi Greg,
commit 9d0273bb1c4b64 ("genirq: Use irqd_get_trigger_type to compare the trigger
type for shared IRQs") causes a regression in v4.4.124. The problem has been fixed
upstream with commit 4f8413a3a799 ("genirq: Track whether the trigger type has
been set"). Please apply that patch to v4.4.y at your earliest convenience.
The patch does not apply cleanly; you'll get a conflict include/linux/irq.h.
The fix is simple - just take the version introduced by the patch. It adds
a couple of extra defines, but those don't hurt and just keep the code aligned
with upstream.
Thanks,
Guenter
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Regression in v4.4.124 due to 'genirq: Use irqd_get_trigger_type to compare ..' 2018-03-28 21:59 Regression in v4.4.124 due to 'genirq: Use irqd_get_trigger_type to compare ..' Guenter Roeck @ 2018-03-29 6:32 ` Greg Kroah-Hartman 2018-03-29 17:54 ` Guenter Roeck 0 siblings, 1 reply; 8+ messages in thread From: Greg Kroah-Hartman @ 2018-03-29 6:32 UTC (permalink / raw) To: Guenter Roeck; +Cc: Marc Zyngier, stable, Hans de Goede On Wed, Mar 28, 2018 at 02:59:18PM -0700, Guenter Roeck wrote: > Hi Greg, > > commit 9d0273bb1c4b64 ("genirq: Use irqd_get_trigger_type to compare the trigger > type for shared IRQs") causes a regression in v4.4.124. The problem has been fixed > upstream with commit 4f8413a3a799 ("genirq: Track whether the trigger type has > been set"). Please apply that patch to v4.4.y at your earliest convenience. > > The patch does not apply cleanly; you'll get a conflict include/linux/irq.h. > The fix is simple - just take the version introduced by the patch. It adds > a couple of extra defines, but those don't hurt and just keep the code aligned > with upstream. Thanks, this was also needed for 4.9.y and 3.18.y. greg k-h ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Regression in v4.4.124 due to 'genirq: Use irqd_get_trigger_type to compare ..' 2018-03-29 6:32 ` Greg Kroah-Hartman @ 2018-03-29 17:54 ` Guenter Roeck 2018-03-29 20:28 ` Guenter Roeck 0 siblings, 1 reply; 8+ messages in thread From: Guenter Roeck @ 2018-03-29 17:54 UTC (permalink / raw) To: Greg Kroah-Hartman; +Cc: Marc Zyngier, stable, Hans de Goede On Thu, Mar 29, 2018 at 08:32:01AM +0200, Greg Kroah-Hartman wrote: > On Wed, Mar 28, 2018 at 02:59:18PM -0700, Guenter Roeck wrote: > > Hi Greg, > > > > commit 9d0273bb1c4b64 ("genirq: Use irqd_get_trigger_type to compare the trigger > > type for shared IRQs") causes a regression in v4.4.124. The problem has been fixed > > upstream with commit 4f8413a3a799 ("genirq: Track whether the trigger type has > > been set"). Please apply that patch to v4.4.y at your earliest convenience. > > > > The patch does not apply cleanly; you'll get a conflict include/linux/irq.h. > > The fix is simple - just take the version introduced by the patch. It adds > > a couple of extra defines, but those don't hurt and just keep the code aligned > > with upstream. > > Thanks, this was also needed for 4.9.y and 3.18.y. > Odd that I didn't see the problem there. But then I still see the following in 4.4.y after the above was added. genirq: Flags mismatch irq 24. 00000080 ([PCI] PME) vs. 00000080 ([EDAC] PCI err) This is with powerpc:mpc8544ds:mpc85xx_defconfig. I do _not_ see this problem in v4.9+. Looks like I'll need to spend more time on this. Guenter ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Regression in v4.4.124 due to 'genirq: Use irqd_get_trigger_type to compare ..' 2018-03-29 17:54 ` Guenter Roeck @ 2018-03-29 20:28 ` Guenter Roeck 2018-03-29 21:07 ` Nathan Chancellor 0 siblings, 1 reply; 8+ messages in thread From: Guenter Roeck @ 2018-03-29 20:28 UTC (permalink / raw) To: Greg Kroah-Hartman; +Cc: Marc Zyngier, stable, Hans de Goede Hi Greg, On Thu, Mar 29, 2018 at 10:54:34AM -0700, Guenter Roeck wrote: > On Thu, Mar 29, 2018 at 08:32:01AM +0200, Greg Kroah-Hartman wrote: > > On Wed, Mar 28, 2018 at 02:59:18PM -0700, Guenter Roeck wrote: > > > Hi Greg, > > > > > > commit 9d0273bb1c4b64 ("genirq: Use irqd_get_trigger_type to compare the trigger > > > type for shared IRQs") causes a regression in v4.4.124. The problem has been fixed > > > upstream with commit 4f8413a3a799 ("genirq: Track whether the trigger type has > > > been set"). Please apply that patch to v4.4.y at your earliest convenience. > > > > > > The patch does not apply cleanly; you'll get a conflict include/linux/irq.h. > > > The fix is simple - just take the version introduced by the patch. It adds > > > a couple of extra defines, but those don't hurt and just keep the code aligned > > > with upstream. > > > > Thanks, this was also needed for 4.9.y and 3.18.y. > > > > Odd that I didn't see the problem there. But then I still see the following > in 4.4.y after the above was added. > > genirq: Flags mismatch irq 24. 00000080 ([PCI] PME) vs. 00000080 ([EDAC] PCI err) > > This is with powerpc:mpc8544ds:mpc85xx_defconfig. I do _not_ see this problem > in v4.9+. > > Looks like I'll need to spend more time on this. > I confirmed that this is still broken in 4.4.y, even after 4f8413a3a799 has been applied. Example output on a Acer 15.6" APL Chromebook, with both patches applied: [ 0.240913] gpiochip_find_base: found new base at 434 [ 0.240956] gpiochip_add_data: registered GPIOs 434 to 511 on device: INT3452:00 [ 0.240960] GPIO chip INT3452:00: created GPIO range 0->77 ==> INT3452:00 PIN 0->77 [ 0.241311] gpiochip_find_base: found new base at 357 [ 0.241347] gpiochip_add_data: registered GPIOs 357 to 433 on device: INT3452:01 [ 0.241350] GPIO chip INT3452:01: created GPIO range 0->76 ==> INT3452:01 PIN 0->76 [ 0.241353] genirq: Flags mismatch irq 14. 00000080 (INT3452:01) vs. 00000080 (INT3452:00) [ 0.242055] broxton-pinctrl INT3452:01: failed to request interrupt [ 0.242696] broxton-pinctrl: probe of INT3452:01 failed with error -16 [ 0.243452] gpiochip_find_base: found new base at 387 [ 0.243490] gpiochip_add_data: registered GPIOs 387 to 433 on device: INT3452:02 [ 0.243493] GPIO chip INT3452:02: created GPIO range 0->46 ==> INT3452:02 PIN 0->46 [ 0.243496] genirq: Flags mismatch irq 14. 00000080 (INT3452:02) vs. 00000080 (INT3452:00) [ 0.244195] broxton-pinctrl INT3452:02: failed to request interrupt [ 0.244813] broxton-pinctrl: probe of INT3452:02 failed with error -16 [ 0.245549] gpiochip_find_base: found new base at 391 [ 0.245585] gpiochip_add_data: registered GPIOs 391 to 433 on device: INT3452:03 [ 0.245588] GPIO chip INT3452:03: created GPIO range 0->42 ==> INT3452:03 PIN 0->42 [ 0.245591] genirq: Flags mismatch irq 14. 00000080 (INT3452:03) vs. 00000080 (INT3452:00) [ 0.246322] broxton-pinctrl INT3452:03: failed to request interrupt [ 0.246912] broxton-pinctrl: probe of INT3452:03 failed with error -16 Reverting 9d0273bb1c4b64 after the v4.4.124 merge into chromeos-4.4 fixes the problem. At this point I got a bit frantic and decided to try the shotgun approach. I applied 4b357daed698 genirq: Look-up trigger type if not specified by caller f35ad083783e genirq: Look-up percpu trigger type if not specified by caller 00b992deaa08 genirq: No need to mask non trigger mode flags before __irq_set_trigger() 7ee7e87dfb15 genirq: Use irq type from irqdata instead of irqdesc (minor conflicts due to pr_warning -> pr_warn) on top of v4.4.124. With those patches applied, the problem went away, both on the Acer Chromebook and the qemu test which previously failed. Note that I have _no_ idea if this is correct, necessary, and/or complete. All I know is that it fixes the problems I have found so far. Overall question is why 9d0273bb1c4b64 was applied to v4.4.y in the first place. It does cause a whole lot of trouble. Was that really worth it ? Guenter ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Regression in v4.4.124 due to 'genirq: Use irqd_get_trigger_type to compare ..' 2018-03-29 20:28 ` Guenter Roeck @ 2018-03-29 21:07 ` Nathan Chancellor 2018-03-29 21:45 ` Guenter Roeck 0 siblings, 1 reply; 8+ messages in thread From: Nathan Chancellor @ 2018-03-29 21:07 UTC (permalink / raw) To: Guenter Roeck; +Cc: Greg Kroah-Hartman, Marc Zyngier, stable, Hans de Goede On Thu, Mar 29, 2018 at 01:28:45PM -0700, Guenter Roeck wrote: > Hi Greg, > > On Thu, Mar 29, 2018 at 10:54:34AM -0700, Guenter Roeck wrote: > > On Thu, Mar 29, 2018 at 08:32:01AM +0200, Greg Kroah-Hartman wrote: > > > On Wed, Mar 28, 2018 at 02:59:18PM -0700, Guenter Roeck wrote: > > > > Hi Greg, > > > > > > > > commit 9d0273bb1c4b64 ("genirq: Use irqd_get_trigger_type to compare the trigger > > > > type for shared IRQs") causes a regression in v4.4.124. The problem has been fixed > > > > upstream with commit 4f8413a3a799 ("genirq: Track whether the trigger type has > > > > been set"). Please apply that patch to v4.4.y at your earliest convenience. > > > > > > > > The patch does not apply cleanly; you'll get a conflict include/linux/irq.h. > > > > The fix is simple - just take the version introduced by the patch. It adds > > > > a couple of extra defines, but those don't hurt and just keep the code aligned > > > > with upstream. > > > > > > Thanks, this was also needed for 4.9.y and 3.18.y. > > > > > > > Odd that I didn't see the problem there. But then I still see the following > > in 4.4.y after the above was added. > > > > genirq: Flags mismatch irq 24. 00000080 ([PCI] PME) vs. 00000080 ([EDAC] PCI err) > > > > This is with powerpc:mpc8544ds:mpc85xx_defconfig. I do _not_ see this problem > > in v4.9+. > > > > Looks like I'll need to spend more time on this. > > > I confirmed that this is still broken in 4.4.y, even after 4f8413a3a799 has been applied. > > Example output on a Acer 15.6" APL Chromebook, with both patches applied: > > [ 0.240913] gpiochip_find_base: found new base at 434 > [ 0.240956] gpiochip_add_data: registered GPIOs 434 to 511 on device: INT3452:00 > [ 0.240960] GPIO chip INT3452:00: created GPIO range 0->77 ==> INT3452:00 PIN 0->77 > [ 0.241311] gpiochip_find_base: found new base at 357 > [ 0.241347] gpiochip_add_data: registered GPIOs 357 to 433 on device: INT3452:01 > [ 0.241350] GPIO chip INT3452:01: created GPIO range 0->76 ==> INT3452:01 PIN 0->76 > [ 0.241353] genirq: Flags mismatch irq 14. 00000080 (INT3452:01) vs. 00000080 (INT3452:00) > [ 0.242055] broxton-pinctrl INT3452:01: failed to request interrupt > [ 0.242696] broxton-pinctrl: probe of INT3452:01 failed with error -16 > [ 0.243452] gpiochip_find_base: found new base at 387 > [ 0.243490] gpiochip_add_data: registered GPIOs 387 to 433 on device: INT3452:02 > [ 0.243493] GPIO chip INT3452:02: created GPIO range 0->46 ==> INT3452:02 PIN 0->46 > [ 0.243496] genirq: Flags mismatch irq 14. 00000080 (INT3452:02) vs. 00000080 (INT3452:00) > [ 0.244195] broxton-pinctrl INT3452:02: failed to request interrupt > [ 0.244813] broxton-pinctrl: probe of INT3452:02 failed with error -16 > [ 0.245549] gpiochip_find_base: found new base at 391 > [ 0.245585] gpiochip_add_data: registered GPIOs 391 to 433 on device: INT3452:03 > [ 0.245588] GPIO chip INT3452:03: created GPIO range 0->42 ==> INT3452:03 PIN 0->42 > [ 0.245591] genirq: Flags mismatch irq 14. 00000080 (INT3452:03) vs. 00000080 (INT3452:00) > [ 0.246322] broxton-pinctrl INT3452:03: failed to request interrupt > [ 0.246912] broxton-pinctrl: probe of INT3452:03 failed with error -16 > > Reverting 9d0273bb1c4b64 after the v4.4.124 merge into chromeos-4.4 fixes > the problem. > > At this point I got a bit frantic and decided to try the shotgun approach. > I applied > > 4b357daed698 genirq: Look-up trigger type if not specified by caller > f35ad083783e genirq: Look-up percpu trigger type if not specified by caller > 00b992deaa08 genirq: No need to mask non trigger mode flags before __irq_set_trigger() > 7ee7e87dfb15 genirq: Use irq type from irqdata instead of irqdesc > (minor conflicts due to pr_warning -> pr_warn) > > on top of v4.4.124. With those patches applied, the problem went away, both > on the Acer Chromebook and the qemu test which previously failed. Note that > I have _no_ idea if this is correct, necessary, and/or complete. All I know > is that it fixes the problems I have found so far. My guess would be the first one based on the logs and the commit mesage of 9d0273bb1c4b64. It seems like all five are basically a series so it should be all or none. I'd say the safer bet would be to revert 9d02733bb1c4b64 since the fact 4b357daed698 hasn't been requested before means not many devices on 4.4 need that functionality. Just my two cents which may be totally incorrect. > > Overall question is why 9d0273bb1c4b64 was applied to v4.4.y in the first place. > It does cause a whole lot of trouble. Was that really worth it ? > It came in via Sasha's auto selection process: https://lkml.org/lkml/2018/3/8/177 > Guenter ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Regression in v4.4.124 due to 'genirq: Use irqd_get_trigger_type to compare ..' 2018-03-29 21:07 ` Nathan Chancellor @ 2018-03-29 21:45 ` Guenter Roeck 2018-03-30 6:26 ` Greg Kroah-Hartman 0 siblings, 1 reply; 8+ messages in thread From: Guenter Roeck @ 2018-03-29 21:45 UTC (permalink / raw) To: Nathan Chancellor; +Cc: Greg Kroah-Hartman, Marc Zyngier, stable, Hans de Goede On Thu, Mar 29, 2018 at 02:07:51PM -0700, Nathan Chancellor wrote: > On Thu, Mar 29, 2018 at 01:28:45PM -0700, Guenter Roeck wrote: > > Hi Greg, > > > > On Thu, Mar 29, 2018 at 10:54:34AM -0700, Guenter Roeck wrote: > > > On Thu, Mar 29, 2018 at 08:32:01AM +0200, Greg Kroah-Hartman wrote: > > > > On Wed, Mar 28, 2018 at 02:59:18PM -0700, Guenter Roeck wrote: > > > > > Hi Greg, > > > > > > > > > > commit 9d0273bb1c4b64 ("genirq: Use irqd_get_trigger_type to compare the trigger > > > > > type for shared IRQs") causes a regression in v4.4.124. The problem has been fixed > > > > > upstream with commit 4f8413a3a799 ("genirq: Track whether the trigger type has > > > > > been set"). Please apply that patch to v4.4.y at your earliest convenience. > > > > > > > > > > The patch does not apply cleanly; you'll get a conflict include/linux/irq.h. > > > > > The fix is simple - just take the version introduced by the patch. It adds > > > > > a couple of extra defines, but those don't hurt and just keep the code aligned > > > > > with upstream. > > > > > > > > Thanks, this was also needed for 4.9.y and 3.18.y. > > > > > > > > > > Odd that I didn't see the problem there. But then I still see the following > > > in 4.4.y after the above was added. > > > > > > genirq: Flags mismatch irq 24. 00000080 ([PCI] PME) vs. 00000080 ([EDAC] PCI err) > > > > > > This is with powerpc:mpc8544ds:mpc85xx_defconfig. I do _not_ see this problem > > > in v4.9+. > > > > > > Looks like I'll need to spend more time on this. > > > > > I confirmed that this is still broken in 4.4.y, even after 4f8413a3a799 has been applied. > > > > Example output on a Acer 15.6" APL Chromebook, with both patches applied: > > > > [ 0.240913] gpiochip_find_base: found new base at 434 > > [ 0.240956] gpiochip_add_data: registered GPIOs 434 to 511 on device: INT3452:00 > > [ 0.240960] GPIO chip INT3452:00: created GPIO range 0->77 ==> INT3452:00 PIN 0->77 > > [ 0.241311] gpiochip_find_base: found new base at 357 > > [ 0.241347] gpiochip_add_data: registered GPIOs 357 to 433 on device: INT3452:01 > > [ 0.241350] GPIO chip INT3452:01: created GPIO range 0->76 ==> INT3452:01 PIN 0->76 > > [ 0.241353] genirq: Flags mismatch irq 14. 00000080 (INT3452:01) vs. 00000080 (INT3452:00) > > [ 0.242055] broxton-pinctrl INT3452:01: failed to request interrupt > > [ 0.242696] broxton-pinctrl: probe of INT3452:01 failed with error -16 > > [ 0.243452] gpiochip_find_base: found new base at 387 > > [ 0.243490] gpiochip_add_data: registered GPIOs 387 to 433 on device: INT3452:02 > > [ 0.243493] GPIO chip INT3452:02: created GPIO range 0->46 ==> INT3452:02 PIN 0->46 > > [ 0.243496] genirq: Flags mismatch irq 14. 00000080 (INT3452:02) vs. 00000080 (INT3452:00) > > [ 0.244195] broxton-pinctrl INT3452:02: failed to request interrupt > > [ 0.244813] broxton-pinctrl: probe of INT3452:02 failed with error -16 > > [ 0.245549] gpiochip_find_base: found new base at 391 > > [ 0.245585] gpiochip_add_data: registered GPIOs 391 to 433 on device: INT3452:03 > > [ 0.245588] GPIO chip INT3452:03: created GPIO range 0->42 ==> INT3452:03 PIN 0->42 > > [ 0.245591] genirq: Flags mismatch irq 14. 00000080 (INT3452:03) vs. 00000080 (INT3452:00) > > [ 0.246322] broxton-pinctrl INT3452:03: failed to request interrupt > > [ 0.246912] broxton-pinctrl: probe of INT3452:03 failed with error -16 > > > > Reverting 9d0273bb1c4b64 after the v4.4.124 merge into chromeos-4.4 fixes > > the problem. > > > > At this point I got a bit frantic and decided to try the shotgun approach. > > I applied > > > > 4b357daed698 genirq: Look-up trigger type if not specified by caller > > f35ad083783e genirq: Look-up percpu trigger type if not specified by caller > > 00b992deaa08 genirq: No need to mask non trigger mode flags before __irq_set_trigger() > > 7ee7e87dfb15 genirq: Use irq type from irqdata instead of irqdesc > > (minor conflicts due to pr_warning -> pr_warn) > > > > on top of v4.4.124. With those patches applied, the problem went away, both > > on the Acer Chromebook and the qemu test which previously failed. Note that > > I have _no_ idea if this is correct, necessary, and/or complete. All I know > > is that it fixes the problems I have found so far. > > My guess would be the first one based on the logs and the commit mesage > of 9d0273bb1c4b64. It seems like all five are basically a series so it > should be all or none. I'd say the safer bet would be to revert > 9d02733bb1c4b64 since the fact 4b357daed698 hasn't been requested before > means not many devices on 4.4 need that functionality. Just my two cents > which may be totally incorrect. > Personally I would prefer a revert as well. I am going to do that for the merge of v4.4.124 into chromeos-4.4. Everything else adds just too much risk at this point. Guenter > > > > Overall question is why 9d0273bb1c4b64 was applied to v4.4.y in the first place. > > It does cause a whole lot of trouble. Was that really worth it ? > > > > It came in via Sasha's auto selection process: https://lkml.org/lkml/2018/3/8/177 > > > Guenter ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Regression in v4.4.124 due to 'genirq: Use irqd_get_trigger_type to compare ..' 2018-03-29 21:45 ` Guenter Roeck @ 2018-03-30 6:26 ` Greg Kroah-Hartman 2018-03-30 8:59 ` Greg Kroah-Hartman 0 siblings, 1 reply; 8+ messages in thread From: Greg Kroah-Hartman @ 2018-03-30 6:26 UTC (permalink / raw) To: Guenter Roeck; +Cc: Nathan Chancellor, Marc Zyngier, stable, Hans de Goede On Thu, Mar 29, 2018 at 02:45:15PM -0700, Guenter Roeck wrote: > On Thu, Mar 29, 2018 at 02:07:51PM -0700, Nathan Chancellor wrote: > > On Thu, Mar 29, 2018 at 01:28:45PM -0700, Guenter Roeck wrote: > > > Hi Greg, > > > > > > On Thu, Mar 29, 2018 at 10:54:34AM -0700, Guenter Roeck wrote: > > > > On Thu, Mar 29, 2018 at 08:32:01AM +0200, Greg Kroah-Hartman wrote: > > > > > On Wed, Mar 28, 2018 at 02:59:18PM -0700, Guenter Roeck wrote: > > > > > > Hi Greg, > > > > > > > > > > > > commit 9d0273bb1c4b64 ("genirq: Use irqd_get_trigger_type to compare the trigger > > > > > > type for shared IRQs") causes a regression in v4.4.124. The problem has been fixed > > > > > > upstream with commit 4f8413a3a799 ("genirq: Track whether the trigger type has > > > > > > been set"). Please apply that patch to v4.4.y at your earliest convenience. > > > > > > > > > > > > The patch does not apply cleanly; you'll get a conflict include/linux/irq.h. > > > > > > The fix is simple - just take the version introduced by the patch. It adds > > > > > > a couple of extra defines, but those don't hurt and just keep the code aligned > > > > > > with upstream. > > > > > > > > > > Thanks, this was also needed for 4.9.y and 3.18.y. > > > > > > > > > > > > > Odd that I didn't see the problem there. But then I still see the following > > > > in 4.4.y after the above was added. > > > > > > > > genirq: Flags mismatch irq 24. 00000080 ([PCI] PME) vs. 00000080 ([EDAC] PCI err) > > > > > > > > This is with powerpc:mpc8544ds:mpc85xx_defconfig. I do _not_ see this problem > > > > in v4.9+. > > > > > > > > Looks like I'll need to spend more time on this. > > > > > > > I confirmed that this is still broken in 4.4.y, even after 4f8413a3a799 has been applied. > > > > > > Example output on a Acer 15.6" APL Chromebook, with both patches applied: > > > > > > [ 0.240913] gpiochip_find_base: found new base at 434 > > > [ 0.240956] gpiochip_add_data: registered GPIOs 434 to 511 on device: INT3452:00 > > > [ 0.240960] GPIO chip INT3452:00: created GPIO range 0->77 ==> INT3452:00 PIN 0->77 > > > [ 0.241311] gpiochip_find_base: found new base at 357 > > > [ 0.241347] gpiochip_add_data: registered GPIOs 357 to 433 on device: INT3452:01 > > > [ 0.241350] GPIO chip INT3452:01: created GPIO range 0->76 ==> INT3452:01 PIN 0->76 > > > [ 0.241353] genirq: Flags mismatch irq 14. 00000080 (INT3452:01) vs. 00000080 (INT3452:00) > > > [ 0.242055] broxton-pinctrl INT3452:01: failed to request interrupt > > > [ 0.242696] broxton-pinctrl: probe of INT3452:01 failed with error -16 > > > [ 0.243452] gpiochip_find_base: found new base at 387 > > > [ 0.243490] gpiochip_add_data: registered GPIOs 387 to 433 on device: INT3452:02 > > > [ 0.243493] GPIO chip INT3452:02: created GPIO range 0->46 ==> INT3452:02 PIN 0->46 > > > [ 0.243496] genirq: Flags mismatch irq 14. 00000080 (INT3452:02) vs. 00000080 (INT3452:00) > > > [ 0.244195] broxton-pinctrl INT3452:02: failed to request interrupt > > > [ 0.244813] broxton-pinctrl: probe of INT3452:02 failed with error -16 > > > [ 0.245549] gpiochip_find_base: found new base at 391 > > > [ 0.245585] gpiochip_add_data: registered GPIOs 391 to 433 on device: INT3452:03 > > > [ 0.245588] GPIO chip INT3452:03: created GPIO range 0->42 ==> INT3452:03 PIN 0->42 > > > [ 0.245591] genirq: Flags mismatch irq 14. 00000080 (INT3452:03) vs. 00000080 (INT3452:00) > > > [ 0.246322] broxton-pinctrl INT3452:03: failed to request interrupt > > > [ 0.246912] broxton-pinctrl: probe of INT3452:03 failed with error -16 > > > > > > Reverting 9d0273bb1c4b64 after the v4.4.124 merge into chromeos-4.4 fixes > > > the problem. > > > > > > At this point I got a bit frantic and decided to try the shotgun approach. > > > I applied > > > > > > 4b357daed698 genirq: Look-up trigger type if not specified by caller > > > f35ad083783e genirq: Look-up percpu trigger type if not specified by caller > > > 00b992deaa08 genirq: No need to mask non trigger mode flags before __irq_set_trigger() > > > 7ee7e87dfb15 genirq: Use irq type from irqdata instead of irqdesc > > > (minor conflicts due to pr_warning -> pr_warn) > > > > > > on top of v4.4.124. With those patches applied, the problem went away, both > > > on the Acer Chromebook and the qemu test which previously failed. Note that > > > I have _no_ idea if this is correct, necessary, and/or complete. All I know > > > is that it fixes the problems I have found so far. > > > > My guess would be the first one based on the logs and the commit mesage > > of 9d0273bb1c4b64. It seems like all five are basically a series so it > > should be all or none. I'd say the safer bet would be to revert > > 9d02733bb1c4b64 since the fact 4b357daed698 hasn't been requested before > > means not many devices on 4.4 need that functionality. Just my two cents > > which may be totally incorrect. > > > Personally I would prefer a revert as well. I am going to do that for the merge > of v4.4.124 into chromeos-4.4. Everything else adds just too much risk at this > point. Yeah, I'll just do a revert. Give me a few hours and I'll push out -rc2 releases with this change in them. thanks, greg k-h ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Regression in v4.4.124 due to 'genirq: Use irqd_get_trigger_type to compare ..' 2018-03-30 6:26 ` Greg Kroah-Hartman @ 2018-03-30 8:59 ` Greg Kroah-Hartman 0 siblings, 0 replies; 8+ messages in thread From: Greg Kroah-Hartman @ 2018-03-30 8:59 UTC (permalink / raw) To: Guenter Roeck; +Cc: Nathan Chancellor, Marc Zyngier, stable, Hans de Goede On Fri, Mar 30, 2018 at 08:26:07AM +0200, Greg Kroah-Hartman wrote: > On Thu, Mar 29, 2018 at 02:45:15PM -0700, Guenter Roeck wrote: > > On Thu, Mar 29, 2018 at 02:07:51PM -0700, Nathan Chancellor wrote: > > > On Thu, Mar 29, 2018 at 01:28:45PM -0700, Guenter Roeck wrote: > > > > Hi Greg, > > > > > > > > On Thu, Mar 29, 2018 at 10:54:34AM -0700, Guenter Roeck wrote: > > > > > On Thu, Mar 29, 2018 at 08:32:01AM +0200, Greg Kroah-Hartman wrote: > > > > > > On Wed, Mar 28, 2018 at 02:59:18PM -0700, Guenter Roeck wrote: > > > > > > > Hi Greg, > > > > > > > > > > > > > > commit 9d0273bb1c4b64 ("genirq: Use irqd_get_trigger_type to compare the trigger > > > > > > > type for shared IRQs") causes a regression in v4.4.124. The problem has been fixed > > > > > > > upstream with commit 4f8413a3a799 ("genirq: Track whether the trigger type has > > > > > > > been set"). Please apply that patch to v4.4.y at your earliest convenience. > > > > > > > > > > > > > > The patch does not apply cleanly; you'll get a conflict include/linux/irq.h. > > > > > > > The fix is simple - just take the version introduced by the patch. It adds > > > > > > > a couple of extra defines, but those don't hurt and just keep the code aligned > > > > > > > with upstream. > > > > > > > > > > > > Thanks, this was also needed for 4.9.y and 3.18.y. > > > > > > > > > > > > > > > > Odd that I didn't see the problem there. But then I still see the following > > > > > in 4.4.y after the above was added. > > > > > > > > > > genirq: Flags mismatch irq 24. 00000080 ([PCI] PME) vs. 00000080 ([EDAC] PCI err) > > > > > > > > > > This is with powerpc:mpc8544ds:mpc85xx_defconfig. I do _not_ see this problem > > > > > in v4.9+. > > > > > > > > > > Looks like I'll need to spend more time on this. > > > > > > > > > I confirmed that this is still broken in 4.4.y, even after 4f8413a3a799 has been applied. > > > > > > > > Example output on a Acer 15.6" APL Chromebook, with both patches applied: > > > > > > > > [ 0.240913] gpiochip_find_base: found new base at 434 > > > > [ 0.240956] gpiochip_add_data: registered GPIOs 434 to 511 on device: INT3452:00 > > > > [ 0.240960] GPIO chip INT3452:00: created GPIO range 0->77 ==> INT3452:00 PIN 0->77 > > > > [ 0.241311] gpiochip_find_base: found new base at 357 > > > > [ 0.241347] gpiochip_add_data: registered GPIOs 357 to 433 on device: INT3452:01 > > > > [ 0.241350] GPIO chip INT3452:01: created GPIO range 0->76 ==> INT3452:01 PIN 0->76 > > > > [ 0.241353] genirq: Flags mismatch irq 14. 00000080 (INT3452:01) vs. 00000080 (INT3452:00) > > > > [ 0.242055] broxton-pinctrl INT3452:01: failed to request interrupt > > > > [ 0.242696] broxton-pinctrl: probe of INT3452:01 failed with error -16 > > > > [ 0.243452] gpiochip_find_base: found new base at 387 > > > > [ 0.243490] gpiochip_add_data: registered GPIOs 387 to 433 on device: INT3452:02 > > > > [ 0.243493] GPIO chip INT3452:02: created GPIO range 0->46 ==> INT3452:02 PIN 0->46 > > > > [ 0.243496] genirq: Flags mismatch irq 14. 00000080 (INT3452:02) vs. 00000080 (INT3452:00) > > > > [ 0.244195] broxton-pinctrl INT3452:02: failed to request interrupt > > > > [ 0.244813] broxton-pinctrl: probe of INT3452:02 failed with error -16 > > > > [ 0.245549] gpiochip_find_base: found new base at 391 > > > > [ 0.245585] gpiochip_add_data: registered GPIOs 391 to 433 on device: INT3452:03 > > > > [ 0.245588] GPIO chip INT3452:03: created GPIO range 0->42 ==> INT3452:03 PIN 0->42 > > > > [ 0.245591] genirq: Flags mismatch irq 14. 00000080 (INT3452:03) vs. 00000080 (INT3452:00) > > > > [ 0.246322] broxton-pinctrl INT3452:03: failed to request interrupt > > > > [ 0.246912] broxton-pinctrl: probe of INT3452:03 failed with error -16 > > > > > > > > Reverting 9d0273bb1c4b64 after the v4.4.124 merge into chromeos-4.4 fixes > > > > the problem. > > > > > > > > At this point I got a bit frantic and decided to try the shotgun approach. > > > > I applied > > > > > > > > 4b357daed698 genirq: Look-up trigger type if not specified by caller > > > > f35ad083783e genirq: Look-up percpu trigger type if not specified by caller > > > > 00b992deaa08 genirq: No need to mask non trigger mode flags before __irq_set_trigger() > > > > 7ee7e87dfb15 genirq: Use irq type from irqdata instead of irqdesc > > > > (minor conflicts due to pr_warning -> pr_warn) > > > > > > > > on top of v4.4.124. With those patches applied, the problem went away, both > > > > on the Acer Chromebook and the qemu test which previously failed. Note that > > > > I have _no_ idea if this is correct, necessary, and/or complete. All I know > > > > is that it fixes the problems I have found so far. > > > > > > My guess would be the first one based on the logs and the commit mesage > > > of 9d0273bb1c4b64. It seems like all five are basically a series so it > > > should be all or none. I'd say the safer bet would be to revert > > > 9d02733bb1c4b64 since the fact 4b357daed698 hasn't been requested before > > > means not many devices on 4.4 need that functionality. Just my two cents > > > which may be totally incorrect. > > > > > Personally I would prefer a revert as well. I am going to do that for the merge > > of v4.4.124 into chromeos-4.4. Everything else adds just too much risk at this > > point. > > Yeah, I'll just do a revert. Give me a few hours and I'll push out -rc2 > releases with this change in them. Now reverted and pushed out. thanks, greg k-h ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2018-03-30 8:59 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-03-28 21:59 Regression in v4.4.124 due to 'genirq: Use irqd_get_trigger_type to compare ..' Guenter Roeck 2018-03-29 6:32 ` Greg Kroah-Hartman 2018-03-29 17:54 ` Guenter Roeck 2018-03-29 20:28 ` Guenter Roeck 2018-03-29 21:07 ` Nathan Chancellor 2018-03-29 21:45 ` Guenter Roeck 2018-03-30 6:26 ` Greg Kroah-Hartman 2018-03-30 8:59 ` Greg Kroah-Hartman
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.