My screen goes black -- How can I find out what's happening using journalctl?

Beaverfriend · 02-15-2021, 03:56 AM

Quote:

Originally Posted by ondoho

"--boot -1" shows entries from the last uptime, i.e. before you rebooted.
Combining that with --since only makes sense if the start time was during or before that last uptime.

I believe the journal will include entries for the event of the problematic behaviour. Better to go a few seconds back in time though.

Yes, then I think I'm at the right place. The blackout happened during the last boot some minutes before the time I used for --since. But you're right, in this case --since would have been enough to get to the right place in the journal.

ondoho · 02-15-2021, 12:35 PM

Quote:

Originally Posted by Beaverfriend

The blackout happened during the last boot some minutes before the time I used for --since.

Then the most interesting entries will be cut off by some minutes.

Beaverfriend · 02-16-2021, 03:58 AM

Quote:

Originally Posted by ondoho

Then the most interesting entries will be cut off by some minutes.

Sorry, I mean after the --since time of course.

Examining the logs a bit more I can't find anything there that I can see could have caused this. Also discovered that closing and opening the laptop lid will get the screen going again, so I strongly suspect it to be something with the display driver.

ondoho · 02-16-2021, 01:26 PM

Quote:

Originally Posted by Beaverfriend

Sorry, I mean after the --since time of course.

Then it would be nice to see that so we can help you some more.
And once more point out the correct timeframe to me, please

Beaverfriend · 02-21-2021, 05:47 AM

Quote:

Originally Posted by ondoho

Then it would be nice to see that so we can help you some more.
And once more point out the correct timeframe to me, please

That would be very appreciated

'

However the event in question is now lost in log rotation ... but as soon as it happens again I will post.

Have a good time and see you!

Beaverfriend · 02-21-2021, 08:34 AM

It happened again at 14:34.

Here's the log:

Code:

journalctl --since 14:32 --until 14:36

Code:

feb 21 14:32:25 gnagaren systemd[1]: Started Run anacron jobs.
feb 21 14:32:25 gnagaren anacron[5451]: Anacron 2.3 started on 2021-02-21
feb 21 14:32:25 gnagaren anacron[5451]: Normal exit (0 jobs run)
feb 21 14:32:25 gnagaren systemd[1]: anacron.service: Succeeded.
feb 21 14:34:10 gnagaren systemd-logind[981]: Lid closed. Note: This is what I did just after the crash to restore the screen
feb 21 14:34:10 gnagaren wpa_supplicant[984]: wlo1: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-94 noise=9999 txrate=240000
feb 21 14:34:12 gnagaren systemd-logind[981]: Lid opened.
feb 21 14:34:42 gnagaren kernel: EXT4-fs (sdb1): warning: maximal mount count reached, running e2fsck is recommended
feb 21 14:34:42 gnagaren udisksd[983]: Mounted /dev/sdb1 (system) at /media/1/1 on behalf of uid 1000
feb 21 14:34:42 gnagaren kernel: EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null)
feb 21 14:34:44 gnagaren udisksd[983]: Cleaning up mount point /media/1/1 (device 8:17 is not mounted)
feb 21 14:34:44 gnagaren systemd[1411]: media-1-1.mount: Succeeded.
feb 21 14:34:44 gnagaren systemd[1]: media-1-1.mount: Succeeded.
feb 21 14:34:44 gnagaren udisksd[983]: Unmounted /dev/sdb1 on behalf of uid 1000
feb 21 14:34:46 gnagaren kernel: usb 2-2: USB disconnect, device number 2
feb 21 14:34:46 gnagaren kernel: usb 2-2.2: USB disconnect, device number 4
feb 21 14:34:47 gnagaren kernel: usb 2-3.1: USB disconnect, device number 6
feb 21 14:35:31 gnagaren wpa_supplicant[984]: wlo1: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-66 noise=9999 txrate=240000
feb 21 14:35:46 gnagaren wpa_supplicant[984]: wlo1: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-69 noise=9999 txrate=240000

