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 na
On Sat, 3 Sep 2011 10:25:16 -0500, Jonathan Nieder 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 kernel (following
the
Hi again,
Jameson Graef Rollins wrote:
> On Sat, 27 Aug 2011 14:34:56 -0500, Jonathan Nieder
> 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
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 mul
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
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 sh
On Sat, 27 Aug 2011 14:34:56 -0500, Jonathan Nieder 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 rebuild my kerne
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 downgra
On Thu, 25 Aug 2011 12:42:00 -0500, Jonathan Nieder 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 udev) I do *not*
On Thu, 25 Aug 2011 12:42:00 -0500, Jonathan Nieder 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 output of dm
On Thu, 25 Aug 2011 12:42:00 -0500, Jonathan Nieder 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 after I started runn
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 lea
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 q
On Wed, Aug 24, 2011 at 08:59:19PM +0200, Marco d'Itri wrote:
> On Aug 24, Jameson Graef Rollins 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.
Marco is righ
On Aug 24, Jameson Graef Rollins 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, 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
Processing commands for cont...@bugs.debian.org:
> reassign 638887 linux-2.6
Bug #638887 [udev] udev: cdrom_id process can not be killed
Bug reassigned from package 'udev' to 'linux-2.6'.
Bug No longer marked as found in versions udev/172-1.
> thanks
Stopping processing here.
Please contact me if
reassign 638887 linux-2.6
thanks
On Aug 22, 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
This is always a kernel bug.
--
ciao,
Marco
signature.asc
Description: Digital signature
18 matches
Mail list logo
