similar to: Debian kernel bug - task blocked for more than 120 seconds

Dear Debian-Bugteam Unfortunately this problem still exists. I want to use the server in production environment, but can't by reason of this error. Installed XEN-Versions: ii xen-hypervisor-4.4-amd64 4.4.1-9+deb8u5 amd64 Xen Hypervisor on AMD64 ii xen-linux-system-3.16.0-4-amd64 3.16.7-ckt25-2 amd64

Dear XEN-Team I've set up a complete new VM, tested copying and backuping with following error again: [ 1920.052129] INFO: task jbd2/xvda2-8:98 blocked for more than 120 seconds. [ 1920.052143] Not tainted 3.16.0-4-amd64 #1 [ 1920.052147] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1920.052153] jbd2/xvda2-8 D ffff880004986e78 0 98

Hi All. I have a server which hanged two times because we could not connect to the box, it was not responding. In /var/log/messages I saw: Apr 11 10:13:29 server kernel: INFO: task imap:5855 blocked for more than 120 seconds. Apr 11 10:13:29 server kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Apr 11 10:13:29 server kernel: imap D

Package: xen-hypervisor-4.4-amd64 Version: 4.4.1-9+deb8u4 Severity: grave Justification: renders package unusable Dear Maintainer, * What led up to the situation? Running Backup Exec or a copy command to NFS-Share causes the VM regurarly to freeze. First message on VM-Console: ---------------------------------------------------------------------------------------------------------------

This may or may not be CentOS related, but am out of ideas at this point and wanted to bounce this off the list. I'm running a CentOS 5.5 server, running the latest kernel 2.6.18-194.32.1.el5. Almost everyday around 3:30 AM the server completely locks up and has to be power cycled before it will come back online. (this means someone hat to wake up and reboot the server, oh how I love being

Hello all, Anybody found this problem before? I kept hitting this issue for 2.6.31 guest kernel even with a simple network test. INFO: task kjournal:337 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_sec" disables this message. kjournald D 00000041 0 337 2 0x00000000 My test is totally being blocked. Thanks Shirley

Hello all, Anybody found this problem before? I kept hitting this issue for 2.6.31 guest kernel even with a simple network test. INFO: task kjournal:337 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_sec" disables this message. kjournald D 00000041 0 337 2 0x00000000 My test is totally being blocked. Thanks Shirley

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I did some configuration changes on a XenServer 5.6 (Which I believe is running CentOS 5.5 under the hood). After a reboot, the server failed to come back up. Connecting to the serial console, I see that it hangs right after setting hostname: Setting hostname somehostname: [ OK ] INFO: task nash:5282 blocked for more than 120 seconds. "echo

If I manually delete the Q35 USB Controllers, I can use managedsave/start, but I start getting tty errors that don't happen before the managedsave/start. Using libvirt 1.2.18 (-1 Arch) and QEMU git-master (2.4.0.r40384.2d69736). Installed using Q35 chipset. I'm running QEMU git, which allows SCSI controller migration, so I can attempt doing this. I started my guest, and waited for 15

Good morning, we've recently had some strange message in /var/log/syslog. System: debian bullseye, kernel 5.10.0-21-amd64 and 5.10.0-22-amd64 gluster 10.3 The message look like: Apr 27 13:30:18 piggy kernel: [24287.715229] INFO: task glfs_fusenoti:2787 blocked for more than 120 seconds. Apr 27 13:30:18 piggy kernel: [24287.715327] Not tainted 5.10.0-22-amd64 #1 Debian 5.10.178-3 Apr

Hello, Sacha, le ven. 08 févr. 2019 18:00:22 +0100, a ecrit: > On  Debian GNU/Linux 9.7 (stretch) amd64, we have a bug on the last Xen > Hypervisor version: > > xen-hypervisor-4.8-amd64 4.8.5+shim4.10.2+xsa282 (Read: 4.8.5+shim4.10.2+xsa282-1+deb9u11) > The rollback on the previous package version corrected the problem: > > xen-hypervisor-4.8-amd64

On 2/11/19 2:37 AM, Dongli Zhang wrote: > > On 2/10/19 12:35 AM, Samuel Thibault wrote: >> >> Hans van Kranenburg, le sam. 09 févr. 2019 17:01:55 +0100, a ecrit: >>>> I have forwarded the original mail: all VM I/O get stuck, and thus the >>>> VM becomes unusable. >>> >>> These are in many cases the symptoms of running out of "grant

I don't think the issue is on gluster side, it seems the issue is on kernel side (possible deadlock in fuse_reverse_inval_entry) https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bda9a71980e083699a0360963c0135657b73f47a On Tue, May 2, 2023 at 5:48?PM Hu Bert <revirii at googlemail.com> wrote: > Good morning, > > we've recently had some strange

Hello, Hans van Kranenburg, le sam. 09 févr. 2019 17:01:55 +0100, a ecrit: > > I have forwarded the original mail: all VM I/O get stuck, and thus the > > VM becomes unusable. > > These are in many cases the symptoms of running out of "grant frames". Oh! That could be it indeed. I'm wondering what could be monopolizing them, though, and why +deb9u11 is affected

On 02/12/2019 06:10 AM, Samuel Thibault wrote: > Hans van Kranenburg, le lun. 11 févr. 2019 22:59:11 +0100, a ecrit: >> On 2/11/19 2:37 AM, Dongli Zhang wrote: >>> >>> On 2/10/19 12:35 AM, Samuel Thibault wrote: >>>> >>>> Hans van Kranenburg, le sam. 09 févr. 2019 17:01:55 +0100, a ecrit: >>>>>> I have forwarded the original

02:00.0 VGA compatible controller: NVIDIA Corporation G98 [GeForce 8400 GS Rev. 2] (rev a1) Chipset: G98 (NV98) Family : NV50 The same for all four kernel: - 3.18.0-0.rc0.git8.1.fc22.x86_64 - 3.18.0-0.rc0.git9.1.fc22.x86_64 - 3.18.0-0.rc0.git9.3.fc22.x86_64 - 3.18.0-0.rc0.git9.4.fc22.x86_64 after "fb: switching to nouveaufb from VESA VGA" display is powered off. The magic SysRq key

Hey, I''ve a 2x4TB RAID1 setup with btrfs on kernel 3.8.0. Under high I/O load (BackupPC dump or writing a large file over gigabit) I get messages in syslog such as the one mentioned in the subject. The full non-logcheck-ignored log is under [1]. A BackupPC dump between the same exact machines onto a 2TB ext4 volume take 90 minutes on average, the process on the btrfs volume took 465

Hello all: I have two machines with btrfs, that give me the "blocked for more than 120 seconds" message. After that I cannot write anything to disk, i am unable to unmount the btrfs filesystem and i can only reboot with sysrq-trigger. It always happens when i write many files with rsync over network. When i used 3.2rc6 it happened randomly on both machines after 50-500gb of writes.

https://bugs.freedesktop.org/show_bug.cgi?id=91413 Bug ID: 91413 Summary: INFO: task Xorg:2419 blocked for more than 120 seconds. Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau

Hello, yesterday night I had a problem with my server located at a hoster (strato.de). I couldn't ssh to it and over the remote serial console I saw "out of memory" errors (sorry, don't have the text). Then I had reinstall CentOS 5.5/64 bit + all my setup (2h work), because I have a contract with a social network and they will shut down my little card game if it is not