On Wed, 23 Feb 2005, linux-os wrote:
> On Wed, 23 Feb 2005, Bodo Eggert wrote:
> > linux-os <[EMAIL PROTECTED]> wrote:
> >> You don't seem to understand. A process that's stuck in 'D' state
> >> shows a SEVERE error, usually with a hardware driver.
> >
> > Or a network filesystem mount to a no
I have recently run into similar issue involving processes stuck in D state -
involves khubd and usb-storage. This happens with 2.6.11-rc4.
Check lkml for subject Re: [linux-usb-devel] 2.6: USB Storage hangs mac..
Parag
> On Tue, 22 Feb 2005 22:31:03 +0100, Olaf Titz <[EMAIL PROTECTED]>
On Tue, 22 Feb 2005 22:31:03 +0100, Olaf Titz <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]> you write:
> > The most recent one was yesterday: I had run lsusb in the morning and had no
> > problems, but at the end of the day I ran it again, and after outputting 3
> > lines of data, it
On Wed, 23 Feb 2005, Bodo Eggert wrote:
linux-os <[EMAIL PROTECTED]> wrote:
You don't seem to understand. A process that's stuck in 'D' state
shows a SEVERE error, usually with a hardware driver.
Or a network filesystem mount to a no longer existing server or share.
But that's a whole different
On Tue, 2005-02-22 at 22:05 -0300, Horst von Brand wrote:
> Chris Friesen <[EMAIL PROTECTED]> said:
[...]
> > Maybe I'm on crack, but would it not be technically possible to have all
> > resource usage be tracked so that when a task tries to do something and
> > hangs, eventually it gets cleaned
In article <[EMAIL PROTECTED]> you write:
> The most recent one was yesterday: I had run lsusb in the morning and had no
> problems, but at the end of the day I ran it again, and after outputting 3
> lines of data, it hung, stuck in D-state. So now I have this:
>
> [/home/user]$ ps aux|grep D
>
In article [EMAIL PROTECTED] you write:
The most recent one was yesterday: I had run lsusb in the morning and had no
problems, but at the end of the day I ran it again, and after outputting 3
lines of data, it hung, stuck in D-state. So now I have this:
[/home/user]$ ps aux|grep D
USER
On Tue, 2005-02-22 at 22:05 -0300, Horst von Brand wrote:
Chris Friesen [EMAIL PROTECTED] said:
[...]
Maybe I'm on crack, but would it not be technically possible to have all
resource usage be tracked so that when a task tries to do something and
hangs, eventually it gets cleaned up?
On Wed, 23 Feb 2005, Bodo Eggert wrote:
linux-os [EMAIL PROTECTED] wrote:
You don't seem to understand. A process that's stuck in 'D' state
shows a SEVERE error, usually with a hardware driver.
Or a network filesystem mount to a no longer existing server or share.
But that's a whole different
On Tue, 22 Feb 2005 22:31:03 +0100, Olaf Titz [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED] you write:
The most recent one was yesterday: I had run lsusb in the morning and had no
problems, but at the end of the day I ran it again, and after outputting 3
lines of data, it hung,
I have recently run into similar issue involving processes stuck in D state -
involves khubd and usb-storage. This happens with 2.6.11-rc4.
Check lkml for subject Re: [linux-usb-devel] 2.6: USB Storage hangs mac..
Parag
On Tue, 22 Feb 2005 22:31:03 +0100, Olaf Titz [EMAIL PROTECTED] wrote:
On Wed, 23 Feb 2005, linux-os wrote:
On Wed, 23 Feb 2005, Bodo Eggert wrote:
linux-os [EMAIL PROTECTED] wrote:
You don't seem to understand. A process that's stuck in 'D' state
shows a SEVERE error, usually with a hardware driver.
Or a network filesystem mount to a no longer existing
Chris Friesen <[EMAIL PROTECTED]> said:
> Horst von Brand wrote:
> > Anthony DiSante <[EMAIL PROTECTED]> said:
> >>That's one of the things I asked a few messages ago. Some people on
> >>the list were saying that it'd be "really hard" and would "require a
> >>lot of bookkeeping" to "fix"
linux-os <[EMAIL PROTECTED]> wrote:
> You don't seem to understand. A process that's stuck in 'D' state
> shows a SEVERE error, usually with a hardware driver.
Or a network filesystem mount to a no longer existing server or share.
> For instance,
> somebody may have coded something in a
linux-os wrote:
Before I get into the reply, I just want to make it clear that I'm not
arguing that we *should* do any of this, just that it is not technically
impossible. It's a thought experiment, not a design suggestion.
All wonderful. However, it dosn't fix the problem. You are,
again,
On Tue, 22 Feb 2005, Chris Friesen wrote:
linux-os wrote:
Now, somebody needs a resource. It executes down();
once it gets control again, it has that resource. It attempts
to use that resource through a driver. The driver waits forever.
The resource is now permanently dorked --forever because its
linux-os wrote:
Now, somebody needs a resource. It executes down();
once it gets control again, it has that resource. It attempts
to use that resource through a driver. The driver waits forever.
The resource is now permanently dorked --forever because its
driver is waiting forever. The user code
On Tue, 22 Feb 2005, Chris Friesen wrote:
Horst von Brand wrote:
Anthony DiSante <[EMAIL PROTECTED]> said:
That's one of the things I asked a few messages ago. Some people on the
list were saying that it'd be "really hard" and would "require a lot of
bookkeeping" to "fix" permanently-D-stated
Horst von Brand wrote:
Anthony DiSante <[EMAIL PROTECTED]> said:
That's one of the things I asked a few messages ago. Some people on the
list were saying that it'd be "really hard" and would "require a lot of
bookkeeping" to "fix" permanently-D-stated processes... which is completely
Chris Friesen wrote:
There has been some discussion that these hung
states could be "fixed", but that's absolutely
positively incorrect.
That's one of the things I asked a few messages ago. Some people on
the list were saying that it'd be "really hard" and would "require a
lot of bookkeeping"
Anthony DiSante <[EMAIL PROTECTED]> said:
> linux-os wrote:
> > There has been some discussion that these hung
> > states could be "fixed", but that's absolutely
> > positively incorrect.
> That's one of the things I asked a few messages ago. Some people on the
> list were saying that it'd be
Anthony DiSante wrote:
linux-os wrote:
There has been some discussion that these hung
states could be "fixed", but that's absolutely
positively incorrect.
That's one of the things I asked a few messages ago. Some people on the
list were saying that it'd be "really hard" and would "require a lot
linux-os wrote:
There has been some discussion that these hung
states could be "fixed", but that's absolutely
positively incorrect.
That's one of the things I asked a few messages ago. Some people on the
list were saying that it'd be "really hard" and would "require a lot of
bookkeeping" to
On Tue, 22 Feb 2005, Anthony DiSante wrote:
Helge Hafting wrote:
The infrastructure for that does not exist, so instead, the "killed"
process remains. Not all of it, but at least the memory pinned down by the
io request. This overhead is typically small, and the overehad of adding
forced io
Denis Vlasenko wrote:
The infrastructure for that does not exist, so instead, the "killed"
process remains. Not all of it, but at least the memory pinned down by
the io request. This overhead is typically small, and the overehad of
adding forced io abort to every driver might
be larger than a
On Tuesday 22 February 2005 13:16, Anthony DiSante wrote:
> Helge Hafting wrote:
> > The infrastructure for that does not exist, so instead, the "killed"
> > process remains. Not all of it, but at least the memory pinned down by
> > the io request. This overhead is typically small, and the
Helge Hafting wrote:
The infrastructure for that does not exist, so instead, the "killed"
process remains. Not all of it, but at least the memory pinned down by
the io request. This overhead is typically small, and the overehad of
adding forced io abort to every driver might
be larger than a
Helge Hafting wrote:
The infrastructure for that does not exist, so instead, the killed
process remains. Not all of it, but at least the memory pinned down by
the io request. This overhead is typically small, and the overehad of
adding forced io abort to every driver might
be larger than a
On Tuesday 22 February 2005 13:16, Anthony DiSante wrote:
Helge Hafting wrote:
The infrastructure for that does not exist, so instead, the killed
process remains. Not all of it, but at least the memory pinned down by
the io request. This overhead is typically small, and the overehad of
Denis Vlasenko wrote:
The infrastructure for that does not exist, so instead, the killed
process remains. Not all of it, but at least the memory pinned down by
the io request. This overhead is typically small, and the overehad of
adding forced io abort to every driver might
be larger than a
On Tue, 22 Feb 2005, Anthony DiSante wrote:
Helge Hafting wrote:
The infrastructure for that does not exist, so instead, the killed
process remains. Not all of it, but at least the memory pinned down by the
io request. This overhead is typically small, and the overehad of adding
forced io
linux-os wrote:
There has been some discussion that these hung
states could be fixed, but that's absolutely
positively incorrect.
That's one of the things I asked a few messages ago. Some people on the
list were saying that it'd be really hard and would require a lot of
bookkeeping to fix
Anthony DiSante wrote:
linux-os wrote:
There has been some discussion that these hung
states could be fixed, but that's absolutely
positively incorrect.
That's one of the things I asked a few messages ago. Some people on the
list were saying that it'd be really hard and would require a lot of
Anthony DiSante [EMAIL PROTECTED] said:
linux-os wrote:
There has been some discussion that these hung
states could be fixed, but that's absolutely
positively incorrect.
That's one of the things I asked a few messages ago. Some people on the
list were saying that it'd be really hard
Chris Friesen wrote:
There has been some discussion that these hung
states could be fixed, but that's absolutely
positively incorrect.
That's one of the things I asked a few messages ago. Some people on
the list were saying that it'd be really hard and would require a
lot of bookkeeping to fix
Horst von Brand wrote:
Anthony DiSante [EMAIL PROTECTED] said:
That's one of the things I asked a few messages ago. Some people on the
list were saying that it'd be really hard and would require a lot of
bookkeeping to fix permanently-D-stated processes... which is completely
different than
On Tue, 22 Feb 2005, Chris Friesen wrote:
Horst von Brand wrote:
Anthony DiSante [EMAIL PROTECTED] said:
That's one of the things I asked a few messages ago. Some people on the
list were saying that it'd be really hard and would require a lot of
bookkeeping to fix permanently-D-stated
linux-os wrote:
Now, somebody needs a resource. It executes down(semaphore);
once it gets control again, it has that resource. It attempts
to use that resource through a driver. The driver waits forever.
The resource is now permanently dorked --forever because its
driver is waiting forever. The
On Tue, 22 Feb 2005, Chris Friesen wrote:
linux-os wrote:
Now, somebody needs a resource. It executes down(semaphore);
once it gets control again, it has that resource. It attempts
to use that resource through a driver. The driver waits forever.
The resource is now permanently dorked --forever
linux-os wrote:
Before I get into the reply, I just want to make it clear that I'm not
arguing that we *should* do any of this, just that it is not technically
impossible. It's a thought experiment, not a design suggestion.
All wonderful. However, it dosn't fix the problem. You are,
again,
linux-os [EMAIL PROTECTED] wrote:
You don't seem to understand. A process that's stuck in 'D' state
shows a SEVERE error, usually with a hardware driver.
Or a network filesystem mount to a no longer existing server or share.
For instance,
somebody may have coded something in a critical
Chris Friesen [EMAIL PROTECTED] said:
Horst von Brand wrote:
Anthony DiSante [EMAIL PROTECTED] said:
That's one of the things I asked a few messages ago. Some people on
the list were saying that it'd be really hard and would require a
lot of bookkeeping to fix permanently-D-stated
On Mon, 21 Feb 2005 19:06:23 EST, Anthony DiSante said:
> The driver code for my devices has "been given" to me as part of the kernel.
> Any of a handful of USB devices has caused permanent D states, as has a
> CDROM and a NIC. I guess I'll need to start debugging all of these drivers.
>
Chris Friesen wrote:
It's indisputable that there will always be driver bugs and faulty
hardware. Of course these should be fixed, but if it's possible for
the kernel to gracefully deal with the bugs until they get fixed, then
why shouldn't it do so?
Think of the overhead required to track
On Mon, 21 Feb 2005 17:44:32 -0500, Anthony DiSante
<[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > See the thread rooted here:
> >
> > Date: Wed, 03 Nov 2004 07:51:39 -0500
> > From: Gene Heskett <[EMAIL PROTECTED]>
> > Subject: is killing zombies possible w/o a reboot?
> > Sender:
[EMAIL PROTECTED] wrote:
See the thread rooted here:
Date: Wed, 03 Nov 2004 07:51:39 -0500
From: Gene Heskett <[EMAIL PROTECTED]>
Subject: is killing zombies possible w/o a reboot?
Sender: [EMAIL PROTECTED]
To: linux-kernel@vger.kernel.org
Reply-to: [EMAIL PROTECTED]
Message-id: <[EMAIL
Anthony DiSante wrote:
It's indisputable that there will always be driver bugs and faulty
hardware. Of course these should be fixed, but if it's possible for the
kernel to gracefully deal with the bugs until they get fixed, then why
shouldn't it do so?
Think of the overhead required to track
[EMAIL PROTECTED] wrote:
See the thread rooted here:
Date: Wed, 03 Nov 2004 07:51:39 -0500
From: Gene Heskett <[EMAIL PROTECTED]>
Subject: is killing zombies possible w/o a reboot?
Sender: [EMAIL PROTECTED]
To: linux-kernel@vger.kernel.org
Reply-to: [EMAIL PROTECTED]
Message-id: <[EMAIL
On Mon, 21 Feb 2005 15:24:21 EST, Anthony DiSante said:
> Or maybe it SHOULD have killed your process, in some "proper" way that
> prevents any outstanding I/O requests from coming in days later and breaking
> things. Again, I'm no kernel hacker, but if an I/O request takes *3 days*,
> isn't
[EMAIL PROTECTED] wrote:
It seems like this problem is always going to exist, because some hardware
and some drivers will always be buggy. So shouldn't we have some sort of
watchdog higher up in the kernel, that watches for hung processes like this
and kills them?
And said watchdog would clean
On Mon, 21 Feb 2005 14:18:44 EST, Anthony DiSante said:
> It seems like this problem is always going to exist, because some hardware
> and some drivers will always be buggy. So shouldn't we have some sort of
> watchdog higher up in the kernel, that watches for hung processes like this
> and
Processes that get permanently stuck in "uninterruptible sleep" (the D state
as indicated by "ps aux") are such a pain. Of course they've always
existed, but at least on the 3 systems that I administer, they are far more
frequent with udev than they ever were before. I'm constantly upgrading
Processes that get permanently stuck in uninterruptible sleep (the D state
as indicated by ps aux) are such a pain. Of course they've always
existed, but at least on the 3 systems that I administer, they are far more
frequent with udev than they ever were before. I'm constantly upgrading
On Mon, 21 Feb 2005 14:18:44 EST, Anthony DiSante said:
It seems like this problem is always going to exist, because some hardware
and some drivers will always be buggy. So shouldn't we have some sort of
watchdog higher up in the kernel, that watches for hung processes like this
and kills
[EMAIL PROTECTED] wrote:
It seems like this problem is always going to exist, because some hardware
and some drivers will always be buggy. So shouldn't we have some sort of
watchdog higher up in the kernel, that watches for hung processes like this
and kills them?
And said watchdog would clean
On Mon, 21 Feb 2005 15:24:21 EST, Anthony DiSante said:
Or maybe it SHOULD have killed your process, in some proper way that
prevents any outstanding I/O requests from coming in days later and breaking
things. Again, I'm no kernel hacker, but if an I/O request takes *3 days*,
isn't that an
[EMAIL PROTECTED] wrote:
See the thread rooted here:
Date: Wed, 03 Nov 2004 07:51:39 -0500
From: Gene Heskett [EMAIL PROTECTED]
Subject: is killing zombies possible w/o a reboot?
Sender: [EMAIL PROTECTED]
To: linux-kernel@vger.kernel.org
Reply-to: [EMAIL PROTECTED]
Message-id: [EMAIL PROTECTED]
Anthony DiSante wrote:
It's indisputable that there will always be driver bugs and faulty
hardware. Of course these should be fixed, but if it's possible for the
kernel to gracefully deal with the bugs until they get fixed, then why
shouldn't it do so?
Think of the overhead required to track
[EMAIL PROTECTED] wrote:
See the thread rooted here:
Date: Wed, 03 Nov 2004 07:51:39 -0500
From: Gene Heskett [EMAIL PROTECTED]
Subject: is killing zombies possible w/o a reboot?
Sender: [EMAIL PROTECTED]
To: linux-kernel@vger.kernel.org
Reply-to: [EMAIL PROTECTED]
Message-id: [EMAIL PROTECTED]
On Mon, 21 Feb 2005 17:44:32 -0500, Anthony DiSante
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
See the thread rooted here:
Date: Wed, 03 Nov 2004 07:51:39 -0500
From: Gene Heskett [EMAIL PROTECTED]
Subject: is killing zombies possible w/o a reboot?
Sender: [EMAIL PROTECTED]
Chris Friesen wrote:
It's indisputable that there will always be driver bugs and faulty
hardware. Of course these should be fixed, but if it's possible for
the kernel to gracefully deal with the bugs until they get fixed, then
why shouldn't it do so?
Think of the overhead required to track
On Mon, 21 Feb 2005 19:06:23 EST, Anthony DiSante said:
The driver code for my devices has been given to me as part of the kernel.
Any of a handful of USB devices has caused permanent D states, as has a
CDROM and a NIC. I guess I'll need to start debugging all of these drivers.
When
62 matches
Mail list logo
