date:20190913

[Kernel-packages] [Bug 1842838] Re: bionic/linux-gcp: 5.0.0-1016.16~18.04.1 -proposed tracker

2019-09-13 Thread Juerg Haefliger

** Summary changed:

- bionic/linux-gcp:  -proposed tracker
+ bionic/linux-gcp: 5.0.0-1016.16~18.04.1 -proposed tracker

** Changed in: kernel-sru-workflow/prepare-package
   Status: Confirmed => In Progress

** Changed in: kernel-sru-workflow/prepare-package
 Assignee: Canonical Kernel Team (canonical-kernel-team) => Juerg Haefliger 
(juergh)

** Changed in: kernel-sru-workflow/prepare-package-lrm
   Status: New => In Progress

** Changed in: kernel-sru-workflow/prepare-package-lrm
 Assignee: Canonical Kernel Team (canonical-kernel-team) => Juerg Haefliger 
(juergh)

** Changed in: kernel-sru-workflow/prepare-package-meta
   Status: New => In Progress

** Changed in: kernel-sru-workflow/prepare-package-meta
 Assignee: Canonical Kernel Team (canonical-kernel-team) => Juerg Haefliger 
(juergh)

** Changed in: kernel-sru-workflow/prepare-package-signed
   Status: New => In Progress

** Changed in: kernel-sru-workflow/prepare-package-signed
 Assignee: Canonical Kernel Team (canonical-kernel-team) => Juerg Haefliger 
(juergh)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-gcp in Ubuntu.
https://bugs.launchpad.net/bugs/1842838

Title:
  bionic/linux-gcp: 5.0.0-1016.16~18.04.1 -proposed tracker

Status in Kernel SRU Workflow:
  In Progress
Status in Kernel SRU Workflow automated-testing series:
  New
Status in Kernel SRU Workflow certification-testing series:
  Invalid
Status in Kernel SRU Workflow prepare-package series:
  In Progress
Status in Kernel SRU Workflow prepare-package-lrm series:
  In Progress
Status in Kernel SRU Workflow prepare-package-meta series:
  In Progress
Status in Kernel SRU Workflow prepare-package-signed series:
  In Progress
Status in Kernel SRU Workflow promote-to-proposed series:
  New
Status in Kernel SRU Workflow promote-to-security series:
  New
Status in Kernel SRU Workflow promote-to-updates series:
  New
Status in Kernel SRU Workflow regression-testing series:
  New
Status in Kernel SRU Workflow security-signoff series:
  New
Status in Kernel SRU Workflow verification-testing series:
  New
Status in linux-gcp package in Ubuntu:
  Invalid
Status in linux-gcp source package in Bionic:
  Confirmed

Bug description:
  This bug will contain status and test results related to a kernel
  source (or snap) as stated in the title.

  For an explanation of the tasks and the associated workflow see:
https://wiki.ubuntu.com/Kernel/kernel-sru-workflow

  -- swm properties --
  kernel-stable-master-bug: 1842590
  packages:
lrm: linux-restricted-modules-gcp
main: linux-gcp
meta: linux-meta-gcp
signed: linux-signed-gcp
  phase: Packaging
  phase-changed: Friday, 13. September 2019 06:55 UTC
  reason:
prepare-package: Pending -- package not yet uploaded
prepare-package-lrm: Pending -- package not yet uploaded
prepare-package-meta: Pending -- package not yet uploaded
prepare-package-signed: Pending -- package not yet uploaded
  replaces: bug 1842549
  trackers:
bionic/linux-gcp-edge: bug 1842837
bionic/linux-gcp/gcp-kernel: bug 1842836
  variant: debs

To manage notifications about this bug go to:
https://bugs.launchpad.net/kernel-sru-workflow/+bug/1842838/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1842838] Re: bionic/linux-gcp: 5.0.0-1016.16~18.04.1 -proposed tracker

2019-09-13 Thread Ubuntu Kernel Bot

** Description changed:

  This bug will contain status and test results related to a kernel source
  (or snap) as stated in the title.
  
  For an explanation of the tasks and the associated workflow see:
