Re: [PATCH v11 7/7] at24: Support probing while in non-zero ACPI D state

ute probe while being in ACPI D state other than 0 (which means fully > powered on). > > Signed-off-by: Sakari Ailus > Reviewed-by: Tomasz Figa > --- I like this much better now, thanks! Acked-by: Bartosz Golaszewski

[PATCH v11 6/7] media: i2c: imx319: Support device probe in non-zero ACPI D state

From: Rajmohan Mani Tell ACPI device PM code that the driver supports the device being in non-zero ACPI D state when the driver's probe function is entered. Signed-off-by: Rajmohan Mani Signed-off-by: Sakari Ailus Reviewed-by: Tomasz Figa Reviewed-by: Bingbu Cao --- drivers/media/i2c

[PATCH v11 7/7] at24: Support probing while in non-zero ACPI D state

In certain use cases (where the chip is part of a camera module, and the camera module is wired together with a camera privacy LED), powering on the device during probe is undesirable. Add support for the at24 to execute probe while being in ACPI D state other than 0 (which means fully powered

[PATCH v11 5/7] ov5670: Support probe whilst the device is in ACPI D state other than 0

Tell ACPI device PM code that the driver supports the device being in a non-zero D state when the driver's probe function is entered. Also do identification on the first access of the device, whether in probe or when starting streaming. Signed-off-by: Sakari Ailus Reviewed-by: Tomasz Figa

[Question] How to deal D state on request_wait_answer?

Hi We recently detected a bug in virtiofs. Here, we created a virtual machine as guest with Qemu and virtiofsd. We mounted virtiofs on guest, for example /home/virtiofs. Then we killed the virtiofsd in host and accessed /home/virtiofs in guest later. This casued a process with D state which

Re: kswapd warning at kernel/rcu/tree.c:1358 rcu_advance_cbs_nowake causing processes to enter d state

processes to enter d state All, After upgrading our systems from 5.3.x to 5.4.51 we started experiencing problems where some processes would enter an uninterruptible sleep state. We do not have a swap enabled or a swap mount point. We have tried updating to 5.7.10 and still experience the same issue

[PATCH v3] hung_task:add detecting task in D state milliseconds timeout

current hung_task_check_interval_secs and hung_task_timeout_secs only supports seconds. In some cases,the TASK_UNINTERRUPTIBLE state takes less than 1 second,may need to hung task trigger panic get ramdump or print all cpu task. modify hung_task_check_interval_secs to

[PATCH v3] hung_task:add detecting task in D state milliseconds timeout

current hung_task_check_interval_secs and hung_task_timeout_secs only supports seconds. In some cases,the TASK_UNINTERRUPTIBLE state takes less than 1 second,may need to hung task trigger panic get ramdump or print all cpu task. modify hung_task_check_interval_secs to

Re: [RFC] hung_task:add detecting task in D state milliseconds timeout

I will learn how to use KernelShark. Try to solve my problem,thanks for your suggestion. Talk about I solved a problem with hung task milliseconds： the process get anon_vma read lock when it directly reclaims memory, but other process down anon_vma write lock, long time waiting for write lock

Re: [RFC] hung_task:add detecting task in D state milliseconds timeout

On Fri, Jul 03, 2020 at 11:18:28AM +0800, yang che wrote: > my understanding, KernelShark can't trigger panic, hung_task can > trigger. According to my use, > sometimes need to trigger panic to grab ramdump to analyze lock and > memory problems. You shouldn't need to trigger a panic to analyse

Re: [PATCH v2] hung_task:add detecting task in D state milliseconds timeout

On Sun, Jul 05, 2020 at 08:48:52PM +0800, yang che wrote: > @@ -16,8 +16,9 @@ extern unsigned int sysctl_hung_task_all_cpu_backtrace; > > extern intsysctl_hung_task_check_count; > extern unsigned int sysctl_hung_task_panic; > +extern unsigned long sysctl_hung_task_timeout_millisecs;

[PATCH v2] hung_task:add detecting task in D state milliseconds timeout

current hung_task_check_interval_secs and hung_task_timeout_secs only supports seconds. In some cases,the TASK_UNINTERRUPTIBLE state takes less than 1 second,may need to hung task trigger panic get ramdump or print all cpu task. modify hung_task_check_interval_secs to

Re: [RFC] hung_task:add detecting task in D state milliseconds timeout

my understanding, KernelShark can't trigger panic, hung_task can trigger. According to my use, sometimes need to trigger panic to grab ramdump to analyze lock and memory problems. So I want to increase this millisecond support. Matthew Wilcox 于2020年7月3日周五 上午1:43写道： > > On Thu, Jul 02, 2020 at

Re: [RFC] hung_task:add detecting task in D state milliseconds timeout

On Thu, Jul 02, 2020 at 10:08:13PM +0800, yang che wrote: > current hung_task_check_interval_secs and hung_task_timeout_secs > only supports seconds.in some cases,the TASK_UNINTERRUPTIBLE state > takes less than 1 second.The task of the graphical interface, > the unterruptible state lasts for

[RFC] hung_task:add detecting task in D state milliseconds timeout

current hung_task_check_interval_secs and hung_task_timeout_secs only supports seconds.in some cases,the TASK_UNINTERRUPTIBLE state takes less than 1 second.The task of the graphical interface, the unterruptible state lasts for hundreds of milliseconds will cause the interface to freeze echo 1 >

Re: Traversing XFS mounted VM puts process in D state

On Fri, Dec 08, 2017 at 02:00:19PM +0530, Dinesh Pathak wrote: > Hi Dave, Thanks for your time. The above link only reports a similar > bug, which has same kernel trace, which we found on internet. Our > client machine, where traversal is done, is using CentOS. Then you need to report it to your

Re: Traversing XFS mounted VM puts process in D state

On Fri, Dec 08, 2017 at 02:00:19PM +0530, Dinesh Pathak wrote: > Hi Dave, Thanks for your time. The above link only reports a similar > bug, which has same kernel trace, which we found on internet. Our > client machine, where traversal is done, is using CentOS. Then you need to report it to your

Re: Traversing XFS mounted VM puts process in D state

ing traversing, the process goes into D state and can not be >> killed. Eventually system needs to IPMI rebooted. This happens once in 100 >> times. >> >> This VM backup is kept on NFS storage. So we first do NFS mounting. Then do >> loopback mount of the partition whi

Re: Traversing XFS mounted VM puts process in D state

On Fri, Dec 8, 2017 at 7:08 AM, Dave Chinner wrote: > [cc linux-...@vger.kernel.org] > > On Fri, Dec 08, 2017 at 06:42:32AM +0530, Dinesh Pathak wrote: >> Hi, We are mounting and traversing one backup of a VM with XFS filesystem. >> Sometimes during traversing, the proc

Re: Traversing XFS mounted VM puts process in D state

[cc linux-...@vger.kernel.org] On Fri, Dec 08, 2017 at 06:42:32AM +0530, Dinesh Pathak wrote: > Hi, We are mounting and traversing one backup of a VM with XFS filesystem. > Sometimes during traversing, the process goes into D state and can not be > killed. Eventually system needs to IPMI

Re: Traversing XFS mounted VM puts process in D state

[cc linux-...@vger.kernel.org] On Fri, Dec 08, 2017 at 06:42:32AM +0530, Dinesh Pathak wrote: > Hi, We are mounting and traversing one backup of a VM with XFS filesystem. > Sometimes during traversing, the process goes into D state and can not be > killed. Eventually system needs to IPMI

Traversing XFS mounted VM puts process in D state

Hi, We are mounting and traversing one backup of a VM with XFS filesystem. Sometimes during traversing, the process goes into D state and can not be killed. Eventually system needs to IPMI rebooted. This happens once in 100 times. This VM backup is kept on NFS storage. So we first do NFS mounting

Traversing XFS mounted VM puts process in D state

Hi, We are mounting and traversing one backup of a VM with XFS filesystem. Sometimes during traversing, the process goes into D state and can not be killed. Eventually system needs to IPMI rebooted. This happens once in 100 times. This VM backup is kept on NFS storage. So we first do NFS mounting

Re: Worker threads in D state since c5a94a618e7ac86 (workqueue: Use TASK_IDLE)

8e7ac86b20f53d947f68d7cee6a4c6bc > > > > > > Author: Peter Zijlstra <pet...@infradead.org> > > > > > > Date: Wed Aug 23 13:58:44 2017 +0200 > > > > > > > > > > > > workqueue: Use TASK_IDLE > > > >

Re: Worker threads in D state since c5a94a618e7ac86 (workqueue: Use TASK_IDLE)

c5a94a618e7ac86b20f53d947f68d7cee6a4c6bc > > > > > > Author: Peter Zijlstra > > > > > > Date: Wed Aug 23 13:58:44 2017 +0200 > > > > > > > > > > > > workqueue: Use TASK_IDLE > > > > > > >

Re: Worker threads in D state since c5a94a618e7ac86 (workqueue: Use TASK_IDLE)

..@infradead.org> > > > > > Date: Wed Aug 23 13:58:44 2017 +0200 > > > > > > > > > > workqueue: Use TASK_IDLE > > > > > > > > > > > > > > > all worker threads are in D state. They all show up when using "magic &g

Re: Worker threads in D state since c5a94a618e7ac86 (workqueue: Use TASK_IDLE)

Date: Wed Aug 23 13:58:44 2017 +0200 > > > > > > > > > > workqueue: Use TASK_IDLE > > > > > > > > > > > > > > > all worker threads are in D state. They all show up when using "magic > > > > > SysR

Re: Worker threads in D state since c5a94a618e7ac86 (workqueue: Use TASK_IDLE)

us Trippelsdorf wrote: > > > > Since: > > > > > > > > commit c5a94a618e7ac86b20f53d947f68d7cee6a4c6bc > > > > Author: Peter Zijlstra <pet...@infradead.org> > > > > Date: Wed Aug 23 13:58:44 2017 +0200 > > > > > > > &g

Re: Worker threads in D state since c5a94a618e7ac86 (workqueue: Use TASK_IDLE)

us Trippelsdorf wrote: > > > > Since: > > > > > > > > commit c5a94a618e7ac86b20f53d947f68d7cee6a4c6bc > > > > Author: Peter Zijlstra > > > > Date: Wed Aug 23 13:58:44 2017 +0200 > > > > > > > > workqueue: Use

Re: Worker threads in D state since c5a94a618e7ac86 (workqueue: Use TASK_IDLE)

947f68d7cee6a4c6bc > > > Author: Peter Zijlstra <pet...@infradead.org> > > > Date: Wed Aug 23 13:58:44 2017 +0200 > > > > > > workqueue: Use TASK_IDLE > > > > > > > > > all worker threads are in D state. They all show

Re: Worker threads in D state since c5a94a618e7ac86 (workqueue: Use TASK_IDLE)

947f68d7cee6a4c6bc > > > Author: Peter Zijlstra > > > Date: Wed Aug 23 13:58:44 2017 +0200 > > > > > > workqueue: Use TASK_IDLE > > > > > > > > > all worker threads are in D state. They all show up when using "magic >

Re: Worker threads in D state since c5a94a618e7ac86 (workqueue: Use TASK_IDLE)

> Date: Wed Aug 23 13:58:44 2017 +0200 > > > > workqueue: Use TASK_IDLE > > > > > > all worker threads are in D state. They all show up when using "magic > > SysRq w". In htop they all have big fat red 'D' in the state column. > > Is

Re: Worker threads in D state since c5a94a618e7ac86 (workqueue: Use TASK_IDLE)

2017 +0200 > > > > workqueue: Use TASK_IDLE > > > > > > all worker threads are in D state. They all show up when using "magic > > SysRq w". In htop they all have big fat red 'D' in the state column. > > Is this really desirable? > > &g

Re: Worker threads in D state since c5a94a618e7ac86 (workqueue: Use TASK_IDLE)

> > > all worker threads are in D state. They all show up when using "magic > SysRq w". In htop they all have big fat red 'D' in the state column. > Is this really desirable? > > I have attached the output of "ps aux" after boot and the SysRq-w > output.

Re: Worker threads in D state since c5a94a618e7ac86 (workqueue: Use TASK_IDLE)

Hello, On Sun, Sep 10, 2017 at 09:36:53AM +0200, Markus Trippelsdorf wrote: > Since: > > commit c5a94a618e7ac86b20f53d947f68d7cee6a4c6bc > Author: Peter Zijlstra > Date: Wed Aug 23 13:58:44 2017 +0200 > > workqueue: Use TASK_IDLE > > > all worker th

Worker threads in D state since c5a94a618e7ac86 (workqueue: Use TASK_IDLE)

Since: commit c5a94a618e7ac86b20f53d947f68d7cee6a4c6bc Author: Peter Zijlstra <pet...@infradead.org> Date: Wed Aug 23 13:58:44 2017 +0200 workqueue: Use TASK_IDLE all worker threads are in D state. They all show up when using "magic SysRq w". In htop they all hav

Worker threads in D state since c5a94a618e7ac86 (workqueue: Use TASK_IDLE)

Since: commit c5a94a618e7ac86b20f53d947f68d7cee6a4c6bc Author: Peter Zijlstra Date: Wed Aug 23 13:58:44 2017 +0200 workqueue: Use TASK_IDLE all worker threads are in D state. They all show up when using "magic SysRq w". In htop they all have big fat red 'D' in the st

Re: [BUG] 4.11.0-rc3 xterm hung in D state on exit, wchan is tty_release_struct

+Peter On Thu, Mar 23, 2017 at 4:22 PM, wrote: > On Thu, Mar 23, 2017 at 11:57:22AM -0500, Rob Herring wrote: >> On Thu, Mar 23, 2017 at 08:46:03AM -0500, Rob Herring wrote: >> > On Thu, Mar 23, 2017 at 12:30:18AM -0700, l...@pengaru.com wrote: >> > > On Wed, Mar 22, 2017 at

Re: [BUG] 4.11.0-rc3 xterm hung in D state on exit, wchan is tty_release_struct

+Peter On Thu, Mar 23, 2017 at 4:22 PM, wrote: > On Thu, Mar 23, 2017 at 11:57:22AM -0500, Rob Herring wrote: >> On Thu, Mar 23, 2017 at 08:46:03AM -0500, Rob Herring wrote: >> > On Thu, Mar 23, 2017 at 12:30:18AM -0700, l...@pengaru.com wrote: >> > > On Wed, Mar 22, 2017 at 11:44:18PM -0700,

Re: [BUG] 4.11.0-rc3 xterm hung in D state on exit, wchan is tty_release_struct

On Thu, Mar 23, 2017 at 11:57:22AM -0500, Rob Herring wrote: > On Thu, Mar 23, 2017 at 08:46:03AM -0500, Rob Herring wrote: > > On Thu, Mar 23, 2017 at 12:30:18AM -0700, l...@pengaru.com wrote: > > > On Wed, Mar 22, 2017 at 11:44:18PM -0700, l...@pengaru.com wrote: > > > > On Wed, Mar 22, 2017 at

Re: [BUG] 4.11.0-rc3 xterm hung in D state on exit, wchan is tty_release_struct

On Thu, Mar 23, 2017 at 11:57:22AM -0500, Rob Herring wrote: > On Thu, Mar 23, 2017 at 08:46:03AM -0500, Rob Herring wrote: > > On Thu, Mar 23, 2017 at 12:30:18AM -0700, l...@pengaru.com wrote: > > > On Wed, Mar 22, 2017 at 11:44:18PM -0700, l...@pengaru.com wrote: > > > > On Wed, Mar 22, 2017 at

Re: [BUG] 4.11.0-rc3 xterm hung in D state on exit, wchan is tty_release_struct

On Thu, Mar 23, 2017 at 08:46:03AM -0500, Rob Herring wrote: > On Thu, Mar 23, 2017 at 12:30:18AM -0700, l...@pengaru.com wrote: > > On Wed, Mar 22, 2017 at 11:44:18PM -0700, l...@pengaru.com wrote: > > > On Wed, Mar 22, 2017 at 07:08:46PM -0700, l...@pengaru.com wrote: > > > > Hello list, > > > >

Re: [BUG] 4.11.0-rc3 xterm hung in D state on exit, wchan is tty_release_struct

On Thu, Mar 23, 2017 at 08:46:03AM -0500, Rob Herring wrote: > On Thu, Mar 23, 2017 at 12:30:18AM -0700, l...@pengaru.com wrote: > > On Wed, Mar 22, 2017 at 11:44:18PM -0700, l...@pengaru.com wrote: > > > On Wed, Mar 22, 2017 at 07:08:46PM -0700, l...@pengaru.com wrote: > > > > Hello list, > > > >

Re: [BUG] 4.11.0-rc3 xterm hung in D state on exit, wchan is tty_release_struct

On Thu, Mar 23, 2017 at 12:30:18AM -0700, l...@pengaru.com wrote: > On Wed, Mar 22, 2017 at 11:44:18PM -0700, l...@pengaru.com wrote: > > On Wed, Mar 22, 2017 at 07:08:46PM -0700, l...@pengaru.com wrote: > > > Hello list, > > > > > > After approximately one day day of running 4.11.0-rc3 with

Re: [BUG] 4.11.0-rc3 xterm hung in D state on exit, wchan is tty_release_struct

On Thu, Mar 23, 2017 at 12:30:18AM -0700, l...@pengaru.com wrote: > On Wed, Mar 22, 2017 at 11:44:18PM -0700, l...@pengaru.com wrote: > > On Wed, Mar 22, 2017 at 07:08:46PM -0700, l...@pengaru.com wrote: > > > Hello list, > > > > > > After approximately one day day of running 4.11.0-rc3 with

Re: [BUG] 4.11.0-rc3 xterm hung in D state on exit, wchan is tty_release_struct

On Wed, Mar 22, 2017 at 07:08:46PM -0700, l...@pengaru.com wrote: > Hello list, > > After approximately one day day of running 4.11.0-rc3 with 7e54d9d reverted to > enable regular use, this happened upon destroying an xterm: > > [80817.525112] BUG: unable to handle kernel paging request at

Re: [BUG] 4.11.0-rc3 xterm hung in D state on exit, wchan is tty_release_struct

On Wed, Mar 22, 2017 at 07:08:46PM -0700, l...@pengaru.com wrote: > Hello list, > > After approximately one day day of running 4.11.0-rc3 with 7e54d9d reverted to > enable regular use, this happened upon destroying an xterm: > > [80817.525112] BUG: unable to handle kernel paging request at

Re: [BUG] 4.11.0-rc3 xterm hung in D state on exit, wchan is tty_release_struct

On Wed, Mar 22, 2017 at 11:44:18PM -0700, l...@pengaru.com wrote: > On Wed, Mar 22, 2017 at 07:08:46PM -0700, l...@pengaru.com wrote: > > Hello list, > > > > After approximately one day day of running 4.11.0-rc3 with 7e54d9d reverted > > to > > enable regular use, this happened upon destroying

Re: [BUG] 4.11.0-rc3 xterm hung in D state on exit, wchan is tty_release_struct

On Wed, Mar 22, 2017 at 11:44:18PM -0700, l...@pengaru.com wrote: > On Wed, Mar 22, 2017 at 07:08:46PM -0700, l...@pengaru.com wrote: > > Hello list, > > > > After approximately one day day of running 4.11.0-rc3 with 7e54d9d reverted > > to > > enable regular use, this happened upon destroying

[BUG] 4.11.0-rc3 xterm hung in D state on exit, wchan is tty_release_struct

Hello list, After approximately one day day of running 4.11.0-rc3 with 7e54d9d reverted to enable regular use, this happened upon destroying an xterm: [80817.525112] BUG: unable to handle kernel paging request at 2260 [80817.525239] IP: n_tty_receive_buf_common+0x68/0xab0

[BUG] 4.11.0-rc3 xterm hung in D state on exit, wchan is tty_release_struct

Hello list, After approximately one day day of running 4.11.0-rc3 with 7e54d9d reverted to enable regular use, this happened upon destroying an xterm: [80817.525112] BUG: unable to handle kernel paging request at 2260 [80817.525239] IP: n_tty_receive_buf_common+0x68/0xab0

[PATCH 3.16.y-ckt 099/254] um: ubd: Fix for processes stuck in D state forever

3.16.7-ckt2 -stable review patch. If anyone has any objections, please let me know. -- From: Thorsten Knabe commit 2a2361228c5e6d8c1733f00653481de918598e50 upstream. Starting with Linux 3.12 processes get stuck in D state forever in UserModeLinux under sync heavy workloads

[PATCH 3.16.y-ckt 099/254] um: ubd: Fix for processes stuck in D state forever

3.16.7-ckt2 -stable review patch. If anyone has any objections, please let me know. -- From: Thorsten Knabe li...@thorsten-knabe.de commit 2a2361228c5e6d8c1733f00653481de918598e50 upstream. Starting with Linux 3.12 processes get stuck in D state forever in UserModeLinux under

[PATCH 3.12 076/206] um: ubd: Fix for processes stuck in D state forever

From: Thorsten Knabe 3.12-stable review patch. If anyone has any objections, please let me know. === commit 2a2361228c5e6d8c1733f00653481de918598e50 upstream. Starting with Linux 3.12 processes get stuck in D state forever in UserModeLinux under sync heavy workloads. This bug

[PATCH 3.12 076/206] um: ubd: Fix for processes stuck in D state forever

From: Thorsten Knabe li...@thorsten-knabe.de 3.12-stable review patch. If anyone has any objections, please let me know. === commit 2a2361228c5e6d8c1733f00653481de918598e50 upstream. Starting with Linux 3.12 processes get stuck in D state forever in UserModeLinux under sync heavy

[PATCH 3.14 044/203] um: ubd: Fix for processes stuck in D state forever

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Thorsten Knabe commit 2a2361228c5e6d8c1733f00653481de918598e50 upstream. Starting with Linux 3.12 processes get stuck in D state forever in UserModeLinux under sync heavy workloads. This bug

[PATCH 3.17 069/319] um: ubd: Fix for processes stuck in D state forever

3.17-stable review patch. If anyone has any objections, please let me know. -- From: Thorsten Knabe commit 2a2361228c5e6d8c1733f00653481de918598e50 upstream. Starting with Linux 3.12 processes get stuck in D state forever in UserModeLinux under sync heavy workloads. This bug

[PATCH 3.17 069/319] um: ubd: Fix for processes stuck in D state forever

3.17-stable review patch. If anyone has any objections, please let me know. -- From: Thorsten Knabe li...@thorsten-knabe.de commit 2a2361228c5e6d8c1733f00653481de918598e50 upstream. Starting with Linux 3.12 processes get stuck in D state forever in UserModeLinux under sync

[PATCH 3.14 044/203] um: ubd: Fix for processes stuck in D state forever

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Thorsten Knabe li...@thorsten-knabe.de commit 2a2361228c5e6d8c1733f00653481de918598e50 upstream. Starting with Linux 3.12 processes get stuck in D state forever in UserModeLinux under sync

[PATCH 3.13 092/105] um: ubd: Fix for processes stuck in D state forever

3.13.11.10 -stable review patch. If anyone has any objections, please let me know. -- From: Thorsten Knabe commit 2a2361228c5e6d8c1733f00653481de918598e50 upstream. Starting with Linux 3.12 processes get stuck in D state forever in UserModeLinux under sync heavy workloads

[PATCH 3.13 092/105] um: ubd: Fix for processes stuck in D state forever

3.13.11.10 -stable review patch. If anyone has any objections, please let me know. -- From: Thorsten Knabe li...@thorsten-knabe.de commit 2a2361228c5e6d8c1733f00653481de918598e50 upstream. Starting with Linux 3.12 processes get stuck in D state forever in UserModeLinux under

Re: [PATCH] UML: UBD: Fix for processes stuck in D state forever in UserModeLinux

>>>> Am 23.08.2014 19:43, schrieb Thorsten Knabe: >>>>>> Hi Richard. >>>>>> >>>>>> On 08/23/2014 05:34 PM, Richard Weinberger wrote: >>>>>>> Hi! >>>>>>> >>>>>>> A

Re: [PATCH] UML: UBD: Fix for processes stuck in D state forever in UserModeLinux

Thorsten Knabe: Hi Richard. On 08/23/2014 05:34 PM, Richard Weinberger wrote: Hi! Am 23.08.2014 15:47, schrieb Thorsten Knabe: From: Thorsten Knabe li...@thorsten-knabe.de UML: UBD: Fix for processes stuck in D state forever in UserModeLinux. Starting with Linux 3.12 processes get stuck

Re: [PATCH] UML: UBD: Fix for processes stuck in D state forever in UserModeLinux

; Hi Richard. >>>>> >>>>> On 08/23/2014 05:34 PM, Richard Weinberger wrote: >>>>>> Hi! >>>>>> >>>>>> Am 23.08.2014 15:47, schrieb Thorsten Knabe: >>>>>>> From: Thorsten Knabe >>>>

Re: [PATCH] UML: UBD: Fix for processes stuck in D state forever in UserModeLinux

8/23/2014 05:34 PM, Richard Weinberger wrote: >>>>> Hi! >>>>> >>>>> Am 23.08.2014 15:47, schrieb Thorsten Knabe: >>>>>> From: Thorsten Knabe >>>>>> >>>>>> UML: UBD: Fix for processes stuck in D state forever in

Re: [PATCH] UML: UBD: Fix for processes stuck in D state forever in UserModeLinux

>>>> Am 23.08.2014 15:47, schrieb Thorsten Knabe: >>>>> From: Thorsten Knabe >>>>> >>>>> UML: UBD: Fix for processes stuck in D state forever in UserModeLinux. >>>>> >>>>> Starting with Linux 3.12 processes get stu

Re: [PATCH] UML: UBD: Fix for processes stuck in D state forever in UserModeLinux

-knabe.de UML: UBD: Fix for processes stuck in D state forever in UserModeLinux. Starting with Linux 3.12 processes get stuck in D state forever in UserModeLinux under sync heavy workloads. This bug was introduced by commit 805f11a0d5 (um: ubd: Add REQ_FLUSH suppport). Fix bug by adding a check

Re: [PATCH] UML: UBD: Fix for processes stuck in D state forever in UserModeLinux

Thorsten Knabe: From: Thorsten Knabe li...@thorsten-knabe.de UML: UBD: Fix for processes stuck in D state forever in UserModeLinux. Starting with Linux 3.12 processes get stuck in D state forever in UserModeLinux under sync heavy workloads. This bug was introduced by commit 805f11a0d5 (um: ubd

Re: [PATCH] UML: UBD: Fix for processes stuck in D state forever in UserModeLinux

wrote: Hi! Am 23.08.2014 15:47, schrieb Thorsten Knabe: From: Thorsten Knabe li...@thorsten-knabe.de UML: UBD: Fix for processes stuck in D state forever in UserModeLinux. Starting with Linux 3.12 processes get stuck in D state forever in UserModeLinux under sync heavy workloads. This bug

Re: [PATCH] UML: UBD: Fix for processes stuck in D state forever in UserModeLinux

From: Thorsten Knabe >>>> >>>> UML: UBD: Fix for processes stuck in D state forever in UserModeLinux. >>>> >>>> Starting with Linux 3.12 processes get stuck in D state forever in >>>> UserModeLinux under sync heavy workloads. This bug was

Re: [PATCH] UML: UBD: Fix for processes stuck in D state forever in UserModeLinux

Am 23.08.2014 19:43, schrieb Thorsten Knabe: > Hi Richard. > > On 08/23/2014 05:34 PM, Richard Weinberger wrote: >> Hi! >> >> Am 23.08.2014 15:47, schrieb Thorsten Knabe: >>> From: Thorsten Knabe >>> >>> UML: UBD: Fix for processes stuck

Re: [PATCH] UML: UBD: Fix for processes stuck in D state forever in UserModeLinux

Am 23.08.2014 19:43, schrieb Thorsten Knabe: Hi Richard. On 08/23/2014 05:34 PM, Richard Weinberger wrote: Hi! Am 23.08.2014 15:47, schrieb Thorsten Knabe: From: Thorsten Knabe li...@thorsten-knabe.de UML: UBD: Fix for processes stuck in D state forever in UserModeLinux. Starting

Re: [PATCH] UML: UBD: Fix for processes stuck in D state forever in UserModeLinux

in D state forever in UserModeLinux. Starting with Linux 3.12 processes get stuck in D state forever in UserModeLinux under sync heavy workloads. This bug was introduced by commit 805f11a0d5 (um: ubd: Add REQ_FLUSH suppport). Fix bug by adding a check if FLUSH request was successfully submitted

Re: [PATCH] UML: UBD: Fix for processes stuck in D state forever in UserModeLinux

Hi Richard. On 08/23/2014 05:34 PM, Richard Weinberger wrote: > Hi! > > Am 23.08.2014 15:47, schrieb Thorsten Knabe: >> From: Thorsten Knabe >> >> UML: UBD: Fix for processes stuck in D state forever in UserModeLinux. >> >> Starting with Linux 3.12

Re: [PATCH] UML: UBD: Fix for processes stuck in D state forever in UserModeLinux

Hi! Am 23.08.2014 15:47, schrieb Thorsten Knabe: > From: Thorsten Knabe > > UML: UBD: Fix for processes stuck in D state forever in UserModeLinux. > > Starting with Linux 3.12 processes get stuck in D state forever in > UserModeLinux under sync heavy workloads. This

[PATCH] UML: UBD: Fix for processes stuck in D state forever in UserModeLinux

From: Thorsten Knabe UML: UBD: Fix for processes stuck in D state forever in UserModeLinux. Starting with Linux 3.12 processes get stuck in D state forever in UserModeLinux under sync heavy workloads. This bug was introduced by commit 805f11a0d5 (um: ubd: Add REQ_FLUSH suppport). Fix bug

[PATCH] UML: UBD: Fix for processes stuck in D state forever in UserModeLinux

From: Thorsten Knabe li...@thorsten-knabe.de UML: UBD: Fix for processes stuck in D state forever in UserModeLinux. Starting with Linux 3.12 processes get stuck in D state forever in UserModeLinux under sync heavy workloads. This bug was introduced by commit 805f11a0d5 (um: ubd: Add REQ_FLUSH

Re: [PATCH] UML: UBD: Fix for processes stuck in D state forever in UserModeLinux

Hi! Am 23.08.2014 15:47, schrieb Thorsten Knabe: From: Thorsten Knabe li...@thorsten-knabe.de UML: UBD: Fix for processes stuck in D state forever in UserModeLinux. Starting with Linux 3.12 processes get stuck in D state forever in UserModeLinux under sync heavy workloads. This bug

Re: [PATCH] UML: UBD: Fix for processes stuck in D state forever in UserModeLinux

Hi Richard. On 08/23/2014 05:34 PM, Richard Weinberger wrote: Hi! Am 23.08.2014 15:47, schrieb Thorsten Knabe: From: Thorsten Knabe li...@thorsten-knabe.de UML: UBD: Fix for processes stuck in D state forever in UserModeLinux. Starting with Linux 3.12 processes get stuck in D state

Re: Killing process in D state on mount to dead NFS server. (when process is in fsync)

On Fri, Aug 1, 2014 at 11:19 PM, NeilBrown wrote: > On Fri, 1 Aug 2014 22:55:42 -0400 Trond Myklebust wrote: > >> > That still leaves some open questions though... >> > >> > Is that enough to fix it? You'd still have the dirty pages lingering >> > around, right? Would a umount -f presumably work

Re: Killing process in D state on mount to dead NFS server. (when process is in fsync)

On Fri, 1 Aug 2014 22:55:42 -0400 Trond Myklebust wrote: > > That still leaves some open questions though... > > > > Is that enough to fix it? You'd still have the dirty pages lingering > > around, right? Would a umount -f presumably work at that point? > > 'umount -f' will kill any outstanding

Re: Killing process in D state on mount to dead NFS server. (when process is in fsync)

On Fri, Aug 1, 2014 at 9:21 PM, Jeff Layton wrote: > On Fri, 1 Aug 2014 07:50:53 +1000 > NeilBrown wrote: > >> On Thu, 31 Jul 2014 14:20:07 -0700 Ben Greear >> wrote: >> >> > -BEGIN PGP SIGNED MESSAGE- >> > Hash: SHA1 >> > >> > On 07/31/2014 01:42 PM, NeilBrown wrote: >> > > On Thu, 31

Re: Killing process in D state on mount to dead NFS server. (when process is in fsync)

On Fri, 1 Aug 2014 20:50:13 -0500 Roger Heflin wrote: > Doesn't NFS have an intr flag to allow kill -9 to work? Whenever I > have had that set it has appeared to work after about 30 seconds or > so...without that kill -9 does not work when the nfs server is > missing. > > Not anymore. That

Re: Killing process in D state on mount to dead NFS server. (when process is in fsync)

Doesn't NFS have an intr flag to allow kill -9 to work? Whenever I have had that set it has appeared to work after about 30 seconds or so...without that kill -9 does not work when the nfs server is missing. On Fri, Aug 1, 2014 at 8:21 PM, Jeff Layton wrote: > On Fri, 1 Aug 2014 07:50:53

Re: Killing process in D state on mount to dead NFS server. (when process is in fsync)

On Fri, 1 Aug 2014 07:50:53 +1000 NeilBrown wrote: > On Thu, 31 Jul 2014 14:20:07 -0700 Ben Greear wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On 07/31/2014 01:42 PM, NeilBrown wrote: > > > On Thu, 31 Jul 2014 11:00:35 -0700 Ben Greear > > > wrote: > > > > > >>

Re: Killing process in D state on mount to dead NFS server. (when process is in fsync)

On Fri 01-08-14 07:50:53, NeilBrown wrote: > On Thu, 31 Jul 2014 14:20:07 -0700 Ben Greear wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On 07/31/2014 01:42 PM, NeilBrown wrote: > > > On Thu, 31 Jul 2014 11:00:35 -0700 Ben Greear > > > wrote: > > > > > >> So, this has

Re: Killing process in D state on mount to dead NFS server. (when process is in fsync)

On Fri 01-08-14 07:50:53, NeilBrown wrote: On Thu, 31 Jul 2014 14:20:07 -0700 Ben Greear gree...@candelatech.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/31/2014 01:42 PM, NeilBrown wrote: On Thu, 31 Jul 2014 11:00:35 -0700 Ben Greear gree...@candelatech.com

Re: Killing process in D state on mount to dead NFS server. (when process is in fsync)

On Fri, 1 Aug 2014 07:50:53 +1000 NeilBrown ne...@suse.de wrote: On Thu, 31 Jul 2014 14:20:07 -0700 Ben Greear gree...@candelatech.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/31/2014 01:42 PM, NeilBrown wrote: On Thu, 31 Jul 2014 11:00:35 -0700 Ben Greear

Re: Killing process in D state on mount to dead NFS server. (when process is in fsync)

Doesn't NFS have an intr flag to allow kill -9 to work? Whenever I have had that set it has appeared to work after about 30 seconds or so...without that kill -9 does not work when the nfs server is missing. On Fri, Aug 1, 2014 at 8:21 PM, Jeff Layton jlay...@poochiereds.net wrote: On Fri, 1

Re: Killing process in D state on mount to dead NFS server. (when process is in fsync)

On Fri, 1 Aug 2014 20:50:13 -0500 Roger Heflin rogerhef...@gmail.com wrote: Doesn't NFS have an intr flag to allow kill -9 to work? Whenever I have had that set it has appeared to work after about 30 seconds or so...without that kill -9 does not work when the nfs server is missing. Not

Re: Killing process in D state on mount to dead NFS server. (when process is in fsync)

On Fri, Aug 1, 2014 at 9:21 PM, Jeff Layton jlay...@poochiereds.net wrote: On Fri, 1 Aug 2014 07:50:53 +1000 NeilBrown ne...@suse.de wrote: On Thu, 31 Jul 2014 14:20:07 -0700 Ben Greear gree...@candelatech.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/31/2014 01:42

Re: Killing process in D state on mount to dead NFS server. (when process is in fsync)

On Fri, 1 Aug 2014 22:55:42 -0400 Trond Myklebust tron...@gmail.com wrote: That still leaves some open questions though... Is that enough to fix it? You'd still have the dirty pages lingering around, right? Would a umount -f presumably work at that point? 'umount -f' will kill any

Re: Killing process in D state on mount to dead NFS server. (when process is in fsync)

On Fri, Aug 1, 2014 at 11:19 PM, NeilBrown ne...@suse.de wrote: On Fri, 1 Aug 2014 22:55:42 -0400 Trond Myklebust tron...@gmail.com wrote: That still leaves some open questions though... Is that enough to fix it? You'd still have the dirty pages lingering around, right? Would a umount -f

Re: Killing process in D state on mount to dead NFS server. (when process is in fsync)

On Thu, 31 Jul 2014 14:20:07 -0700 Ben Greear wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/31/2014 01:42 PM, NeilBrown wrote: > > On Thu, 31 Jul 2014 11:00:35 -0700 Ben Greear > > wrote: > > > >> So, this has been asked all over the interweb for years and years, but the

Re: Killing process in D state on mount to dead NFS server. (when process is in fsync)

On Thu, 31 Jul 2014 14:20:07 -0700 Ben Greear gree...@candelatech.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/31/2014 01:42 PM, NeilBrown wrote: On Thu, 31 Jul 2014 11:00:35 -0700 Ben Greear gree...@candelatech.com wrote: So, this has been asked all over the

Re: Processes in D state / development of real-time apps

s of the kernel given the involvement of tty/sshd/and > a process stuck in "D" state waiting on flush_work. Yeah, when workqueues can't run, box stops working. > I am developing an application where many threads are spin-waiting on > input--i.e., they are pegged at 100%. One thr

Processes in D state / development of real-time apps

All: I am simply not sure whether this is the right list to post this question to. Please redirect me if not. I chose to post here based on some indications that the problem may involve some aspects of the kernel given the involvement of tty/sshd/and a process stuck in "D" sta

Processes in D state / development of real-time apps

All: I am simply not sure whether this is the right list to post this question to. Please redirect me if not. I chose to post here based on some indications that the problem may involve some aspects of the kernel given the involvement of tty/sshd/and a process stuck in D state waiting

Re: Processes in D state / development of real-time apps

the involvement of tty/sshd/and a process stuck in D state waiting on flush_work. Yeah, when workqueues can't run, box stops working. I am developing an application where many threads are spin-waiting on input--i.e., they are pegged at 100%. One thread per CPU. The spin is on a memory location

Re: How to diagnose a process stuck in D state?

gs, with the > process stuck D state. When this happens, the process sticks around > until I reboot the machine. > > I have tried the following to start diagnosing the problem: > > * Running 'ps -axl' shows "-" in the wchan column. > * The contents of /proc/pi

  1   2   3   4   5   6   7   >