BTW, I _do_ realize that you want a starting point for bisection; I'm
sorry this is turning out so messy.
On 04/11/2018 05:51 PM, Martin Weinberg wrote:
> 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.
>
> --M
>
>
> On 04/11/2018 11:18 AM, Joseph Salisbury wrote:
>> 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://kernel.ubuntu.com/~kernel-ppa/mainline/v4.14/
>> v4.15-rc1: http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.15-rc1/
>> v4.15-rc4: http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.15-rc4/
>> v4.15 Final: http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.15/
>>
>> 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
BTW, I _do_ realize that you want a starting point for bisection; I'm
sorry this is turning out so messy.
On 04/11/2018 05:51 PM, Martin Weinberg wrote: 041112- generic from mainline. Both had the bug. 041001- generic from mainline and tested it. This 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/
> 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-
>
> 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-
> 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:
>> 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