Sorry for the delay. I've just installed the apparent latest kernel,
which is v4.9-rc1. So far, I haven't been able to reproduce the problem
with it, unlike previous kernels 4.8-rc2 and 4.4.0-{31,34,43}. Looks
like it might be fixed!
** Changed in: linux (Ubuntu)
Status: Incomplete => Confi
nstall and then upgrading X (as well as the
kernel)?
On Thu, Sep 1, 2016, 11:41 Christopher M. Penalver <
christopher.m.penal...@gmail.com> wrote:
> Nathan Dorfman, to keep this relevant to upstream, one would want to
> test the latest mainline kernel (now 4.8-rc4) as it is released.
Forgot to mention: in the kern.log attached above, there are some new
messages with the 4.8.0-rc2 kernel that weren't present with 4.4.0-31:
Aug 15 18:47:06 panzer kernel: [ 310.233191]
[drm:drm_atomic_helper_commit_cleanup_done [drm_kms_helper]] *ERROR*
[CRTC:26:pipe A] flip_done timed out
Thes
Forgot to mention: in the kern.log attached above, there are some new
messages with the 4.8.0-rc2 kernel that weren't present with 4.4.0-31:
Aug 15 18:47:06 panzer kernel: [ 310.233191]
[drm:drm_atomic_helper_commit_cleanup_done [drm_kms_helper]] *ERROR*
[CRTC:26:pipe A] flip_done timed out
Thes
Thanks for the suggestion. Unfortunately, it's at least as bad with the
new kernel; maybe worse.
So first of all, "2nd login" doesn't reproduce the issue 100% reliably
after all. I tested one last time with kernel 4.4.0-31, and the same
exact problem occurred again, but on the 3rd, not 2nd login.
Public bug reported:
This might be too minor to even be worth mentioning, but I just happened
to notice that it wasn't quite correct.
When installing Ubuntu (using the 16.04.1 desktop amd64 ISO), I selected
the 'something else' option for manual partitioning, then did only the
following two thing
I also took an ubuntu-bug --save of xorg. Trying to update this report
with it didn't work (apport-cli -u tells me I must use apport-collect,
which has no option to use an existing save file), but it is attached in
its raw form.
** Attachment added: "bug2.apport"
https://bugs.launchpad.net/ubu
Public bug reported:
First boot after a fresh install of 16.04 from the 16.04.1 amd64 desktop
ISO, with 'download updates' enabled. This is alongside an existing
14.04 installation, which continues to work flawlessly. In particular,
this issue cannot be reproduced there. (I've installed the -lts-x
8 matches
Mail list logo