Date: Thu, 17 Sep 2020 23:31:54 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 248659] random system freezes Message-ID: <bug-248659-227-3OY17KHIxx@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-248659-227@https.bugs.freebsd.org/bugzilla/> References: <bug-248659-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D248659 --- Comment #5 from rkoberman@gmail.com --- I've continued to analyze the problem. Don't know if this will help track it soen, but I have noted the following: System is substantially more stable under X (Mate) than under just VT. Once= I start Mate, I often have the system stay up and running for over an hour. W= hen X11 is not running, I have not seen the system stay operational for over 10 minutes when the keyboard is not active. Also, when working on X, I have had the system lock up even when the keyboard is active. I have not tested the reliability of the system when using a vty while X is also running. The freeze is not instantaneous. With my system monitor running and a bulk = disk to disk data transfer running (rsync of 190GB of media files) from a USB di= sk to the system disk, I note that the transfer slow dramatically a few seconds before the complete freeze. The write rate slowly declines from over 50MBps= to zero. When it reaches zero, the system may be barely alive. I have managed = to do a sync(1) once or twice which greatly reduces the number of corrections needed by fsck when I reboot. Even when the keyboard stops responding, my system monitor (gkrellm) will continue to update for a few seconds and on a couple of occasions, Ctrl-C to a frozen process caused the system to become responsive again for a couple of seconds with the system monitor updating a= nd commands typed but not even echoed to appear in terminal windows. My system has only 4B of RAM, so is rather restricted. Have not been able to even try running a VM on it. I have 16 G on order, but lost in the mail. The system ahd a WD Black 2TB drive. Could a drive issue be at the root? The initial report wee also on a fairly recent Lenovo system. Could a bad disk batch be the trigger? But, if it is a disk issue, why no problems on 12.1? --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-248659-227-3OY17KHIxx>