https://wiki.ubuntu.com/Kernel/kernel-sru-workflow
  
  -- swm properties --
  kernel-stable-master-bug: 1842590
  packages:
lrm: linux-restricted-modules-gcp
main: linux-gcp
meta: linux-meta-gcp
signed: linux-signed-gcp
- phase: Ready for Packaging
- phase-changed: Monday, 09. September 2019 04:51 UTC
+ phase: Packaging
+ phase-changed: Friday, 13. September 2019 06:55 UTC
  reason:
-   prepare-package: Pending -- version not specified
+   prepare-package: Pending -- package not yet uploaded
+   prepare-package-lrm: Pending -- package not yet uploaded
+   prepare-package-meta: Pending -- package not yet uploaded
+   prepare-package-signed: Pending -- package not yet uploaded
  replaces: bug 1842549
  trackers:
bionic/linux-gcp-edge: bug 1842837
bionic/linux-gcp/gcp-kernel: bug 1842836
  variant: debs

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-gcp in Ubuntu.
https://bugs.launchpad.net/bugs/1842838

Title:
  bionic/linux-gcp: 5.0.0-1016.16~18.04.1 -proposed tracker

Status in Kernel SRU Workflow:
  In Progress
Status in Kernel SRU Workflow automated-testing series:
  New
Status in Kernel SRU Workflow certification-testing series:
  Invalid
Status in Kernel SRU Workflow prepare-package series:
  In Progress
Status in Kernel SRU Workflow prepare-package-lrm series:
  In Progress
Status in Kernel SRU Workflow prepare-package-meta series:
  In Progress
Status in Kernel SRU Workflow prepare-package-signed series:
  In Progress
Status in Kernel SRU Workflow promote-to-proposed series:
  New
Status in Kernel SRU Workflow promote-to-security series:
  New
Status in Kernel SRU Workflow promote-to-updates series:
  New
Status in Kernel SRU Workflow regression-testing series:
  New
Status in Kernel SRU Workflow security-signoff series:
  New
Status in Kernel SRU Workflow verification-testing series:
  New
Status in linux-gcp package in Ubuntu:
  Invalid
Status in linux-gcp source package in Bionic:
  Confirmed

Bug description:
  This bug will contain status and test results related to a kernel
  source (or snap) as stated in the title.

  For an explanation of the tasks and the associated workflow see:
https://wiki.ubuntu.com/Kernel/kernel-sru-workflow

  -- swm properties --
  kernel-stable-master-bug: 1842590
  packages:
lrm: linux-restricted-modules-gcp
main: linux-gcp
meta: linux-meta-gcp
signed: linux-signed-gcp
  phase: Packaging
  phase-changed: Friday, 13. September 2019 06:55 UTC
  reason:
prepare-package: Pending -- package not yet uploaded
prepare-package-lrm: Pending -- package not yet uploaded
prepare-package-meta: Pending -- package not yet uploaded
prepare-package-signed: Pending -- package not yet uploaded
  replaces: bug 1842549
  trackers:
bionic/linux-gcp-edge: bug 1842837
bionic/linux-gcp/gcp-kernel: bug 1842836
  variant: debs

To manage notifications about this bug go to:
https://bugs.launchpad.net/kernel-sru-workflow/+bug/1842838/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1833281]

2019-09-13 Thread m.novosyolov

