kernel dependent deterministic view crash on X startup

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

WARNING: the apport above is with the kernel 3.13.0-36-generic, where there is no problem (see the origonal post), hence it is useful only for getting the configuration of my machine.

In case of 3.16.0-23-generic I am not able to get a non-blank X neither a readable console, hence I can not provide an apport-collect result for that kernel.

However, if someone could provide me a shell script for BLIND use, then I can login blindly into a character console and run that shell script, but I have NO CHANCE to answer any question or to make any selection, since I sen NOTHING useful: the character console is broken in a different way: the usual left edge is vibrating somewhere at the 80% of the width, an only every second scan row is visible, and what is beyond the rigth edge, that appears really fuzzy on the left side.

Many thanks in advance,
        Péter.

I have just received the new kernel 3.16.0-24-generic. but the problem is still there.

3.13.0-36-generic NO problem using the SAME system and config as in the problematik 3 other cases below:

3.13.0-37-generic problem in question

3.16.0-23-generic problem in question

3.16.0-23-generic problem in question

There is a typo at the last item of the list above, so the correct list is:

3.13.0-36-generic NO problem

3.13.0-37-generic problem in question

3.16.0-23-generic problem in question

3.16.0-24-generic problem in question

This change was made by a bot.

Does the issue go away by just booting the 3.13.0-36-generic kernel and making no other changes? Then the problem comes back if you boot 3.13.0-37-generic? If that is the case, we can perform a kernel bisect to identify the commit that introduced this regression.

Yes, actuall that was the way, how I used my main computer when 14.04 was in use:

namely I had the both of 3.13.0-37-generic and 3.13.0-36-generic there in 14.04, and I made my daily work using 3.13.0-36-generic, and sometimes booting into 3.13.0-37-generic I checked whether the problem went away due to a lucky update of an X-related package.

Now I have 14.10 and I have 3.16.0-24-generic showing the same error and 3.13.0-36-generic what I can use on daily base, and whenever an update occures, I try out whether it swiped away the problem.

I would be very happy to perform a kernel bisect.

Could you tell me, how to RE-install 3.13.0-37-generic ONTO 14.10, because I did not know about the kernel bisect possibility, and I simply purged this kernel version.

I think, that 3.13.0-37-generic will show the problem using 14.10 as well, since the later 3.16.0-23-generic and 3.16.0-24-generic also shows the SAME problem.

Thanks,
        Peter.

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.18 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18-rc5-vivid/

(1)

Getting help how to make tests with upstream kernels, I did find the step,
where using NONE of the few kernels BEFORE that point I have NO xorg error,
while using ANY of the few kernels AFTER that point I HAVE xorg error.

        before 3.13 upstream 3.12.33-031233-generic has NO error

        v3.13.11.6-trusty 13-Aug-2014 and before is OK

        v3.13.11.7-trusty 18-Sep-2014 and after has the ERROR

        after 3.13 upstream 3.14.25-031425-generic has the ERROR

                    upstream 3.18.0-031800rc5-generic has the ERROR

Reinstalling a formerly purged NON-upstream Ubuntu kernel, and investigating
the release date of the kernel packages, I could verify, that the critical
kernel change step is exactly at the correspondig point.

        3.13.0-36-generic 04-Sep-2014 and before is OK

        3.13.0-37-generic 25-Sep-2014 and after has the ERROR

        3.16.0-24-generic ... has the ERROR

All of these kernels were tested with the SAME Ubuntu 14.10 systems, and the
only difference between them was that wich kernel is booted. In case of
Ubuntu 14.04 I had the critical point EXACTLY at this same place.

(2)

Intalling upstream v3.13.11.7-trusty kernel, I catched the folowing error:

        Running depmod.

        depmod: ERROR: Module 'hci_vhci' has devname (vhci) but lacks
        major and minor information. Ignoring.

        update-initramfs: deferring update (hook will be called later)

(3)

Trying out two dozens of different kernels, now I can give a bit better
description of the nature of the graphic error depending on kernel version.

3/a: except for few cases, the keyboard shortcuts work, they can invoke
programs assigned to them, ... naturally I can not use them, because I can
not see them.