The preceding event 14:32 (an anacron process that didn't perform anything) isn't likely to have caused the blackout I guess.

ondoho · 02-22-2021, 02:31 PM

Nothing that would clarify the issue IMO.
Of course it can't hurt to heed the advice given.
You could also try if the behaviour changes when you disconnect /dev/sdb1.

Beyond that you probably have to look at ACPI issues... and I won't be able to help much with that.

BTW, scrolling back I just noticed a possible misunderstanding:
Somebody suggested pressing Ctrl-Alt-Fn when the screen goes blank - what they meant was one of the Function keys F1 - F12, and NOT the "Fn" key most laptops have.

Also, what did you upgrade to? that looks really weird in your first post.

Code:

cat /etc/*release*

please.

And since this is Ubuntu you really might want to ask on ubuntuforums.org - or askubuntu.com.

Beaverfriend · 02-23-2021, 10:15 AM

Quote:

Originally Posted by ondoho

Nothing that would clarify the issue IMO.
BTW, scrolling back I just noticed a possible misunderstanding:
Somebody suggested pressing Ctrl-Alt-Fn when the screen goes blank - what they meant was one of the Function keys F1 - F12, and NOT the "Fn" key most laptops have.

Yes, I got that. I can get to another terminal, probably, but won't see it or anything else since the screen is sleeping

Quote:

Originally Posted by ondoho

Also, what did you upgrade to? that looks really weird in your first post.

Code:

cat /etc/*release*

please.

And since this is Ubuntu you really might want to ask on ubuntuforums.org - or askubuntu.com.

Code:

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.2 LTS"
NAME="Ubuntu"
VERSION="20.04.2 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.2 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

Yea, I'll continue the quest! Great to get some input anyhow, and I've learnt a lot about journalctl.

ondoho · 02-24-2021, 01:42 AM

I wonder if we explored the hardware side of things already.
How is the screen connected, have you tried a different screen. OK, you mentioned that, but I'm not sure I understood - the issue only affects the internal screen (meaning this is a laptop), when you connect an external screen it continues to work just fine? That would mean the system does not get unresponsive at all.
And how can you know that the keyboard is unresponsive when you can't see anything?
Have you tried ssh'ing in? Have you tried playing sound - does the sound stop or continue when the issue occurs?
Are you watching sensors for temperatures closely? Cleaned out the fans? How's the battery?
And why we were fixated on journalctl for the last few posts, you should also look at 'dmesg' (that's a command) and other logs, both before and after it happens.
And lastly, tell us about your hardware/drivers:

Code:

lspci -k

Beaverfriend · 03-01-2021, 11:07 AM

Thanks for writing!

No, it's not really unresponsive (as it looked first), but that's been discussed earlier.

I'll try a `dmesg -T` next time it happens and see if there's something.

Quote:

$ lspci -k
00:00.0 Host bridge: Intel Corporation Haswell-ULT DRAM Controller (rev 0b)
Subsystem: Hewlett-Packard Company Haswell-ULT DRAM Controller
Kernel driver in use: hsw_uncore
00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b)
DeviceName: 128
Subsystem: Hewlett-Packard Company Haswell-ULT Integrated Graphics Controller
Kernel driver in use: i915
Kernel modules: i915
00:03.0 Audio device: Intel Corporation Haswell-ULT HD Audio Controller (rev 0b)
Subsystem: Hewlett-Packard Company Haswell-ULT HD Audio Controller
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel
00:14.0 USB controller: Intel Corporation 8 Series USB xHCI HC (rev 04)
Subsystem: Hewlett-Packard Company 8 Series USB xHCI HC
Kernel driver in use: xhci_hcd
00:16.0 Communication controller: Intel Corporation 8 Series HECI #0 (rev 04)
Subsystem: Hewlett-Packard Company 8 Series HECI
Kernel driver in use: mei_me
Kernel modules: mei_me
00:16.3 Serial controller: Intel Corporation 8 Series HECI KT (rev 04)
Subsystem: Hewlett-Packard Company 8 Series HECI KT
Kernel driver in use: serial
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I218-LM (rev 04)
Subsystem: Hewlett-Packard Company Ethernet Connection I218-LM
Kernel driver in use: e1000e
Kernel modules: e1000e
00:1b.0 Audio device: Intel Corporation 8 Series HD Audio Controller (rev 04)
Subsystem: Hewlett-Packard Company 8 Series HD Audio Controller
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel
00:1c.0 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 1 (rev e4)
Kernel driver in use: pcieport
00:1c.3 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 4 (rev e4)
Kernel driver in use: pcieport
00:1c.5 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 6 (rev e4)
Kernel driver in use: pcieport
00:1d.0 USB controller: Intel Corporation 8 Series USB EHCI #1 (rev 04)
Subsystem: Hewlett-Packard Company 8 Series USB EHCI
Kernel driver in use: ehci-pci
00:1f.0 ISA bridge: Intel Corporation 8 Series LPC Controller (rev 04)
Subsystem: Hewlett-Packard Company 8 Series LPC Controller
Kernel driver in use: lpc_ich
Kernel modules: lpc_ich
00:1f.2 SATA controller: Intel Corporation 8 Series SATA Controller 1 [AHCI mode] (rev 04)
Subsystem: Hewlett-Packard Company 8 Series SATA Controller 1 [AHCI mode]
Kernel driver in use: ahci
Kernel modules: ahci
00:1f.3 SMBus: Intel Corporation 8 Series SMBus Controller (rev 04)
Subsystem: Hewlett-Packard Company 8 Series SMBus Controller
Kernel driver in use: i801_smbus
Kernel modules: i2c_i801
02:00.0 Network controller: Intel Corporation Wireless 7260 (rev 73)
DeviceName: WLAN
Subsystem: Intel Corporation Dual Band Wireless-N 7260
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi
03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5227 PCI Express Card Reader (rev 01)
Subsystem: Hewlett-Packard Company RTS5227 PCI Express Card Reader
Kernel driver in use: rtsx_pci
Kernel modules: rtsx_pci