Created attachment 1455777 [details] First and last meminfo collected by job when froze Description of problem: A system with 8 GB of RAM regularly freezes without a warning while Firefox is apparently using up to half of that memory and no other application is in use. System monitor tools like "ksysguard" often show multiple "Web" processes that belong to Firefox. In a recent case, the Firefox main process used about 700 MB and 3 Web processes used about 900 MB each. While it's not a Fedora issue that Firefox uses an absurd amount of memory for a bunch of webpages (not one of them with multimedia content), it is quite inappropriate of a modern operating system to suddenly become unresponsive like Windows 98 did 20 years ago. Whenever the system freezes, the mouse cursor stops moving within seconds and the whole system freezes completely. No screensaver will show up. It's not possible to close the Firefox window so that the system can release memory. It's not possible to switch to another tty in order to kill firefox or see what's going. And while the system would recover within 15 or 30 minutes in some cases, it's often frozen for an hour or more. To my knowledge, not even Windows behaves that way. Every system is expected to slow down when it starts swapping but it's usually not a problem to terminate the browser or to open a process manager and kill the process that's using up too much memory. Unfortunately, Fedora 28 just freezes without a warning, which often means that the user has to reset the system, losing unsaved work. Version-Release number of selected component (if applicable): Fedora 28 MATE 1.20 Firefox 60.0.1 ("Quantum") How reproducible: Happens almost daily. Steps to Reproduce: 1. Use Firefox. 2. Have more than 5 or 10 tabs open, don't quit the browser after an hour. 3. When clicking a link or when reading a webpage, the system freezes. Actual results: Instant freeze, probably caused by Firefox using a lot of memory. Expected results: The system should never become completely unresponsive. Additional info: Note that 3 or 4 GB used by Firefox is less than the total amount of 8 GB of RAM. Also, to be able to hibernate the system, a swap partition of that same size is available (and it's usually not or hardly used). That's according to "ksysguard" as seen a few minutes before the freeze. On the other hand, last time the system froze, I had a job running that collects /proc/meminfo every couple of minutes and although it only ran one more time when the system froze, its output reveals that "MemFree" was only 126 MB. However, "SwapFree" was 7690 MB (out of 8192), indicating that the system was swapping quite a bit. On the other hand, that particular computer (the same behavior has been seen on other computers, possibly even more so after upgrading to Fedora 28) does have an SSD. Another new symptom in Fedora 28 is that whenever this happens, a message pops up saying that the Battery Icon has crashed (asking if it should be reloaded or removed) when the system recovers.
Do you see any interesting entry at journalctl or dmesg?
(In reply to Martin Stransky from comment #1) > Do you see any interesting entry at journalctl or dmesg? No, the last time(s) it happened, I did not notice anything there. Btw: One time this happened, I managed to close a tab in Chromium (which I opened after Firefox, or maybe it was just Firefox, I don't really remember) while the mouse was still partially responsive - and I had ksysguard running in the background. The graph in the system monitor showed that while everything was about to freeze, the ram usage was around 6 or 6.5 GB and a few seconds later (on the right side of the graph), memory usage dropped at least 1 GB.
This problem affects me nearly every day on my laptop (8GB ram/8GB Swap) running Fedora 29. In my case I have yet to see the system recover. I thought it might have been youtube's h.264 implementation so I switched video playback to chromium but the issue persists without video playing and without chromium being open. Firefox 62.0.3 Fedora 29 - 4.19.0-1.fc30.x86_64 (rawhide kernel)
Not only seeing this with Firefox, but with other applications as well. Failure progresses in one of three ways: either the screen goes black and unable to connect to a virtual connection (ctl-alt-F1), or the application in the foreground at the time of the failure becomes unresponsivek, but the Mouse still moves and other apps can be started - but also hang after a bit. Or, the screen freezes and is totally unresponsive but still displays things as they were at the point of the failure. I'm seeing this problem both with FC28 and with FC29. Seemed to be less frequent with current DNF update (11/27/2018) but it is still happening. IMHO it is acting like a memory leak. FC28 kernel 2-200, FC29 kernel 3-300, 3-400.
My screen never goes black when this happens. It's true that it's not just Firefox, although it seems to be the best example as it consumes unbelievable amounts of memory. It's not unusual for Firefox to be using 5 GB of RAM after it's been running for several days (web pages, not even videos or anything), which is how much is released when exiting Firefox. It appears like Fedora has trouble handling low-memory situations and Firefox is just the trigger. It often happens when I open a new tab or window, which indicates that the additional memory required for the new tab is too much for the system even though there's still quite a lot of available ram as well as several GB of swap space (according to ksysguard, for example). So it may also happen when both Firefox and Chromium is running, Firefox is using a lot of ram and then a new Chromium tab is opened. When that happens, the mouse usually still moves for the first few seconds, but not smoothly. Sometimes it's still possible to move the mouse to the X icon to close the window or tab but then, the system is already too slow to handle the click (the hover animation also doesn't work or takes minutes to highlight the X button). If I'm fast enough to close the newly opened tab and if it's a Chromium tab, the system will immediately stop hanging and become responsive again because Chromium tabs run in separate processes that release their memory when closed. Far more often than that, the system freezes almost instantly, at which point everything just stays on the screen. In that state, the system is way too slow to start the screensaver or switch to another tty as Rich mentioned. At that point, I have to leave it like that for an hour. At some point, it'll be done hanging (whatever it was doing) and be responsive again. It's obviously not ok for Firefox to be using several GB of RAM (for web pages, mostly text and images!), but we can't change that. I've already seen complaints about that and Mozilla tried to put the blame on the user or some addons, as far as I remember correctly. It's sad that Mozilla keeps removing core features, changing the design to make it look like Chromium, adding things like Chat that really don't belong in a browser - instead of spending their time on improving the browser. However, this bug is about Fedora and how it handles those situations. Even if there's not much available ram left (but still lots of swap space), an operating system should not become unresponsive to the point that the user isn't able to close the application that's using up too much memory.
I have the same problem here, firefox fill all the memory, the the system block and after a while reset. I guess there's a memory leak somewhere. I can reproduce the bug easily: it happens when i'm debugging a nodejs app running on localhost with firefox web tools. nov 30 14:52:57 localhost.localdomain kernel: Out of memory: Kill process 3129 (Web Content) score 819 or sacrifice child
Created attachment 1510201 [details] Journal of out of memory crash
f29 ff64 q8200 4gb ram 730 gpu 415 drivers Randome freeze system when use firefox, no hdd active, no caps lock active, no mouse active, help just hard reboot.
Wat you see is oom-killer. You can try https://github.com/rfjakob/earlyoom which does not lock up the system. You can also try a different DE - MATE for instance or XFCE. You can also check about:performance and about:memory pages to find the tab/page which consumes your memory/cpu.
4.20.15-200.fc29.x86_64 and a lot of kernels before (and a couple of OS version at least), probably for half a year, but last days it happens 4-5 times a day. I have exactly same problem: (mostly) when using firefox (no matter what version), fedora freezes (screen is not repainted, caps lock not works, only B from REISUB seems to work). journalctl is totally silent about what happens, as well as any logs I'm aware of. Any help is highly appreciated! $ sudo lshw -short | egrep -i "cpu|RAM|core|USB|hdd|controller|memory|system|processor|video|radeon|description" H/W path Device Class Description system HP ZBook 15 G3 (M9R63AV) /0/0 memory 128KiB L1 cache /0/1 memory 128KiB L1 cache /0/2 memory 1MiB L2 cache /0/3 memory 8MiB L3 cache /0/4 processor Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz /0/5 memory 32GiB System Memory /0/5/0 memory 16GiB SODIMM DDR4 Synchronous Unbuffered (Unregistered) 2133 MHz (0.5 ns) /0/5/1 memory 16GiB SODIMM DDR4 Synchronous Unbuffered (Unregistered) 2133 MHz (0.5 ns) /0/5/2 memory [empty] /0/5/3 memory [empty] /0/b memory 64KiB BIOS /0/100 bridge Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers /0/100/1 bridge Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor PCIe Controller (x16) /0/100/1/0 display Venus XTX [Radeon HD 8890M / R9 M275X/M375X] /0/100/1/0.1 multimedia Oland/Hainan/Cape Verde/Pitcairn HDMI Audio [Radeon HD 7000 Series] /0/100/14 bus 100 Series/C230 Series Chipset Family USB 3.0 xHCI Controller /0/100/14/0 usb1 bus xHCI Host Controller /0/100/14/1 usb2 bus xHCI Host Controller /0/100/14.2 generic 100 Series/C230 Series Chipset Family Thermal Subsystem /0/100/16 communication 100 Series/C230 Series Chipset Family MEI Controller #1 /0/100/17 storage Q170/Q150/B150/H170/H110/Z170/CM236 Chipset SATA Controller [AHCI Mode] /0/100/1c.4/0/4/0/0/0 bus ASM1042A USB 3.0 Host Controller /0/100/1c.4/0/4/0/0/0/0 usb3 bus xHCI Host Controller /0/100/1c.4/0/4/0/0/0/0/1/3 bus USB2.0 Hub /0/100/1c.4/0/4/0/0/0/0/1/3/1 input USB Optical Mouse /0/100/1c.4/0/4/0/0/0/0/1/4 bus USB2.0 Hub /0/100/1c.4/0/4/0/0/0/1 usb4 bus xHCI Host Controller /0/100/1c.4/0/4/0/0/0/1/1/3 bus USB3.0 Hub /0/100/1c.4/0/4/0/0/0/1/1/4 bus USB3.0 Hub /0/100/1d/0 storage NVMe SSD Controller SM951/PM951 /0/100/1f bridge CM236 Chipset LPC/eSPI Controller /0/100/1f.2 memory Memory controller /0/100/1f.3 multimedia 100 Series/C230 Series Chipset Family HD Audio Controller $ dmesg | egrep -i -A 10 -B 10 "error|fail|cannot" [ 0.404224] ACPI: Added _OSI(Processor Device) [ 0.404224] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.404224] ACPI: Added _OSI(Processor Aggregator Device) [ 0.404224] ACPI: Added _OSI(Linux-Dell-Video) [ 0.404224] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio) [ 0.429041] ACPI: 10 ACPI AML tables successfully acquired and loaded [ 0.431539] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored [ 0.487069] ACPI: Dynamic OEM Table Load: [ 0.487081] ACPI: SSDT 0xFFFF904399AB8800 0005FD (v02 PmRef Cpu0Ist 00003000 INTL 20121018) [ 0.487482] ACPI: \_PR_.CPU0: _OSC native thermal LVT Acked [ 0.487689] ACPI Error: Field [CAP1] at bit offset/length 64/32 exceeds size of target Buffer (64 bits) (20181003/dsopcode-201) [ 0.487692] ACPI Error: Method parse/execution failed \_SB._OSC, AE_AML_BUFFER_LIMIT (20181003/psparse-516) [ 0.488173] ACPI: Dynamic OEM Table Load: [ 0.488178] ACPI: SSDT 0xFFFF904399452400 00037F (v02 PmRef Cpu0Cst 00003001 INTL 20121018) [ 0.488955] ACPI: Dynamic OEM Table Load: [ 0.488961] ACPI: SSDT 0xFFFF904399ABF800 0005AA (v02 PmRef ApIst 00003000 INTL 20121018) [ 0.489519] ACPI: Dynamic OEM Table Load: [ 0.489524] ACPI: SSDT 0xFFFF904399B1BA00 000119 (v02 PmRef ApCst 00003000 INTL 20121018) [ 0.492457] ACPI: EC: EC started [ 0.492457] ACPI: EC: interrupt blocked [ 3.540560] ACPI: \_SB_.PCI0.LPCB.EC0_: Used as first EC [ 3.540561] ACPI: \_SB_.PCI0.LPCB.EC0_: GPE=0x6e, EC_CMD/EC_SC=0x66, EC_DATA=0x62 -- [ 4.432370] ACPI: Thermal Zone [PCHZ] (127 C) [ 4.432530] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled [ 4.435313] serial 0000:00:16.3: enabling device (0000 -> 0003) [ 4.456270] 0000:00:16.3: ttyS4 at I/O 0x7040 (irq = 19, base_baud = 115200) is a 16550A [ 4.457497] Non-volatile memory driver v1.3 [ 4.457671] Linux agpgart interface v0.103 [ 4.460270] tpm_tis 00:0a: 1.2 TPM (device-id 0x1B, rev-id 16) [ 4.463393] battery: ACPI: Battery Slot [BAT0] (battery present) [ 4.472815] tpm tpm0: TPM is disabled/deactivated (0x7) [ 4.472817] tpm tpm0: tpm_read_log_acpi: TCPA log area empty [ 4.472827] tpm_tis: probe of 00:0a failed with error -5 [ 4.473741] ahci 0000:00:17.0: version 3.0 [ 4.473847] ahci 0000:00:17.0: SSS flag set, parallel bus scan disabled [ 4.473864] ahci 0000:00:17.0: AHCI 0001.0301 32 slots 2 ports 6 Gbps 0x2 impl SATA mode [ 4.473866] ahci 0000:00:17.0: flags: 64bit ncq sntf stag pm led clo only pio slum part ems deso sadm sds apst [ 4.474100] scsi host0: ahci [ 4.474388] scsi host1: ahci [ 4.474410] ata1: DUMMY [ 4.474413] ata2: SATA max UDMA/133 abar m2048@0xda54d000 port 0xda54d180 irq 136 [ 4.474543] libphy: Fixed MDIO Bus: probed [ 4.474669] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver -- [ 4.549857] hidraw: raw HID events driver (C) Jiri Kosina [ 4.549876] usbcore: registered new interface driver usbhid [ 4.549876] usbhid: USB HID core driver [ 4.549910] intel_pmc_core: initialized [ 4.549952] drop_monitor: Initializing network drop monitor service [ 4.550143] Initializing XFRM netlink socket [ 4.550242] NET: Registered protocol family 10 [ 4.552997] Segment Routing with IPv6 [ 4.553009] mip6: Mobile IPv6 [ 4.553010] NET: Registered protocol family 17 [ 4.553840] RAS: Correctable Errors collector initialized. [ 4.553902] microcode: sig=0x506e3, pf=0x20, revision=0xc6 [ 4.553978] microcode: Microcode Update Driver: v2.2. [ 4.553984] AVX2 version of gcm_enc/dec engaged. [ 4.553985] AES CTR mode by8 optimization enabled [ 4.573825] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3 [ 4.583544] sched_clock: Marking stable (4584144347, -603414)->(4607642412, -24101479) [ 4.583926] registered taskstats version 1 [ 4.583931] Loading compiled-in X.509 certificates [ 4.609187] Loaded X.509 cert 'Fedora kernel signing key: c1492d91f925fcf1b548811e4c9300258fa8d6ef' [ 4.610467] zswap: loaded using pool lzo/zbud -- [ 48.041511] systemd-sysv-generator[1222]: [/etc/rc.d/init.d/cprocsp:4] PID file not absolute. Ignoring. [ 48.159080] systemd[1]: Stopped Switch Root. [ 48.159265] systemd[1]: systemd-journald.service: Service has no hold-off time (RestartSec=0), scheduling restart. [ 48.159317] systemd[1]: systemd-journald.service: Scheduled restart job, restart counter is at 1. [ 48.159333] systemd[1]: Stopped Journal Service. [ 48.160222] systemd[1]: Starting Journal Service... [ 48.160612] systemd[1]: Listening on udev Kernel Socket. [ 48.160750] systemd[1]: Listening on initctl Compatibility Named Pipe. [ 48.170215] Adding 33554428k swap on /dev/mapper/san-swap. Priority:-2 extents:1 across:33554428k SSFS [ 48.176519] vboxdrv: loading out-of-tree module taints kernel. [ 48.176658] vboxdrv: module verification failed: signature and/or required key missing - tainting kernel [ 48.181494] vboxdrv: Found 8 processor cores [ 48.192662] EXT4-fs (dm-1): re-mounted. Opts: (null) [ 48.197196] vboxdrv: TSC mode is Invariant, tentative frequency 2711998781 Hz [ 48.197197] vboxdrv: Successfully loaded version 5.2.24_RPMFusion (interface 0x00290001) [ 48.198165] VBoxNetFlt: Successfully started. [ 48.198941] VBoxNetAdp: Successfully started. [ 48.199943] VBoxPciLinuxInit [ 48.199946] vboxpci: IOMMU not found (not registered) [ 48.215290] systemd-journald[1228]: Received request to flush runtime journal from PID 1 [ 48.243535] systemd-journald[1228]: File /var/log/journal/589f3aa71f9e4f4a9e635d8478d590c7/system.journal corrupted or uncleanly shut down, renaming and replacing. [ 48.440933] tpm_inf_pnp 00:0a: Found TPM with ID IFX0102 [ 48.442565] input: HP Wireless hotkeys as /devices/virtual/input/input21 [ 48.449465] hp_accel: hardware type HPZBook15 found [ 48.518051] mei_me 0000:00:16.0: enabling device (0000 -> 0002) [ 48.522142] i801_smbus 0000:00:1f.4: enabling device (0000 -> 0003) [ 48.522291] i801_smbus 0000:00:1f.4: SPD Write Disable is set [ 48.522333] i801_smbus 0000:00:1f.4: SMBus using PCI interrupt [ 48.565589] hp_wmi: query 0x4 returned error 0x5 [ 48.568446] lis3lv02d: 8 bits 3DC sensor found [ 48.568551] hp_wmi: query 0x4 returned error 0x5 [ 48.570383] cfg80211: Loading compiled-in X.509 certificates for regulatory database [ 48.571075] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' [ 48.578987] RAPL PMU: API unit is 2^-32 Joules, 5 fixed counters, 655360 ms ovfl timer [ 48.578989] RAPL PMU: hw unit of domain pp0-core 2^-14 Joules [ 48.578989] RAPL PMU: hw unit of domain package 2^-14 Joules [ 48.578990] RAPL PMU: hw unit of domain dram 2^-14 Joules [ 48.578991] RAPL PMU: hw unit of domain pp1-gpu 2^-14 Joules [ 48.578991] RAPL PMU: hw unit of domain psys 2^-14 Joules [ 48.580124] hp_wmi: query 0xd returned error 0x5 [ 48.580171] input: HP WMI hotkeys as /devices/virtual/input/input22 [ 48.615793] snd_hda_intel 0000:00:1f.3: enabling device (0000 -> 0002) [ 48.616154] snd_hda_intel 0000:01:00.1: enabling device (0000 -> 0002) [ 48.616219] snd_hda_intel 0000:01:00.1: Handle vga_switcheroo audio client [ 48.616220] snd_hda_intel 0000:01:00.1: Force to non-snoop mode [ 48.621685] Intel(R) Wireless WiFi driver for Linux [ 48.621686] Copyright(c) 2003- 2015 Intel Corporation [ 48.622304] iwlwifi 0000:02:00.0: enabling device (0000 -> 0002) [ 48.638136] iwlwifi 0000:02:00.0: loaded firmware version 36.9f0a2d68.0 op_mode iwlmvm [ 48.642523] snd_hda_codec_conexant hdaudioC0D0: CX20724: BIOS auto-probing. -- [ 48.751904] Bluetooth: hci0: Secure boot is enabled [ 48.751905] Bluetooth: hci0: OTP lock is enabled [ 48.751906] Bluetooth: hci0: API lock is enabled [ 48.751907] Bluetooth: hci0: Debug lock is disabled [ 48.751908] Bluetooth: hci0: Minimum firmware build 1 week 10 2014 [ 48.753575] Bluetooth: hci0: Found device firmware: intel/ibt-11-5.sfi [ 48.756257] iwlwifi 0000:02:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208 [ 48.759027] intel_rapl: Found RAPL domain package [ 48.759028] intel_rapl: Found RAPL domain core [ 48.759029] intel_rapl: Found RAPL domain dram [ 48.771530] Bluetooth: hci0: Failed to send firmware data (-38) [ 48.773976] uvcvideo: Found UVC 1.00 device HP HD Camera (04ca:7054) [ 48.780987] uvcvideo 1-7:1.0: Entity type for entity Extension 4 was not initialized! [ 48.780988] uvcvideo 1-7:1.0: Entity type for entity Processing 2 was not initialized! [ 48.780990] uvcvideo 1-7:1.0: Entity type for entity Camera 1 was not initialized! [ 48.781874] input: HP HD Camera: HP HD Camera as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/input/input31 [ 48.781966] usbcore: registered new interface driver uvcvideo [ 48.781966] USB Video Class driver (1.1.1) [ 48.827189] iTCO_vendor_support: vendor-support=0 [ 48.829089] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11 [ 48.829234] iTCO_wdt: Found a Intel PCH TCO device (Version=4, TCOBASE=0x0400) [ 48.829505] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) [ 48.843454] iwlwifi 0000:02:00.0: base HW address: 44:85:00:31:ec:c3 [ 48.860787] usb 3-2: 2:1: cannot get freq at ep 0x1 [ 48.921629] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs' [ 48.921877] thermal thermal_zone8: failed to read out thermal zone (-61) [ 48.925887] iwlwifi 0000:02:00.0 wlp2s0: renamed from wlan0 [ 49.272448] usb 3-1.3.3: Warning! Unlikely big volume range (=4096), cval->res is probably wrong. [ 49.272454] usb 3-1.3.3: [11] FU [Sidetone Playback Volume] ch = 1, val = 0/4096/1 [ 49.360035] usbcore: registered new interface driver snd-usb-audio [ 49.725328] input: ST LIS3LV02DL Accelerometer as /devices/platform/lis3lv02d/input/input32 [ 53.941783] kauditd_printk_skb: 53 callbacks suppressed [ 53.941787] audit: type=1131 audit(1552903333.821:79): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-rfkill comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 55.874514] usb 1-12: reset full-speed USB device number 3 using xhci_hcd [ 64.344224] mei_wdt mei::05b79a6f-4628-4d7f-899d-a91514cb32ab:02: Could not reg notif event ret=-22 [ 64.344487] mei_wdt: probe of mei::05b79a6f-4628-4d7f-899d-a91514cb32ab:02 failed with error -22 [ 65.083936] thunderbolt 0-0: ignoring unnecessary extra entries in DROM [ 65.099063] audit: type=1130 audit(1552903344.979:80): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-udev-settle comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 65.119151] audit: type=1130 audit(1552903344.999:81): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dmraid-activation comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 65.119163] audit: type=1131 audit(1552903344.999:82): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dmraid-activation comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 65.131776] loop: module loaded [ 65.146297] audit: type=1130 audit(1552903345.026:83): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-fsck@dev-disk-by\x2duuid-44F4\x2d3057 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 65.154955] squashfs: version 4.0 (2009/01/31) Phillip Lougher [ 65.199946] audit: type=1130 audit(1552903345.079:84): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-fsck@dev-disk-by\x2duuid-ba67767d\x2d356d\x2d45c6\x2d9cf2\x2d160c4486adc0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 65.220492] EXT4-fs (nvme0n1p2): mounted filesystem with ordered data mode. Opts: (null) [ 65.518018] thunderbolt 0-3: new device found, vendor=0xf0 device=0x8190 $ free total used free shared buff/cache available Mem: 32855376 15235168 14203024 210256 3417184 16714560 $ df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 16G 0 16G 0% /dev tmpfs 16G 189M 16G 2% /dev/shm tmpfs 16G 2.5M 16G 1% /run tmpfs 16G 0 16G 0% /sys/fs/cgroup /dev/mapper/san-root 54G 23G 29G 45% / tmpfs 16G 256K 16G 1% /tmp /dev/loop3 91M 91M 0 100% /var/lib/snapd/snap/core/6350 /dev/loop0 91M 91M 0 100% /var/lib/snapd/snap/core/6405 /dev/loop1 603M 603M 0 100% /var/lib/snapd/snap/intellij-idea-ultimate/114 /dev/loop2 92M 92M 0 100% /var/lib/snapd/snap/core/6531 /dev/loop4 603M 603M 0 100% /var/lib/snapd/snap/intellij-idea-ultimate/122 /dev/loop5 602M 602M 0 100% /var/lib/snapd/snap/intellij-idea-ultimate/109 /dev/nvme0n1p2 240M 160M 64M 72% /boot /dev/nvme0n1p1 256M 8.0M 248M 4% /boot/efi /dev/mapper/san-home 384G 99G 266G 28% /home tmpfs 3.2G 12K 3.2G 1% /run/user/42 tmpfs 3.2G 56K 3.2G 1% /run/user/1000
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Nothing has changed, this is still happening. However, it does not look like a simple bug but rather like something more complex, i.e., bad behavior when the system is about to run out of RAM and beginning to swap. Even if Firefox (occasionally plus Chromium or Thunderbird) should not be using 3 GB of RAM or more, that's not the point. The point is that Fedora should not freeze (often staying unresponsive for hours) while swapping. It's obviously related to swapping because sometimes, the system does not freeze immediately but it's getting difficult to move the mouse cursor and things start to freeze up slowly and with a lot of luck, the mouse can still be moved to a Chrome window button in the taskbar, which can be closed with a middle click. It takes a few minutes for that click to be picked up but if it works, the window is closed, in which case Chromium *immediately* releases the memory that was used by this window (unlike Firefox, which takes more time) and at that point, the system will *immediately* be responsive again, almost as if nothing had happened. (At that point, Firefox typically opens a dialog saying that some internal script appears to be unresponsive and if it should be stopped, which would cause the Firefox window to break somehow, e.g., tabs cannot be switched anymore.) In other words, it was swapping and only after it stopped swapping, the system is usable again. The system should remain usable even while swapping and input devices like mouse and keyboard should be prioritized.
- I'm also facing same issue. Fedora completely freezes after some time. I'm completely new to Linux and don't know whats happening.
$ dmesg | egrep -i -A 10 -B 10 "error|fail|cannot" [ 1.433349] ACPI: Power Resource [PLPE] (on) [ 1.439560] ACPI: Power Resource [CLK0] (on) [ 1.439640] ACPI: Power Resource [CLK1] (on) [ 1.510339] ACPI: Power Resource [FN00] (off) [ 1.510540] ACPI: Power Resource [FN01] (off) [ 1.510724] ACPI: Power Resource [FN02] (off) [ 1.510904] ACPI: Power Resource [FN03] (off) [ 1.511090] ACPI: Power Resource [FN04] (off) [ 1.512206] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) [ 1.512215] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3] [ 1.512836] acpi PNP0A08:00: _OSC failed (AE_ERROR); disabling ASPM [ 1.512857] acpi PNP0A08:00: [Firmware Info]: MMCONFIG for domain 0000 [bus 00-3f] only partially covers this bridge [ 1.513431] PCI host bridge to bus 0000:00 [ 1.513436] pci_bus 0000:00: root bus resource [io 0x0070-0x0077] [ 1.513439] pci_bus 0000:00: root bus resource [io 0x0000-0x006f window] [ 1.513441] pci_bus 0000:00: root bus resource [io 0x0078-0x0cf7 window] [ 1.513444] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window] [ 1.513447] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window] [ 1.513449] pci_bus 0000:00: root bus resource [mem 0x000c0000-0x000dffff window] [ 1.513452] pci_bus 0000:00: root bus resource [mem 0x000e0000-0x000fffff window] [ 1.513455] pci_bus 0000:00: root bus resource [mem 0x80000000-0x90affffe window] -- [ 1.668930] pnp: PnP ACPI: found 6 devices [ 1.677260] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns [ 1.677333] pci 0000:00:1c.0: bridge window [io 0x1000-0x0fff] to [bus 01] add_size 1000 [ 1.677339] pci 0000:00:1c.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 01] add_size 200000 add_align 100000 [ 1.677342] pci 0000:00:1c.0: bridge window [mem 0x00100000-0x000fffff] to [bus 01] add_size 200000 add_align 100000 [ 1.677347] pci 0000:00:1c.1: bridge window [io 0x1000-0x0fff] to [bus 02] add_size 1000 [ 1.677351] pci 0000:00:1c.1: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 02] add_size 200000 add_align 100000 [ 1.677355] pci 0000:00:1c.2: bridge window [io 0x1000-0x0fff] to [bus 03] add_size 1000 [ 1.677359] pci 0000:00:1c.2: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 03] add_size 200000 add_align 100000 [ 1.677383] pci 0000:00:1c.0: BAR 14: no space for [mem size 0x00200000] [ 1.677386] pci 0000:00:1c.0: BAR 14: failed to assign [mem size 0x00200000] [ 1.677395] pci 0000:00:1c.0: BAR 15: no space for [mem size 0x00200000 64bit pref] [ 1.677398] pci 0000:00:1c.0: BAR 15: failed to assign [mem size 0x00200000 64bit pref] [ 1.677406] pci 0000:00:1c.1: BAR 15: no space for [mem size 0x00200000 64bit pref] [ 1.677408] pci 0000:00:1c.1: BAR 15: failed to assign [mem size 0x00200000 64bit pref] [ 1.677416] pci 0000:00:1c.2: BAR 15: no space for [mem size 0x00200000 64bit pref] [ 1.677419] pci 0000:00:1c.2: BAR 15: failed to assign [mem size 0x00200000 64bit pref] [ 1.677425] pci 0000:00:1c.0: BAR 13: assigned [io 0x3000-0x3fff] [ 1.677429] pci 0000:00:1c.1: BAR 13: assigned [io 0x4000-0x4fff] [ 1.677434] pci 0000:00:1c.2: BAR 13: assigned [io 0x5000-0x5fff] [ 1.677445] pci 0000:00:1c.2: BAR 15: no space for [mem size 0x00200000 64bit pref] [ 1.677448] pci 0000:00:1c.2: BAR 15: failed to assign [mem size 0x00200000 64bit pref] [ 1.677456] pci 0000:00:1c.1: BAR 15: no space for [mem size 0x00200000 64bit pref] [ 1.677458] pci 0000:00:1c.1: BAR 15: failed to assign [mem size 0x00200000 64bit pref] [ 1.677463] pci 0000:00:1c.0: BAR 14: no space for [mem size 0x00200000] [ 1.677466] pci 0000:00:1c.0: BAR 14: failed to assign [mem size 0x00200000] [ 1.677474] pci 0000:00:1c.0: BAR 15: no space for [mem size 0x00200000 64bit pref] [ 1.677476] pci 0000:00:1c.0: BAR 15: failed to assign [mem size 0x00200000 64bit pref] [ 1.677481] pci 0000:00:1c.0: PCI bridge to [bus 01] [ 1.677485] pci 0000:00:1c.0: bridge window [io 0x3000-0x3fff] [ 1.677495] pci 0000:00:1c.1: PCI bridge to [bus 02] [ 1.677498] pci 0000:00:1c.1: bridge window [io 0x4000-0x4fff] [ 1.677502] pci 0000:00:1c.1: bridge window [mem 0x90700000-0x907fffff] [ 1.677509] pci 0000:00:1c.2: PCI bridge to [bus 03] [ 1.677512] pci 0000:00:1c.2: bridge window [io 0x5000-0x5fff] [ 1.677517] pci 0000:00:1c.2: bridge window [mem 0x90600000-0x906fffff] [ 1.677524] pci 0000:00:1c.3: PCI bridge to [bus 04] [ 1.677527] pci 0000:00:1c.3: bridge window [io 0x1000-0x1fff] -- [ 1.677773] NET: Registered protocol family 2 [ 1.678096] tcp_listen_portaddr_hash hash table entries: 2048 (order: 3, 32768 bytes) [ 1.678161] TCP established hash table entries: 32768 (order: 6, 262144 bytes) [ 1.678299] TCP bind hash table entries: 32768 (order: 7, 524288 bytes) [ 1.678442] TCP: Hash tables configured (established 32768 bind 32768) [ 1.678541] UDP hash table entries: 2048 (order: 4, 65536 bytes) [ 1.678582] UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes) [ 1.678725] NET: Registered protocol family 1 [ 1.678737] NET: Registered protocol family 44 [ 1.678758] pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff] [ 2.882128] pci 0000:00:1d.0: EHCI: BIOS handoff failed (BIOS bug?) 01010001 [ 2.882255] pci 0000:00:1d.0: quirk_usb_early_handoff+0x0/0x645 took 1174909 usecs [ 2.882289] PCI: CLS 64 bytes, default 64 [ 2.882401] Trying to unpack rootfs image as initramfs... [ 3.554531] Freeing initrd memory: 24336K [ 3.554595] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) [ 3.554598] software IO TLB: mapped [mem 0x6c000000-0x70000000] (64MB) [ 3.554726] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x1f37ff50e1e, max_idle_ns: 440795224014 ns [ 3.554750] clocksource: Switched to clocksource tsc [ 3.559765] Initialise system trusted keyrings [ 3.559787] Key type blacklist registered -- [ 3.657317] usbcore: registered new interface driver usbhid [ 3.657323] usbhid: USB HID core driver [ 3.658755] drop_monitor: Initializing network drop monitor service [ 3.659107] Initializing XFRM netlink socket [ 3.660292] NET: Registered protocol family 10 [ 3.671320] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3 [ 3.678372] Segment Routing with IPv6 [ 3.678432] mip6: Mobile IPv6 [ 3.678437] NET: Registered protocol family 17 [ 3.681068] mce: Using 6 MCE banks [ 3.681107] RAS: Correctable Errors collector initialized. [ 3.681205] microcode: sig=0x30678, pf=0x8, revision=0x838 [ 3.681719] microcode: Microcode Update Driver: v2.2. [ 3.681752] sched_clock: Marking stable (3679605260, 1509148)->(3692211584, -11097176) [ 3.684040] registered taskstats version 1 [ 3.684060] Loading compiled-in X.509 certificates [ 3.777820] Loaded X.509 cert 'Fedora kernel signing key: 4625787132bfadc1dfdcfdce5b9e005a219cbed3' [ 3.777991] zswap: loaded using pool lzo/zbud [ 3.817885] Key type big_key registered [ 3.842339] Key type encrypted registered [ 3.844384] integrity: Loading X.509 certificate: UEFI:db -- [ 32.719825] Bluetooth: HCI UART protocol H4 registered [ 32.719826] Bluetooth: HCI UART protocol BCSP registered [ 32.719848] Bluetooth: HCI UART protocol LL registered [ 32.719849] Bluetooth: HCI UART protocol ATH3K registered [ 32.719863] Bluetooth: HCI UART protocol Three-wire (H5) registered [ 32.719917] Bluetooth: HCI UART protocol Intel registered [ 32.719982] Bluetooth: HCI UART protocol Broadcom registered [ 32.719997] Bluetooth: HCI UART protocol QCA registered [ 32.719998] Bluetooth: HCI UART protocol AG6XX registered [ 32.719999] Bluetooth: HCI UART protocol Marvell registered [ 32.841395] hp_wmi: query 0xd returned error 0x5 [ 32.841594] input: HP WMI hotkeys as /devices/virtual/input/input8 [ 33.133705] media: Linux media interface: v0.10 [ 33.183894] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 3290, rev 0015 detected [ 33.191907] ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 3290 detected [ 33.224492] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 33.233665] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' [ 33.274918] videodev: Linux video capture interface: v2.00 [ 33.383478] rt2800pci 0000:02:00.0 wlp2s0f0: renamed from wlan0 [ 33.468613] intel_rapl: Found RAPL domain package [ 33.468621] intel_rapl: Found RAPL domain core
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are 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 30 kernel bugs. Fedora 30 has now been rebased to 5.2.9-200.fc30. 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 31, and are still experiencing this issue, please change the version to Fedora 31. 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 3 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.
Created attachment 1627229 [details] System log Ok, that's actually pretty strange. I just faced the same issue with Fedora 31 Beta. I'm not sure how related it's to Firefox, but I used the system normally for about 2 hours without Firefox opened, but after 15 min with Firefox running the system froze. I let a script running each 0.5s for gather some info from the system (memory usage, dmesg, journal log, ps, ..) and I couldn't see anything wrong right before the system freeze (at least 0.5s before) from these logs. Firefox memory usage was actually pretty fine, nothing close to swap. I'm currently using KDE as my DE on Fedora 31 Beta, but with Fedora 30 using cwm (a lightweight wm) I didn't hit it a single time. I'm going to downgrade it to Fedora 30 KDE to see what happens. System spec: $ uname -a Linux glitch 5.3.4-300.fc31.x86_64 #1 SMP Mon Oct 7 11:16:50 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux $ cat /etc/fedora-release Fedora release 31 (Thirty One) $ lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 43 bits physical, 48 bits virtual CPU(s): 12 On-line CPU(s) list: 0-11 Thread(s) per core: 2 Core(s) per socket: 6 Socket(s): 1 NUMA node(s): 1 Vendor ID: AuthenticAMD CPU family: 23 Model: 113 Model name: AMD Ryzen 5 3600X 6-Core Processor Stepping: 0 Frequency boost: enabled CPU MHz: 2200.169 CPU max MHz: 3800.0000 CPU min MHz: 2200.0000 BogoMIPS: 7600.75 Virtualization: AMD-V L1d cache: 192 KiB L1i cache: 192 KiB L2 cache: 3 MiB L3 cache: 32 MiB NUMA node0 CPU(s): 0-11 Vulnerability L1tf: Not affected Vulnerability Mds: Not affected Vulnerability Meltdown: Not affected Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization Vulnerability Spectre v2: Mitigation; Full AMD retpoline, IBPB conditional, STIBP always-on, RSB filling Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid a perfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce to poext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate sme ssbd mba sev ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveop t xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfth reshold avic v_vmsave_vmload vgif umip rdpid overflow_recov succor smca
Well, yes, this issue also happens in Fedora30. At the same time, it doesn't has anything to do with Firefox specifically, since I've tested with Chromium and the system also froze. At first I thought it could be related to drm/nouveau driver for new GPUs (GTX 1660, RTX 2060, ...) but in comment#10 there is an AMD Radeon running. Can we reopen this bug trying to get more people involved? It seems it's lurking around since F29 and will show up in F31 as well. Any new ideas or analysis are welcome!
(In reply to Bruno Meneguele from comment #18) > I let a script running each 0.5s for gather some info from the system > (memory usage, dmesg, journal log, ps, ..) and I couldn't see anything wrong > right before the system freeze (at least 0.5s before) from these logs. > Firefox memory usage was actually pretty fine, nothing close to swap. That might be a wrong impression, I believe, as memory usage isn't always simple and obvious (even mate-system-monitor and ksysguard have different opinions on the current memory usage, see screenshot in Bug 1426657). What I've noticed many times after a quick recovery (system starts to slow down, it's beginning to get difficult to move the mouse, after a couple of minutes the mouse reaches the X button of the Chromium window and once the click is handled, the system instantly becomes responsive again) is that RAM usage spiked for a few minutes until the window/process was closed (CPU as well because of kswap), but in the graph shown by tools like ksysguard it always seems like memory usage never actually reaches 100%. There might even be 1 GB (out of 8, for example) GB RAM "available" when the systems becomes unresponsive. > I'm currently using KDE as my DE on Fedora 31 Beta, but with Fedora 30 using > cwm (a lightweight wm) I didn't hit it a single time. > I'm going to downgrade it to Fedora 30 KDE to see what happens. I'm sure that's just coincidental. KDE uses more resources, especially RAM, more than most other DEs (for a rare example, see Bug 1396740). (In reply to Bruno Meneguele from comment #19) > At the same time, it doesn't has anything to do with Firefox specifically, > since I've tested with Chromium and the system also froze. Yes, I'm pretty sure it's not triggered by Firefox exclusively. Instead, it seems Fedora in its default configuration is unable to handle almost-out-of-memory situations properly. It's one thing that the system begins to swap when more than 1 GB of RAM is still available (if that information is even correct as shown by ksysguard, again, see Bug 1426657). But the real problem is that it becomes unresponsive. Assuming a modern computer with 8 GB of RAM is really running out of memory just because Firefox has been running for a few weeks (in some cases, closing Firefox released 5 GB of RAM even though it didn't even have a lot of tabs open anymore). So it has to swap. And we all know that swapping is slow because hard drives are slower than RAM (nevermind that most of us are using SSDs nowadays in their workstations but I guess those are still considered too slow to swap). That's still no justification for freezing up like Windows did in the 90's. Fedora should still handle other processes while swapping. It might be that graphical desktops (i.e., workstations running a DE like KDE as opposed to headless servers) are hit worse as things like the mouse cursor, window frames including X buttons or even screensavers (that might prevent the user from closing anything while it's almost impossible to unlock the session because it takes minutes for each keystroke to arrive and some keys are just lost somehow) don't seem to be prioritized while swapping. In a text-only tty, you might not be able to log in in such a situation because there's a login timeout that hits before the username and password you've entered shows up on the screen (I could open another bug report for that because I've seen that a thousand times but I'm not motivated now). But if you're already logged into a tty, you might have a chance to type in "pkill firefox". > At first I thought it could be related to drm/nouveau driver for new GPUs > (GTX 1660, RTX 2060, ...) but in comment#10 there is an AMD Radeon running. I have no reason to believe that any of this is specifically related to a graphics driver. > Can we reopen this bug trying to get more people involved? It seems it's > lurking around since F29 and will show up in F31 as well. > Any new ideas or analysis are welcome! I'm not stopping you from opening another bug (where you might link this one) but I wonder how that would help. I guess we're doing the usual thing - waiting for the auto-close robot "This message is a reminder that Fedora is nearing its end of life..." and updating the release version field to the current version. I still think that Firefox is an important aspect, simply because it tends to use humongous amounts of memory sometimes and therefore acts as a trigger for that problem. However, if my interpretation is accurate, this cannot be solved by updating Firefox, changing graphics drivers or hitting a simple "do not freeze" switch somewhere. It seems like there's something amiss, something is wrong somewhere deep in the system, wherever memory management meets X11 or graphical desktops, maybe.
(In reply to Basic Six from comment #20) > (In reply to Bruno Meneguele from comment #18) > > > I let a script running each 0.5s for gather some info from the system > > (memory usage, dmesg, journal log, ps, ..) and I couldn't see anything wrong > > right before the system freeze (at least 0.5s before) from these logs. > > Firefox memory usage was actually pretty fine, nothing close to swap. > > That might be a wrong impression, I believe, as memory usage isn't always > simple and obvious (even mate-system-monitor and ksysguard have different > opinions on the current memory usage, see screenshot in Bug 1426657). > What I've noticed many times after a quick recovery (system starts to slow > down, it's beginning to get difficult to move the mouse, after a couple of > minutes the mouse reaches the X button of the Chromium window and once the > click is handled, the system instantly becomes responsive again) is that RAM > usage spiked for a few minutes until the window/process was closed (CPU as > well because of kswap), but in the graph shown by tools like ksysguard it > always seems like memory usage never actually reaches 100%. There might even > be 1 GB (out of 8, for example) GB RAM "available" when the systems becomes > unresponsive. > Yes, indeed I agree with you, but the problem is that I didn't experienced any actual "slowdown process" before the system hangs completely, what I've seen was the system 100% freezing out of the sudden. > > I'm currently using KDE as my DE on Fedora 31 Beta, but with Fedora 30 using > > cwm (a lightweight wm) I didn't hit it a single time. > > I'm going to downgrade it to Fedora 30 KDE to see what happens. > > I'm sure that's just coincidental. KDE uses more resources, especially RAM, > more than most other DEs (for a rare example, see Bug 1396740). > > (In reply to Bruno Meneguele from comment #19) > > At the same time, it doesn't has anything to do with Firefox specifically, > > since I've tested with Chromium and the system also froze. > > Yes, I'm pretty sure it's not triggered by Firefox exclusively. Instead, it > seems Fedora in its default configuration is unable to handle > almost-out-of-memory situations properly. It's one thing that the system > begins to swap when more than 1 GB of RAM is still available (if that > information is even correct as shown by ksysguard, again, see Bug 1426657). > But the real problem is that it becomes unresponsive. Assuming a modern > computer with 8 GB of RAM is really running out of memory just because > Firefox has been running for a few weeks (in some cases, closing Firefox > released 5 GB of RAM even though it didn't even have a lot of tabs open > anymore). So it has to swap. And we all know that swapping is slow because > hard drives are slower than RAM (nevermind that most of us are using SSDs > nowadays in their workstations but I guess those are still considered too > slow to swap). That's still no justification for freezing up like Windows > did in the 90's. Fedora should still handle other processes while swapping. > It might be that graphical desktops (i.e., workstations running a DE like > KDE as opposed to headless servers) are hit worse as things like the mouse > cursor, window frames including X buttons or even screensavers (that might > prevent the user from closing anything while it's almost impossible to > unlock the session because it takes minutes for each keystroke to arrive and > some keys are just lost somehow) don't seem to be prioritized while > swapping. In a text-only tty, you might not be able to log in in such a > situation because there's a login timeout that hits before the username and > password you've entered shows up on the screen (I could open another bug > report for that because I've seen that a thousand times but I'm not > motivated now). But if you're already logged into a tty, you might have a > chance to type in "pkill firefox". > > > At first I thought it could be related to drm/nouveau driver for new GPUs > > (GTX 1660, RTX 2060, ...) but in comment#10 there is an AMD Radeon running. > > I have no reason to believe that any of this is specifically related to a > graphics driver. > I was about to report in here about that, but last week I gave another try to this whole subject, but instead of trying the default Fedora installation I installed nvidia's official (proprietary) driver right after Fedora installation was completed. Since then I haven't experienced a single issue. I always have heard about how bad some brand new GPUs (mostly nvidia) were behaving on linux, but never saw anything in reality, however it seems that _something_ is actually related to that. Right now I'm using Fedora 31 + KDE (KWin over Xorg) + Firefox + "NVIDIA Driver Version: 435.21" with no problems at all for about one 1.5 weeks. > > Can we reopen this bug trying to get more people involved? It seems it's > > lurking around since F29 and will show up in F31 as well. > > Any new ideas or analysis are welcome! > > I'm not stopping you from opening another bug (where you might link this > one) but I wonder how that would help. > I guess we're doing the usual thing - waiting for the auto-close robot "This > message is a reminder that Fedora is nearing its end of life..." and > updating the release version field to the current version. > Ah no, I didn't say someone was stopping anything, just thought that letting it open would encourage people facing related issues to actually comment in here, otherwise they could feel a bit unconfortable of doing so. But at the same time I agree with you of running the "usual thing", not sure how healthy is that hehehe :/ > I still think that Firefox is an important aspect, simply because it tends > to use humongous amounts of memory sometimes and therefore acts as a trigger > for that problem. However, if my interpretation is accurate, this cannot be > solved by updating Firefox, changing graphics drivers or hitting a simple > "do not freeze" switch somewhere. It seems like there's something amiss, > something is wrong somewhere deep in the system, wherever memory management > meets X11 or graphical desktops, maybe. Yes, that's my guess too, but with a bit of salt on drm layer, even more considering my last week's experience with proprietary nvidia driver solving the issue.
Hello all, I am having the same problem, and it happens since FC28. Current setup: Linux nova 5.3.11-200.fc30.x86_64 #1 SMP Running on a Ryzen 2600 , and Nvidia GTX 1060 6GB Also, my desktop environ is Xfce. I noticed that it is not RAM related. i.e. when it freezes on mine, usually I can only see 2% utilization of RAM for firefox (I do have 32GB RAM) Also I noticed that to a lesser extent, it happens also to Konsole. One thing I found is this: I am using rpmfusion.org , so I load the nvidia driver from there. I have noticed the following: [bobx@nova]$ rpm -qa | grep nvidia kmod-nvidia-5.3.6-200.fc30.x86_64-430.40-1.fc30.x86_64 xorg-x11-drv-nvidia-kmodsrc-440.31-1.fc30.x86_64 kmod-nvidia-5.3.11-200.fc30.x86_64-440.31-1.fc30.x86_64 xorg-x11-drv-nvidia-440.31-1.fc30.x86_64 xorg-x11-drv-nvidia-cuda-libs-440.31-1.fc30.x86_64 kmod-nvidia-5.3.7-200.fc30.x86_64-440.31-1.fc30.x86_64 xorg-x11-drv-nvidia-libs-440.31-1.fc30.x86_64 nvidia-settings-440.31-1.fc30.x86_64 xorg-x11-drv-nvidia-libs-440.31-1.fc30.i686 akmod-nvidia-440.31-1.fc30.x86_64 I guess there maybe several nvidia modules fighting for resources ? Maybe the removal process is not working properly when doing a dnf upgrade. What I will do next is to shut it all down, remove all the nvidia RPMs, and reinstall just kmod-nvidia, and see if that improves things.
Oh well, I cleaned up all the nvidia packages, then reinstalled akmod from rpmfusion, then upgraded to FC31 , but I still have the same issues with Firefox. First freeze came 10 minutes after logging in. I noticed on a top, that Xorg goes to almost 100%cpu , followed by firefox at say 20% cpu (this is a 6 core Ryzen).
I have a quick update on this. 1. I updated to the latest FC31, and cleaned up the Nvidia drivers. 2. I saw the same behaviour after a few minutes of usage. Then later on, I was able to cause the freeze, both in Firefox, and Konsole , by unplugging a standard keyboard, and plugging in a SONiX USB keyboard (it's an Apple keyboard). Same symptoms appeared exactly upon plugging in the keyboard, so I reckon it's Nvidia driver related, and not exclusive to Firefox.
I'm having this issue on a mobile Intel Skylake GPU (Thinkpad T480s). Firefox and Chromium both cause system lag while playing video. Maybe the problem is related to gstreamer as opposed to a driver issue?
I am having this issue in Fedora 31 vanilla install on an IdeaPad 730S-13IWL, Intel Core i7-8565U, Intel UHD Graphics 620. Firefox 70.0.1-4.fc31. As pages load or have any IO Firefox freezes. This does not occur with Chromium.
(In reply to Robert Musial from comment #26) > I am having this issue in Fedora 31 vanilla install on an IdeaPad > 730S-13IWL, Intel Core i7-8565U, Intel UHD Graphics 620. Firefox > 70.0.1-4.fc31. > > As pages load or have any IO Firefox freezes. This does not occur with > Chromium. Can you please try Firefox-x11 package? Thanks.
(In reply to Martin Stransky from comment #27) > (In reply to Robert Musial from comment #26) > > I am having this issue in Fedora 31 vanilla install on an IdeaPad > > 730S-13IWL, Intel Core i7-8565U, Intel UHD Graphics 620. Firefox > > 70.0.1-4.fc31. > > > > As pages load or have any IO Firefox freezes. This does not occur with > > Chromium. > > Can you please try Firefox-x11 package? > Thanks. I installed that package and I can't replicate the issue in the x11 package but I can in the default install. So this is a valid suggestion. Thanks!
(In reply to Bruno Meneguele from comment #21) > > Yes, indeed I agree with you, but the problem is that I didn't experienced > any actual "slowdown process" before the system hangs completely, what I've > seen was the system 100% freezing out of the sudden. > Well, last time when it happened to me (I believe... yesterday), it also got stuck so fast that I didn't have a chance to close anything. Before that, I had both Firefox and Chromium running and started Thunderbird (I felt like taking the risk) and it was slowing down noticeably but I was able to move the mouse over the Thunderbird program button (in the task bar) and middle-click to close it, to recover instantly. > I was about to report in here about that, but last week I gave another try > to this whole subject, but instead of trying the default Fedora installation > I installed nvidia's official (proprietary) driver right after Fedora > installation was completed. Since then I haven't experienced a single issue. > I always have heard about how bad some brand new GPUs (mostly nvidia) were > behaving on linux, but never saw anything in reality, however it seems that > _something_ is actually related to that. Right now I'm using Fedora 31 + KDE > (KWin over Xorg) + Firefox + "NVIDIA Driver Version: 435.21" with no > problems at all for about one 1.5 weeks. Have you had (almost-)out-of-memory situations since then? Have you closed Firefox since then (try not to close it, if possible). > Ah no, I didn't say someone was stopping anything, just thought that letting > it open would encourage people facing related issues to actually comment in > here, otherwise they could feel a bit unconfortable of doing so. You're right but what I meant was that I think blaming the graphics driver, you're probably way off track. Of course, I might be wrong, but to me, I just see the obvious connection to memory usage. On the other hand - if you really think that the graphics driver might play a role in this (e.g., after running Firefox long enough to use up almost all memory to the point that the system starts swapping without getting stuck), please do open a new bug report and link this one. On this particular computer, lspci lists the GPU as "Intel Corporation Skylake GT2 [HD Graphics 520]" and if you do actually get different results with different drivers, I might try that too.
I am having the same issue on my HP Laptop (I7 with 8G RAM) O/S: Fedora 31 Kernel: 5.5.9-200.fc31.x86_64 #1 SMP CPU: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz Case 1: Firefox and Chrome up. Tried to add a new doc to my google docs, had hard crash Case 2: virt manager up with CentOS 8 VM running (2G RAM). Started loading a CentOS 7 VM (2G RAM), hard crash
(In reply to Wade Hampton from comment #30) > I am having the same issue on my HP Laptop (I7 with 8G RAM) > O/S: Fedora 31 > Kernel: 5.5.9-200.fc31.x86_64 #1 SMP > CPU: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz > > Case 1: Firefox and Chrome up. Tried to add a new doc to my google docs, had hard crash > Case 2: virt manager up with CentOS 8 VM running (2G RAM). Started loading a CentOS 7 VM (2G RAM), hard crash It might be better to open a new bug against F31 for this. And please attach a log captured after rebooting after the crash: $ journalctl -b -1 --no-hostname -k > dmesg.txt ^^--- specifies the log for the previous boot
This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '30'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 30 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
While Firefox definitely uses too much memory, I believe the issue here is they are using spinlocks which can hang the whole system. You can actually see this in their code for opening audio/video.
Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
This issue is caused by heavy swapping. Firefox is just what makes the system swap because it tends to use incredible amounts of memory if it's not restarted every few hours (apparently, 8 GB is not enough for a browser with a few dozen web pages open at the same time). The root SSD on a computer that was experiencing this issue regularly (because Firefox is being used all the time) has been replaced with an NVME SSD and it seems, the freezes are completely gone. The computer still has to start swapping every now and then but when it does, it stays responsive so while the fans spin up because the SSD gets hotter and kswap processes show up, it's possible to close the last browser window to release some memory. In other words, it still has to swap a lot but it now swaps much faster so it doesn't freeze the whole desktop environment like it did before. I still think it's bad behavior that a swapping operating system does not give the desktop environment and user input enough priority to keep the system responsive while swapping and I still wonder if this could be improved in Fedora Linux somehow? After replacing the root SSD, it may be necessary to manually recreate the boot image and since that part does not seem to be documented in much detail, I've opened Bug 1925973 with some instructions. Before the SSD was replaced, some attempts were made to manipulate the swappiness (/proc/sys/vm/swappiness) but that did not appear to improve the situation. To all commenters having issues with software packages: This may not be the right bug report for your issue. You should open another bug report. If you think there's something useful in this bug report, you could reference it in your bug report (like this: Bug 1597028). Also, it's unclear how this could be graphics related as some say (if it appears related, please open another bug and mention this Bug 1597028). However, there's some other graphics issue which is probably unrelated but may look very similar and maybe that's something one of the commenters has witnessed: Sometimes, the screen freezes up, everything stops moving including the mouse. However, input still works so if you are in a text editor and type something, it'll show what you've typed when the system recovers (or if you've hit the enter key multiple times trying to confirm something, you may have confirmed several things). So let's call that a graphics or gui freeze. If you're experiencing such a gui freeze, it's easy to recover. One way is to switch to another workspace several times (other, back, other, back) which you're obviously going to have to do using your keyboard, e.g., Super+Right and Super+Left or Ctrl+Alt+Right and Ctrl+Alt+Left. Another very reliable way to recover is to switch to another tty (Ctrl+Alt+F3) and back (Ctrl+Alt+F1... usually, sometimes F2...). If this gui freeze issue becomes too annoying, I'll open a separate bug for it but for now, I just want to make clear that it is something different than the swapping behavior of Fedora which causes the system to stop responding completely as described in this bug. (In reply to Robert Hoffmann from comment #22) > I noticed that it is not RAM related. i.e. when it freezes on mine, usually > I can only see 2% utilization of RAM for firefox (I do have 32GB RAM) > Also I noticed that to a lesser extent, it happens also to Konsole. Please see my comments above - if your issue is not RAM related, I'd advise you to open a separate bug report and maybe link to this one (or mention Bug 1597028).
Created attachment 2005027 [details] screenshot showing Firefox's gigantic memory leak I just had a different Fedora system freeze for the same reason: Firefox. CAUSE: The attached screenshots shows the tragedy. It has been running for only 3 days, it has 3 windows open, three tabs in one of them, 12 in another (including empty new tab pages) and another ≈0 in the third window. Not a single video or highres content, most pages are text with some images that should fit in a couple of MB of RAM but if Firefox keeps requesting more and more memory, never releasing anything, no wonder this would happen. FIREFOX: Unfortunately, the quality of Firefox appears to get worse over time compared to the high-quality browser that it used to be. Nowadays, the Mozilla devs keep removing core parts like toolbars or ftp support and they keep adding annoying icons and addons like auto translations (popups), ff account, library, pocket, so every couple of months we users have to remove yet another new icon that appeared next to the address bar. And while Mozilla appears to be focusing on those things, it almost seems like the memory leak (or leaks) is/are getting worse. WORKLOAD: The hardware is different, most of the workload is different, but what's important is that Firefox is used and because it's not restarted every couple of hours, saving and restoring open pages etc... so all memory is eventually used by Firefox and its many "Isolated Web Container" processes. In other words: To reproduce, use Firefox, browse and then keep a couple of pages open for more than a day or two. FEDORA (THIS BUG): It's one thing that Firefox has a memory leak but it is another thing that Fedora becomes completely unresponsive when that happens! How is any user supposed to close whatever seems to be using too much memory if the system freezes? If it doesn't freeze completely, then it usually locks the screen after some time and it's impossible to unlock it because it's too slow. Switching to a text tty to login there doesn't work either because it times out while checking the password! Quoting the initial comment from five years ago: > Every system is expected to slow down when it starts swapping but it's usually not a problem to terminate the browser or to open a process manager and kill the process that's using up too much memory. Unfortunately, Fedora 28 just freezes without a warning, which often means that the user has to reset the system, losing unsaved work. Why doesn't Fedora prioritize user input and things like window managers and login screens over Firefox when swapping?
Can you reliably reproduce the issue with given set of web pages? If so please provide the info here so I can replicate it. Also is the memory raise incremental or not? Please look at about:memory and to mem measurement and attach it here (if you see the leak but it's still under control). Please attach your about:support page. Thanks.
This happens to me every week a few times, it's a pain in the @$$. If you can suggest a good light weight privacy oriented browser I'd quit Firefox. It's the only program running in the session started by me, apart from background processes, without add ons, and it still freezes, completely unresponsive keyboard, no escape shortcuts work, and journalctl doesn't seem to report anything I can see noticeable. Also, it doesn't matter which web pages are loaded, there's no pattern there. From 6 windows open up, you're playing with fire. And if you happen to open another program (Gedit, Tor Browser, etc.) then you're going down the cliff for sure. Power button is going to be your only option. This is terrible. My guess is Firefox is rubbish in terms of memory management (also, web pages are horribly programmed, consuming way more resources than really required to deliver their information) but even if it were so, Fedora has a serious responsibility in the colapse since it doesn't even give the user the chance to close Firefox or a potential offending window/tab...
(In reply to benhot from comment #38) > This happens to me every week a few times, it's a pain in the @$$. If you > can suggest a good light weight privacy oriented browser I'd quit Firefox. > It's the only program running in the session started by me, apart from > background processes, without add ons, and it still freezes, completely > unresponsive keyboard, no escape shortcuts work, and journalctl doesn't seem > to report anything I can see noticeable. Also, it doesn't matter which web > pages are loaded, there's no pattern there. From 6 windows open up, you're > playing with fire. And if you happen to open another program (Gedit, Tor > Browser, etc.) then you're going down the cliff for sure. Power button is > going to be your only option. This is terrible. My guess is Firefox is > rubbish in terms of memory management (also, web pages are horribly > programmed, consuming way more resources than really required to deliver > their information) but even if it were so, Fedora has a serious > responsibility in the colapse since it doesn't even give the user the chance > to close Firefox or a potential offending window/tab... Please look at about:memory and to mem measurement and attach it here (if you see the leak but it's still under control). Please attach your about:support page and also look at about:performance page - there's memory overview per tab. Thanks.
(In reply to benhot from comment #38) > This happens to me every week a few times,... I notice Firefox uses more memory the longer it is up. I have to restart it every week regardless. Also, if you're just monitoring memory, you might miss what actually triggers the crash or freeze. I find it's usually when my swap is used up that it freezes. Palemoon seems to be even worse.