(In reply to howaboutsynergy from comment #55)
> On an unrelated note(but since btrfs was thought to be a problem at some
> point), I've discovered that btrfs with zstd:5 (or worse zstd:15) can cause
> (at least) mouse cursor stuttering(like it was skipping frames), while
> zstd:1 doesn't(likely because of the low CPU usage during compression),
> regardless of how fast/many writes are happening on the SSD(2-6M/s with
> zstd:15, 38-50+M/s with zstd:1), apparently due to high CPU usage during the
> compression. (zstd unspecified means zstd:3 aka default)

I tried to move Chromium cache from btrfs to tmpfs, nothing became
better, seems that Load Average became even a bit bigger in peacks
(regrading what is described in comment#51).

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1833281

Title:
  System freeze when memory is put on SWAP in Linux >4.10.x

Status in Linux:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed

Bug 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...
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.9-0ubuntu7.6
  Architecture: amd64
  AudioDevicesInUse:
   USERPID 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.
   
   lono 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-firmware1.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.v

[Kernel-packages] [Bug 1833281]

2019-09-13 Thread m.novosyolov

(In reply to Mikhail Novosyolov from comment #54)
> 
> So, something was fixed in upstream, backported to LTS kernel 4.19 and to
> Ubuntu kernel. I don't know what. And that issue is 100% not in BTRFS but is
> another problem or another aspect of the problem.
> 
I can suspect commit 2c012a4ad1a2cd3fb5a0f9307b9d219f84eda1fa "mm: vmscan: scan 
anonymous pages on file refaults"

https://github.com/torvalds/linux/commit/2c012a4ad1a2cd3fb5a0f9307b9d219f84eda1fa

It appeared in kernel 5.3 and was backported to 4.19.62 and Ubuntu
kernel 4.15.0-59

(In reply to ValdikSS from comment #53)
> Recently, about since kernel 5.2.7, the issue is either gone or present to
> much less extent.
> Right now I'm running kernel 5.2.11 and finally I can keel Firefox and
> VirtualBox running at the same time, with 3G+ in swap, and the system does
> not freeze.
... and to 5.2.3

But that commit "fixes" commits from the era of kernels 3.8 and 3.9, so
probably it is not the one I'm looking for.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1833281

Title:
  System freeze when memory is put on SWAP in Linux >4.10.x

Status in Linux:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed

Bug 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...
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.9-0ubuntu7.6
  Architecture: amd64
  AudioDevicesInUse:
   USERPID 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.
   
   lono 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-firmware1.173.6
  RfKill:
   0: hci0: Bluetooth
Soft blocked: no

[Kernel-packages] [Bug 1833281]

2019-09-13 Thread howaboutsynergy

On an unrelated note(but since btrfs was thought to be a problem at some
point), I've discovered that btrfs with zstd:5 (or worse zstd:15) can
cause (at least) mouse cursor stuttering(like it was skipping frames),
while zstd:1 doesn't(likely because of the low CPU usage during
compression), regardless of how fast/many writes are happening on the
SSD(2-6M/s with zstd:15, 38-50+M/s with zstd:1), apparently due to high
CPU usage during the compression. (zstd unspecified means zstd:3 aka
default)

Normal CPU usage by itself(eg. during compiling) doesn't cause such
stuttering though. I've tested this on a Lenovo Ideapad Z575, 16G RAM,
Kingston SSD SA400S37240G firmware SBFK71F1, and I've personally
switched to zstd:1

ie.
```
diff --git a/fs/btrfs/zstd.c b/fs/btrfs/zstd.c
index 6b9e29d050f3..02ffdb27c360 100644
--- a/fs/btrfs/zstd.c
+++ b/fs/btrfs/zstd.c
@@ -22,7 +22,7 @@
 
 #define ZSTD_BTRFS_MAX_WINDOWLOG 17
 #define ZSTD_BTRFS_MAX_INPUT (1 << ZSTD_BTRFS_MAX_WINDOWLOG)
-#define ZSTD_BTRFS_DEFAULT_LEVEL 3
+#define ZSTD_BTRFS_DEFAULT_LEVEL 1
 #define ZSTD_BTRFS_MAX_LEVEL 15
 /* 307s to avoid pathologically clashing with transaction commit */
 #define ZSTD_BTRFS_RECLAIM_JIFFIES (307 * HZ)
```

but zstd:1 in /etc/fstab should also work, unless using too old kernel
that doesn't know about it (hence why I prefer using the patch anyway)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1833281

Title:
  System freeze when memory is put on SWAP in Linux >4.10.x

Status in Linux:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed

Bug 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...
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.9-0ubuntu7.6
  Architecture: amd64
  AudioDevicesInUse:
   USERPID 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.
   
   lono 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-9f

[Kernel-packages] [Bug 1833281]

2019-09-13 Thread iam

Recently, about since kernel 5.2.7, the issue is either gone or present to much 
less extent.
Right now I'm running kernel 5.2.11 and finally I can keel Firefox and 
VirtualBox running at the same time, with 3G+ in swap, and the system does not 
freeze.

Could anyone affected by this issue try newer kernels?

Mikhail, I have a spare laptop which I can setup for you for tests. Do
you have time and wish to investigate this issue?

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1833281

Title:
  System freeze when memory is put on SWAP in Linux >4.10.x

Status in Linux:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed

Bug 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...
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.9-0ubuntu7.6
  Architecture: amd64
  AudioDevicesInUse:
   USERPID 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.
   
   lono 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-firmware1.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

[Kernel-packages] [Bug 1833281]

2019-09-13 Thread m.novosyolov

(In reply to ValdikSS from comment #53)
> Recently, about since kernel 5.2.7, the issue is either gone or present to
> much less extent.
> Right now I'm running kernel 5.2.11 and finally I can keel Firefox and
> VirtualBox running at the same time, with 3G+ in swap, and the system does
> not freeze.
>
> Could anyone affected by this issue try newer kernels?

First of all, did you reset all your custom sysctls to default values?

1) One user (ilfat@) reported that:
1.1) on kernels 4.19.57 and Ubuntu kernel 4.15.0-54 his system did not swap
correctly: all memory was full but only a small part of the swap was used, that
lead to freezes
1.2) on kernels 4.19.67 and Ubuntu kernels 4.15.0-60, 4.15.0-62 systemd swaps
in general normally, but he tweaked vm.watermark_scale_factor to make it swap
better
1.3) Ilfat had exactly the same problem on both ext4 and btrfs