3/b: almost alway the option to go Ctrl-Alt-F1 and apply Ctrl-Alt-Del is
alive, while almost never can I read anything even on the caracter terminal,
... except for the case, if the crash of the graphic view arrives a bit (few
seconds) later, and I have a narrow time slot to escape to the character
consoles.

3/c: if the crash is later, then it is exactly when I first move the mouse.

3/d: I left the most important experinece to the end:

the graphical view crash has four different states, the middle two of them
are new views for me, due to the new kernels I tried out:

    -1- as if an oldtimer CRT was not able to correctly position the
        horisontal sync, and hence the picture is horisontally rotated, and
        this state is different from all the other erratic state in that I
        can invoke and use graphical programs, hard to use, because of the
        rotation: going rightward out I arrive and enter at the left edge

    -2- as if an oldtimer CRT can not catch at all an inappropriate
        horisontal sync, far beyond its frequency limit

    -3- the essentially almost homogenous white view is patched of
        very small very intesively blinking regions

    -4- at the top a very few lines reflect the original content of the top
        unity line, but the rest is white and STILL, no blinking, ... let us
        mention, that my background is white, but NOTHING can occur in this
        area, this is a de...

The new 3.16.0-25-generic has the bug as well.

There are a few commits specific to radeon in 3.13.11.7:

aed6386 drm/radeon: tweak ACCEL_WORKING2 query for hawaii
519eac7 drm/radeon: use packet2 for nop on hawaii with old firmware
c031389 drm/radeon: re-enable dpm by default on BTC
43ee795 drm/radeon: re-enable dpm by default on cayman
1e22169 drm/radeon/dpm: handle voltage info fetching on hawaii
6f846eb drm/radeon/atom: add new voltage fetch function for hawaii
382d6be drm/radeon: set VM base addr using the PFP v2
7b421b8 drm/radeon: load the lm63 driver for an lm64 thermal chip.

Before starting a bisect, I'll build some test kernel with a few of these commits removed to see if we can narrow down if any of these commits caused the bug.

I built a test kernel up to the following commit: 1e22169

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1386534

Can you test this kernel and see if it has the bug or not?

The kernel 3.13.11-03131106-generic_3.13.11-03131106.201412021942_amd64
you were kind to build extra for me DOES WORK.

During the installation there was a message: "Running depmod.
depmod: ERROR: Module 'hci_vhci' has devname (vhci) but lacks major and minor information. Ignoring."

To be sure, I checked again, that the kernel 3.13.11-03131107-generic from ppa does not work.

I built a test kernel up to the following commit: aed6386

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1386534

Can you test this kernel and see if it has the bug or not?

The kernel you prepared me replaced the 3.13.11-03131106-generic kernel you gave me before.

This new version DOES *NOT* WORK, it shows exactly the same visual and functional phenomenon, collapse.

Looking forward to the next test,
        Péter.

Thanks for testing.

I built a test kernel up to the following commit:
c031389a56ca4789876f5896ca349aaa1cd3d544

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1386534

Can you test this kernel and see if it has the bug or not?

I have just tested the specially prepared 3.13.11-03131106-generic kernel you gave me,

and the usual error IS THERE. Using the last few new kernels, the typical scenario is this:

        (1) the correct picture is there for 1 or at most 2 seconds

        (2) then the view is wraps around, asif the horisontal synchron position was at the two-third of the lines

        (3) then within additional very fey seconds the screen becomes white, except for the topmost few scan lines

        (4) and again pretty soon, the whole bright area begins to vibrate between bright white and less bright

And as soon as I boot back into an earlier kernel but using the same Ubuntu root partition, then the screen is steady, and I can work, e.g. write this comment.

Many thanks for your help and valuable time,
        Peter.

I built a test kernel up to the following commit:
43ee79566aea566d7692bfbd68dcbe39feea047d

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1386534

Can you test this kernel and see if it has the bug or not?

Good news: the latest version DOES WORK, I use it to make this comment.

Linux pc56 3.13.11-03131106-generic #201412111801 SMP Thu Dec 11 18:02:51 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Thanks,
        Peter.

