Hi again,
Jameson Graef Rollins wrote:
On Sat, 27 Aug 2011 14:34:56 -0500, Jonathan Nieder jrnie...@gmail.com
wrote:
The only potentially problematic commit I could find is the following.
It might be worth testing with it backed out.
Hey, Jonathan. I haven't done much kernel rebuilding
On Sat, 3 Sep 2011 10:25:16 -0500, Jonathan Nieder jrnie...@gmail.com wrote:
Now I'm in suspense. Did you get a chance to test the kernel with
Tejun Heo's commit bf2253a6f00e[1] reverted?
Hi, Jonathan. Sorry to keep you in suspense!
So I just tried reverting the patch and rebuilding the
forwarded 628600 http://thread.gmane.org/gmane.linux.kernel/1187762
quit
Jameson Graef Rollins wrote:
Thanks so much for identifying the suspect commit! Please let me know
if there's anything else I can do to help, such as testing and more
patches, or new kernel packages.
Thank you for
Hello there,
On Mon, Aug 22, 2011 at 10:30:32AM -0700, Jameson Graef Rollins wrote:
Occasionally I find a cdrom_id process stuck in the D
(uninterruptible sleep) state that can not be killed. I'm not
exactly sure what's causing this (possibly detaching from my dock?)
but this causes multiple
forcemerge 628600 638887
quit
(-cc: Marco)
Jonathan Nieder wrote:
Jameson Graef Rollins wrote:
If I keep everything else the same (same version of udev) I do *not*
experience the problem with kernel:
2.6.38-2-amd64
but I *do* experience the problem with kernels:
2.6.39-2-amd64
On Thu, 25 Aug 2011 12:42:00 -0500, Jonathan Nieder jrnie...@gmail.com wrote:
Please send the full content of /var/log/dmesg after running
echo d /proc/sysrq-trigger/proc/sysrq-trigger
echo w /proc/sysrq-trigger
when a process is in this hung state.
Attached is a diff of the
On Thu, 25 Aug 2011 12:42:00 -0500, Jonathan Nieder jrnie...@gmail.com wrote:
Does downgrading udev or the kernel help? /var/log/dpkg.log should
describe the upgrade history of both, and http://snapshot.debian.org/
has historical packages.
If I keep everything else the same (same version of
Jameson Graef Rollins wrote:
If I keep everything else the same (same version of udev) I do *not*
experience the problem with kernel:
2.6.38-2-amd64
but I *do* experience the problem with kernels:
2.6.39-2-amd64
3.0.0-1-amd64
If you really think it's worthwhile to try downgrading udev
On Sat, 27 Aug 2011 14:34:56 -0500, Jonathan Nieder jrnie...@gmail.com wrote:
The only potentially problematic commit I could find is the following.
It might be worth testing with it backed out.
Hey, Jonathan. I haven't done much kernel rebuilding at all, so I'm not
sure what's the best way to
Hi Jamie,
Jameson Graef Rollins wrote:
Hey, Jonathan. I haven't done much kernel rebuilding at all, so I'm not
sure what's the best way to rebuild my kernel with this patch reverted.
If you can give me a few pointers on a good way to do that it would be
much appreciated. Presumably I
So this problem is now happening with other udev functions as well:
Aug 25 00:53:14 servo udevd[23014]: timeout: killing 'scsi_id --export
--whitelisted --device=/dev/sr0' [23017]
This leaves me not particularly convinced that this is not at least
partially a udev issue.
This issue has become
Hi Jamie,
Jameson Graef Rollins wrote:
So this problem is now happening with other udev functions as well:
Aug 25 00:53:14 servo udevd[23014]: timeout: killing 'scsi_id --export
--whitelisted --device=/dev/sr0' [23017]
This leaves me not particularly convinced that this is not at least
On Thu, 25 Aug 2011 12:42:00 -0500, Jonathan Nieder jrnie...@gmail.com wrote:
Does downgrading udev or the kernel help? /var/log/dpkg.log should
describe the upgrade history of both, and http://snapshot.debian.org/
has historical packages.
I'm fairly confident that this started happening
reassign 638887 linux-2.6
thanks
On Aug 22, Jameson Graef Rollins jroll...@finestructure.net wrote:
Occasionally I find a cdrom_id process stuck in the D
(uninterruptible sleep) state that can not be killed. I'm not
This is always a kernel bug.
--
ciao,
Marco
signature.asc
Description:
On Wed, 24 Aug 2011 19:49:53 +0200, m...@linux.it (Marco d'Itri) wrote:
Occasionally I find a cdrom_id process stuck in the D
(uninterruptible sleep) state that can not be killed. I'm not
This is always a kernel bug.
Hi, Marco. Can you explain why this is always a kernel bug? It's
On Aug 24, Jameson Graef Rollins jroll...@finestructure.net wrote:
Hi, Marco. Can you explain why this is always a kernel bug? It's
certainly not obvious to me. Thanks.
Because processes are not supposed to get stuck in D state.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Wed, Aug 24, 2011 at 08:59:19PM +0200, Marco d'Itri wrote:
On Aug 24, Jameson Graef Rollins jroll...@finestructure.net wrote:
Hi, Marco. Can you explain why this is always a kernel bug? It's
certainly not obvious to me. Thanks.
Because processes are not supposed to get stuck in D
Package: udev
Version: 172-1
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Occasionally I find a cdrom_id process stuck in the D
(uninterruptible sleep) state that can not be killed. I'm not
exactly sure what's causing this (possibly detaching from my dock?)
but this causes
18 matches
Mail list logo
