Description of problem: The Linux distro is running as a virtual machine in VMWare player 6.0.3. The machine was programmed to execute an rsync on fedora 23 repo starting at 18:00. When I tried to use the system the next morning at 8:00, I discovered the error. I was able to open another instance of text terminal login (Ctrl-Alt-F3). I saw the rsync completed. I had to execute 'shutdown -r now' to recover the GUI interface. Additional info: reporter: libreport-2.6.3 NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [rcuos/1:18] Modules linked in: arc4 md4 cifs dns_resolver fscache nls_utf8 hfsplus vfat fat loop rfcomm fuse xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_filter ebtable_broute bridge stp llc ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw vmw_vsock_vmci_transport vsock bnep iosf_mbi coretemp ppdev crct10dif_pclmul crc32_pclmul crc32c_intel btusb btrtl btbcm btintel bluetooth vmw_balloon joydev rfkill vmw_vmci i2c_piix4 shpchp parport_pc parport acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc vmwgfx drm_kms_helper serio_raw ttm mptspi drm e1000 scsi_transport_spi mptscsih mptbase ata_generic pata_acpi irq event stamp: 603884487 hardirqs last enabled at (603884486): [<ffffffff81872bc6>] _raw_spin_unlock_irqrestore+0x36/0x60 hardirqs last disabled at (603884487): [<ffffffff8187454b>] apic_timer_interrupt+0x6b/0x80 softirqs last enabled at (603873202): [<ffffffff8112b2bd>] rcu_nocb_kthread+0x20d/0x5f0 softirqs last disabled at (603873203): [<ffffffff8187539c>] do_softirq_own_stack+0x1c/0x30 CPU: 0 PID: 18 Comm: rcuos/1 Not tainted 4.2.6-301.fc23.x86_64+debug #1 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013 task: ffff8801326f5480 ti: ffff880132700000 task.ti: ffff880132700000 RIP: 0010:[<ffffffffa0010586>] [<ffffffffa0010586>] mpt_put_msg_frame+0x66/0x90 [mptbase] RSP: 0018:ffff880133603b78 EFLAGS: 00000246 RAX: ffffc90000900000 RBX: ffffffff811285ad RCX: 00000000000003c0 RDX: ffff880035913a00 RSI: 000000000000000a RDI: 000000000000000e RBP: ffff880133603b88 R08: 0000000000000003 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff880133603ae8 R13: ffffffff81874550 R14: ffff880133603b88 R15: 00000000b76c2bc3 FS: 0000000000000000(0000) GS:ffff880133600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fed29f0b000 CR3: 0000000105012000 CR4: 00000000001406f0 Stack: ffff8800b7651498 ffff8800b76cdf6c ffff880133603c38 ffffffffa002f6ce ffff8800b7650008 0400000006b51340 000000000000000a 0000000000000028 ffff8800b7650170 000000600000000a ffff8800b76cdf6c ffff8800b76c2bc0 Call Trace:
Created attachment 1103892 [details] File: dmesg
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 23 kernel bugs. Fedora 23 has now been rebased to 4.7.4-100.fc23. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 24 or 25, and are still experiencing this issue, please change the version to Fedora 24 or 25. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 4 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.
(In reply to Laura Abbott from comment #3) > *********** MASS BUG UPDATE ************** > This bug is being closed with INSUFFICIENT_DATA as there has not been a > response in 4 weeks. If you are still experiencing this issue, please reopen > and attach the relevant data from the latest kernel you are running and any > data that might have been requested previously. In fact, we have passed to kernel 4.6.4 in end July and have not seen such an issue.