c031389a is reported as the first bad commit. This is commit b47f210 in the Utopic repo.

I built a Utopic test kernel with commit b47f210 reverted.

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1386534

Can you test this kernel and see if it has the bug or not?

The kernel you sent me recently, replaced the existing Utopic kernel 3.16.0-28,
if I understood correctly this was a normal behaviour due to the identical
version numbers, ... anyways:

NONE OF the original 3.16.0-28 kernel and the fresh kernel you sent me works,

I see exactly the same crash view, perhaps in a bit slower performance, say
I have to wait even 2 seconds to see the second phase of the crash, and again
2 seconds for the third phase. So the timing is a little bit slower, but not
significantly slower.

I made a repeated check with the kernels I tried earlier: the error is still there,

I try to be careful not to reconfigure my system during the error discovery weeks.

The kernel should have the following text in the name: ~lp1386534.

Can you run 'uname -a' to confirm this is the correct kernel?

And just to confirm, you installed the following two .deb packages:

linux-image-3.16.0-28-generic_3.16.0-28.38~lp1386534_amd64.deb
linux-image-extra-3.16.0-28-generic_3.16.0-28.38~lp1386534_amd64.deb

Due to your careful question, it turned out, that I have made very serious error!

When installing your "Utopic test kernel with commit b47f210 reverted"

        I did not install the linux-image-extra...

I tried to check whether I did same kind of error earlier.

In case of 3.13.0-36-generic, 3.13.0-36-generic and 3.16.0-28-generic, and in general, if the installation source was an Ubuntu release, then the extra was there always.

In case of kernel-PPA, following the https://wiki.ubuntu.com/Kernel/MainlineBuilds tips ( comment here: #30), I installed the headers as well, while I did NOT installed the kernel extra, since there is no such separated stuff. I tested quite a lot of kernels.

But, do I see correctly, that a size of greater than 50MB of kernel binary package means, that that package contains the extras as well? I see, when there is a separate extra package, then the normal and extra package together is slighly larger than the single "over 50MB" kernel binary package, this is why I think that this kind of single package contains the extras as well.

Then I got 4 different kernels upto diverse commits, but since they are gone from the URL you gave me, I can not RETEST them, ... while I am suspicious that I did not install the extras, but may happen that I installed on the base of "why not if it is there", simply I do not remember.

Now in case of the latest kernel, which is already an "Utopic test kernel with commit b47f210 reverted", I am sure, that I did NOT install extras.

However this kernel without the extras, --- due to it's revision number collision with the similar kernel of the normal Ubuntu release, --- is sensitive to whether the packages of the normal Ubuntu kernels are there or not.

In my #42 comment: the extras of the normal release kerlen of the same version number was there, while the extras you provided were NOT installed, and in this case I get the usual error.

But, if I remove any trace of the normal release kernel, and then I install your kernel with extras, then IT WORKS, ... actually I write this comment using your latest kerenel provided me!

I try to prevent this kernel from updating by the automatic updating system of Ubuntu.

Is installing linux-image-### and linux-image-extra-### enough to get rid of the other kernel with same version number, or what I have to do to make a clean install of the kernels you gave me?

In short: 3.13.0-36-generic works, 3.13.0-37-generic has the issue, official 3.16.0-28-generic also has the issue, but YOUR 3.16.0-28-generic WORKS.

I really excuse myself for my big error and WASTING YOUR TIME, and naturally I am ready to repeat former tests, if you could provide those packages again.

This week I prepared to formulate my thanks that regardless of we know each other you give your time and knowledge, ... and jut in this week I had to discover my error vasting resources. I advocate the free softwares approximately since two and half decades, as a university staff, so in theory I understand the importance and the meaning of this global movement, ... but it is very touching to have such an abstract and at the same time personal experinece, that someone from the mankind w...

Hello,

Just to confirm, the kernel posted in comment #41 fixes the issue?

I confirm, thet my commnet #42 is erratic, and the kernel you gave me in comment #41
DOES WORK, if I install ALSO the linux-image-extra... package. I write this comment using

