Your message dated Mon, 18 Feb 2019 13:34:28 +0000
with message-id <[email protected]>
and subject line Re: task xenconsoled blocked in state D after reboot
has caused the Debian Bug report #869123,
regarding task xenconsoled blocked in state D after reboot
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
869123: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869123
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: xen-utils-4.4
Version: 4.4.1-9+deb8u9
Severity: normal
Hi,
Since the latest security update of the xen 4.4 packages we notice that
after rebooting a dom0, there's a chance that the xenconsoled process
ends up hanging in D state.
The kernel logs show these messages repeatedly:
INFO: task xenconsoled:1135 blocked for more than 120 seconds.
Not tainted 3.16.0-4-amd64 #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
xenconsoled D ffff88017ce2c628 0 1135 1 0x00000000
ffff88017ce2c1d0 0000000000000286 0000000000012f40 ffff8800776b3fd8
0000000000012f40 ffff88017ce2c1d0 ffff88017ccc7848 ffff8800776b3f20
ffff88017ccc784c ffff88017ce2c1d0 00000000ffffffff ffff88017ccc7850
Call Trace:
[<ffffffff81517095>] ? schedule_preempt_disabled+0x25/0x70
[<ffffffff81518b33>] ? __mutex_lock_slowpath+0xd3/0x1d0
[<ffffffff81518c4b>] ? mutex_lock+0x1b/0x2a
[<ffffffff811c753d>] ? __fdget_pos+0x3d/0x50
[<ffffffff811aba4a>] ? SyS_write+0x1a/0xa0
[<ffffffff8151a48d>] ? system_call_fast_compare_end+0x10/0x15
Also:
-# cat /proc/1135/stack
[<ffffffff811c753d>] __fdget_pos+0x3d/0x50
[<ffffffff811aba4a>] SyS_write+0x1a/0xa0
[<ffffffff8151a48d>] system_call_fast_compare_end+0x10/0x15
[<ffffffffffffffff>] 0xffffffffffffffff
I have seen this happening multiple times now, and have never seen it in
the past with Xen on Jessie. The servers used are HP Proliant dl360 gen8
and gen9 types.
I have an empty dom0 in this state currently, so I could do more
investigation right now. If there's quick feedback on this bug, I can
probably keep it blacklisted for usage until monday.
Another problem that might possibly be related is the fact that the
serial console of the dom0 stops giving any output right at '(XEN) Dom0
has maximum 4 VCPUs'. But, that problem is already present for years,
and if that happens, we usually (argh) reboot again until it stays
responding. I haven't ever seen a proper explanation or fix for this
issue in the past years. But it's also happening right now here. When
doing a reboot later, during shutdown, the serial console (here attached
to the HP ilo virtual serial console) will suddenly start printing all
text like everything has been buffered somewhere.
But, I'm not touching this thing right now or trying anything yet. Hope
we can come up with some useful debugging steps that might help finding
this xenconsoled problem.
--
Thanks,
Hans van Kranenburg
--- End Message ---
--- Begin Message ---
Version: 4.11.1-1
On 1/24/19 12:10 AM, Hans van Kranenburg wrote:
> tags 869123 + moreinfo
> thanks
>
> Hi Hans,
>
> This is about the bug report about xenconsoled ending up in state D that
> you filed before in the Debian bug tracker, against the Xen packages.
>
> [...]
> * I had this problem, and since upgrading to Stretch / Buster / ? it
> seems it was solved, and I forgot to report it again. Please close it,
> thanks.
I haven't seen this happen with the 4.11 packages at all.
With Jessie 4.4 it happens sporadically.
Hans
--- End Message ---
