Re: system freeze - beaglebone black xenomai - gpio interrupts driver
Hi, On Thu, Feb 27, 2020 at 8:34 AM Laurentiu-Cristian Duca wrote: > > Hi, > > Good job. It works now. > I will do more testing and will let you know. > > Thanks! Great!, I think the only other bug that I know of in the ipipe-arm is for the RPI boards, where we loose the interrupt in the root stage at some point. I'm looking into that issue now, let me know if you see anything like that but I think it's isolated to BCM chips. Thanks Greg > > On 2/24/20, Greg Gallagher wrote: > > Hi, > > > > On Sat, Feb 8, 2020 at 6:56 AM Laurentiu-Cristian Duca > > wrote: > >> > >> Hello there > >> > >> Greg, any news? > >> > >> Thanks > >> > >> On 1/31/20, Greg Gallagher wrote: > >> > Hey, > >> > > >> > On Wed, Jan 29, 2020 at 11:58 AM Greg Gallagher > >> > wrote: > >> >> > >> >> Hey, > >> >> > >> >> On Wed, Jan 29, 2020 at 12:07 AM Greg Gallagher > >> >> > >> >> wrote: > >> >> > > >> >> > Hi, > >> >> > > >> >> > On Tue, Jan 28, 2020 at 7:37 AM Laurentiu-Cristian Duca > >> >> > wrote: > >> >> > > > >> >> > > Again, to make things clear: > >> >> > > I have tested two modules: one with RTDM gpio-interrupts and one > >> >> > > with > >> >> > > classic linux interrupts. > >> >> > > The one with RTDM gpio-interrupts: > >> >> > > - makes kernel freeze on 4.14.71 and 4.19.82 ipipe-enabled kernels > >> >> > > - works (but with ipipe warnings when interrupt arrives) in 4.4.71 > >> >> > > and > >> >> > > 4.9.51 > >> >> > > The one with classic linux interrupts: > >> >> > > - works in PREEMPT_RT linux (tested on 5.4.5 and 4.19.59 > >> >> > > PREEMPT_RT > >> >> > > non-ipipe non-xenomai) > >> >> > > - makes kernel freeze when interrupt arrives on 4.14.71 and > >> >> > > 4.19.82 > >> >> > > for xenomai ipipe enabled kernels > >> >> > > > >> >> > > On 1/28/20, Laurentiu-Cristian Duca > >> >> > > wrote: > >> >> > > > This does not happen with non-ipipe enabled kernels. > >> >> > > > I have tested a classic gpio-interrupt module on PREEMPT_RT and > >> >> > > > it > >> >> > > > works, > >> >> > > > but when I tested it on an ipipe-enabled kernel (4.14.71 and > >> >> > > > 4.19.82) > >> >> > > > got kernel freeze. > >> >> > > > > >> >> > > > On 1/28/20, Greg Gallagher wrote: > >> >> > > >> On Tue, Jan 28, 2020 at 7:11 AM Laurentiu-Cristian Duca < > >> >> > > >> laurentiu.d...@gmail.com> wrote: > >> >> > > >> > >> >> > > >>> I forgot to say that I've tested 4.14.71 with xenomai 3.0.9 > >> >> > > >>> > >> >> > > >>> On 1/28/20, Laurentiu-Cristian Duca > >> >> > > >>> wrote: > >> >> > > >>> > Hello Jan and friends, > >> >> > > >>> > > >> >> > > >>> > The situation is the following for bbb: > >> >> > > >>> > - 4.14.71 and 4.19.82 xenomai-3 master enabled kernels > >> >> > > >>> > freeze when trying to use gpio-interrupts; > >> >> > > >>> > when interrupt comes the gpioout is toggled but the system > >> >> > > >>> > do not respond anymore to keyboard and nothing more is shown > >> >> > > >>> > on > >> >> > > >>> > the > >> >> > > >>> screen > >> >> > > >>> > - note that even if I try a classic (linux only, > >> >> > > >>> > non-xenomai) > >> >> > > >> > >> >> > > >> This happens even with non-ipipe enables kernels? > >> >> > > > > >> >> > > >> > >> >> > > >> > >> >> > > >>> > gpio interrupt handler in 4.19.82 with xenomai-3 > >> >> > > >>> > the system freeze when interrupt comes > >> >> > > >>> > - 4.9.51 and 4.4.71 xenomai 3.0.5 enabled kernels work > >> >> > > >>> > blinking gpioout and do not block, > >> >> > > >>> > but both show warnings when interrupt comes > >> >> > > >>> > which significantly increase interrupt latency. > >> >> > > >>> > > >> >> > > >>> > > >> >> > > >>> > On 1/28/20, Jan Kiszka wrote: > >> >> > > >>> >> On 24.01.20 07:24, Greg Gallagher via Xenomai wrote: > >> >> > > >>> >>> I sent a patch offline, if you could try it that would be > >> >> > > >>> >>> great. > >> >> > > >>> >>> I'm > >> >> > > >>> >>> having issues getting my board set up. > >> >> > > >>> >>> > >> >> > > >>> >> > >> >> > > >>> >> Do we know by now if this is an I-pipe issue or rather > >> >> > > >>> >> something > >> >> > > >>> >> cobalt-related? > >> >> > > >>> >> > >> >> > > >>> >> Jan > >> >> > > >>> >> > >> >> > > >>> >>> On Thu, Jan 23, 2020 at 1:13 PM Greg Gallagher > >> >> > > >>> >>> > >> >> > > >>> >>> wrote: > >> >> > > >>> > >> >> > > >>> Hi, > >> >> > > >>> > >> >> > > >>> On Thu, Jan 23, 2020 at 12:15 PM Laurentiu-Cristian Duca > >> >> > > >>> wrote: > >> >> > > >>> > > >> >> > > >>> > Hi, the interrupt comes one per second in my test, so > >> >> > > >>> > there > >> >> > > >>> > is no > >> >> > > >>> > flood. > >> >> > > >>> > In 4.19 the system it blinks the gpioout but it does not > >> >> > > >>> > respond > >> >> > > >>> > to > >> >> > > >>> > keyboard and does not show anything more on the screen. > >> >> > > >>> > >> >> > > >>> Okay, there's a couple things that are different between > >> >> > > >>> 4.4 > >> >> > > >>> and > >> >>
Re: system freeze - beaglebone black xenomai - gpio interrupts driver
Hi, Good job. It works now. I will do more testing and will let you know. Thanks! On 2/24/20, Greg Gallagher wrote: > Hi, > > On Sat, Feb 8, 2020 at 6:56 AM Laurentiu-Cristian Duca > wrote: >> >> Hello there >> >> Greg, any news? >> >> Thanks >> >> On 1/31/20, Greg Gallagher wrote: >> > Hey, >> > >> > On Wed, Jan 29, 2020 at 11:58 AM Greg Gallagher >> > wrote: >> >> >> >> Hey, >> >> >> >> On Wed, Jan 29, 2020 at 12:07 AM Greg Gallagher >> >> >> >> wrote: >> >> > >> >> > Hi, >> >> > >> >> > On Tue, Jan 28, 2020 at 7:37 AM Laurentiu-Cristian Duca >> >> > wrote: >> >> > > >> >> > > Again, to make things clear: >> >> > > I have tested two modules: one with RTDM gpio-interrupts and one >> >> > > with >> >> > > classic linux interrupts. >> >> > > The one with RTDM gpio-interrupts: >> >> > > - makes kernel freeze on 4.14.71 and 4.19.82 ipipe-enabled kernels >> >> > > - works (but with ipipe warnings when interrupt arrives) in 4.4.71 >> >> > > and >> >> > > 4.9.51 >> >> > > The one with classic linux interrupts: >> >> > > - works in PREEMPT_RT linux (tested on 5.4.5 and 4.19.59 >> >> > > PREEMPT_RT >> >> > > non-ipipe non-xenomai) >> >> > > - makes kernel freeze when interrupt arrives on 4.14.71 and >> >> > > 4.19.82 >> >> > > for xenomai ipipe enabled kernels >> >> > > >> >> > > On 1/28/20, Laurentiu-Cristian Duca >> >> > > wrote: >> >> > > > This does not happen with non-ipipe enabled kernels. >> >> > > > I have tested a classic gpio-interrupt module on PREEMPT_RT and >> >> > > > it >> >> > > > works, >> >> > > > but when I tested it on an ipipe-enabled kernel (4.14.71 and >> >> > > > 4.19.82) >> >> > > > got kernel freeze. >> >> > > > >> >> > > > On 1/28/20, Greg Gallagher wrote: >> >> > > >> On Tue, Jan 28, 2020 at 7:11 AM Laurentiu-Cristian Duca < >> >> > > >> laurentiu.d...@gmail.com> wrote: >> >> > > >> >> >> > > >>> I forgot to say that I've tested 4.14.71 with xenomai 3.0.9 >> >> > > >>> >> >> > > >>> On 1/28/20, Laurentiu-Cristian Duca >> >> > > >>> wrote: >> >> > > >>> > Hello Jan and friends, >> >> > > >>> > >> >> > > >>> > The situation is the following for bbb: >> >> > > >>> > - 4.14.71 and 4.19.82 xenomai-3 master enabled kernels >> >> > > >>> > freeze when trying to use gpio-interrupts; >> >> > > >>> > when interrupt comes the gpioout is toggled but the system >> >> > > >>> > do not respond anymore to keyboard and nothing more is shown >> >> > > >>> > on >> >> > > >>> > the >> >> > > >>> screen >> >> > > >>> > - note that even if I try a classic (linux only, >> >> > > >>> > non-xenomai) >> >> > > >> >> >> > > >> This happens even with non-ipipe enables kernels? >> >> > > > >> >> > > >> >> >> > > >> >> >> > > >>> > gpio interrupt handler in 4.19.82 with xenomai-3 >> >> > > >>> > the system freeze when interrupt comes >> >> > > >>> > - 4.9.51 and 4.4.71 xenomai 3.0.5 enabled kernels work >> >> > > >>> > blinking gpioout and do not block, >> >> > > >>> > but both show warnings when interrupt comes >> >> > > >>> > which significantly increase interrupt latency. >> >> > > >>> > >> >> > > >>> > >> >> > > >>> > On 1/28/20, Jan Kiszka wrote: >> >> > > >>> >> On 24.01.20 07:24, Greg Gallagher via Xenomai wrote: >> >> > > >>> >>> I sent a patch offline, if you could try it that would be >> >> > > >>> >>> great. >> >> > > >>> >>> I'm >> >> > > >>> >>> having issues getting my board set up. >> >> > > >>> >>> >> >> > > >>> >> >> >> > > >>> >> Do we know by now if this is an I-pipe issue or rather >> >> > > >>> >> something >> >> > > >>> >> cobalt-related? >> >> > > >>> >> >> >> > > >>> >> Jan >> >> > > >>> >> >> >> > > >>> >>> On Thu, Jan 23, 2020 at 1:13 PM Greg Gallagher >> >> > > >>> >>> >> >> > > >>> >>> wrote: >> >> > > >>> >> >> > > >>> Hi, >> >> > > >>> >> >> > > >>> On Thu, Jan 23, 2020 at 12:15 PM Laurentiu-Cristian Duca >> >> > > >>> wrote: >> >> > > >>> > >> >> > > >>> > Hi, the interrupt comes one per second in my test, so >> >> > > >>> > there >> >> > > >>> > is no >> >> > > >>> > flood. >> >> > > >>> > In 4.19 the system it blinks the gpioout but it does not >> >> > > >>> > respond >> >> > > >>> > to >> >> > > >>> > keyboard and does not show anything more on the screen. >> >> > > >>> >> >> > > >>> Okay, there's a couple things that are different between >> >> > > >>> 4.4 >> >> > > >>> and >> >> > > >>> 4.19 >> >> > > >>> that I'm looking into, which is taking me a little long >> >> > > >>> then >> >> > > >>> I >> >> > > >>> thought. I won't have this patch ready till tomorrow >> >> > > >>> morning. I >> >> > > >>> finally have beaglebone black hardware, I'll make sure >> >> > > >>> the >> >> > > >>> kernel >> >> > > >>> boots and then send the patch to you for testing. >> >> > > >>> >> >> > > >>> -Greg >> >> > > >>> >> >> > > >>> >> >> > > >>> > >> >> > > >>> > On Thu, Jan 23, 2020, 19:03 Greg Gallagher >> >> > > >>>
Re: system freeze - beaglebone black xenomai - gpio interrupts driver
Hi, On Sat, Feb 8, 2020 at 6:56 AM Laurentiu-Cristian Duca wrote: > > Hello there > > Greg, any news? > > Thanks > > On 1/31/20, Greg Gallagher wrote: > > Hey, > > > > On Wed, Jan 29, 2020 at 11:58 AM Greg Gallagher > > wrote: > >> > >> Hey, > >> > >> On Wed, Jan 29, 2020 at 12:07 AM Greg Gallagher > >> wrote: > >> > > >> > Hi, > >> > > >> > On Tue, Jan 28, 2020 at 7:37 AM Laurentiu-Cristian Duca > >> > wrote: > >> > > > >> > > Again, to make things clear: > >> > > I have tested two modules: one with RTDM gpio-interrupts and one with > >> > > classic linux interrupts. > >> > > The one with RTDM gpio-interrupts: > >> > > - makes kernel freeze on 4.14.71 and 4.19.82 ipipe-enabled kernels > >> > > - works (but with ipipe warnings when interrupt arrives) in 4.4.71 and > >> > > 4.9.51 > >> > > The one with classic linux interrupts: > >> > > - works in PREEMPT_RT linux (tested on 5.4.5 and 4.19.59 PREEMPT_RT > >> > > non-ipipe non-xenomai) > >> > > - makes kernel freeze when interrupt arrives on 4.14.71 and 4.19.82 > >> > > for xenomai ipipe enabled kernels > >> > > > >> > > On 1/28/20, Laurentiu-Cristian Duca wrote: > >> > > > This does not happen with non-ipipe enabled kernels. > >> > > > I have tested a classic gpio-interrupt module on PREEMPT_RT and it > >> > > > works, > >> > > > but when I tested it on an ipipe-enabled kernel (4.14.71 and > >> > > > 4.19.82) > >> > > > got kernel freeze. > >> > > > > >> > > > On 1/28/20, Greg Gallagher wrote: > >> > > >> On Tue, Jan 28, 2020 at 7:11 AM Laurentiu-Cristian Duca < > >> > > >> laurentiu.d...@gmail.com> wrote: > >> > > >> > >> > > >>> I forgot to say that I've tested 4.14.71 with xenomai 3.0.9 > >> > > >>> > >> > > >>> On 1/28/20, Laurentiu-Cristian Duca > >> > > >>> wrote: > >> > > >>> > Hello Jan and friends, > >> > > >>> > > >> > > >>> > The situation is the following for bbb: > >> > > >>> > - 4.14.71 and 4.19.82 xenomai-3 master enabled kernels > >> > > >>> > freeze when trying to use gpio-interrupts; > >> > > >>> > when interrupt comes the gpioout is toggled but the system > >> > > >>> > do not respond anymore to keyboard and nothing more is shown on > >> > > >>> > the > >> > > >>> screen > >> > > >>> > - note that even if I try a classic (linux only, non-xenomai) > >> > > >> > >> > > >> This happens even with non-ipipe enables kernels? > >> > > > > >> > > >> > >> > > >> > >> > > >>> > gpio interrupt handler in 4.19.82 with xenomai-3 > >> > > >>> > the system freeze when interrupt comes > >> > > >>> > - 4.9.51 and 4.4.71 xenomai 3.0.5 enabled kernels work > >> > > >>> > blinking gpioout and do not block, > >> > > >>> > but both show warnings when interrupt comes > >> > > >>> > which significantly increase interrupt latency. > >> > > >>> > > >> > > >>> > > >> > > >>> > On 1/28/20, Jan Kiszka wrote: > >> > > >>> >> On 24.01.20 07:24, Greg Gallagher via Xenomai wrote: > >> > > >>> >>> I sent a patch offline, if you could try it that would be > >> > > >>> >>> great. > >> > > >>> >>> I'm > >> > > >>> >>> having issues getting my board set up. > >> > > >>> >>> > >> > > >>> >> > >> > > >>> >> Do we know by now if this is an I-pipe issue or rather > >> > > >>> >> something > >> > > >>> >> cobalt-related? > >> > > >>> >> > >> > > >>> >> Jan > >> > > >>> >> > >> > > >>> >>> On Thu, Jan 23, 2020 at 1:13 PM Greg Gallagher > >> > > >>> >>> > >> > > >>> >>> wrote: > >> > > >>> > >> > > >>> Hi, > >> > > >>> > >> > > >>> On Thu, Jan 23, 2020 at 12:15 PM Laurentiu-Cristian Duca > >> > > >>> wrote: > >> > > >>> > > >> > > >>> > Hi, the interrupt comes one per second in my test, so there > >> > > >>> > is no > >> > > >>> > flood. > >> > > >>> > In 4.19 the system it blinks the gpioout but it does not > >> > > >>> > respond > >> > > >>> > to > >> > > >>> > keyboard and does not show anything more on the screen. > >> > > >>> > >> > > >>> Okay, there's a couple things that are different between 4.4 > >> > > >>> and > >> > > >>> 4.19 > >> > > >>> that I'm looking into, which is taking me a little long then > >> > > >>> I > >> > > >>> thought. I won't have this patch ready till tomorrow > >> > > >>> morning. I > >> > > >>> finally have beaglebone black hardware, I'll make sure the > >> > > >>> kernel > >> > > >>> boots and then send the patch to you for testing. > >> > > >>> > >> > > >>> -Greg > >> > > >>> > >> > > >>> > >> > > >>> > > >> > > >>> > On Thu, Jan 23, 2020, 19:03 Greg Gallagher > >> > > >>> > > >> > > >>> > wrote: > >> > > >>> >> > >> > > >>> >> Hi, > >> > > >>> >> > >> > > >>> >> On Thu, Jan 23, 2020 at 9:21 AM Laurentiu-Cristian Duca > >> > > >>> >> via > >> > > >>> >> Xenomai > >> > > >>> >> wrote: > >> > > >>> >>> > >> > > >>> >>> Hello xenomai community, > >> > > >>> >>> > >> > > >>> >>> I have successfully tested in xenomai SPI with > >> > > >>>
Re: system freeze - beaglebone black xenomai - gpio interrupts driver
Hi On Sat, Feb 8, 2020 at 7:51 AM Greg Gallagher wrote: > > Hi, > > On Sat, Feb 8, 2020 at 6:56 AM Laurentiu-Cristian Duca > wrote: >> >> Hello there >> >> Greg, any news? >> Good news, looks like I have a fix. I'll need a night or two to clean up the patch but I should have it up for review by Friday. -Greg >> Thanks > > > Still working on it, I’ve only had a couple hours this week to work on it. > I’m debugging the irq storm that happens after we trigger the gpio interrupt. > I plan on spending some time this weekend on it. > > Greg >> >> >> On 1/31/20, Greg Gallagher wrote: >> > Hey, >> > >> > On Wed, Jan 29, 2020 at 11:58 AM Greg Gallagher >> > wrote: >> >> >> >> Hey, >> >> >> >> On Wed, Jan 29, 2020 at 12:07 AM Greg Gallagher >> >> wrote: >> >> > >> >> > Hi, >> >> > >> >> > On Tue, Jan 28, 2020 at 7:37 AM Laurentiu-Cristian Duca >> >> > wrote: >> >> > > >> >> > > Again, to make things clear: >> >> > > I have tested two modules: one with RTDM gpio-interrupts and one with >> >> > > classic linux interrupts. >> >> > > The one with RTDM gpio-interrupts: >> >> > > - makes kernel freeze on 4.14.71 and 4.19.82 ipipe-enabled kernels >> >> > > - works (but with ipipe warnings when interrupt arrives) in 4.4.71 and >> >> > > 4.9.51 >> >> > > The one with classic linux interrupts: >> >> > > - works in PREEMPT_RT linux (tested on 5.4.5 and 4.19.59 PREEMPT_RT >> >> > > non-ipipe non-xenomai) >> >> > > - makes kernel freeze when interrupt arrives on 4.14.71 and 4.19.82 >> >> > > for xenomai ipipe enabled kernels >> >> > > >> >> > > On 1/28/20, Laurentiu-Cristian Duca wrote: >> >> > > > This does not happen with non-ipipe enabled kernels. >> >> > > > I have tested a classic gpio-interrupt module on PREEMPT_RT and it >> >> > > > works, >> >> > > > but when I tested it on an ipipe-enabled kernel (4.14.71 and >> >> > > > 4.19.82) >> >> > > > got kernel freeze. >> >> > > > >> >> > > > On 1/28/20, Greg Gallagher wrote: >> >> > > >> On Tue, Jan 28, 2020 at 7:11 AM Laurentiu-Cristian Duca < >> >> > > >> laurentiu.d...@gmail.com> wrote: >> >> > > >> >> >> > > >>> I forgot to say that I've tested 4.14.71 with xenomai 3.0.9 >> >> > > >>> >> >> > > >>> On 1/28/20, Laurentiu-Cristian Duca >> >> > > >>> wrote: >> >> > > >>> > Hello Jan and friends, >> >> > > >>> > >> >> > > >>> > The situation is the following for bbb: >> >> > > >>> > - 4.14.71 and 4.19.82 xenomai-3 master enabled kernels >> >> > > >>> > freeze when trying to use gpio-interrupts; >> >> > > >>> > when interrupt comes the gpioout is toggled but the system >> >> > > >>> > do not respond anymore to keyboard and nothing more is shown on >> >> > > >>> > the >> >> > > >>> screen >> >> > > >>> > - note that even if I try a classic (linux only, non-xenomai) >> >> > > >> >> >> > > >> This happens even with non-ipipe enables kernels? >> >> > > > >> >> > > >> >> >> > > >> >> >> > > >>> > gpio interrupt handler in 4.19.82 with xenomai-3 >> >> > > >>> > the system freeze when interrupt comes >> >> > > >>> > - 4.9.51 and 4.4.71 xenomai 3.0.5 enabled kernels work >> >> > > >>> > blinking gpioout and do not block, >> >> > > >>> > but both show warnings when interrupt comes >> >> > > >>> > which significantly increase interrupt latency. >> >> > > >>> > >> >> > > >>> > >> >> > > >>> > On 1/28/20, Jan Kiszka wrote: >> >> > > >>> >> On 24.01.20 07:24, Greg Gallagher via Xenomai wrote: >> >> > > >>> >>> I sent a patch offline, if you could try it that would be >> >> > > >>> >>> great. >> >> > > >>> >>> I'm >> >> > > >>> >>> having issues getting my board set up. >> >> > > >>> >>> >> >> > > >>> >> >> >> > > >>> >> Do we know by now if this is an I-pipe issue or rather >> >> > > >>> >> something >> >> > > >>> >> cobalt-related? >> >> > > >>> >> >> >> > > >>> >> Jan >> >> > > >>> >> >> >> > > >>> >>> On Thu, Jan 23, 2020 at 1:13 PM Greg Gallagher >> >> > > >>> >>> >> >> > > >>> >>> wrote: >> >> > > >>> >> >> > > >>> Hi, >> >> > > >>> >> >> > > >>> On Thu, Jan 23, 2020 at 12:15 PM Laurentiu-Cristian Duca >> >> > > >>> wrote: >> >> > > >>> > >> >> > > >>> > Hi, the interrupt comes one per second in my test, so there >> >> > > >>> > is no >> >> > > >>> > flood. >> >> > > >>> > In 4.19 the system it blinks the gpioout but it does not >> >> > > >>> > respond >> >> > > >>> > to >> >> > > >>> > keyboard and does not show anything more on the screen. >> >> > > >>> >> >> > > >>> Okay, there's a couple things that are different between 4.4 >> >> > > >>> and >> >> > > >>> 4.19 >> >> > > >>> that I'm looking into, which is taking me a little long then >> >> > > >>> I >> >> > > >>> thought. I won't have this patch ready till tomorrow >> >> > > >>> morning. I >> >> > > >>> finally have beaglebone black hardware, I'll make sure the >> >> > > >>> kernel >> >> > > >>> boots and then send the patch to you for testing. >> >> > > >>> >> >> > > >>> -Greg >> >> > >
Re: system freeze - beaglebone black xenomai - gpio interrupts driver
Hi, On Sat, Feb 8, 2020 at 6:56 AM Laurentiu-Cristian Duca < laurentiu.d...@gmail.com> wrote: > Hello there > > Greg, any news? > > Thanks > Still working on it, I’ve only had a couple hours this week to work on it. I’m debugging the irq storm that happens after we trigger the gpio interrupt. I plan on spending some time this weekend on it. Greg > > On 1/31/20, Greg Gallagher wrote: > > Hey, > > > > On Wed, Jan 29, 2020 at 11:58 AM Greg Gallagher > > wrote: > >> > >> Hey, > >> > >> On Wed, Jan 29, 2020 at 12:07 AM Greg Gallagher > >> wrote: > >> > > >> > Hi, > >> > > >> > On Tue, Jan 28, 2020 at 7:37 AM Laurentiu-Cristian Duca > >> > wrote: > >> > > > >> > > Again, to make things clear: > >> > > I have tested two modules: one with RTDM gpio-interrupts and one > with > >> > > classic linux interrupts. > >> > > The one with RTDM gpio-interrupts: > >> > > - makes kernel freeze on 4.14.71 and 4.19.82 ipipe-enabled kernels > >> > > - works (but with ipipe warnings when interrupt arrives) in 4.4.71 > and > >> > > 4.9.51 > >> > > The one with classic linux interrupts: > >> > > - works in PREEMPT_RT linux (tested on 5.4.5 and 4.19.59 PREEMPT_RT > >> > > non-ipipe non-xenomai) > >> > > - makes kernel freeze when interrupt arrives on 4.14.71 and 4.19.82 > >> > > for xenomai ipipe enabled kernels > >> > > > >> > > On 1/28/20, Laurentiu-Cristian Duca > wrote: > >> > > > This does not happen with non-ipipe enabled kernels. > >> > > > I have tested a classic gpio-interrupt module on PREEMPT_RT and it > >> > > > works, > >> > > > but when I tested it on an ipipe-enabled kernel (4.14.71 and > >> > > > 4.19.82) > >> > > > got kernel freeze. > >> > > > > >> > > > On 1/28/20, Greg Gallagher wrote: > >> > > >> On Tue, Jan 28, 2020 at 7:11 AM Laurentiu-Cristian Duca < > >> > > >> laurentiu.d...@gmail.com> wrote: > >> > > >> > >> > > >>> I forgot to say that I've tested 4.14.71 with xenomai 3.0.9 > >> > > >>> > >> > > >>> On 1/28/20, Laurentiu-Cristian Duca > >> > > >>> wrote: > >> > > >>> > Hello Jan and friends, > >> > > >>> > > >> > > >>> > The situation is the following for bbb: > >> > > >>> > - 4.14.71 and 4.19.82 xenomai-3 master enabled kernels > >> > > >>> > freeze when trying to use gpio-interrupts; > >> > > >>> > when interrupt comes the gpioout is toggled but the system > >> > > >>> > do not respond anymore to keyboard and nothing more is shown > on > >> > > >>> > the > >> > > >>> screen > >> > > >>> > - note that even if I try a classic (linux only, non-xenomai) > >> > > >> > >> > > >> This happens even with non-ipipe enables kernels? > >> > > > > >> > > >> > >> > > >> > >> > > >>> > gpio interrupt handler in 4.19.82 with xenomai-3 > >> > > >>> > the system freeze when interrupt comes > >> > > >>> > - 4.9.51 and 4.4.71 xenomai 3.0.5 enabled kernels work > >> > > >>> > blinking gpioout and do not block, > >> > > >>> > but both show warnings when interrupt comes > >> > > >>> > which significantly increase interrupt latency. > >> > > >>> > > >> > > >>> > > >> > > >>> > On 1/28/20, Jan Kiszka wrote: > >> > > >>> >> On 24.01.20 07:24, Greg Gallagher via Xenomai wrote: > >> > > >>> >>> I sent a patch offline, if you could try it that would be > >> > > >>> >>> great. > >> > > >>> >>> I'm > >> > > >>> >>> having issues getting my board set up. > >> > > >>> >>> > >> > > >>> >> > >> > > >>> >> Do we know by now if this is an I-pipe issue or rather > >> > > >>> >> something > >> > > >>> >> cobalt-related? > >> > > >>> >> > >> > > >>> >> Jan > >> > > >>> >> > >> > > >>> >>> On Thu, Jan 23, 2020 at 1:13 PM Greg Gallagher > >> > > >>> >>> > >> > > >>> >>> wrote: > >> > > >>> > >> > > >>> Hi, > >> > > >>> > >> > > >>> On Thu, Jan 23, 2020 at 12:15 PM Laurentiu-Cristian Duca > >> > > >>> wrote: > >> > > >>> > > >> > > >>> > Hi, the interrupt comes one per second in my test, so > there > >> > > >>> > is no > >> > > >>> > flood. > >> > > >>> > In 4.19 the system it blinks the gpioout but it does not > >> > > >>> > respond > >> > > >>> > to > >> > > >>> > keyboard and does not show anything more on the screen. > >> > > >>> > >> > > >>> Okay, there's a couple things that are different between > 4.4 > >> > > >>> and > >> > > >>> 4.19 > >> > > >>> that I'm looking into, which is taking me a little long > then > >> > > >>> I > >> > > >>> thought. I won't have this patch ready till tomorrow > >> > > >>> morning. I > >> > > >>> finally have beaglebone black hardware, I'll make sure the > >> > > >>> kernel > >> > > >>> boots and then send the patch to you for testing. > >> > > >>> > >> > > >>> -Greg > >> > > >>> > >> > > >>> > >> > > >>> > > >> > > >>> > On Thu, Jan 23, 2020, 19:03 Greg Gallagher > >> > > >>> > > >> > > >>> > wrote: > >> > > >>> >> > >> > > >>> >> Hi, > >> > > >>> >> > >> > > >>> >> On Thu, Jan 23, 2020 at 9:21 AM Laurentiu-Cristian Duca > >>
Re: system freeze - beaglebone black xenomai - gpio interrupts driver
Hello there Greg, any news? Thanks On 1/31/20, Greg Gallagher wrote: > Hey, > > On Wed, Jan 29, 2020 at 11:58 AM Greg Gallagher > wrote: >> >> Hey, >> >> On Wed, Jan 29, 2020 at 12:07 AM Greg Gallagher >> wrote: >> > >> > Hi, >> > >> > On Tue, Jan 28, 2020 at 7:37 AM Laurentiu-Cristian Duca >> > wrote: >> > > >> > > Again, to make things clear: >> > > I have tested two modules: one with RTDM gpio-interrupts and one with >> > > classic linux interrupts. >> > > The one with RTDM gpio-interrupts: >> > > - makes kernel freeze on 4.14.71 and 4.19.82 ipipe-enabled kernels >> > > - works (but with ipipe warnings when interrupt arrives) in 4.4.71 and >> > > 4.9.51 >> > > The one with classic linux interrupts: >> > > - works in PREEMPT_RT linux (tested on 5.4.5 and 4.19.59 PREEMPT_RT >> > > non-ipipe non-xenomai) >> > > - makes kernel freeze when interrupt arrives on 4.14.71 and 4.19.82 >> > > for xenomai ipipe enabled kernels >> > > >> > > On 1/28/20, Laurentiu-Cristian Duca wrote: >> > > > This does not happen with non-ipipe enabled kernels. >> > > > I have tested a classic gpio-interrupt module on PREEMPT_RT and it >> > > > works, >> > > > but when I tested it on an ipipe-enabled kernel (4.14.71 and >> > > > 4.19.82) >> > > > got kernel freeze. >> > > > >> > > > On 1/28/20, Greg Gallagher wrote: >> > > >> On Tue, Jan 28, 2020 at 7:11 AM Laurentiu-Cristian Duca < >> > > >> laurentiu.d...@gmail.com> wrote: >> > > >> >> > > >>> I forgot to say that I've tested 4.14.71 with xenomai 3.0.9 >> > > >>> >> > > >>> On 1/28/20, Laurentiu-Cristian Duca >> > > >>> wrote: >> > > >>> > Hello Jan and friends, >> > > >>> > >> > > >>> > The situation is the following for bbb: >> > > >>> > - 4.14.71 and 4.19.82 xenomai-3 master enabled kernels >> > > >>> > freeze when trying to use gpio-interrupts; >> > > >>> > when interrupt comes the gpioout is toggled but the system >> > > >>> > do not respond anymore to keyboard and nothing more is shown on >> > > >>> > the >> > > >>> screen >> > > >>> > - note that even if I try a classic (linux only, non-xenomai) >> > > >> >> > > >> This happens even with non-ipipe enables kernels? >> > > > >> > > >> >> > > >> >> > > >>> > gpio interrupt handler in 4.19.82 with xenomai-3 >> > > >>> > the system freeze when interrupt comes >> > > >>> > - 4.9.51 and 4.4.71 xenomai 3.0.5 enabled kernels work >> > > >>> > blinking gpioout and do not block, >> > > >>> > but both show warnings when interrupt comes >> > > >>> > which significantly increase interrupt latency. >> > > >>> > >> > > >>> > >> > > >>> > On 1/28/20, Jan Kiszka wrote: >> > > >>> >> On 24.01.20 07:24, Greg Gallagher via Xenomai wrote: >> > > >>> >>> I sent a patch offline, if you could try it that would be >> > > >>> >>> great. >> > > >>> >>> I'm >> > > >>> >>> having issues getting my board set up. >> > > >>> >>> >> > > >>> >> >> > > >>> >> Do we know by now if this is an I-pipe issue or rather >> > > >>> >> something >> > > >>> >> cobalt-related? >> > > >>> >> >> > > >>> >> Jan >> > > >>> >> >> > > >>> >>> On Thu, Jan 23, 2020 at 1:13 PM Greg Gallagher >> > > >>> >>> >> > > >>> >>> wrote: >> > > >>> >> > > >>> Hi, >> > > >>> >> > > >>> On Thu, Jan 23, 2020 at 12:15 PM Laurentiu-Cristian Duca >> > > >>> wrote: >> > > >>> > >> > > >>> > Hi, the interrupt comes one per second in my test, so there >> > > >>> > is no >> > > >>> > flood. >> > > >>> > In 4.19 the system it blinks the gpioout but it does not >> > > >>> > respond >> > > >>> > to >> > > >>> > keyboard and does not show anything more on the screen. >> > > >>> >> > > >>> Okay, there's a couple things that are different between 4.4 >> > > >>> and >> > > >>> 4.19 >> > > >>> that I'm looking into, which is taking me a little long then >> > > >>> I >> > > >>> thought. I won't have this patch ready till tomorrow >> > > >>> morning. I >> > > >>> finally have beaglebone black hardware, I'll make sure the >> > > >>> kernel >> > > >>> boots and then send the patch to you for testing. >> > > >>> >> > > >>> -Greg >> > > >>> >> > > >>> >> > > >>> > >> > > >>> > On Thu, Jan 23, 2020, 19:03 Greg Gallagher >> > > >>> > >> > > >>> > wrote: >> > > >>> >> >> > > >>> >> Hi, >> > > >>> >> >> > > >>> >> On Thu, Jan 23, 2020 at 9:21 AM Laurentiu-Cristian Duca >> > > >>> >> via >> > > >>> >> Xenomai >> > > >>> >> wrote: >> > > >>> >>> >> > > >>> >>> Hello xenomai community, >> > > >>> >>> >> > > >>> >>> I have successfully tested in xenomai SPI with >> > > >>> >>> interrupts >> > > >>> >>> on >> > > >>> >>> bbb. >> > > >>> >>> However, on bbb, if I try to test a basic gpio interrupts >> > > >>> >>> driver, >> > > >>> >>> problems appear. >> > > >>> >>> Please see details below. I appreciate any idea. >> > > >>> >>> >> > > >>> >>> 1. xenomai-3 master
Re: system freeze - beaglebone black xenomai - gpio interrupts driver
Hey, On Wed, Jan 29, 2020 at 11:58 AM Greg Gallagher wrote: > > Hey, > > On Wed, Jan 29, 2020 at 12:07 AM Greg Gallagher wrote: > > > > Hi, > > > > On Tue, Jan 28, 2020 at 7:37 AM Laurentiu-Cristian Duca > > wrote: > > > > > > Again, to make things clear: > > > I have tested two modules: one with RTDM gpio-interrupts and one with > > > classic linux interrupts. > > > The one with RTDM gpio-interrupts: > > > - makes kernel freeze on 4.14.71 and 4.19.82 ipipe-enabled kernels > > > - works (but with ipipe warnings when interrupt arrives) in 4.4.71 and > > > 4.9.51 > > > The one with classic linux interrupts: > > > - works in PREEMPT_RT linux (tested on 5.4.5 and 4.19.59 PREEMPT_RT > > > non-ipipe non-xenomai) > > > - makes kernel freeze when interrupt arrives on 4.14.71 and 4.19.82 > > > for xenomai ipipe enabled kernels > > > > > > On 1/28/20, Laurentiu-Cristian Duca wrote: > > > > This does not happen with non-ipipe enabled kernels. > > > > I have tested a classic gpio-interrupt module on PREEMPT_RT and it > > > > works, > > > > but when I tested it on an ipipe-enabled kernel (4.14.71 and 4.19.82) > > > > got kernel freeze. > > > > > > > > On 1/28/20, Greg Gallagher wrote: > > > >> On Tue, Jan 28, 2020 at 7:11 AM Laurentiu-Cristian Duca < > > > >> laurentiu.d...@gmail.com> wrote: > > > >> > > > >>> I forgot to say that I've tested 4.14.71 with xenomai 3.0.9 > > > >>> > > > >>> On 1/28/20, Laurentiu-Cristian Duca wrote: > > > >>> > Hello Jan and friends, > > > >>> > > > > >>> > The situation is the following for bbb: > > > >>> > - 4.14.71 and 4.19.82 xenomai-3 master enabled kernels > > > >>> > freeze when trying to use gpio-interrupts; > > > >>> > when interrupt comes the gpioout is toggled but the system > > > >>> > do not respond anymore to keyboard and nothing more is shown on the > > > >>> screen > > > >>> > - note that even if I try a classic (linux only, non-xenomai) > > > >> > > > >> This happens even with non-ipipe enables kernels? > > > > > > > >> > > > >> > > > >>> > gpio interrupt handler in 4.19.82 with xenomai-3 > > > >>> > the system freeze when interrupt comes > > > >>> > - 4.9.51 and 4.4.71 xenomai 3.0.5 enabled kernels work > > > >>> > blinking gpioout and do not block, > > > >>> > but both show warnings when interrupt comes > > > >>> > which significantly increase interrupt latency. > > > >>> > > > > >>> > > > > >>> > On 1/28/20, Jan Kiszka wrote: > > > >>> >> On 24.01.20 07:24, Greg Gallagher via Xenomai wrote: > > > >>> >>> I sent a patch offline, if you could try it that would be great. > > > >>> >>> I'm > > > >>> >>> having issues getting my board set up. > > > >>> >>> > > > >>> >> > > > >>> >> Do we know by now if this is an I-pipe issue or rather something > > > >>> >> cobalt-related? > > > >>> >> > > > >>> >> Jan > > > >>> >> > > > >>> >>> On Thu, Jan 23, 2020 at 1:13 PM Greg Gallagher > > > >>> >>> > > > >>> >>> wrote: > > > >>> > > > >>> Hi, > > > >>> > > > >>> On Thu, Jan 23, 2020 at 12:15 PM Laurentiu-Cristian Duca > > > >>> wrote: > > > >>> > > > > >>> > Hi, the interrupt comes one per second in my test, so there is > > > >>> > no > > > >>> > flood. > > > >>> > In 4.19 the system it blinks the gpioout but it does not respond > > > >>> > to > > > >>> > keyboard and does not show anything more on the screen. > > > >>> > > > >>> Okay, there's a couple things that are different between 4.4 and > > > >>> 4.19 > > > >>> that I'm looking into, which is taking me a little long then I > > > >>> thought. I won't have this patch ready till tomorrow morning. I > > > >>> finally have beaglebone black hardware, I'll make sure the kernel > > > >>> boots and then send the patch to you for testing. > > > >>> > > > >>> -Greg > > > >>> > > > >>> > > > >>> > > > > >>> > On Thu, Jan 23, 2020, 19:03 Greg Gallagher > > > >>> > > > > >>> > wrote: > > > >>> >> > > > >>> >> Hi, > > > >>> >> > > > >>> >> On Thu, Jan 23, 2020 at 9:21 AM Laurentiu-Cristian Duca via > > > >>> >> Xenomai > > > >>> >> wrote: > > > >>> >>> > > > >>> >>> Hello xenomai community, > > > >>> >>> > > > >>> >>> I have successfully tested in xenomai SPI with interrupts > > > >>> >>> on > > > >>> >>> bbb. > > > >>> >>> However, on bbb, if I try to test a basic gpio interrupts > > > >>> >>> driver, > > > >>> >>> problems appear. > > > >>> >>> Please see details below. I appreciate any idea. > > > >>> >>> > > > >>> >>> 1. xenomai-3 master linux 4.19.82, default dts > > > >>> >>> # insmod xeno_osc-gpio-rtdm.ko > > > >>> >>> [ 105.582245] IRQ number 62 ! > > > >>> >>> [ 105.585976] after request irq = 62 > > > >>> >>> System freeze when first interrupt occurs and I must power > > > >>> >>> off. > > > >>> >> Is it possible to use raw_printk and see if the system is still > > > >>> >>
Re: system freeze - beaglebone black xenomai - gpio interrupts driver
Hey, On Wed, Jan 29, 2020 at 12:07 AM Greg Gallagher wrote: > > Hi, > > On Tue, Jan 28, 2020 at 7:37 AM Laurentiu-Cristian Duca > wrote: > > > > Again, to make things clear: > > I have tested two modules: one with RTDM gpio-interrupts and one with > > classic linux interrupts. > > The one with RTDM gpio-interrupts: > > - makes kernel freeze on 4.14.71 and 4.19.82 ipipe-enabled kernels > > - works (but with ipipe warnings when interrupt arrives) in 4.4.71 and > > 4.9.51 > > The one with classic linux interrupts: > > - works in PREEMPT_RT linux (tested on 5.4.5 and 4.19.59 PREEMPT_RT > > non-ipipe non-xenomai) > > - makes kernel freeze when interrupt arrives on 4.14.71 and 4.19.82 > > for xenomai ipipe enabled kernels > > > > On 1/28/20, Laurentiu-Cristian Duca wrote: > > > This does not happen with non-ipipe enabled kernels. > > > I have tested a classic gpio-interrupt module on PREEMPT_RT and it works, > > > but when I tested it on an ipipe-enabled kernel (4.14.71 and 4.19.82) > > > got kernel freeze. > > > > > > On 1/28/20, Greg Gallagher wrote: > > >> On Tue, Jan 28, 2020 at 7:11 AM Laurentiu-Cristian Duca < > > >> laurentiu.d...@gmail.com> wrote: > > >> > > >>> I forgot to say that I've tested 4.14.71 with xenomai 3.0.9 > > >>> > > >>> On 1/28/20, Laurentiu-Cristian Duca wrote: > > >>> > Hello Jan and friends, > > >>> > > > >>> > The situation is the following for bbb: > > >>> > - 4.14.71 and 4.19.82 xenomai-3 master enabled kernels > > >>> > freeze when trying to use gpio-interrupts; > > >>> > when interrupt comes the gpioout is toggled but the system > > >>> > do not respond anymore to keyboard and nothing more is shown on the > > >>> screen > > >>> > - note that even if I try a classic (linux only, non-xenomai) > > >> > > >> This happens even with non-ipipe enables kernels? > > > > > >> > > >> > > >>> > gpio interrupt handler in 4.19.82 with xenomai-3 > > >>> > the system freeze when interrupt comes > > >>> > - 4.9.51 and 4.4.71 xenomai 3.0.5 enabled kernels work > > >>> > blinking gpioout and do not block, > > >>> > but both show warnings when interrupt comes > > >>> > which significantly increase interrupt latency. > > >>> > > > >>> > > > >>> > On 1/28/20, Jan Kiszka wrote: > > >>> >> On 24.01.20 07:24, Greg Gallagher via Xenomai wrote: > > >>> >>> I sent a patch offline, if you could try it that would be great. > > >>> >>> I'm > > >>> >>> having issues getting my board set up. > > >>> >>> > > >>> >> > > >>> >> Do we know by now if this is an I-pipe issue or rather something > > >>> >> cobalt-related? > > >>> >> > > >>> >> Jan > > >>> >> > > >>> >>> On Thu, Jan 23, 2020 at 1:13 PM Greg Gallagher > > >>> >>> > > >>> >>> wrote: > > >>> > > >>> Hi, > > >>> > > >>> On Thu, Jan 23, 2020 at 12:15 PM Laurentiu-Cristian Duca > > >>> wrote: > > >>> > > > >>> > Hi, the interrupt comes one per second in my test, so there is no > > >>> > flood. > > >>> > In 4.19 the system it blinks the gpioout but it does not respond > > >>> > to > > >>> > keyboard and does not show anything more on the screen. > > >>> > > >>> Okay, there's a couple things that are different between 4.4 and > > >>> 4.19 > > >>> that I'm looking into, which is taking me a little long then I > > >>> thought. I won't have this patch ready till tomorrow morning. I > > >>> finally have beaglebone black hardware, I'll make sure the kernel > > >>> boots and then send the patch to you for testing. > > >>> > > >>> -Greg > > >>> > > >>> > > >>> > > > >>> > On Thu, Jan 23, 2020, 19:03 Greg Gallagher > > >>> > wrote: > > >>> >> > > >>> >> Hi, > > >>> >> > > >>> >> On Thu, Jan 23, 2020 at 9:21 AM Laurentiu-Cristian Duca via > > >>> >> Xenomai > > >>> >> wrote: > > >>> >>> > > >>> >>> Hello xenomai community, > > >>> >>> > > >>> >>> I have successfully tested in xenomai SPI with interrupts > > >>> >>> on > > >>> >>> bbb. > > >>> >>> However, on bbb, if I try to test a basic gpio interrupts > > >>> >>> driver, > > >>> >>> problems appear. > > >>> >>> Please see details below. I appreciate any idea. > > >>> >>> > > >>> >>> 1. xenomai-3 master linux 4.19.82, default dts > > >>> >>> # insmod xeno_osc-gpio-rtdm.ko > > >>> >>> [ 105.582245] IRQ number 62 ! > > >>> >>> [ 105.585976] after request irq = 62 > > >>> >>> System freeze when first interrupt occurs and I must power off. > > >>> >> Is it possible to use raw_printk and see if the system is still > > >>> >> working but possibly getting flooded by interrupts? When I > > >>> >> encountered this issue with the BCM2835 port I placed a > > >>> >> raw_printk > > >>> in > > >>> >> one of the functions that initially handles the interrupt to see > > >>> >> if > > >>> >> it > > >>> >> was being ack'd. > > >>> >>> > > >>> >>> > > >>> >>> 2.
Re: system freeze - beaglebone black xenomai - gpio interrupts driver
Hi, On Tue, Jan 28, 2020 at 7:37 AM Laurentiu-Cristian Duca wrote: > > Again, to make things clear: > I have tested two modules: one with RTDM gpio-interrupts and one with > classic linux interrupts. > The one with RTDM gpio-interrupts: > - makes kernel freeze on 4.14.71 and 4.19.82 ipipe-enabled kernels > - works (but with ipipe warnings when interrupt arrives) in 4.4.71 and 4.9.51 > The one with classic linux interrupts: > - works in PREEMPT_RT linux (tested on 5.4.5 and 4.19.59 PREEMPT_RT > non-ipipe non-xenomai) > - makes kernel freeze when interrupt arrives on 4.14.71 and 4.19.82 > for xenomai ipipe enabled kernels > > On 1/28/20, Laurentiu-Cristian Duca wrote: > > This does not happen with non-ipipe enabled kernels. > > I have tested a classic gpio-interrupt module on PREEMPT_RT and it works, > > but when I tested it on an ipipe-enabled kernel (4.14.71 and 4.19.82) > > got kernel freeze. > > > > On 1/28/20, Greg Gallagher wrote: > >> On Tue, Jan 28, 2020 at 7:11 AM Laurentiu-Cristian Duca < > >> laurentiu.d...@gmail.com> wrote: > >> > >>> I forgot to say that I've tested 4.14.71 with xenomai 3.0.9 > >>> > >>> On 1/28/20, Laurentiu-Cristian Duca wrote: > >>> > Hello Jan and friends, > >>> > > >>> > The situation is the following for bbb: > >>> > - 4.14.71 and 4.19.82 xenomai-3 master enabled kernels > >>> > freeze when trying to use gpio-interrupts; > >>> > when interrupt comes the gpioout is toggled but the system > >>> > do not respond anymore to keyboard and nothing more is shown on the > >>> screen > >>> > - note that even if I try a classic (linux only, non-xenomai) > >> > >> This happens even with non-ipipe enables kernels? > > > >> > >> > >>> > gpio interrupt handler in 4.19.82 with xenomai-3 > >>> > the system freeze when interrupt comes > >>> > - 4.9.51 and 4.4.71 xenomai 3.0.5 enabled kernels work > >>> > blinking gpioout and do not block, > >>> > but both show warnings when interrupt comes > >>> > which significantly increase interrupt latency. > >>> > > >>> > > >>> > On 1/28/20, Jan Kiszka wrote: > >>> >> On 24.01.20 07:24, Greg Gallagher via Xenomai wrote: > >>> >>> I sent a patch offline, if you could try it that would be great. > >>> >>> I'm > >>> >>> having issues getting my board set up. > >>> >>> > >>> >> > >>> >> Do we know by now if this is an I-pipe issue or rather something > >>> >> cobalt-related? > >>> >> > >>> >> Jan > >>> >> > >>> >>> On Thu, Jan 23, 2020 at 1:13 PM Greg Gallagher > >>> >>> > >>> >>> wrote: > >>> > >>> Hi, > >>> > >>> On Thu, Jan 23, 2020 at 12:15 PM Laurentiu-Cristian Duca > >>> wrote: > >>> > > >>> > Hi, the interrupt comes one per second in my test, so there is no > >>> > flood. > >>> > In 4.19 the system it blinks the gpioout but it does not respond > >>> > to > >>> > keyboard and does not show anything more on the screen. > >>> > >>> Okay, there's a couple things that are different between 4.4 and > >>> 4.19 > >>> that I'm looking into, which is taking me a little long then I > >>> thought. I won't have this patch ready till tomorrow morning. I > >>> finally have beaglebone black hardware, I'll make sure the kernel > >>> boots and then send the patch to you for testing. > >>> > >>> -Greg > >>> > >>> > >>> > > >>> > On Thu, Jan 23, 2020, 19:03 Greg Gallagher > >>> > wrote: > >>> >> > >>> >> Hi, > >>> >> > >>> >> On Thu, Jan 23, 2020 at 9:21 AM Laurentiu-Cristian Duca via > >>> >> Xenomai > >>> >> wrote: > >>> >>> > >>> >>> Hello xenomai community, > >>> >>> > >>> >>> I have successfully tested in xenomai SPI with interrupts > >>> >>> on > >>> >>> bbb. > >>> >>> However, on bbb, if I try to test a basic gpio interrupts > >>> >>> driver, > >>> >>> problems appear. > >>> >>> Please see details below. I appreciate any idea. > >>> >>> > >>> >>> 1. xenomai-3 master linux 4.19.82, default dts > >>> >>> # insmod xeno_osc-gpio-rtdm.ko > >>> >>> [ 105.582245] IRQ number 62 ! > >>> >>> [ 105.585976] after request irq = 62 > >>> >>> System freeze when first interrupt occurs and I must power off. > >>> >> Is it possible to use raw_printk and see if the system is still > >>> >> working but possibly getting flooded by interrupts? When I > >>> >> encountered this issue with the BCM2835 port I placed a > >>> >> raw_printk > >>> in > >>> >> one of the functions that initially handles the interrupt to see > >>> >> if > >>> >> it > >>> >> was being ack'd. > >>> >>> > >>> >>> > >>> >>> 2. xenomai 3.0.5 linux 4.4.71, default dts > >>> >>> # insmod xeno_osc-gpio-rtdm.ko > >>> >>> [ 39.901907] IRQ number 142 ! > >>> >>> [ 39.905447] after request irq = 142 > >>> >>> > >>> >>> When first interrupt occurs: > >>> >>> [ 322.104560] irq 142, desc: df15e500, depth: 1, count: 0, > >>>
Re: system freeze - beaglebone black xenomai - gpio interrupts driver
Again, to make things clear: I have tested two modules: one with RTDM gpio-interrupts and one with classic linux interrupts. The one with RTDM gpio-interrupts: - makes kernel freeze on 4.14.71 and 4.19.82 ipipe-enabled kernels - works (but with ipipe warnings when interrupt arrives) in 4.4.71 and 4.9.51 The one with classic linux interrupts: - works in PREEMPT_RT linux (tested on 5.4.5 and 4.19.59 PREEMPT_RT non-ipipe non-xenomai) - makes kernel freeze when interrupt arrives on 4.14.71 and 4.19.82 for xenomai ipipe enabled kernels On 1/28/20, Laurentiu-Cristian Duca wrote: > This does not happen with non-ipipe enabled kernels. > I have tested a classic gpio-interrupt module on PREEMPT_RT and it works, > but when I tested it on an ipipe-enabled kernel (4.14.71 and 4.19.82) > got kernel freeze. > > On 1/28/20, Greg Gallagher wrote: >> On Tue, Jan 28, 2020 at 7:11 AM Laurentiu-Cristian Duca < >> laurentiu.d...@gmail.com> wrote: >> >>> I forgot to say that I've tested 4.14.71 with xenomai 3.0.9 >>> >>> On 1/28/20, Laurentiu-Cristian Duca wrote: >>> > Hello Jan and friends, >>> > >>> > The situation is the following for bbb: >>> > - 4.14.71 and 4.19.82 xenomai-3 master enabled kernels >>> > freeze when trying to use gpio-interrupts; >>> > when interrupt comes the gpioout is toggled but the system >>> > do not respond anymore to keyboard and nothing more is shown on the >>> screen >>> > - note that even if I try a classic (linux only, non-xenomai) >> >> This happens even with non-ipipe enables kernels? > >> >> >>> > gpio interrupt handler in 4.19.82 with xenomai-3 >>> > the system freeze when interrupt comes >>> > - 4.9.51 and 4.4.71 xenomai 3.0.5 enabled kernels work >>> > blinking gpioout and do not block, >>> > but both show warnings when interrupt comes >>> > which significantly increase interrupt latency. >>> > >>> > >>> > On 1/28/20, Jan Kiszka wrote: >>> >> On 24.01.20 07:24, Greg Gallagher via Xenomai wrote: >>> >>> I sent a patch offline, if you could try it that would be great. >>> >>> I'm >>> >>> having issues getting my board set up. >>> >>> >>> >> >>> >> Do we know by now if this is an I-pipe issue or rather something >>> >> cobalt-related? >>> >> >>> >> Jan >>> >> >>> >>> On Thu, Jan 23, 2020 at 1:13 PM Greg Gallagher >>> >>> >>> >>> wrote: >>> >>> Hi, >>> >>> On Thu, Jan 23, 2020 at 12:15 PM Laurentiu-Cristian Duca >>> wrote: >>> > >>> > Hi, the interrupt comes one per second in my test, so there is no >>> > flood. >>> > In 4.19 the system it blinks the gpioout but it does not respond >>> > to >>> > keyboard and does not show anything more on the screen. >>> >>> Okay, there's a couple things that are different between 4.4 and >>> 4.19 >>> that I'm looking into, which is taking me a little long then I >>> thought. I won't have this patch ready till tomorrow morning. I >>> finally have beaglebone black hardware, I'll make sure the kernel >>> boots and then send the patch to you for testing. >>> >>> -Greg >>> >>> >>> > >>> > On Thu, Jan 23, 2020, 19:03 Greg Gallagher >>> > wrote: >>> >> >>> >> Hi, >>> >> >>> >> On Thu, Jan 23, 2020 at 9:21 AM Laurentiu-Cristian Duca via >>> >> Xenomai >>> >> wrote: >>> >>> >>> >>> Hello xenomai community, >>> >>> >>> >>> I have successfully tested in xenomai SPI with interrupts >>> >>> on >>> >>> bbb. >>> >>> However, on bbb, if I try to test a basic gpio interrupts >>> >>> driver, >>> >>> problems appear. >>> >>> Please see details below. I appreciate any idea. >>> >>> >>> >>> 1. xenomai-3 master linux 4.19.82, default dts >>> >>> # insmod xeno_osc-gpio-rtdm.ko >>> >>> [ 105.582245] IRQ number 62 ! >>> >>> [ 105.585976] after request irq = 62 >>> >>> System freeze when first interrupt occurs and I must power off. >>> >> Is it possible to use raw_printk and see if the system is still >>> >> working but possibly getting flooded by interrupts? When I >>> >> encountered this issue with the BCM2835 port I placed a >>> >> raw_printk >>> in >>> >> one of the functions that initially handles the interrupt to see >>> >> if >>> >> it >>> >> was being ack'd. >>> >>> >>> >>> >>> >>> 2. xenomai 3.0.5 linux 4.4.71, default dts >>> >>> # insmod xeno_osc-gpio-rtdm.ko >>> >>> [ 39.901907] IRQ number 142 ! >>> >>> [ 39.905447] after request irq = 142 >>> >>> >>> >>> When first interrupt occurs: >>> >>> [ 322.104560] irq 142, desc: df15e500, depth: 1, count: 0, >>> >>> unhandled: >>> >>> 0 >>> >>> [ 322.111310] ->handle_irq(): c00998b4, >>> >>> handle_edge_irq+0x0/0x168 >>> >>> [ 322.117606] ->irq_data.chip(): df156710, 0xdf156710 >>> >>> [ 322.122702] ->action(): (null) >>> >>> [ 322.126067]IRQ_NOPROBE set >>> >>> [ 322.129252] unexpected IRQ
Re: system freeze - beaglebone black xenomai - gpio interrupts driver
This does not happen with non-ipipe enabled kernels. I have tested a classic gpio-interrupt module on PREEMPT_RT and it works, but when I tested it on an ipipe-enabled kernel (4.14.71 and 4.19.82) got kernel freeze. On 1/28/20, Greg Gallagher wrote: > On Tue, Jan 28, 2020 at 7:11 AM Laurentiu-Cristian Duca < > laurentiu.d...@gmail.com> wrote: > >> I forgot to say that I've tested 4.14.71 with xenomai 3.0.9 >> >> On 1/28/20, Laurentiu-Cristian Duca wrote: >> > Hello Jan and friends, >> > >> > The situation is the following for bbb: >> > - 4.14.71 and 4.19.82 xenomai-3 master enabled kernels >> > freeze when trying to use gpio-interrupts; >> > when interrupt comes the gpioout is toggled but the system >> > do not respond anymore to keyboard and nothing more is shown on the >> screen >> > - note that even if I try a classic (linux only, non-xenomai) > > This happens even with non-ipipe enables kernels? > > >> > gpio interrupt handler in 4.19.82 with xenomai-3 >> > the system freeze when interrupt comes >> > - 4.9.51 and 4.4.71 xenomai 3.0.5 enabled kernels work >> > blinking gpioout and do not block, >> > but both show warnings when interrupt comes >> > which significantly increase interrupt latency. >> > >> > >> > On 1/28/20, Jan Kiszka wrote: >> >> On 24.01.20 07:24, Greg Gallagher via Xenomai wrote: >> >>> I sent a patch offline, if you could try it that would be great. I'm >> >>> having issues getting my board set up. >> >>> >> >> >> >> Do we know by now if this is an I-pipe issue or rather something >> >> cobalt-related? >> >> >> >> Jan >> >> >> >>> On Thu, Jan 23, 2020 at 1:13 PM Greg Gallagher >> >>> >> >>> wrote: >> >> Hi, >> >> On Thu, Jan 23, 2020 at 12:15 PM Laurentiu-Cristian Duca >> wrote: >> > >> > Hi, the interrupt comes one per second in my test, so there is no >> > flood. >> > In 4.19 the system it blinks the gpioout but it does not respond to >> > keyboard and does not show anything more on the screen. >> >> Okay, there's a couple things that are different between 4.4 and >> 4.19 >> that I'm looking into, which is taking me a little long then I >> thought. I won't have this patch ready till tomorrow morning. I >> finally have beaglebone black hardware, I'll make sure the kernel >> boots and then send the patch to you for testing. >> >> -Greg >> >> >> > >> > On Thu, Jan 23, 2020, 19:03 Greg Gallagher >> > wrote: >> >> >> >> Hi, >> >> >> >> On Thu, Jan 23, 2020 at 9:21 AM Laurentiu-Cristian Duca via >> >> Xenomai >> >> wrote: >> >>> >> >>> Hello xenomai community, >> >>> >> >>> I have successfully tested in xenomai SPI with interrupts on >> >>> bbb. >> >>> However, on bbb, if I try to test a basic gpio interrupts driver, >> >>> problems appear. >> >>> Please see details below. I appreciate any idea. >> >>> >> >>> 1. xenomai-3 master linux 4.19.82, default dts >> >>> # insmod xeno_osc-gpio-rtdm.ko >> >>> [ 105.582245] IRQ number 62 ! >> >>> [ 105.585976] after request irq = 62 >> >>> System freeze when first interrupt occurs and I must power off. >> >> Is it possible to use raw_printk and see if the system is still >> >> working but possibly getting flooded by interrupts? When I >> >> encountered this issue with the BCM2835 port I placed a raw_printk >> in >> >> one of the functions that initially handles the interrupt to see >> >> if >> >> it >> >> was being ack'd. >> >>> >> >>> >> >>> 2. xenomai 3.0.5 linux 4.4.71, default dts >> >>> # insmod xeno_osc-gpio-rtdm.ko >> >>> [ 39.901907] IRQ number 142 ! >> >>> [ 39.905447] after request irq = 142 >> >>> >> >>> When first interrupt occurs: >> >>> [ 322.104560] irq 142, desc: df15e500, depth: 1, count: 0, >> >>> unhandled: >> >>> 0 >> >>> [ 322.111310] ->handle_irq(): c00998b4, >> >>> handle_edge_irq+0x0/0x168 >> >>> [ 322.117606] ->irq_data.chip(): df156710, 0xdf156710 >> >>> [ 322.122702] ->action(): (null) >> >>> [ 322.126067]IRQ_NOPROBE set >> >>> [ 322.129252] unexpected IRQ trap at vector 8e >> >>> [ 322.133706] [ cut here ] >> >>> [ 322.138530] WARNING: CPU: 0 PID: 0 at kernel/irq/chip.c:843 >> >>> __ipipe_ack_bad_irq+0x24/0x3c() >> >>> [ 322.147244] Modules linked in: xeno_osc_gpio_rtdm(O) >> >>> [ 322.152444] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G >> >>> O >> >>> 4.4.71-ipipe #1 >> >>> [ 322.160434] Hardware name: Generic AM33XX (Flattened Device >> Tree) >> >>> [ 322.166791] I-pipe domain: Linux >> >>> [ 322.170175] [] (unwind_backtrace) from [] >> >>> (show_stack+0x10/0x14) >> >>> [ 322.178273] [] (show_stack) from [] >> >>> (dump_stack+0x9c/0xc4) >> >>> [ 322.185829] [] (dump_stack) from [] >> >>>
Re: system freeze - beaglebone black xenomai - gpio interrupts driver
On Tue, Jan 28, 2020 at 7:11 AM Laurentiu-Cristian Duca < laurentiu.d...@gmail.com> wrote: > I forgot to say that I've tested 4.14.71 with xenomai 3.0.9 > > On 1/28/20, Laurentiu-Cristian Duca wrote: > > Hello Jan and friends, > > > > The situation is the following for bbb: > > - 4.14.71 and 4.19.82 xenomai-3 master enabled kernels > > freeze when trying to use gpio-interrupts; > > when interrupt comes the gpioout is toggled but the system > > do not respond anymore to keyboard and nothing more is shown on the > screen > > - note that even if I try a classic (linux only, non-xenomai) This happens even with non-ipipe enables kernels? > > gpio interrupt handler in 4.19.82 with xenomai-3 > > the system freeze when interrupt comes > > - 4.9.51 and 4.4.71 xenomai 3.0.5 enabled kernels work > > blinking gpioout and do not block, > > but both show warnings when interrupt comes > > which significantly increase interrupt latency. > > > > > > On 1/28/20, Jan Kiszka wrote: > >> On 24.01.20 07:24, Greg Gallagher via Xenomai wrote: > >>> I sent a patch offline, if you could try it that would be great. I'm > >>> having issues getting my board set up. > >>> > >> > >> Do we know by now if this is an I-pipe issue or rather something > >> cobalt-related? > >> > >> Jan > >> > >>> On Thu, Jan 23, 2020 at 1:13 PM Greg Gallagher > >>> wrote: > > Hi, > > On Thu, Jan 23, 2020 at 12:15 PM Laurentiu-Cristian Duca > wrote: > > > > Hi, the interrupt comes one per second in my test, so there is no > > flood. > > In 4.19 the system it blinks the gpioout but it does not respond to > > keyboard and does not show anything more on the screen. > > Okay, there's a couple things that are different between 4.4 and 4.19 > that I'm looking into, which is taking me a little long then I > thought. I won't have this patch ready till tomorrow morning. I > finally have beaglebone black hardware, I'll make sure the kernel > boots and then send the patch to you for testing. > > -Greg > > > > > > On Thu, Jan 23, 2020, 19:03 Greg Gallagher > > wrote: > >> > >> Hi, > >> > >> On Thu, Jan 23, 2020 at 9:21 AM Laurentiu-Cristian Duca via Xenomai > >> wrote: > >>> > >>> Hello xenomai community, > >>> > >>> I have successfully tested in xenomai SPI with interrupts on > >>> bbb. > >>> However, on bbb, if I try to test a basic gpio interrupts driver, > >>> problems appear. > >>> Please see details below. I appreciate any idea. > >>> > >>> 1. xenomai-3 master linux 4.19.82, default dts > >>> # insmod xeno_osc-gpio-rtdm.ko > >>> [ 105.582245] IRQ number 62 ! > >>> [ 105.585976] after request irq = 62 > >>> System freeze when first interrupt occurs and I must power off. > >> Is it possible to use raw_printk and see if the system is still > >> working but possibly getting flooded by interrupts? When I > >> encountered this issue with the BCM2835 port I placed a raw_printk > in > >> one of the functions that initially handles the interrupt to see if > >> it > >> was being ack'd. > >>> > >>> > >>> 2. xenomai 3.0.5 linux 4.4.71, default dts > >>> # insmod xeno_osc-gpio-rtdm.ko > >>> [ 39.901907] IRQ number 142 ! > >>> [ 39.905447] after request irq = 142 > >>> > >>> When first interrupt occurs: > >>> [ 322.104560] irq 142, desc: df15e500, depth: 1, count: 0, > >>> unhandled: > >>> 0 > >>> [ 322.111310] ->handle_irq(): c00998b4, handle_edge_irq+0x0/0x168 > >>> [ 322.117606] ->irq_data.chip(): df156710, 0xdf156710 > >>> [ 322.122702] ->action(): (null) > >>> [ 322.126067]IRQ_NOPROBE set > >>> [ 322.129252] unexpected IRQ trap at vector 8e > >>> [ 322.133706] [ cut here ] > >>> [ 322.138530] WARNING: CPU: 0 PID: 0 at kernel/irq/chip.c:843 > >>> __ipipe_ack_bad_irq+0x24/0x3c() > >>> [ 322.147244] Modules linked in: xeno_osc_gpio_rtdm(O) > >>> [ 322.152444] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O > >>> 4.4.71-ipipe #1 > >>> [ 322.160434] Hardware name: Generic AM33XX (Flattened Device > Tree) > >>> [ 322.166791] I-pipe domain: Linux > >>> [ 322.170175] [] (unwind_backtrace) from [] > >>> (show_stack+0x10/0x14) > >>> [ 322.178273] [] (show_stack) from [] > >>> (dump_stack+0x9c/0xc4) > >>> [ 322.185829] [] (dump_stack) from [] > >>> (warn_slowpath_common+0x78/0xb4) > >>> [ 322.194280] [] (warn_slowpath_common) from > [] > >>> (warn_slowpath_null+0x1c/0x24) > >>> [ 322.203455] [] (warn_slowpath_null) from [] > >>> (__ipipe_ack_bad_irq+0x24/0x3c) > >>> [ 322.212542] [] (__ipipe_ack_bad_irq) from [] > >>> (__ipipe_dispatch_irq+0x78/0x1d8) > >>> [ 322.221903] [] (__ipipe_dispatch_irq) from > [] > >>>
Re: system freeze - beaglebone black xenomai - gpio interrupts driver
I forgot to say that I've tested 4.14.71 with xenomai 3.0.9 On 1/28/20, Laurentiu-Cristian Duca wrote: > Hello Jan and friends, > > The situation is the following for bbb: > - 4.14.71 and 4.19.82 xenomai-3 master enabled kernels > freeze when trying to use gpio-interrupts; > when interrupt comes the gpioout is toggled but the system > do not respond anymore to keyboard and nothing more is shown on the screen > - note that even if I try a classic (linux only, non-xenomai) > gpio interrupt handler in 4.19.82 with xenomai-3 > the system freeze when interrupt comes > - 4.9.51 and 4.4.71 xenomai 3.0.5 enabled kernels work > blinking gpioout and do not block, > but both show warnings when interrupt comes > which significantly increase interrupt latency. > > > On 1/28/20, Jan Kiszka wrote: >> On 24.01.20 07:24, Greg Gallagher via Xenomai wrote: >>> I sent a patch offline, if you could try it that would be great. I'm >>> having issues getting my board set up. >>> >> >> Do we know by now if this is an I-pipe issue or rather something >> cobalt-related? >> >> Jan >> >>> On Thu, Jan 23, 2020 at 1:13 PM Greg Gallagher >>> wrote: Hi, On Thu, Jan 23, 2020 at 12:15 PM Laurentiu-Cristian Duca wrote: > > Hi, the interrupt comes one per second in my test, so there is no > flood. > In 4.19 the system it blinks the gpioout but it does not respond to > keyboard and does not show anything more on the screen. Okay, there's a couple things that are different between 4.4 and 4.19 that I'm looking into, which is taking me a little long then I thought. I won't have this patch ready till tomorrow morning. I finally have beaglebone black hardware, I'll make sure the kernel boots and then send the patch to you for testing. -Greg > > On Thu, Jan 23, 2020, 19:03 Greg Gallagher > wrote: >> >> Hi, >> >> On Thu, Jan 23, 2020 at 9:21 AM Laurentiu-Cristian Duca via Xenomai >> wrote: >>> >>> Hello xenomai community, >>> >>> I have successfully tested in xenomai SPI with interrupts on >>> bbb. >>> However, on bbb, if I try to test a basic gpio interrupts driver, >>> problems appear. >>> Please see details below. I appreciate any idea. >>> >>> 1. xenomai-3 master linux 4.19.82, default dts >>> # insmod xeno_osc-gpio-rtdm.ko >>> [ 105.582245] IRQ number 62 ! >>> [ 105.585976] after request irq = 62 >>> System freeze when first interrupt occurs and I must power off. >> Is it possible to use raw_printk and see if the system is still >> working but possibly getting flooded by interrupts? When I >> encountered this issue with the BCM2835 port I placed a raw_printk in >> one of the functions that initially handles the interrupt to see if >> it >> was being ack'd. >>> >>> >>> 2. xenomai 3.0.5 linux 4.4.71, default dts >>> # insmod xeno_osc-gpio-rtdm.ko >>> [ 39.901907] IRQ number 142 ! >>> [ 39.905447] after request irq = 142 >>> >>> When first interrupt occurs: >>> [ 322.104560] irq 142, desc: df15e500, depth: 1, count: 0, >>> unhandled: >>> 0 >>> [ 322.111310] ->handle_irq(): c00998b4, handle_edge_irq+0x0/0x168 >>> [ 322.117606] ->irq_data.chip(): df156710, 0xdf156710 >>> [ 322.122702] ->action(): (null) >>> [ 322.126067]IRQ_NOPROBE set >>> [ 322.129252] unexpected IRQ trap at vector 8e >>> [ 322.133706] [ cut here ] >>> [ 322.138530] WARNING: CPU: 0 PID: 0 at kernel/irq/chip.c:843 >>> __ipipe_ack_bad_irq+0x24/0x3c() >>> [ 322.147244] Modules linked in: xeno_osc_gpio_rtdm(O) >>> [ 322.152444] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O >>> 4.4.71-ipipe #1 >>> [ 322.160434] Hardware name: Generic AM33XX (Flattened Device Tree) >>> [ 322.166791] I-pipe domain: Linux >>> [ 322.170175] [] (unwind_backtrace) from [] >>> (show_stack+0x10/0x14) >>> [ 322.178273] [] (show_stack) from [] >>> (dump_stack+0x9c/0xc4) >>> [ 322.185829] [] (dump_stack) from [] >>> (warn_slowpath_common+0x78/0xb4) >>> [ 322.194280] [] (warn_slowpath_common) from [] >>> (warn_slowpath_null+0x1c/0x24) >>> [ 322.203455] [] (warn_slowpath_null) from [] >>> (__ipipe_ack_bad_irq+0x24/0x3c) >>> [ 322.212542] [] (__ipipe_ack_bad_irq) from [] >>> (__ipipe_dispatch_irq+0x78/0x1d8) >>> [ 322.221903] [] (__ipipe_dispatch_irq) from [] >>> (omap_gpio_irq_handler+0x134/0x1a4) >>> [ 322.231532] [] (omap_gpio_irq_handler) from >>> [] >>> (handle_irq_event_percpu+0xa4/0x304) >>> [ 322.241341] [] (handle_irq_event_percpu) from >>> [] (handle_irq_event+0x38/0x5c) >>> [ 322.250605] [] (handle_irq_event) from [] >>> (handle_level_irq+0x88/0xe4) >>> [ 322.259235] [] (handle_level_irq) from [] >>>
Re: system freeze - beaglebone black xenomai - gpio interrupts driver
Hello Jan and friends, The situation is the following for bbb: - 4.14.71 and 4.19.82 xenomai-3 master enabled kernels freeze when trying to use gpio-interrupts; when interrupt comes the gpioout is toggled but the system do not respond anymore to keyboard and nothing more is shown on the screen - note that even if I try a classic (linux only, non-xenomai) gpio interrupt handler in 4.19.82 with xenomai-3 the system freeze when interrupt comes - 4.9.51 and 4.4.71 xenomai 3.0.5 enabled kernels work blinking gpioout and do not block, but both show warnings when interrupt comes which significantly increase interrupt latency. On 1/28/20, Jan Kiszka wrote: > On 24.01.20 07:24, Greg Gallagher via Xenomai wrote: >> I sent a patch offline, if you could try it that would be great. I'm >> having issues getting my board set up. >> > > Do we know by now if this is an I-pipe issue or rather something > cobalt-related? > > Jan > >> On Thu, Jan 23, 2020 at 1:13 PM Greg Gallagher >> wrote: >>> >>> Hi, >>> >>> On Thu, Jan 23, 2020 at 12:15 PM Laurentiu-Cristian Duca >>> wrote: Hi, the interrupt comes one per second in my test, so there is no flood. In 4.19 the system it blinks the gpioout but it does not respond to keyboard and does not show anything more on the screen. >>> >>> Okay, there's a couple things that are different between 4.4 and 4.19 >>> that I'm looking into, which is taking me a little long then I >>> thought. I won't have this patch ready till tomorrow morning. I >>> finally have beaglebone black hardware, I'll make sure the kernel >>> boots and then send the patch to you for testing. >>> >>> -Greg >>> >>> On Thu, Jan 23, 2020, 19:03 Greg Gallagher wrote: > > Hi, > > On Thu, Jan 23, 2020 at 9:21 AM Laurentiu-Cristian Duca via Xenomai > wrote: >> >> Hello xenomai community, >> >> I have successfully tested in xenomai SPI with interrupts on >> bbb. >> However, on bbb, if I try to test a basic gpio interrupts driver, >> problems appear. >> Please see details below. I appreciate any idea. >> >> 1. xenomai-3 master linux 4.19.82, default dts >> # insmod xeno_osc-gpio-rtdm.ko >> [ 105.582245] IRQ number 62 ! >> [ 105.585976] after request irq = 62 >> System freeze when first interrupt occurs and I must power off. > Is it possible to use raw_printk and see if the system is still > working but possibly getting flooded by interrupts? When I > encountered this issue with the BCM2835 port I placed a raw_printk in > one of the functions that initially handles the interrupt to see if it > was being ack'd. >> >> >> 2. xenomai 3.0.5 linux 4.4.71, default dts >> # insmod xeno_osc-gpio-rtdm.ko >> [ 39.901907] IRQ number 142 ! >> [ 39.905447] after request irq = 142 >> >> When first interrupt occurs: >> [ 322.104560] irq 142, desc: df15e500, depth: 1, count: 0, unhandled: >> 0 >> [ 322.111310] ->handle_irq(): c00998b4, handle_edge_irq+0x0/0x168 >> [ 322.117606] ->irq_data.chip(): df156710, 0xdf156710 >> [ 322.122702] ->action(): (null) >> [ 322.126067]IRQ_NOPROBE set >> [ 322.129252] unexpected IRQ trap at vector 8e >> [ 322.133706] [ cut here ] >> [ 322.138530] WARNING: CPU: 0 PID: 0 at kernel/irq/chip.c:843 >> __ipipe_ack_bad_irq+0x24/0x3c() >> [ 322.147244] Modules linked in: xeno_osc_gpio_rtdm(O) >> [ 322.152444] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O >> 4.4.71-ipipe #1 >> [ 322.160434] Hardware name: Generic AM33XX (Flattened Device Tree) >> [ 322.166791] I-pipe domain: Linux >> [ 322.170175] [] (unwind_backtrace) from [] >> (show_stack+0x10/0x14) >> [ 322.178273] [] (show_stack) from [] >> (dump_stack+0x9c/0xc4) >> [ 322.185829] [] (dump_stack) from [] >> (warn_slowpath_common+0x78/0xb4) >> [ 322.194280] [] (warn_slowpath_common) from [] >> (warn_slowpath_null+0x1c/0x24) >> [ 322.203455] [] (warn_slowpath_null) from [] >> (__ipipe_ack_bad_irq+0x24/0x3c) >> [ 322.212542] [] (__ipipe_ack_bad_irq) from [] >> (__ipipe_dispatch_irq+0x78/0x1d8) >> [ 322.221903] [] (__ipipe_dispatch_irq) from [] >> (omap_gpio_irq_handler+0x134/0x1a4) >> [ 322.231532] [] (omap_gpio_irq_handler) from [] >> (handle_irq_event_percpu+0xa4/0x304) >> [ 322.241341] [] (handle_irq_event_percpu) from >> [] (handle_irq_event+0x38/0x5c) >> [ 322.250605] [] (handle_irq_event) from [] >> (handle_level_irq+0x88/0xe4) >> [ 322.259235] [] (handle_level_irq) from [] >> (generic_handle_irq+0x20/0x34) >> [ 322.268045] [] (generic_handle_irq) from [] >> (__handle_domain_irq+0x64/0xd4) >> [ 322.277127] [] (__handle_domain_irq) from [] >> (__ipipe_do_sync_stage+0x21c/0x25c) >> [ 322.286665] [] (__ipipe_do_sync_stage) from [] >>
Re: system freeze - beaglebone black xenomai - gpio interrupts driver
On 24.01.20 07:24, Greg Gallagher via Xenomai wrote: I sent a patch offline, if you could try it that would be great. I'm having issues getting my board set up. Do we know by now if this is an I-pipe issue or rather something cobalt-related? Jan On Thu, Jan 23, 2020 at 1:13 PM Greg Gallagher wrote: Hi, On Thu, Jan 23, 2020 at 12:15 PM Laurentiu-Cristian Duca wrote: Hi, the interrupt comes one per second in my test, so there is no flood. In 4.19 the system it blinks the gpioout but it does not respond to keyboard and does not show anything more on the screen. Okay, there's a couple things that are different between 4.4 and 4.19 that I'm looking into, which is taking me a little long then I thought. I won't have this patch ready till tomorrow morning. I finally have beaglebone black hardware, I'll make sure the kernel boots and then send the patch to you for testing. -Greg On Thu, Jan 23, 2020, 19:03 Greg Gallagher wrote: Hi, On Thu, Jan 23, 2020 at 9:21 AM Laurentiu-Cristian Duca via Xenomai wrote: Hello xenomai community, I have successfully tested in xenomai SPI with interrupts on bbb. However, on bbb, if I try to test a basic gpio interrupts driver, problems appear. Please see details below. I appreciate any idea. 1. xenomai-3 master linux 4.19.82, default dts # insmod xeno_osc-gpio-rtdm.ko [ 105.582245] IRQ number 62 ! [ 105.585976] after request irq = 62 System freeze when first interrupt occurs and I must power off. Is it possible to use raw_printk and see if the system is still working but possibly getting flooded by interrupts? When I encountered this issue with the BCM2835 port I placed a raw_printk in one of the functions that initially handles the interrupt to see if it was being ack'd. 2. xenomai 3.0.5 linux 4.4.71, default dts # insmod xeno_osc-gpio-rtdm.ko [ 39.901907] IRQ number 142 ! [ 39.905447] after request irq = 142 When first interrupt occurs: [ 322.104560] irq 142, desc: df15e500, depth: 1, count: 0, unhandled: 0 [ 322.111310] ->handle_irq(): c00998b4, handle_edge_irq+0x0/0x168 [ 322.117606] ->irq_data.chip(): df156710, 0xdf156710 [ 322.122702] ->action(): (null) [ 322.126067]IRQ_NOPROBE set [ 322.129252] unexpected IRQ trap at vector 8e [ 322.133706] [ cut here ] [ 322.138530] WARNING: CPU: 0 PID: 0 at kernel/irq/chip.c:843 __ipipe_ack_bad_irq+0x24/0x3c() [ 322.147244] Modules linked in: xeno_osc_gpio_rtdm(O) [ 322.152444] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 4.4.71-ipipe #1 [ 322.160434] Hardware name: Generic AM33XX (Flattened Device Tree) [ 322.166791] I-pipe domain: Linux [ 322.170175] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 322.178273] [] (show_stack) from [] (dump_stack+0x9c/0xc4) [ 322.185829] [] (dump_stack) from [] (warn_slowpath_common+0x78/0xb4) [ 322.194280] [] (warn_slowpath_common) from [] (warn_slowpath_null+0x1c/0x24) [ 322.203455] [] (warn_slowpath_null) from [] (__ipipe_ack_bad_irq+0x24/0x3c) [ 322.212542] [] (__ipipe_ack_bad_irq) from [] (__ipipe_dispatch_irq+0x78/0x1d8) [ 322.221903] [] (__ipipe_dispatch_irq) from [] (omap_gpio_irq_handler+0x134/0x1a4) [ 322.231532] [] (omap_gpio_irq_handler) from [] (handle_irq_event_percpu+0xa4/0x304) [ 322.241341] [] (handle_irq_event_percpu) from [] (handle_irq_event+0x38/0x5c) [ 322.250605] [] (handle_irq_event) from [] (handle_level_irq+0x88/0xe4) [ 322.259235] [] (handle_level_irq) from [] (generic_handle_irq+0x20/0x34) [ 322.268045] [] (generic_handle_irq) from [] (__handle_domain_irq+0x64/0xd4) [ 322.277127] [] (__handle_domain_irq) from [] (__ipipe_do_sync_stage+0x21c/0x25c) [ 322.286665] [] (__ipipe_do_sync_stage) from [] (__ipipe_grab_irq+0x5c/0x7c) [ 322.295753] [] (__ipipe_grab_irq) from [] (__irq_svc+0x54/0x60) [ 322.303745] Exception stack(0xc0937f58 to 0xc0937fa0) [ 322.309017] 7f40: df91d240 [ 322.317556] 7f60: c092e240 c0938a24 c09f4c3c c09389c4 0001 [ 322.326095] 7f80: c064d88c c0937fa8 c0080f04 c00df35c 6013 [ 322.334634] [] (__irq_svc) from [] (ipipe_unstall_root+0x38/0x50) [ 322.342822] [] (ipipe_unstall_root) from [] (cpu_startup_entry+0x68/0x2b8) [ 322.351826] [] (cpu_startup_entry) from [] (start_kernel+0x370/0x3e8) [ 322.360361] ---[ end trace 3de49b4cee31ba0b ]--- When other interrupts occur: [ 322.365188] irq 142, desc: df15e500, depth: 1, count: 0, unhandled: 0 [ 322.371908] ->handle_irq(): c00998b4, handle_edge_irq+0x0/0x168 [ 322.378183] ->irq_data.chip(): df156710, 0xdf156710 [ 322.383277] ->action(): (null) [ 322.386641]IRQ_NOPROBE set [ 322.389825] unexpected IRQ trap at vector 8e [ 324.664939] irq 142, desc: df15e500, depth: 1, count: 0, unhandled: 0 [ 324.671684] ->handle_irq(): c00998b4, handle_edge_irq+0x0/0x168 [ 324.677980] ->irq_data.chip(): df156710, 0xdf156710 [ 324.683077] ->action(): (null) [ 324.686442]IRQ_NOPROBE set ... 3.
Re: system freeze - beaglebone black xenomai - gpio interrupts driver
Hi, On Thu, Jan 23, 2020 at 12:15 PM Laurentiu-Cristian Duca wrote: > > Hi, the interrupt comes one per second in my test, so there is no flood. In > 4.19 the system it blinks the gpioout but it does not respond to keyboard and > does not show anything more on the screen. Okay, there's a couple things that are different between 4.4 and 4.19 that I'm looking into, which is taking me a little long then I thought. I won't have this patch ready till tomorrow morning. I finally have beaglebone black hardware, I'll make sure the kernel boots and then send the patch to you for testing. -Greg > > On Thu, Jan 23, 2020, 19:03 Greg Gallagher wrote: >> >> Hi, >> >> On Thu, Jan 23, 2020 at 9:21 AM Laurentiu-Cristian Duca via Xenomai >> wrote: >> > >> > Hello xenomai community, >> > >> > I have successfully tested in xenomai SPI with interrupts on bbb. >> > However, on bbb, if I try to test a basic gpio interrupts driver, >> > problems appear. >> > Please see details below. I appreciate any idea. >> > >> > 1. xenomai-3 master linux 4.19.82, default dts >> > # insmod xeno_osc-gpio-rtdm.ko >> > [ 105.582245] IRQ number 62 ! >> > [ 105.585976] after request irq = 62 >> > System freeze when first interrupt occurs and I must power off. >> Is it possible to use raw_printk and see if the system is still >> working but possibly getting flooded by interrupts? When I >> encountered this issue with the BCM2835 port I placed a raw_printk in >> one of the functions that initially handles the interrupt to see if it >> was being ack'd. >> > >> > >> > 2. xenomai 3.0.5 linux 4.4.71, default dts >> > # insmod xeno_osc-gpio-rtdm.ko >> > [ 39.901907] IRQ number 142 ! >> > [ 39.905447] after request irq = 142 >> > >> > When first interrupt occurs: >> > [ 322.104560] irq 142, desc: df15e500, depth: 1, count: 0, unhandled: 0 >> > [ 322.111310] ->handle_irq(): c00998b4, handle_edge_irq+0x0/0x168 >> > [ 322.117606] ->irq_data.chip(): df156710, 0xdf156710 >> > [ 322.122702] ->action(): (null) >> > [ 322.126067]IRQ_NOPROBE set >> > [ 322.129252] unexpected IRQ trap at vector 8e >> > [ 322.133706] [ cut here ] >> > [ 322.138530] WARNING: CPU: 0 PID: 0 at kernel/irq/chip.c:843 >> > __ipipe_ack_bad_irq+0x24/0x3c() >> > [ 322.147244] Modules linked in: xeno_osc_gpio_rtdm(O) >> > [ 322.152444] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O >> > 4.4.71-ipipe #1 >> > [ 322.160434] Hardware name: Generic AM33XX (Flattened Device Tree) >> > [ 322.166791] I-pipe domain: Linux >> > [ 322.170175] [] (unwind_backtrace) from [] >> > (show_stack+0x10/0x14) >> > [ 322.178273] [] (show_stack) from [] >> > (dump_stack+0x9c/0xc4) >> > [ 322.185829] [] (dump_stack) from [] >> > (warn_slowpath_common+0x78/0xb4) >> > [ 322.194280] [] (warn_slowpath_common) from [] >> > (warn_slowpath_null+0x1c/0x24) >> > [ 322.203455] [] (warn_slowpath_null) from [] >> > (__ipipe_ack_bad_irq+0x24/0x3c) >> > [ 322.212542] [] (__ipipe_ack_bad_irq) from [] >> > (__ipipe_dispatch_irq+0x78/0x1d8) >> > [ 322.221903] [] (__ipipe_dispatch_irq) from [] >> > (omap_gpio_irq_handler+0x134/0x1a4) >> > [ 322.231532] [] (omap_gpio_irq_handler) from [] >> > (handle_irq_event_percpu+0xa4/0x304) >> > [ 322.241341] [] (handle_irq_event_percpu) from >> > [] (handle_irq_event+0x38/0x5c) >> > [ 322.250605] [] (handle_irq_event) from [] >> > (handle_level_irq+0x88/0xe4) >> > [ 322.259235] [] (handle_level_irq) from [] >> > (generic_handle_irq+0x20/0x34) >> > [ 322.268045] [] (generic_handle_irq) from [] >> > (__handle_domain_irq+0x64/0xd4) >> > [ 322.277127] [] (__handle_domain_irq) from [] >> > (__ipipe_do_sync_stage+0x21c/0x25c) >> > [ 322.286665] [] (__ipipe_do_sync_stage) from [] >> > (__ipipe_grab_irq+0x5c/0x7c) >> > [ 322.295753] [] (__ipipe_grab_irq) from [] >> > (__irq_svc+0x54/0x60) >> > [ 322.303745] Exception stack(0xc0937f58 to 0xc0937fa0) >> > [ 322.309017] 7f40: >> > df91d240 >> > [ 322.317556] 7f60: c092e240 c0938a24 >> > c09f4c3c c09389c4 0001 >> > [ 322.326095] 7f80: c064d88c c0937fa8 c0080f04 >> > c00df35c 6013 >> > [ 322.334634] [] (__irq_svc) from [] >> > (ipipe_unstall_root+0x38/0x50) >> > [ 322.342822] [] (ipipe_unstall_root) from [] >> > (cpu_startup_entry+0x68/0x2b8) >> > [ 322.351826] [] (cpu_startup_entry) from [] >> > (start_kernel+0x370/0x3e8) >> > [ 322.360361] ---[ end trace 3de49b4cee31ba0b ]--- >> > >> > When other interrupts occur: >> > [ 322.365188] irq 142, desc: df15e500, depth: 1, count: 0, unhandled: 0 >> > [ 322.371908] ->handle_irq(): c00998b4, handle_edge_irq+0x0/0x168 >> > [ 322.378183] ->irq_data.chip(): df156710, 0xdf156710 >> > [ 322.383277] ->action(): (null) >> > [ 322.386641]IRQ_NOPROBE set >> > [ 322.389825] unexpected IRQ trap at vector 8e >> > [ 324.664939] irq 142, desc: df15e500, depth: 1, count: 0, unhandled: 0 >> > [ 324.671684] ->handle_irq(): c00998b4,
Re: system freeze - beaglebone black xenomai - gpio interrupts driver
Hi,
On Thu, Jan 23, 2020 at 9:21 AM Laurentiu-Cristian Duca via Xenomai
wrote:
>
> Hello xenomai community,
>
> I have successfully tested in xenomai SPI with interrupts on bbb.
> However, on bbb, if I try to test a basic gpio interrupts driver,
> problems appear.
> Please see details below. I appreciate any idea.
>
> 1. xenomai-3 master linux 4.19.82, default dts
> # insmod xeno_osc-gpio-rtdm.ko
> [ 105.582245] IRQ number 62 !
> [ 105.585976] after request irq = 62
> System freeze when first interrupt occurs and I must power off.
Is it possible to use raw_printk and see if the system is still
working but possibly getting flooded by interrupts? When I
encountered this issue with the BCM2835 port I placed a raw_printk in
one of the functions that initially handles the interrupt to see if it
was being ack'd.
>
>
> 2. xenomai 3.0.5 linux 4.4.71, default dts
> # insmod xeno_osc-gpio-rtdm.ko
> [ 39.901907] IRQ number 142 !
> [ 39.905447] after request irq = 142
>
> When first interrupt occurs:
> [ 322.104560] irq 142, desc: df15e500, depth: 1, count: 0, unhandled: 0
> [ 322.111310] ->handle_irq(): c00998b4, handle_edge_irq+0x0/0x168
> [ 322.117606] ->irq_data.chip(): df156710, 0xdf156710
> [ 322.122702] ->action(): (null)
> [ 322.126067]IRQ_NOPROBE set
> [ 322.129252] unexpected IRQ trap at vector 8e
> [ 322.133706] [ cut here ]
> [ 322.138530] WARNING: CPU: 0 PID: 0 at kernel/irq/chip.c:843
> __ipipe_ack_bad_irq+0x24/0x3c()
> [ 322.147244] Modules linked in: xeno_osc_gpio_rtdm(O)
> [ 322.152444] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O
> 4.4.71-ipipe #1
> [ 322.160434] Hardware name: Generic AM33XX (Flattened Device Tree)
> [ 322.166791] I-pipe domain: Linux
> [ 322.170175] [] (unwind_backtrace) from []
> (show_stack+0x10/0x14)
> [ 322.178273] [] (show_stack) from []
> (dump_stack+0x9c/0xc4)
> [ 322.185829] [] (dump_stack) from []
> (warn_slowpath_common+0x78/0xb4)
> [ 322.194280] [] (warn_slowpath_common) from []
> (warn_slowpath_null+0x1c/0x24)
> [ 322.203455] [] (warn_slowpath_null) from []
> (__ipipe_ack_bad_irq+0x24/0x3c)
> [ 322.212542] [] (__ipipe_ack_bad_irq) from []
> (__ipipe_dispatch_irq+0x78/0x1d8)
> [ 322.221903] [] (__ipipe_dispatch_irq) from []
> (omap_gpio_irq_handler+0x134/0x1a4)
> [ 322.231532] [] (omap_gpio_irq_handler) from []
> (handle_irq_event_percpu+0xa4/0x304)
> [ 322.241341] [] (handle_irq_event_percpu) from
> [] (handle_irq_event+0x38/0x5c)
> [ 322.250605] [] (handle_irq_event) from []
> (handle_level_irq+0x88/0xe4)
> [ 322.259235] [] (handle_level_irq) from []
> (generic_handle_irq+0x20/0x34)
> [ 322.268045] [] (generic_handle_irq) from []
> (__handle_domain_irq+0x64/0xd4)
> [ 322.277127] [] (__handle_domain_irq) from []
> (__ipipe_do_sync_stage+0x21c/0x25c)
> [ 322.286665] [] (__ipipe_do_sync_stage) from []
> (__ipipe_grab_irq+0x5c/0x7c)
> [ 322.295753] [] (__ipipe_grab_irq) from []
> (__irq_svc+0x54/0x60)
> [ 322.303745] Exception stack(0xc0937f58 to 0xc0937fa0)
> [ 322.309017] 7f40:
> df91d240
> [ 322.317556] 7f60: c092e240 c0938a24
> c09f4c3c c09389c4 0001
> [ 322.326095] 7f80: c064d88c c0937fa8 c0080f04
> c00df35c 6013
> [ 322.334634] [] (__irq_svc) from []
> (ipipe_unstall_root+0x38/0x50)
> [ 322.342822] [] (ipipe_unstall_root) from []
> (cpu_startup_entry+0x68/0x2b8)
> [ 322.351826] [] (cpu_startup_entry) from []
> (start_kernel+0x370/0x3e8)
> [ 322.360361] ---[ end trace 3de49b4cee31ba0b ]---
>
> When other interrupts occur:
> [ 322.365188] irq 142, desc: df15e500, depth: 1, count: 0, unhandled: 0
> [ 322.371908] ->handle_irq(): c00998b4, handle_edge_irq+0x0/0x168
> [ 322.378183] ->irq_data.chip(): df156710, 0xdf156710
> [ 322.383277] ->action(): (null)
> [ 322.386641]IRQ_NOPROBE set
> [ 322.389825] unexpected IRQ trap at vector 8e
> [ 324.664939] irq 142, desc: df15e500, depth: 1, count: 0, unhandled: 0
> [ 324.671684] ->handle_irq(): c00998b4, handle_edge_irq+0x0/0x168
> [ 324.677980] ->irq_data.chip(): df156710, 0xdf156710
> [ 324.683077] ->action(): (null)
> [ 324.686442]IRQ_NOPROBE set
> ...
>
>
>
> 3. Source code of the basic gpio interrupt driver:
>
> #include
> #include
> #include
> #include
>
> #include
>
>
> static unsigned int irq_num;
> // bbb gpios that work on PREEMPT_RT linux 4.19.59 and 5.4.5 with default dts
> static unsigned int gpio_out = 48;
> static unsigned int gpio_in = 115;
> static bool value = false;
> static rtdm_irq_t irq_handle;
> static int num_of_intr = 0;
>
>
> static int gpio_irq_handler(rtdm_irq_t * irq)
> {
> value = !value;
> gpio_set_value(gpio_out, value); // toggle the led everytime irq
> handler is invoked
> trace_printk("GPIO interrupt \n");
> num_of_intr++;
> return RTDM_IRQ_HANDLED;
> }
>
>
> static int __init rtdm_init (void)
> {
> int err;
>
> if ((err = gpio_request(gpio_in, THIS_MODULE->name)) != 0) {
Re: system freeze - beaglebone black xenomai - gpio interrupts driver
I forgot to mention that on xenomai 3.0.5 linux 4.4.71 with default dts,
although warnings appear, the driver works
but in xenomai-3 master linux 4.19.82 with default dts got system freeze.
On 1/23/20, Laurentiu-Cristian Duca wrote:
> Hello xenomai community,
>
> I have successfully tested in xenomai SPI with interrupts on bbb.
> However, on bbb, if I try to test a basic gpio interrupts driver,
> problems appear.
> Please see details below. I appreciate any idea.
>
> 1. xenomai-3 master linux 4.19.82, default dts
> # insmod xeno_osc-gpio-rtdm.ko
> [ 105.582245] IRQ number 62 !
> [ 105.585976] after request irq = 62
> System freeze when first interrupt occurs and I must power off.
>
>
> 2. xenomai 3.0.5 linux 4.4.71, default dts
> # insmod xeno_osc-gpio-rtdm.ko
> [ 39.901907] IRQ number 142 !
> [ 39.905447] after request irq = 142
>
> When first interrupt occurs:
> [ 322.104560] irq 142, desc: df15e500, depth: 1, count: 0, unhandled: 0
> [ 322.111310] ->handle_irq(): c00998b4, handle_edge_irq+0x0/0x168
> [ 322.117606] ->irq_data.chip(): df156710, 0xdf156710
> [ 322.122702] ->action(): (null)
> [ 322.126067]IRQ_NOPROBE set
> [ 322.129252] unexpected IRQ trap at vector 8e
> [ 322.133706] [ cut here ]
> [ 322.138530] WARNING: CPU: 0 PID: 0 at kernel/irq/chip.c:843
> __ipipe_ack_bad_irq+0x24/0x3c()
> [ 322.147244] Modules linked in: xeno_osc_gpio_rtdm(O)
> [ 322.152444] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O
> 4.4.71-ipipe #1
> [ 322.160434] Hardware name: Generic AM33XX (Flattened Device Tree)
> [ 322.166791] I-pipe domain: Linux
> [ 322.170175] [] (unwind_backtrace) from []
> (show_stack+0x10/0x14)
> [ 322.178273] [] (show_stack) from []
> (dump_stack+0x9c/0xc4)
> [ 322.185829] [] (dump_stack) from []
> (warn_slowpath_common+0x78/0xb4)
> [ 322.194280] [] (warn_slowpath_common) from []
> (warn_slowpath_null+0x1c/0x24)
> [ 322.203455] [] (warn_slowpath_null) from []
> (__ipipe_ack_bad_irq+0x24/0x3c)
> [ 322.212542] [] (__ipipe_ack_bad_irq) from []
> (__ipipe_dispatch_irq+0x78/0x1d8)
> [ 322.221903] [] (__ipipe_dispatch_irq) from []
> (omap_gpio_irq_handler+0x134/0x1a4)
> [ 322.231532] [] (omap_gpio_irq_handler) from []
> (handle_irq_event_percpu+0xa4/0x304)
> [ 322.241341] [] (handle_irq_event_percpu) from
> [] (handle_irq_event+0x38/0x5c)
> [ 322.250605] [] (handle_irq_event) from []
> (handle_level_irq+0x88/0xe4)
> [ 322.259235] [] (handle_level_irq) from []
> (generic_handle_irq+0x20/0x34)
> [ 322.268045] [] (generic_handle_irq) from []
> (__handle_domain_irq+0x64/0xd4)
> [ 322.277127] [] (__handle_domain_irq) from []
> (__ipipe_do_sync_stage+0x21c/0x25c)
> [ 322.286665] [] (__ipipe_do_sync_stage) from []
> (__ipipe_grab_irq+0x5c/0x7c)
> [ 322.295753] [] (__ipipe_grab_irq) from []
> (__irq_svc+0x54/0x60)
> [ 322.303745] Exception stack(0xc0937f58 to 0xc0937fa0)
> [ 322.309017] 7f40:
> df91d240
> [ 322.317556] 7f60: c092e240 c0938a24
> c09f4c3c c09389c4 0001
> [ 322.326095] 7f80: c064d88c c0937fa8 c0080f04
> c00df35c 6013
> [ 322.334634] [] (__irq_svc) from []
> (ipipe_unstall_root+0x38/0x50)
> [ 322.342822] [] (ipipe_unstall_root) from []
> (cpu_startup_entry+0x68/0x2b8)
> [ 322.351826] [] (cpu_startup_entry) from []
> (start_kernel+0x370/0x3e8)
> [ 322.360361] ---[ end trace 3de49b4cee31ba0b ]---
>
> When other interrupts occur:
> [ 322.365188] irq 142, desc: df15e500, depth: 1, count: 0, unhandled: 0
> [ 322.371908] ->handle_irq(): c00998b4, handle_edge_irq+0x0/0x168
> [ 322.378183] ->irq_data.chip(): df156710, 0xdf156710
> [ 322.383277] ->action(): (null)
> [ 322.386641]IRQ_NOPROBE set
> [ 322.389825] unexpected IRQ trap at vector 8e
> [ 324.664939] irq 142, desc: df15e500, depth: 1, count: 0, unhandled: 0
> [ 324.671684] ->handle_irq(): c00998b4, handle_edge_irq+0x0/0x168
> [ 324.677980] ->irq_data.chip(): df156710, 0xdf156710
> [ 324.683077] ->action(): (null)
> [ 324.686442]IRQ_NOPROBE set
> ...
>
>
>
> 3. Source code of the basic gpio interrupt driver:
>
> #include
> #include
> #include
> #include
>
> #include
>
>
> static unsigned int irq_num;
> // bbb gpios that work on PREEMPT_RT linux 4.19.59 and 5.4.5 with default
> dts
> static unsigned int gpio_out = 48;
> static unsigned int gpio_in = 115;
> static bool value = false;
> static rtdm_irq_t irq_handle;
> static int num_of_intr = 0;
>
>
> static int gpio_irq_handler(rtdm_irq_t * irq)
> {
> value = !value;
> gpio_set_value(gpio_out, value); // toggle the led everytime irq
> handler is invoked
> trace_printk("GPIO interrupt \n");
> num_of_intr++;
> return RTDM_IRQ_HANDLED;
> }
>
>
> static int __init rtdm_init (void)
> {
> int err;
>
> if ((err = gpio_request(gpio_in, THIS_MODULE->name)) != 0) {
> printk(" gpio_request gpio_in failed ! \n");
> return err;
> }
>
> if ((err =
system freeze - beaglebone black xenomai - gpio interrupts driver
Hello xenomai community,
I have successfully tested in xenomai SPI with interrupts on bbb.
However, on bbb, if I try to test a basic gpio interrupts driver,
problems appear.
Please see details below. I appreciate any idea.
1. xenomai-3 master linux 4.19.82, default dts
# insmod xeno_osc-gpio-rtdm.ko
[ 105.582245] IRQ number 62 !
[ 105.585976] after request irq = 62
System freeze when first interrupt occurs and I must power off.
2. xenomai 3.0.5 linux 4.4.71, default dts
# insmod xeno_osc-gpio-rtdm.ko
[ 39.901907] IRQ number 142 !
[ 39.905447] after request irq = 142
When first interrupt occurs:
[ 322.104560] irq 142, desc: df15e500, depth: 1, count: 0, unhandled: 0
[ 322.111310] ->handle_irq(): c00998b4, handle_edge_irq+0x0/0x168
[ 322.117606] ->irq_data.chip(): df156710, 0xdf156710
[ 322.122702] ->action(): (null)
[ 322.126067]IRQ_NOPROBE set
[ 322.129252] unexpected IRQ trap at vector 8e
[ 322.133706] [ cut here ]
[ 322.138530] WARNING: CPU: 0 PID: 0 at kernel/irq/chip.c:843
__ipipe_ack_bad_irq+0x24/0x3c()
[ 322.147244] Modules linked in: xeno_osc_gpio_rtdm(O)
[ 322.152444] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O
4.4.71-ipipe #1
[ 322.160434] Hardware name: Generic AM33XX (Flattened Device Tree)
[ 322.166791] I-pipe domain: Linux
[ 322.170175] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[ 322.178273] [] (show_stack) from []
(dump_stack+0x9c/0xc4)
[ 322.185829] [] (dump_stack) from []
(warn_slowpath_common+0x78/0xb4)
[ 322.194280] [] (warn_slowpath_common) from []
(warn_slowpath_null+0x1c/0x24)
[ 322.203455] [] (warn_slowpath_null) from []
(__ipipe_ack_bad_irq+0x24/0x3c)
[ 322.212542] [] (__ipipe_ack_bad_irq) from []
(__ipipe_dispatch_irq+0x78/0x1d8)
[ 322.221903] [] (__ipipe_dispatch_irq) from []
(omap_gpio_irq_handler+0x134/0x1a4)
[ 322.231532] [] (omap_gpio_irq_handler) from []
(handle_irq_event_percpu+0xa4/0x304)
[ 322.241341] [] (handle_irq_event_percpu) from
[] (handle_irq_event+0x38/0x5c)
[ 322.250605] [] (handle_irq_event) from []
(handle_level_irq+0x88/0xe4)
[ 322.259235] [] (handle_level_irq) from []
(generic_handle_irq+0x20/0x34)
[ 322.268045] [] (generic_handle_irq) from []
(__handle_domain_irq+0x64/0xd4)
[ 322.277127] [] (__handle_domain_irq) from []
(__ipipe_do_sync_stage+0x21c/0x25c)
[ 322.286665] [] (__ipipe_do_sync_stage) from []
(__ipipe_grab_irq+0x5c/0x7c)
[ 322.295753] [] (__ipipe_grab_irq) from []
(__irq_svc+0x54/0x60)
[ 322.303745] Exception stack(0xc0937f58 to 0xc0937fa0)
[ 322.309017] 7f40:
df91d240
[ 322.317556] 7f60: c092e240 c0938a24
c09f4c3c c09389c4 0001
[ 322.326095] 7f80: c064d88c c0937fa8 c0080f04
c00df35c 6013
[ 322.334634] [] (__irq_svc) from []
(ipipe_unstall_root+0x38/0x50)
[ 322.342822] [] (ipipe_unstall_root) from []
(cpu_startup_entry+0x68/0x2b8)
[ 322.351826] [] (cpu_startup_entry) from []
(start_kernel+0x370/0x3e8)
[ 322.360361] ---[ end trace 3de49b4cee31ba0b ]---
When other interrupts occur:
[ 322.365188] irq 142, desc: df15e500, depth: 1, count: 0, unhandled: 0
[ 322.371908] ->handle_irq(): c00998b4, handle_edge_irq+0x0/0x168
[ 322.378183] ->irq_data.chip(): df156710, 0xdf156710
[ 322.383277] ->action(): (null)
[ 322.386641]IRQ_NOPROBE set
[ 322.389825] unexpected IRQ trap at vector 8e
[ 324.664939] irq 142, desc: df15e500, depth: 1, count: 0, unhandled: 0
[ 324.671684] ->handle_irq(): c00998b4, handle_edge_irq+0x0/0x168
[ 324.677980] ->irq_data.chip(): df156710, 0xdf156710
[ 324.683077] ->action(): (null)
[ 324.686442]IRQ_NOPROBE set
...
3. Source code of the basic gpio interrupt driver:
#include
#include
#include
#include
#include
static unsigned int irq_num;
// bbb gpios that work on PREEMPT_RT linux 4.19.59 and 5.4.5 with default dts
static unsigned int gpio_out = 48;
static unsigned int gpio_in = 115;
static bool value = false;
static rtdm_irq_t irq_handle;
static int num_of_intr = 0;
static int gpio_irq_handler(rtdm_irq_t * irq)
{
value = !value;
gpio_set_value(gpio_out, value); // toggle the led everytime irq
handler is invoked
trace_printk("GPIO interrupt \n");
num_of_intr++;
return RTDM_IRQ_HANDLED;
}
static int __init rtdm_init (void)
{
int err;
if ((err = gpio_request(gpio_in, THIS_MODULE->name)) != 0) {
printk(" gpio_request gpio_in failed ! \n");
return err;
}
if ((err = gpio_direction_input(gpio_in)) != 0) {
printk(" gpio_direction_input gpio_in failed ! \n");
gpio_free(gpio_in);
return err;
}
irq_num = gpio_to_irq(gpio_in);
printk(" IRQ number %d ! \n",irq_num);
if ((err = gpio_request(gpio_out, THIS_MODULE->name)) != 0) {
printk(" gpio_request gpio_out failed ! \n");
gpio_free(gpio_in);
return err;
}
if ((err = gpio_direction_output(gpio_out, 0)) != 0) {
printk("