Linux pc56 3.16.0-28-generic #38 SMP Mon Dec 15 16:44:02 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

that kernel in comment #41. But as soon as I allow the udpate system to replace this kernel
by the kernel in the normal 14.10 repository, then that offcial kernel does NOT work.
Neither works 3.13.0-37-generic. But 3.13.0-36-generic works, using the same root
partition.

Thanks for your forgiveness for my error,
        Peter.

Thanks for the feedback. I can request that commit c031389a is reverted.

Can you first test the latest mainline kernel, just to see if this bug is fixed already? If it is not, I can send the revert request. The latest kernel can be downloaded from:

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.19-rc3-vivid/

There is no linux-image-extra .deb for that kernel, so you would just need to install:
linux-image-3.19.0-031900rc3-generic_3.19.0-031900rc3.201501060135_amd64.deb

I have just installed the kernel package:

linux-image-3.19.0-031900rc3-generic_3.19.0-031900rc3.201501060135_amd64.deb

and it does NOT work, it showes the same, original problem.

I pinged upstream and asked for some feedback regarding a revert of commit: c031389a. They requested that we test with a revert of commit b2dccf24e77 and leaving commit c031389a.

I built a test kernel with a revert of commit b2dccf24e77 and posted it to:
http://kernel.ubuntu.com/~jsalisbury/lp1386534

Can you test this kernel and see if it has the bug or not?

Actually no need to test the kernel mentioned in the last comment. Upstream just sent a patch. I'll build a test kernel with it and post a link to it shortly.

I built a test kernel with the patch from upstream. It can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1386534

For this kernel, you will need to install both the linux-image and linux-image-extra .deb packages.

Can you test this kernel and see if it has the bug or not?

I have just tried the kernel given in your comment #52:

linux-image-3.16.0-29-generic_3.16.0-29.39~lp1386534v1_amd64.deb

linux-image-extra-3.16.0-29-generic_3.16.0-29.39~lp1386534v1_amd64.deb

It WORKS, ther is NO view crash on X strartup, I use it now for this report:

Linux pc56 3.16.0-29-generic #39 SMP Thu Jan 8 18:06:26 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Just to confirm that the rest of my system produces the error with 3.13.0-37-generic,
I tired that kernel, and the problem is still there. Hence I deduce that the kernel
you provided in comment #52 is "responsible" for disappearing the problem.

In one clear sentece: 3.16.0-29-generic_3.16.0-29.39~lp1386534v1 works error-free.

That is great news, Peter. I'll provide the testing results to upstream and send an SRU request.

Few roadmap questions.

Do I guess correctly, that the appropriate upstream kernel should work, since the kernel you gave me with the patch from upstream worked, in early January?

Is there a way to test, how can I test directly an upstream kernel that it really works in my case? Or it is more or less trivial, that it shoul work and it is not worthwhile to test it? Or the kernel you gave me is almost exaclty same as an upstream kernel, except for the necessary customisations for Ubuntu? In other terms, we tested more or less an upstream kernel in early January?

15.04 is very close to us, but can I expect, that somewhere in the summer the kernel patch that helped me WILL appear in an official Ubuntu kernel upgrade?

Sorry for my elementary questions,
        Péter.

The fix was added to the v3.19-rc6 kernel as the following commit:
4369a69 drm/radeon: add a dpm quirk list

It was also cc'd to stable, so it will make it's way into the upstream 3.16 and other stable kernels.

It was already added to the upstream 3.16 staging queue:
https://lists.ubuntu.com/archives/kernel-team/2015-February/053894.html

You should be able to test the 3.16 kernel with that fix as soon as it's available. You could also test the latest mainline, which does already have the fix:
http://kernel.ubuntu.com/~kernel-ppa/mainline/

A more direct link for the mainline kernel is:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.19-rc7-vivid/

I have just tried the kernel

        http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.19-rc7-vivid/

released three days ago, and it WORKS!

Many tnaks,
        Péter.

Tahks again, I have just upgraded to Ubuntu 15.04, and
the kernel included in it works without radeon.dpm=0.

3.19.0-15-generic #15-Ubuntu SMP Thu Apr 16 23:32:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux