| 2019-06-18 17:26:17 |
Luca Osvaldo Mastromatteo |
bug |
|
|
added bug |
| 2019-06-18 17:26:37 |
Luca Osvaldo Mastromatteo |
description |
I'm reporting this since it's reproduceable the 70% of the time.
Summary:
In different circumstances, when the systems starts to swap out RAM memory, even small amounts, the system becomes completely unusuable and the screen freezes up, no mouse movement, no TTY access or SSH access can be made, only SYSRQ keys seem to do something (only reboot, so REISUB worked so far though, OOM is useless since the memory/swap is not even full)
The I/O Disk led is stuck to 100% in ALL the following cases when this happens.
So far:
- This happens even when only ZRAM is enabled, and no swap partition is used.
- Happens when ZSWAP is used with a swap partition
- Happens also when a partition without zram or zswap is used
However, I'm not experiencing this on my laptop using the same tests.
My laptop is an Intel one, while my desktop is an AMD Ryzen platform.
Here are the specs:
CPU: AMD Ryzen 5 1600 no OC
GPU: AMD RX 580 8GB
SSD: Crucial MX500 500GB
MOBO: MSI B350M Grenade
RAM: 8GB HyperX Kingston 2667Mhz
Ubuntu version: 18.04 LTS, backports repo enabled
Kernel version: 4.18.0-18, official ubuntu repo
Bios settings: Default
Additional info: Maybe I'm not 100% sure, but I noticed when using the 5.0.0-17 generic kernel, the lockups seem to still happen, but they recover eventually. Happened only a few times though...
But will always be frozen for at least 30 seconds, differently from my intel laptop where those do occur.
The SSD make is the same. I bought two of these, they got also the same amount of RAM.
In my laptop those do not occur at all. Swapping memory even huge quantities like 1GB or more, do not produce any issues.
Tests made:
For testing this behaviour I tried:
- Compiling the chromium-browser source code (takes up a lot of system RAM)
- Used the "stress" command, using a specific amount of memory to decide how many it will be swapped, and here I noticed that even small quantities like a couple of megabytes will cause the system to freeze the 70% of the times
Example: "stress --vm 1 --vm-bytes=7G"
What should happen:
I expect system slowdowns when swapping out memory since I do not have enough RAM, but unlikely when using Windows or my laptop with the same Linux version, not a completely unusuable environment. The swap partition is in both cases on an SSD.
Reproduceability: 70% of the times
Additional info again:
I'm not sure this is due to any hardware failure, my SSD health is fine, as my CPU and RAM. As I said swapping in Windows works fine... |
I'm reporting this since it's reproduceable the 70% of the time.
Summary:
In different circumstances, when the systems starts to swap out RAM memory, even small amounts, the system becomes completely unusuable and the screen freezes up, no mouse movement, no TTY access or SSH access can be made, only SYSRQ keys seem to do something (only reboot, so REISUB worked so far though, OOM is useless since the memory/swap is not even full)
The I/O Disk led is stuck to 100% in ALL the following cases when this happens.
So far:
- This happens even when only ZRAM is enabled, and no swap partition is used.
- Happens when ZSWAP is used with a swap partition
- Happens also when a partition without zram or zswap is used
- Maybe it's AMD specific?
However, I'm not experiencing this on my laptop using the same tests.
My laptop is an Intel one, while my desktop is an AMD Ryzen platform.
Here are the specs:
CPU: AMD Ryzen 5 1600 no OC
GPU: AMD RX 580 8GB
SSD: Crucial MX500 500GB
MOBO: MSI B350M Grenade
RAM: 8GB HyperX Kingston 2667Mhz
Ubuntu version: 18.04 LTS, backports repo enabled
Kernel version: 4.18.0-18, official ubuntu repo
Bios settings: Default
Additional info: Maybe I'm not 100% sure, but I noticed when using the 5.0.0-17 generic kernel, the lockups seem to still happen, but they recover eventually. Happened only a few times though...
But will always be frozen for at least 30 seconds, differently from my intel laptop where those do occur.
The SSD make is the same. I bought two of these, they got also the same amount of RAM.
In my laptop those do not occur at all. Swapping memory even huge quantities like 1GB or more, do not produce any issues.
Tests made:
For testing this behaviour I tried:
- Compiling the chromium-browser source code (takes up a lot of system RAM)
- Used the "stress" command, using a specific amount of memory to decide how many it will be swapped, and here I noticed that even small quantities like a couple of megabytes will cause the system to freeze the 70% of the times
Example: "stress --vm 1 --vm-bytes=7G"
What should happen:
I expect system slowdowns when swapping out memory since I do not have enough RAM, but unlikely when using Windows or my laptop with the same Linux version, not a completely unusuable environment. The swap partition is in both cases on an SSD.
Reproduceability: 70% of the times
Additional info again:
I'm not sure this is due to any hardware failure, my SSD health is fine, as my CPU and RAM. As I said swapping in Windows works fine... |
|
| 2019-06-18 17:30:05 |
Ubuntu Kernel Bot |
linux (Ubuntu): status |
New |
Incomplete |
|
| 2019-06-18 17:34:39 |
Luca Osvaldo Mastromatteo |
tags |
|
apport-collected bionic |
|
| 2019-06-18 17:34:40 |
Luca Osvaldo Mastromatteo |
description |
I'm reporting this since it's reproduceable the 70% of the time.
Summary:
In different circumstances, when the systems starts to swap out RAM memory, even small amounts, the system becomes completely unusuable and the screen freezes up, no mouse movement, no TTY access or SSH access can be made, only SYSRQ keys seem to do something (only reboot, so REISUB worked so far though, OOM is useless since the memory/swap is not even full)
The I/O Disk led is stuck to 100% in ALL the following cases when this happens.
So far:
- This happens even when only ZRAM is enabled, and no swap partition is used.
- Happens when ZSWAP is used with a swap partition
- Happens also when a partition without zram or zswap is used
- Maybe it's AMD specific?
However, I'm not experiencing this on my laptop using the same tests.
My laptop is an Intel one, while my desktop is an AMD Ryzen platform.
Here are the specs:
CPU: AMD Ryzen 5 1600 no OC
GPU: AMD RX 580 8GB
SSD: Crucial MX500 500GB
MOBO: MSI B350M Grenade
RAM: 8GB HyperX Kingston 2667Mhz
Ubuntu version: 18.04 LTS, backports repo enabled
Kernel version: 4.18.0-18, official ubuntu repo
Bios settings: Default
Additional info: Maybe I'm not 100% sure, but I noticed when using the 5.0.0-17 generic kernel, the lockups seem to still happen, but they recover eventually. Happened only a few times though...
But will always be frozen for at least 30 seconds, differently from my intel laptop where those do occur.
The SSD make is the same. I bought two of these, they got also the same amount of RAM.
In my laptop those do not occur at all. Swapping memory even huge quantities like 1GB or more, do not produce any issues.
Tests made:
For testing this behaviour I tried:
- Compiling the chromium-browser source code (takes up a lot of system RAM)
- Used the "stress" command, using a specific amount of memory to decide how many it will be swapped, and here I noticed that even small quantities like a couple of megabytes will cause the system to freeze the 70% of the times
Example: "stress --vm 1 --vm-bytes=7G"
What should happen:
I expect system slowdowns when swapping out memory since I do not have enough RAM, but unlikely when using Windows or my laptop with the same Linux version, not a completely unusuable environment. The swap partition is in both cases on an SSD.
Reproduceability: 70% of the times
Additional info again:
I'm not sure this is due to any hardware failure, my SSD health is fine, as my CPU and RAM. As I said swapping in Windows works fine... |
I'm reporting this since it's reproduceable the 70% of the time.
Summary:
In different circumstances, when the systems starts to swap out RAM memory, even small amounts, the system becomes completely unusuable and the screen freezes up, no mouse movement, no TTY access or SSH access can be made, only SYSRQ keys seem to do something (only reboot, so REISUB worked so far though, OOM is useless since the memory/swap is not even full)
The I/O Disk led is stuck to 100% in ALL the following cases when this happens.
So far:
- This happens even when only ZRAM is enabled, and no swap partition is used.
- Happens when ZSWAP is used with a swap partition
- Happens also when a partition without zram or zswap is used
- Maybe it's AMD specific?
However, I'm not experiencing this on my laptop using the same tests.
My laptop is an Intel one, while my desktop is an AMD Ryzen platform.
Here are the specs:
CPU: AMD Ryzen 5 1600 no OC
GPU: AMD RX 580 8GB
SSD: Crucial MX500 500GB
MOBO: MSI B350M Grenade
RAM: 8GB HyperX Kingston 2667Mhz
Ubuntu version: 18.04 LTS, backports repo enabled
Kernel version: 4.18.0-18, official ubuntu repo
Bios settings: Default
Additional info: Maybe I'm not 100% sure, but I noticed when using the 5.0.0-17 generic kernel, the lockups seem to still happen, but they recover eventually. Happened only a few times though...
But will always be frozen for at least 30 seconds, differently from my intel laptop where those do occur.
The SSD make is the same. I bought two of these, they got also the same amount of RAM.
In my laptop those do not occur at all. Swapping memory even huge quantities like 1GB or more, do not produce any issues.
Tests made:
For testing this behaviour I tried:
- Compiling the chromium-browser source code (takes up a lot of system RAM)
- Used the "stress" command, using a specific amount of memory to decide how many it will be swapped, and here I noticed that even small quantities like a couple of megabytes will cause the system to freeze the 70% of the times
Example: "stress --vm 1 --vm-bytes=7G"
What should happen:
I expect system slowdowns when swapping out memory since I do not have enough RAM, but unlikely when using Windows or my laptop with the same Linux version, not a completely unusuable environment. The swap partition is in both cases on an SSD.
Reproduceability: 70% of the times
Additional info again:
I'm not sure this is due to any hardware failure, my SSD health is fine, as my CPU and RAM. As I said swapping in Windows works fine...
---
ProblemType: Bug
ApportVersion: 2.20.9-0ubuntu7.6
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC1: haru 2076 F.... pulseaudio
/dev/snd/controlC2: haru 2076 F.... pulseaudio
/dev/snd/controlC0: haru 2076 F.... pulseaudio
CurrentDesktop: communitheme:ubuntu:GNOME
DistroRelease: Ubuntu 18.04
IwConfig:
enp24s0 no wireless extensions.
lo no wireless extensions.
MachineType: Micro-Star International Co., Ltd. MS-7A37
Package: linux (not installed)
ProcFB: 0 amdgpudrmfb
ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-5.0.0-17-generic root=UUID=75d45574-7169-4653-aea3-9f95087f0806 ro rootflags=subvol=@ quiet splash vt.handoff=1
ProcVersionSignature: Ubuntu 5.0.0-17.18~18.04.1-generic 5.0.8
RelatedPackageVersions:
linux-restricted-modules-5.0.0-17-generic N/A
linux-backports-modules-5.0.0-17-generic N/A
linux-firmware 1.173.6
RfKill:
0: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
Tags: bionic
Uname: Linux 5.0.0-17-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: sudo video
WifiSyslog:
_MarkForUpload: True
dmi.bios.date: 01/22/2019
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 1.K0
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: B350M MORTAR (MS-7A37)
dmi.board.vendor: Micro-Star International Co., Ltd.
dmi.board.version: 1.0
dmi.chassis.asset.tag: To be filled by O.E.M.
dmi.chassis.type: 4
dmi.chassis.vendor: Micro-Star International Co., Ltd.
dmi.chassis.version: 1.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1.K0:bd01/22/2019:svnMicro-StarInternationalCo.,Ltd.:pnMS-7A37:pvr1.0:rvnMicro-StarInternationalCo.,Ltd.:rnB350MMORTAR(MS-7A37):rvr1.0:cvnMicro-StarInternationalCo.,Ltd.:ct4:cvr1.0:
dmi.product.family: To be filled by O.E.M.
dmi.product.name: MS-7A37
dmi.product.sku: To be filled by O.E.M.
dmi.product.version: 1.0
dmi.sys.vendor: Micro-Star International Co., Ltd. |
|
| 2019-06-18 17:34:40 |
Luca Osvaldo Mastromatteo |
attachment added |
|
AlsaInfo.txt https://bugs.launchpad.net/bugs/1833281/+attachment/5271423/+files/AlsaInfo.txt |
|
| 2019-06-18 17:34:41 |
Luca Osvaldo Mastromatteo |
attachment added |
|
CRDA.txt https://bugs.launchpad.net/bugs/1833281/+attachment/5271424/+files/CRDA.txt |
|
| 2019-06-18 17:34:43 |
Luca Osvaldo Mastromatteo |
attachment added |
|
CurrentDmesg.txt https://bugs.launchpad.net/bugs/1833281/+attachment/5271425/+files/CurrentDmesg.txt |
|
| 2019-06-18 17:34:44 |
Luca Osvaldo Mastromatteo |
attachment added |
|
Lspci.txt https://bugs.launchpad.net/bugs/1833281/+attachment/5271426/+files/Lspci.txt |
|
| 2019-06-18 17:34:45 |
Luca Osvaldo Mastromatteo |
attachment added |
|
Lsusb.txt https://bugs.launchpad.net/bugs/1833281/+attachment/5271427/+files/Lsusb.txt |
|
| 2019-06-18 17:34:46 |
Luca Osvaldo Mastromatteo |
attachment added |
|
ProcCpuinfo.txt https://bugs.launchpad.net/bugs/1833281/+attachment/5271428/+files/ProcCpuinfo.txt |
|
| 2019-06-18 17:34:48 |
Luca Osvaldo Mastromatteo |
attachment added |
|
ProcCpuinfoMinimal.txt https://bugs.launchpad.net/bugs/1833281/+attachment/5271429/+files/ProcCpuinfoMinimal.txt |
|
| 2019-06-18 17:34:49 |
Luca Osvaldo Mastromatteo |
attachment added |
|
ProcEnviron.txt https://bugs.launchpad.net/bugs/1833281/+attachment/5271430/+files/ProcEnviron.txt |
|
| 2019-06-18 17:34:51 |
Luca Osvaldo Mastromatteo |
attachment added |
|
ProcInterrupts.txt https://bugs.launchpad.net/bugs/1833281/+attachment/5271431/+files/ProcInterrupts.txt |
|
| 2019-06-18 17:34:53 |
Luca Osvaldo Mastromatteo |
attachment added |
|
ProcModules.txt https://bugs.launchpad.net/bugs/1833281/+attachment/5271432/+files/ProcModules.txt |
|
| 2019-06-18 17:34:54 |
Luca Osvaldo Mastromatteo |
attachment added |
|
PulseList.txt https://bugs.launchpad.net/bugs/1833281/+attachment/5271433/+files/PulseList.txt |
|
| 2019-06-18 17:34:55 |
Luca Osvaldo Mastromatteo |
attachment added |
|
UdevDb.txt https://bugs.launchpad.net/bugs/1833281/+attachment/5271434/+files/UdevDb.txt |
|
| 2019-06-18 17:42:54 |
Luca Osvaldo Mastromatteo |
linux (Ubuntu): status |
Incomplete |
Confirmed |
|
| 2019-06-18 23:27:48 |
Terry Rudd |
bug |
|
|
added subscriber Terry Rudd |
| 2019-06-29 14:50:48 |
Luca Osvaldo Mastromatteo |
bug watch added |
|
https://bugzilla.kernel.org/show_bug.cgi?id=196729 |
|
| 2019-06-29 14:50:48 |
Luca Osvaldo Mastromatteo |
bug task added |
|
linux |
|
| 2019-06-29 14:52:44 |
Luca Osvaldo Mastromatteo |
summary |
Complete system freeze even when swapping small amounts of memory |
System freeze when memory is put on SWAP in Linux >4.10.x |
|
| 2019-06-29 16:23:57 |
Bug Watch Updater |
linux: status |
Unknown |
Confirmed |
|
| 2019-06-29 16:23:57 |
Bug Watch Updater |
linux: importance |
Unknown |
Medium |
|
| 2019-06-29 16:24:03 |
Bug Watch Updater |
bug watch added |
|
https://bugzilla.redhat.com/show_bug.cgi?id=1472336 |
|
| 2019-06-29 16:24:03 |
Bug Watch Updater |
bug watch added |
|
https://bugzilla.redhat.com/show_bug.cgi?id=1577528 |
|
| 2019-06-29 16:24:03 |
Bug Watch Updater |
bug watch added |
|
https://bugzilla.kernel.org/show_bug.cgi?id=199763 |
|
| 2020-01-04 13:55:45 |
shankao |
bug |
|
|
added subscriber shankao |
| 2020-03-14 20:03:09 |
René Bühlmann |
bug |
|
|
added subscriber René Bühlmann |
| 2020-09-12 21:27:22 |
Ryan C. Underwood |
bug |
|
|
added subscriber Ryan C. Underwood |
| 2020-12-24 21:41:34 |
Kevin Wortman |
bug |
|
|
added subscriber Kevin Wortman |
| 2021-01-14 08:37:51 |
Stanislav German-Evtushenko |
bug |
|
|
added subscriber Stanislav German-Evtushenko |
| 2024-08-03 02:26:25 |
Bug Watch Updater |
linux: status |
Confirmed |
Expired |
|
