The first kernel on that list that exhibits the bug is the first one:
4.14 Final. Recall: the bug results in a full up hang. The disk stops
swapping (it's audible). I can reboot with sysctl SUB however.
I then tested 4.13.0-36 from the Ubuntu 17.10 respoitory, followed by
4.11.12-041112-generic from mainline. Both had the bug.
I also tested each of these without cryptswap (i.e. normal swap) and
they did not hang. The system ground to a halt, but I could hear the
disk swapping and the process eventually completed.
I then booted an 16.04 live usb which has kernel 4.10. I had to make a
cryptswap using cryptsetup on the swap partition of the hard disk, to
test it. But this one worked! The behavior was a bit different that
more recent kernels: after allocating 6 GB of the 10 GB that I
requested, the system invoked the oom-killer on the process. However,
it did not hang.
I then grabbed 4.10.1-041001-generic from mainline and tested it. This
worked the same as the live usb. So 4.10 does not have the bug,
although the oom-killer is invoked to kill the process grabbing the memory.
I have an older machine with an SSD. This does not exhibit the bug on
Ubuntu 17.10 running 4.13.0-36. However, this disk is _fast_ (Samsung
EVO), so I'm guessing that there is some tuning problem, maybe, in how
the kernel handles swap speed vs memory allocation requests??? I really
don't know.
The first kernel on that list that exhibits the bug is the first one:
4.14 Final. Recall: the bug results in a full up hang. The disk stops
swapping (it's audible). I can reboot with sysctl SUB however.
I then tested 4.13.0-36 from the Ubuntu 17.10 respoitory, followed by 041112- generic from mainline. Both had the bug.
4.11.12-
I also tested each of these without cryptswap (i.e. normal swap) and
they did not hang. The system ground to a halt, but I could hear the
disk swapping and the process eventually completed.
I then booted an 16.04 live usb which has kernel 4.10. I had to make a
cryptswap using cryptsetup on the swap partition of the hard disk, to
test it. But this one worked! The behavior was a bit different that
more recent kernels: after allocating 6 GB of the 10 GB that I
requested, the system invoked the oom-killer on the process. However,
it did not hang.
I then grabbed 4.10.1- 041001- generic from mainline and tested it. This
worked the same as the live usb. So 4.10 does not have the bug,
although the oom-killer is invoked to kill the process grabbing the memory.
I have an older machine with an SSD. This does not exhibit the bug on
Ubuntu 17.10 running 4.13.0-36. However, this disk is _fast_ (Samsung
EVO), so I'm guessing that there is some tuning problem, maybe, in how
the kernel handles swap speed vs memory allocation requests??? I really
don't know.
--M
On 04/11/2018 11:18 AM, Joseph Salisbury wrote: kernel. ubuntu. com/~kernel- ppa/mainline/ v4.14/ kernel. ubuntu. com/~kernel- ppa/mainline/ v4.15-rc1/ kernel. ubuntu. com/~kernel- ppa/mainline/ v4.15-rc4/ kernel. ubuntu. com/~kernel- ppa/mainline/ v4.15/
> I'd like to perform a bisect to figure out what commit caused this
> regression. We need to identify the earliest kernel where the issue
> started happening as well as the latest kernel that did not have this
> issue.
>
> Can you test the following kernels and report back? We are looking for
> the first kernel version that exhibits this bug:
>
> v4.14 Final: http://
> v4.15-rc1: http://
> v4.15-rc4: http://
> v4.15 Final: http://
>
> You don't have to test every kernel, just up until the kernel that first
> has this bug.
>
> Thanks in advance!
>
> ** Tags added: performing-bisect
>
--
Martin Weinberg
6 Grass Hill Rd
West Whately, MA
010039