On Sat, Feb 20, 2021 at 05:32:30PM +1100, Finn Thain wrote:
> Nope. Interrupt priority masking is there to place an upper bound
> interrupt latency. That's why this feature is shipping in contemporary
> hardware (e.g. ARM GIC). If you care about real time workloads on arm64,
> that may interest
On Thu, 18 Feb 2021, Arnd Bergmann wrote:
> On Thu, Feb 18, 2021 at 6:30 AM Finn Thain wrote:
> > On Wed, 17 Feb 2021, Song Bao Hua (Barry Song) wrote:
> > > > On Sat, 13 Feb 2021, Song Bao Hua (Barry Song) wrote:
> > > >
> > > > That scenario seems a little contrived to me (drivers for two or
>
On Fri, Feb 19, 2021 at 09:10:57AM +0100, Geert Uytterhoeven wrote:
> Hi Michael,
>
> On Thu, Feb 18, 2021 at 11:11 PM Michael Schmitz wrote:
> > On 19/02/21 12:19 am, Arnd Bergmann wrote:
> > > drivers/net/ethernet/8390/apne.c
> > > drivers/net/ethernet/8390/ax88796.c
> > > drivers/net/ethernet/
Hi Michael,
On Thu, Feb 18, 2021 at 11:11 PM Michael Schmitz wrote:
> On 19/02/21 12:19 am, Arnd Bergmann wrote:
> > drivers/net/ethernet/8390/apne.c
> > drivers/net/ethernet/8390/ax88796.c
> > drivers/net/ethernet/8390/hydra.c
> > drivers/net/ethernet/8390/mac8390.c
> > drivers/net/ethernet/8390
On 19/02/21 12:19 am, Arnd Bergmann wrote:
drivers/net/ethernet/8390/apne.c
drivers/net/ethernet/8390/ax88796.c
drivers/net/ethernet/8390/hydra.c
drivers/net/ethernet/8390/mac8390.c
drivers/net/ethernet/8390/ne.c
drivers/net/ethernet/8390/zorro8390.c
[...]
Most of these are normal short-lived
Hi Arnd,
On Thu, Feb 18, 2021 at 2:59 PM Arnd Bergmann wrote:
> On Thu, Feb 18, 2021 at 1:30 PM Geert Uytterhoeven
> wrote:
> > The reason drivers/ide is doing that may be related to IDE hard drive
> > quirks. The old WD Caviar drives didn't obey disabling the IDE interrupt
> > at the drive le
On Thu, Feb 18, 2021 at 1:30 PM Geert Uytterhoeven wrote:
>
> The reason drivers/ide is doing that may be related to IDE hard drive
> quirks. The old WD Caviar drives didn't obey disabling the IDE interrupt
> at the drive level. On PC, that worked fine, as IRQs 14 and 15 weren't
> shared with ot
Hi Arnd,
On Thu, Feb 18, 2021 at 12:20 PM Arnd Bergmann wrote:
> Most of these are normal short-lived interrupts that only transfer
> a few bytes or schedule deferred processing of some sort.
> Most of the scsi and network drivers process the data in
> a softirq, so those are generally fine here,
On Thu, Feb 18, 2021 at 6:30 AM Finn Thain wrote:
> On Wed, 17 Feb 2021, Song Bao Hua (Barry Song) wrote:
> > > On Sat, 13 Feb 2021, Song Bao Hua (Barry Song) wrote:
> > >
> > > That scenario seems a little contrived to me (drivers for two or more
> > > devices sharing state through their interrup
On Wed, 17 Feb 2021, Song Bao Hua (Barry Song) wrote:
> > On Sat, 13 Feb 2021, Song Bao Hua (Barry Song) wrote:
> >
> > >
> > > So what is really confusing and a pain to me is that: For years
> > > people like me have been writing device drivers with the idea that
> > > irq handlers run with in
fun...@jurai.org; ph...@gnu.org; cor...@lwn.net; mi...@redhat.com;
> linux-m...@lists.linux-m68k.org; linux-kernel@vger.kernel.org
> Subject: RE: [RFC] IRQ handlers run with some high-priority interrupts(not
> NMI)
> enabled on some platform
>
> On Sat, 13 Feb 2021, Song Bao Hua (B
On Mon, 15 Feb 2021, Andy Shevchenko wrote:
> On Sun, Feb 14, 2021 at 7:12 AM Finn Thain wrote:
> > On Sat, 13 Feb 2021, Song Bao Hua (Barry Song) wrote:
> > > So what is really confusing and a pain to me is that:
> > > For years people like me have been writing device drivers
> > > with the idea
On Sun, Feb 14, 2021 at 7:12 AM Finn Thain wrote:
> On Sat, 13 Feb 2021, Song Bao Hua (Barry Song) wrote:
> > So what is really confusing and a pain to me is that:
> > For years people like me have been writing device drivers
> > with the idea that irq handlers run with interrupts
> > disabled aft
On Sat, 13 Feb 2021, Song Bao Hua (Barry Song) wrote:
>
> So what is really confusing and a pain to me is that:
> For years people like me have been writing device drivers
> with the idea that irq handlers run with interrupts
> disabled after those commits in genirq. So I don't need
> to care abo
t;
> mi...@redhat.com; linux-m...@lists.linux-m68k.org;
> fth...@telegraphics.com.au; linux-kernel@vger.kernel.org
> Subject: RE: [RFC] IRQ handlers run with some high-priority interrupts(not
> NMI)
> enabled on some platform
>
>
>
> > -Original Message-
rg; cor...@lwn.net;
> mi...@redhat.com; linux-m...@lists.linux-m68k.org;
> fth...@telegraphics.com.au; linux-kernel@vger.kernel.org
> Subject: Re: [RFC] IRQ handlers run with some high-priority interrupts(not
> NMI)
> enabled on some platform
>
> On Sat, Feb 13, 2021 at 12:5
On Sat, Feb 13, 2021 at 12:50 AM Song Bao Hua (Barry Song)
wrote:
> So I was actually trying to warn this unusual case - interrupts
> get nested while both in_hardirq() and irqs_disabled() are true.
>
> diff --git a/include/linux/hardirq.h b/include/linux/hardirq.h
> index 7c9d6a2d7e90..b8ca27555
rg; cor...@lwn.net;
> mi...@redhat.com; linux-m...@lists.linux-m68k.org;
> fth...@telegraphics.com.au; linux-kernel@vger.kernel.org
> Subject: Re: [RFC] IRQ handlers run with some high-priority interrupts(not
> NMI)
> enabled on some platform
>
> On Sat, Feb 13, 2021 at 12:0
xfoundation.org; a...@arndb.de;
> > ge...@linux-m68k.org; fun...@jurai.org; ph...@gnu.org; cor...@lwn.net;
> > mi...@redhat.com; linux-m...@lists.linux-m68k.org;
> > fth...@telegraphics.com.au; linux-kernel@vger.kernel.org
> > Subject: Re: [RFC] IRQ handlers run with some
rg; cor...@lwn.net;
> mi...@redhat.com; linux-m...@lists.linux-m68k.org;
> fth...@telegraphics.com.au; linux-kernel@vger.kernel.org
> Subject: Re: [RFC] IRQ handlers run with some high-priority interrupts(not
> NMI)
> enabled on some platform
>
> On Fri, Feb 12, 2021 at 2:1
On Fri, Feb 12, 2021 at 2:18 AM Song Bao Hua (Barry Song)
wrote:
> So I am requesting comments on:
> 1. are we expecting all interrupts except NMI to be disabled in irq handler,
> or do we actually allow some high-priority interrupts between low and NMI to
> come in some platforms?
I tried to co
21 matches
Mail list logo
