Chained vs. shared EtherNEC interrupts - was: Re: [SOLVED] Re: ARAnyM VMs with Debian hanging at 100% CPU usage

Chained vs. shared EtherNEC interrupts - was: Re: [SOLVED] Re: ARAnyM VMs with Debian hanging at 100% CPU usage

[Michael Schmitz]

Thorsten, Geert:

>>> I hear you - and I am still working on sanitizing the driver's
>>> interrupt use.
>>>
>>
>>
>> Oh, sounds like fun. Good luck! (ragnar76 is the one in need of
>> such drivers, he'd probably help testing, too.)
>>
>>
>
> Looks like I may have something working that will require a minimum of
> changes to the ne.c driver -
> need to run a few last tests though.

Looks like it sort of works - but now I'm stuck at the very same point
that got me
to playing tricks with shared interrupts in the first place: the
interrupt watchdog
kicks in and disables the eip_interrupt handler.

The good news: sharing the timer interrupt with other devices (USB
function on NetUSBee) is trival.

And the EtherNEC still functions even after its interrupts have been
disabled - how that works is a
bit of a mystery to me, but who am I to argue with serendipity?
Latency mushrooms to 50ms, and
data rate drops from 70k/sec to 20k/sec but it's still alive.

Geert - can we do anything other than using noirqdebug = 1 to ensure
this doesn't impact on network
performance?

Cheers,

  Michael

Re: Chained vs. shared EtherNEC interrupts - was: Re: [SOLVED] Re: ARAnyM VMs with Debian hanging at 100% CPU usage

[Geert Uytterhoeven]

Hi Michael,

On Mon, Jul 30, 2012 at 1:09 AM, Michael Schmitz <schmitzmic@gmail.com> wrote:
> Looks like it sort of works - but now I'm stuck at the very same point
> that got me
> to playing tricks with shared interrupts in the first place: the
> interrupt watchdog
> kicks in and disables the eip_interrupt handler.

Oops...

> The good news: sharing the timer interrupt with other devices (USB
> function on NetUSBee) is trival.
>
> And the EtherNEC still functions even after its interrupts have been
> disabled - how that works is a
> bit of a mystery to me, but who am I to argue with serendipity?
> Latency mushrooms to 50ms, and
> data rate drops from 70k/sec to 20k/sec but it's still alive.

My initial guess was that the transmit code also checks for received
packets somewhere, but I can't seem to find this in the code. Oh well...

> Geert - can we do anything other than using noirqdebug = 1 to ensure
> this doesn't impact on network
> performance?

Hmm, so we do need IRQF_SHARED inside an #ifdef.
If we can't convince Paul, that'll mean another 8390 driver. Sigh...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Chained vs. shared EtherNEC interrupts - was: Re: [SOLVED] Re: ARAnyM VMs with Debian hanging at 100% CPU usage

[Michael Schmitz]

Hi Geert,

>> Looks like it sort of works - but now I'm stuck at the very same point
>> that got me
>> to playing tricks with shared interrupts in the first place: the
>> interrupt watchdog
>> kicks in and disables the eip_interrupt handler.
>
> Oops...

Indeed :-)


>> The good news: sharing the timer interrupt with other devices (USB
>> function on NetUSBee) is trival.
>>
>> And the EtherNEC still functions even after its interrupts have been
>> disabled - how that works is a
>> bit of a mystery to me, but who am I to argue with serendipity?
>> Latency mushrooms to 50ms, and
>> data rate drops from 70k/sec to 20k/sec but it's still alive.
>
> My initial guess was that the transmit code also checks for received
> packets somewhere, but I can't seem to find this in the code. Oh well...

Possible ... but I don't think it's all that important really.

>> Geert - can we do anything other than using noirqdebug = 1 to ensure
>> this doesn't impact on network
>> performance?
>
> Hmm, so we do need IRQF_SHARED inside an #ifdef.
> If we can't convince Paul, that'll mean another 8390 driver. Sigh...

No, if we cant't convince Paul we have to make sure irqdebug is not
used, disabled in the config or explicitly vetoed by the m68k arch
setup code (call the noirqdebug kernel option parser from
atari/config,c). Best would be to have a IRQF_BORKED flag to tell the
irqdebug code not to worry about unserviced interrupts.

Any chance to get this sort of stuff accepted by Linus?

(Kidding - I'd settle for a note in the docs to disable IRQ debugging.
In use for a few weeks on my Falcon, with no adverse effects).

I still need to separate the USB driver stuff out of my chained
interrupt patch, and possibly clean up checkpatch violations. Should
be done with that by this weekend. How long until the current merge
window closes?

Cheers,

  Michael

Re: Chained vs. shared EtherNEC interrupts - was: Re: [SOLVED] Re: ARAnyM VMs with Debian hanging at 100% CPU usage

[Geert Uytterhoeven]

On Thu, Aug 9, 2012 at 2:21 AM, Michael Schmitz <schmitzmic@gmail.com> wrote:
> I still need to separate the USB driver stuff out of my chained
> interrupt patch, and possibly clean up checkpatch violations. Should
> be done with that by this weekend. How long until the current merge
> window closes?

There's no "current" merge window, as v3.6-rc1 was released almost one week
ago...
Expect the next merge window (for 3.7) to open around September 20.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Chained vs. shared EtherNEC interrupts - was: Re: [SOLVED] Re: ARAnyM VMs with Debian hanging at 100% CPU usage

[Michael Schmitz]

Geert,
> On Thu, Aug 9, 2012 at 2:21 AM, Michael Schmitz <schmitzmic@gmail.com> wrote:
>> I still need to separate the USB driver stuff out of my chained
>> interrupt patch, and possibly clean up checkpatch violations. Should
>> be done with that by this weekend. How long until the current merge
>> window closes?
> There's no "current" merge window, as v3.6-rc1 was released almost one week
> ago...
> Expect the next merge window (for 3.7) to open around September 20.
Should be enough time for me to miss ... eh, meet that one.

Cheers,

   Michael