Hey everyone,
So it looks like this was a red herring. We were getting spurious
interrupts which I suspect caused the console code to get called in
some critical section. Once we fixed the spurious interrupts we no
longer see the issue. Sorry for the noise.
Thanks,
Raul
On Thu, Jul 9, 2020 at 7:2
On (20/07/08 11:52), Petr Mladek wrote:
>
> I still believe that this is a false positive.
I've no problems with that. The thing that I'm trying to improve here is the
fact that from lockdep's point of view there are no false positives. lockdep
reports the problem and then waves good bye. It disa
On Wed 2020-07-08 17:07:12, Sergey Senozhatsky wrote:
> On (20/07/08 09:40), Kurt Kanzenbach wrote:
> > I'm not sure how this patch will help with the situation. Because at the
> > point of that THRE test the irq handler isn't registered. It's
> > registered a few lines below (up->ops->setup_irq())
On (20/07/08 09:40), Kurt Kanzenbach wrote:
> I'm not sure how this patch will help with the situation. Because at the
> point of that THRE test the irq handler isn't registered. It's
> registered a few lines below (up->ops->setup_irq()) meaning the irq line
> has to be disabled if shared. Otherwis
On Mon Jul 06 2020, Sergey Senozhatsky wrote:
> On (20/07/06 13:31), Kurt Kanzenbach wrote:
>> >> @@ -2275,6 +2275,7 @@ int serial8250_do_startup(struct uart_port *port)
>> >>
>> >> if (port->irq && !(up->port.flags & UPF_NO_THRE_TEST)) {
>> >> unsigned char iir1;
>> >> +
>>
On (20/07/06 13:31), Kurt Kanzenbach wrote:
> >> @@ -2275,6 +2275,7 @@ int serial8250_do_startup(struct uart_port *port)
> >>
> >> if (port->irq && !(up->port.flags & UPF_NO_THRE_TEST)) {
> >> unsigned char iir1;
> >> +
> >> /*
> >> * Test fo
Hi,
On Sat Jul 04 2020, Andy Shevchenko wrote:
> On Fri, Jul 3, 2020 at 1:32 PM Sergey Senozhatsky
> wrote:
>>
>> On (20/07/02 09:05), Tony Lindgren wrote:
>> > * Sergey Senozhatsky [200702 05:13]:
>> > > On (20/06/30 11:02), Tony Lindgren wrote:
>> > > > This conditional disable for irq_shared
On Sat, Jul 04, 2020 at 02:35:46PM +0300, Andy Shevchenko wrote:
> On Fri, Jul 3, 2020 at 1:32 PM Sergey Senozhatsky
> wrote:
> > On (20/07/02 09:05), Tony Lindgren wrote:
> > > * Sergey Senozhatsky [200702 05:13]:
> > > > On (20/06/30 11:02), Tony Lindgren wrote:
...
> > This is, basically, an
On Fri, Jul 3, 2020 at 1:53 PM Sergey Senozhatsky
wrote:
>
> On (20/07/02 11:20), Andy Shevchenko wrote:
> >
> > I didn't look into this deeply, but my understanding that this is something
> > for
> > special case when you have several UART ports sharing the IRQ (multi-port
> > card)
> > and IRQ
On Fri, Jul 3, 2020 at 1:32 PM Sergey Senozhatsky
wrote:
>
> On (20/07/02 09:05), Tony Lindgren wrote:
> > * Sergey Senozhatsky [200702 05:13]:
> > > On (20/06/30 11:02), Tony Lindgren wrote:
> > > > This conditional disable for irq_shared does not look nice to me
> > > > from the other device po
On (20/07/02 11:20), Andy Shevchenko wrote:
>
> I didn't look into this deeply, but my understanding that this is something
> for
> special case when you have several UART ports sharing the IRQ (multi-port
> card)
> and IRQ even maybe undesirable b/c it will confuse real IRQ handler. I don't
> r
On (20/07/02 09:05), Tony Lindgren wrote:
> * Sergey Senozhatsky [200702 05:13]:
> > On (20/06/30 11:02), Tony Lindgren wrote:
> > > This conditional disable for irq_shared does not look nice to me
> > > from the other device point of view :)
> > >
> > > Would it be possible to just set up te dum
* Sergey Senozhatsky [200702 05:13]:
> On (20/06/30 11:02), Tony Lindgren wrote:
> > This conditional disable for irq_shared does not look nice to me
> > from the other device point of view :)
> >
> > Would it be possible to just set up te dummy interrupt handler
> > for the startup, then change
On Thu, Jul 02, 2020 at 02:40:33PM +0900, Sergey Senozhatsky wrote:
> On (20/07/02 14:12), Sergey Senozhatsky wrote:
> > From: Sergey Senozhatsky
> > On (20/06/30 11:02), Tony Lindgren wrote:
...
> > I think we can do it. serial8250_do_startup() and irq handler take
> > port->lock, so they shoul
A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
A: No.
Q: Should I includ
On (20/07/02 06:14), S, Shirish wrote:
> This one:
> https://lkml.org/lkml/2020/6/30/394
>
> I did reply to all, not sure what I am missing while replying.
It's not a formal patch yet. Give us some more time to figure out
how do we want to fix the problem at hand.
-ss
; Andy Shevchenko
; Raul Rangel ; Sergey
Senozhatsky ; linux-kernel
; Andy Shevchenko
; k...@linutronix.de; Peter Zijlstra
; John Ogness ; Steven Rostedt
Subject: Re: UART/TTY console deadlock
On Thu, Jul 02, 2020 at 03:48:43AM +, S, Shirish wrote:
> Hi All,
>
> Can we land t
On Thu, Jul 02, 2020 at 03:48:43AM +, S, Shirish wrote:
> Hi All,
>
> Can we land this patch upstream?
What patch?
> Feel free to add my tested-by.
Please send it in a form that I can add it, to the patch in question.
thanks,
greg k-h
man
> , Andy Shevchenko
> , k...@linutronix.de, "S, Shirish"
> , Peter Zijlstra , John Ogness
> , Steven Rostedt
> Subject: Re: UART/TTY console deadlock
> Message-ID: <20200702051213.GB3450@jagdpanzerIV.localdomain>
>
> On (20/06/30 11:02), Tony Lindgren
On (20/06/30 11:02), Tony Lindgren wrote:
> This conditional disable for irq_shared does not look nice to me
> from the other device point of view :)
>
> Would it be possible to just set up te dummy interrupt handler
> for the startup, then change it back afterwards? See for example
> omap8250_no_
Senozhatsky ; linux-kernel
; Greg Kroah-Hartman
; Andy Shevchenko
; k...@linutronix.de; S, Shirish
; Peter Zijlstra ; John Ogness
; Steven Rostedt
Subject: Re: UART/TTY console deadlock
On 6/30/2020 11:32 PM, Tony Lindgren wrote:
> * Sergey Senozhatsky [200630 13:06]:
>> On (20/06/30 14:
On 6/30/2020 11:32 PM, Tony Lindgren wrote:
* Sergey Senozhatsky [200630 13:06]:
On (20/06/30 14:22), Petr Mladek wrote:
...
@@ -2284,8 +2289,6 @@ int serial8250_do_startup(struct uart_port *port)
* allow register changes to become visible.
*/
* Sergey Senozhatsky [200630 13:06]:
> On (20/06/30 14:22), Petr Mladek wrote:
...
> > > > > @@ -2284,8 +2289,6 @@ int serial8250_do_startup(struct uart_port
> > > > > *port)
> > > > >* allow register changes to become visible.
> > > > >*/
> > > > >
On (20/06/30 14:22), Petr Mladek wrote:
> On Tue 2020-06-30 19:55:12, Sergey Senozhatsky wrote:
> > On (20/06/30 12:21), Petr Mladek wrote:
> > > Anyway, I believe that this is a false positive. If I get it correctly
> > > serial8250_do_startup() must be called before the serial port could
> > > be
On Tue 2020-06-30 19:55:12, Sergey Senozhatsky wrote:
> On (20/06/30 12:21), Petr Mladek wrote:
> > Anyway, I believe that this is a false positive. If I get it correctly
> > serial8250_do_startup() must be called before the serial port could
> > be registered as a console. It means that it could n
On Tue, Jun 30, 2020 at 07:55:12PM +0900, Sergey Senozhatsky wrote:
> On (20/06/30 12:21), Petr Mladek wrote:
...
> > I think that it might be safe but I am not 100% sure, sigh.
>
> Yeah, I'm not 100%, but I'd give it a try.
Thanks for the patch! I think we have to wait for the original reporte
On (20/06/30 12:21), Petr Mladek wrote:
> > So... Do we need to hold uart->port when we disable port->irq? What do we
> > race with? Module removal? The function bumps device PM counter (albeit
> > for UART_CAP_RPM ports only).
>
> Honestly, I do not see where a PM counter gets incremented.
seria
On Tue 2020-06-30 12:58:16, Sergey Senozhatsky wrote:
> Cc-ing more people
>
> https://lore.kernel.org/lkml/cahp75vd8ntzmzdnhptdchdc11zycasfeigbxacpowz1lv9z...@mail.gmail.com
>
> On (20/06/22 20:37), Andy Shevchenko wrote:
> > > [ 279.759811] -> #2 (&irq_desc_lock_class){-.-.}:
> > > [ 279.7598
Cc-ing more people
https://lore.kernel.org/lkml/cahp75vd8ntzmzdnhptdchdc11zycasfeigbxacpowz1lv9z...@mail.gmail.com
On (20/06/22 20:37), Andy Shevchenko wrote:
> > [ 279.759811] -> #2 (&irq_desc_lock_class){-.-.}:
> > [ 279.759813]_raw_spin_lock_irqsave+0x61/0x8d
> > [ 279.759813]
+Cc: Tony and console people
On Mon, Jun 22, 2020 at 8:32 PM Raul Rangel wrote:
>
> We are trying an S3 suspend stress test and occasionally while
> entering S3 we get a console deadlock. Is this a known issue? I'm not
> really sure why a probe would be happening while suspending.
>
> The kernel
We are trying an S3 suspend stress test and occasionally while
entering S3 we get a console deadlock. Is this a known issue? I'm not
really sure why a probe would be happening while suspending.
The kernel command line is `console=ttyS0` and kernel 5.4.39.
Here is the log:
[ 278.885831] leds mmc
31 matches
Mail list logo