So, something was fixed in upstream, backported to LTS kernel 4.19 and
to Ubuntu kernel. I don't know what. And that issue is 100% not in BTRFS
but is another problem or another aspect of the problem.

2) I did not see much difference between Ubuntu kernels 54 and 60, 62 in
what is described in comment#51. So, that mystereous fix did not help.

3) another user (anreas@) reports the same as in (2):
https://forum.rosalinux.ru/viewtopic.php?p=101903&sid=621857320f4d1a566e0cfa6e80ff4a8c#p101903

4) trying to overcome issues from comment#51, I built Ubuntu kernel
4.15.0 with 2 pathes:

* https://abf.io/mikhailnov/kernel-desktop-4.15/blob/master/le9-rosa.patch
*
https://abf.io/mikhailnov/kernel-desktop-4.15/blob/master/Chromium-OS-low-memory-patchset.patch

and set kernel options:
# https://bugzilla.kernel.org/show_bug.cgi?id=196729#c36
vm.watermark_scale_factor=100
vm.unevictable_activefile_kbytes=10
#vm.swappiness=80
# https://bugs.chromium.org/p/chromium/issues/detail?id=263561#c16
# Disable swap read-ahead
vm.page-cluster=0

After that, I _thank_ it became a bit better (I cannot prove it by
numbers, just was unbale to make the system become inresponsive, but LA
remained the same), but unfortunately the main user of that notebook did
not use it for some days and so right now I can't say that according to
her feedback the situation has improved and the system does not
microfreeze from time to time anymore. Let's wait a bit more. And still
that may be a coincidence, not the result of patches and/or tweaked
sysctls.

I was able to dead lock that system by openning too many tabs in
Chromium, but that is not what those patches should have solved.
nohang/earlymoon would have probably helped if it was used.

>
> Mikhail, I have a spare laptop which I can setup for you for tests. Do you
> have time and wish to investigate this issue?

I don't have ideas how to investigate it. And how to measure the result.
Maybe PSI can tell something, I did not try to look at them. And even
more, I don't understand what the problem is ;)

--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1833281

Title:
System freeze when memory is put on SWAP in Linux >4.10.x

Status in Linux:
Confirmed
Status in linux package in Ubuntu:
Confirmed

Bug 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...

1 2 >

1 - 100 of 106 matches

Mail list logo