Hi Thomas,
> On Wed, Oct 28, 2020 at 12:58:41PM +0100, Thomas Gleixner wrote:
>
...
> Something like the completly untested below should work independent of
> config options.
>
> Thanks,
>
> tglx
> ---
> include/linux/irqdesc.h |4 ++
> kernel/irq/manage.c |3 +
>
On Wed, Oct 28, 2020 at 7:58 PM Thomas Gleixner wrote:
>
[...]
> ---
> include/linux/irqdesc.h |4 ++
> kernel/irq/manage.c |3 +
> kernel/irq/spurious.c | 74
> +++-
> 3 files changed, 61 insertions(+), 20 deletions(-)
>
> ---
On Wed, Oct 28, 2020 at 12:58:41PM +0100, Thomas Gleixner wrote:
> On Wed, Oct 28 2020 at 14:02, Pingfan Liu wrote:
> > On Tue, Oct 27, 2020 at 3:59 AM Thomas Gleixner wrote:
> >> Also Liu's patch only works if:
> >>
> >> 1) CONFIG_IRQ_TIME_ACCOUNTING is enabled
> >
> > I wonder whether it can
On Tue, Oct 27, 2020 at 3:59 AM Thomas Gleixner wrote:
>
[...]
>
> And contrary to Liu's patches which try to disable a requested interrupt
> if too many of them arrive, the kernel cannot do anything because there
> is nothing to disable in your case. That's why you needed to do the MSI
> disable
On Wed, Oct 28 2020 at 14:02, Pingfan Liu wrote:
> On Tue, Oct 27, 2020 at 3:59 AM Thomas Gleixner wrote:
>> Also Liu's patch only works if:
>>
>> 1) CONFIG_IRQ_TIME_ACCOUNTING is enabled
>
> I wonder whether it can not be a default option or not by the following
> method:
>
On Mon, Oct 26, 2020 at 6:21 PM Thomas Gleixner wrote:
> [...]
> > So, I don't want to hijack Liu's thread, but do you think it makes
> > sense to have my approach as a (debug) parameter to prevent such a
> > degenerate case?
>
> At least it makes sense to some extent even if it's incomplete.
On Mon, Oct 26 2020 at 17:28, Guilherme Piccoli wrote:
> On Mon, Oct 26, 2020 at 4:59 PM Thomas Gleixner wrote:
>> It gets flooded right at the point where the crash kernel enables
>> interrupts in start_kernel(). At that point there is no device driver
>> and no interupt requested. All you can
On Mon, Oct 26, 2020 at 4:59 PM Thomas Gleixner wrote:
>
> On Mon, Oct 26 2020 at 12:06, Guilherme Piccoli wrote:
> > On Sun, Oct 25, 2020 at 8:12 AM Pingfan Liu wrote:
> >
> > Some time ago (2 years) we faced a similar issue in x86-64, a hard to
> > debug problem in kdump, that eventually was
On Mon, Oct 26 2020 at 12:06, Guilherme Piccoli wrote:
> On Sun, Oct 25, 2020 at 8:12 AM Pingfan Liu wrote:
>
> Some time ago (2 years) we faced a similar issue in x86-64, a hard to
> debug problem in kdump, that eventually was narrowed to a buggy NIC FW
> flooding IRQs in kdump kernel, and no
On Sun, Oct 25, 2020 at 8:12 AM Pingfan Liu wrote:
>
> On Thu, Oct 22, 2020 at 4:37 PM Thomas Gleixner wrote:
> >
> > On Thu, Oct 22 2020 at 13:56, Pingfan Liu wrote:
> > > I hit a irqflood bug on powerpc platform, and two years ago, on a x86
> > > platform.
> > > When the bug happens, the
On Mon, Oct 26, 2020 at 12:11 AM Pingfan Liu wrote:
>
> On Sun, Oct 25, 2020 at 8:21 PM Oliver O'Halloran wrote:
> >
> > On Sun, Oct 25, 2020 at 10:22 PM Pingfan Liu wrote:
> > >
> > > On Thu, Oct 22, 2020 at 4:37 PM Thomas Gleixner
> > > wrote:
> > > >
> > > > On Thu, Oct 22 2020 at 13:56,
On Sun, Oct 25, 2020 at 8:21 PM Oliver O'Halloran wrote:
>
> On Sun, Oct 25, 2020 at 10:22 PM Pingfan Liu wrote:
> >
> > On Thu, Oct 22, 2020 at 4:37 PM Thomas Gleixner wrote:
> > >
> > > On Thu, Oct 22 2020 at 13:56, Pingfan Liu wrote:
> > > > I hit a irqflood bug on powerpc platform, and two
On Sun, Oct 25, 2020 at 10:22 PM Pingfan Liu wrote:
>
> On Thu, Oct 22, 2020 at 4:37 PM Thomas Gleixner wrote:
> >
> > On Thu, Oct 22 2020 at 13:56, Pingfan Liu wrote:
> > > I hit a irqflood bug on powerpc platform, and two years ago, on a x86
> > > platform.
> > > When the bug happens, the
On Thu, Oct 22, 2020 at 4:37 PM Thomas Gleixner wrote:
>
> On Thu, Oct 22 2020 at 13:56, Pingfan Liu wrote:
> > I hit a irqflood bug on powerpc platform, and two years ago, on a x86
> > platform.
> > When the bug happens, the kernel is totally occupies by irq. Currently,
> > there
> > may be
On Thu, Oct 22 2020 at 13:56, Pingfan Liu wrote:
> I hit a irqflood bug on powerpc platform, and two years ago, on a x86
> platform.
> When the bug happens, the kernel is totally occupies by irq. Currently, there
> may be nothing or just soft lockup warning showed in console. It is better
> to
I hit a irqflood bug on powerpc platform, and two years ago, on a x86 platform.
When the bug happens, the kernel is totally occupies by irq. Currently, there
may be nothing or just soft lockup warning showed in console. It is better
to warn users with irq flood info.
In the kdump case, the
16 matches
Mail list logo