All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ritesh Raj Sarraf <rrs@researchut.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [Suspend-devel] Fwd: Kernel Oops with 2.6.23
Date: Mon, 17 Dec 2007 21:45:54 +0530	[thread overview]
Message-ID: <200712172146.01667.rrs@researchut.com> (raw)
In-Reply-To: <20071203215105.GC8704@elf.ucw.cz>

[-- Attachment #1: Type: text/plain, Size: 1906 bytes --]

On Tuesday 04 December 2007, Pavel Machek wrote:
> On Mon 2007-12-03 06:01:26, Ritesh Raj Sarraf wrote:
> > On Sunday 02 December 2007, Pavel Machek wrote:
> > > killall -9 pulseaudio. If pulseaudio is not dead within 60 seconds,
> > > you hit a kernel bug. If it needs suspend to be reproduced, you
> > > probably have a suspend bug.
> >
> > Hi Pavel,
> >
> > Something similar to this are multiple cases where the kernel is not able
> > to kill a process at all.
> >
> > A good example is an application pumping IO to a multipathed device. When
> > all the paths to the multipathed devices go down, and you'd like to kill
> > the process, there is no way left to do it. In fact, a reboot also
> > doesn't work in such cases. Reboot gets hung in midway trying to kill the
> > process. The user is left to do a hard reset of the machine.
> >
> > In situations like these, the processes go into D state.
> >
> > Here's what the manpage of ps says:
> >
> > PROCESS STATE CODES
> >        Here are the different values that the s, stat and state output
> > specifiers (header "STAT" or "S")
> >        will display to describe the state of a process.
> >        D    Uninterruptible sleep (usually IO)
> >
> > Does it mean that processes in D state are excluded by the kernel from
> > being killed ? Or is it still a kernel bug ?
>
> Still a kernel bug. Processes should not stay in D state for long.
> 									Pavel

Hi Pavel,

Sometime back we discussed about 'D' state processes which are not killed by 
the kernel by any signal.

Here's a bugzilla detailing the symptom.
https://bugzilla.redhat.com/show_bug.cgi?id=419581
[I/O Processes don't get killed when all the paths to the LUN are down]

It is still being assumed as working as designed.

Ritesh
-- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

       reply	other threads:[~2007-12-17 16:18 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200711300103.38658.rrs@researchut.com>
     [not found] ` <200712030601.33212.rrs@researchut.com>
     [not found]   ` <20071203215105.GC8704@elf.ucw.cz>
2007-12-17 16:15     ` Ritesh Raj Sarraf [this message]
2007-12-26 21:11       ` [Suspend-devel] Fwd: Kernel Oops with 2.6.23 Pavel Machek

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=200712172146.01667.rrs@researchut.com \
    --to=rrs@researchut.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /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.