All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Skeggs <bskeggs@redhat.com>
To: Andrew Lutomirski <luto@mit.edu>
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/2] Fix nouveau-related freezes
Date: Wed, 17 Nov 2010 09:09:57 +1000	[thread overview]
Message-ID: <1289948997.2311.16.camel@nisroch> (raw)
In-Reply-To: <AANLkTimM6EUeFiyaH=6bkes19LtYO6t1PJL_SE9Zt3-L@mail.gmail.com>

On Tue, 2010-11-16 at 17:19 -0500, Andrew Lutomirski wrote:
> On Wed, Nov 10, 2010 at 6:04 PM, Andy Lutomirski <luto@mit.edu> wrote:
> > Nouveau takes down my system quite reliably when any hotplug event occurs.
> > The bug happens because the IRQ handler didn't acknowledge the hotplug
> > state until the bottom half, so the card generated a new interrupt
> > immediately, starving the bottom half and permanently starving that CPU
> > (and hence the bottom half).
> >
> > Even with this fix, a lot of the IRQ code looks rather broken.
> >
> > This is tested on 2.6.36 (and makes the system stable for me), but it also
> > applies cleanly to 2.6.37 (untested, but surely also necessary).  Fedora 14's
> > 2.6.35 kernels seem to have to same problem for me, so I suspect that 2.6.35
> > needs this fix as well.  (All of my tests are on an NV50 card.)
> >
> > Changes from v1:
> >  - Ignore unrequested hotplug bits (I accidentally removed that part).
> >  - Support newer hardware (untested -- Ben, can you check this?)
> 
> Just a quick ping: is this making its way to Linus (and stable)?  I've
> been running it for five days through (literally, due to monitor bugs)
> thousands of plug/unplug cycles with no ill effects.
This issue has been fixed in nouveau git now, but that fix can't be
pulled into stable/linus as it depends on architectural changes to
nouveau that Linus probably wouldn't accept this late.

I responded to a mail asking that the patches be redone to just fix the
bug *without* removing the "magic numbers" (so, just patch 2/2
essentially), to avoid more unnecessary conflicts with nouveau git.

Ben.

> 
> (Can we *please* get rid of, or at least ratelimit, the
> plugged/unplugged printk?  It's taking over my logs, and I'm almost
> certain that it's not a driver bug.)
> 
> --Andy



WARNING: multiple messages have this Message-ID (diff)
From: Ben Skeggs <bskeggs@redhat.com>
To: Andrew Lutomirski <luto@mit.edu>
Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 0/2] Fix nouveau-related freezes
Date: Wed, 17 Nov 2010 09:09:57 +1000	[thread overview]
Message-ID: <1289948997.2311.16.camel@nisroch> (raw)
In-Reply-To: <AANLkTimM6EUeFiyaH=6bkes19LtYO6t1PJL_SE9Zt3-L@mail.gmail.com>

On Tue, 2010-11-16 at 17:19 -0500, Andrew Lutomirski wrote:
> On Wed, Nov 10, 2010 at 6:04 PM, Andy Lutomirski <luto@mit.edu> wrote:
> > Nouveau takes down my system quite reliably when any hotplug event occurs.
> > The bug happens because the IRQ handler didn't acknowledge the hotplug
> > state until the bottom half, so the card generated a new interrupt
> > immediately, starving the bottom half and permanently starving that CPU
> > (and hence the bottom half).
> >
> > Even with this fix, a lot of the IRQ code looks rather broken.
> >
> > This is tested on 2.6.36 (and makes the system stable for me), but it also
> > applies cleanly to 2.6.37 (untested, but surely also necessary).  Fedora 14's
> > 2.6.35 kernels seem to have to same problem for me, so I suspect that 2.6.35
> > needs this fix as well.  (All of my tests are on an NV50 card.)
> >
> > Changes from v1:
> >  - Ignore unrequested hotplug bits (I accidentally removed that part).
> >  - Support newer hardware (untested -- Ben, can you check this?)
> 
> Just a quick ping: is this making its way to Linus (and stable)?  I've
> been running it for five days through (literally, due to monitor bugs)
> thousands of plug/unplug cycles with no ill effects.
This issue has been fixed in nouveau git now, but that fix can't be
pulled into stable/linus as it depends on architectural changes to
nouveau that Linus probably wouldn't accept this late.

I responded to a mail asking that the patches be redone to just fix the
bug *without* removing the "magic numbers" (so, just patch 2/2
essentially), to avoid more unnecessary conflicts with nouveau git.

Ben.

> 
> (Can we *please* get rid of, or at least ratelimit, the
> plugged/unplugged printk?  It's taking over my logs, and I'm almost
> certain that it's not a driver bug.)
> 
> --Andy

  reply	other threads:[~2010-11-16 23:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-10 23:04 [PATCH v2 0/2] Fix nouveau-related freezes Andy Lutomirski
2010-11-10 23:04 ` Andy Lutomirski
2010-11-10 23:04 ` [PATCH 1/2] Use existing defines for NV50 hotplug registers Andy Lutomirski
2010-11-10 23:04 ` [PATCH 2/2] nouveau: Acknowledge HPD irq in handler, not bottom half Andy Lutomirski
2010-11-16 22:19 ` [PATCH v2 0/2] Fix nouveau-related freezes Andrew Lutomirski
2010-11-16 22:19   ` Andrew Lutomirski
2010-11-16 23:09   ` Ben Skeggs [this message]
2010-11-16 23:09     ` Ben Skeggs

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1289948997.2311.16.camel@nisroch \
    --to=bskeggs@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.