Alright, I think this is safe to rule as invalid because the cause is most likely hardware failure: Oneiric boot media now also fails to boot here despite being the one used to install this system initially. I even went so far back as installing Jaunty (didn’t have anything more recent at hand, before Oneiric) and it also segfaults when X should start (though the graphical installer did work). I’ll still do tests if @Joseph disagrees (and has new ideas to test), but for now I’ll just settle for using fbdev (which seems to not trigger the issue).
I initially posed this as Question #188982, but now decided to report it as it seems to persist and no definitive answers as to the cause were found. I was apprehensive about reporting at first mainly because this doesn’t seem to occur on my other (Precise-running) computers. It is however 100% reproducible on this one (i.e. the flood occurs on each creation of an Xorg log, though I don’t know what triggers individual lines).
My Xorg log is flooded with lines about reusing xkmfile:
jani@saegusa:~$ grep ”XKB: reuse xkmfile /var/lib/xkb/server-” /var/log/Xorg.0.log | tail
[ 391.894] (II) XKB: reuse xkmfile /var/lib/xkb/server-5CBD5B10CEC815928ACEFB86BAB14051BA0C83FF.xkm
[ 391.901] (II) XKB: reuse xkmfile /var/lib/xkb/server-5CBD5B10CEC815928ACEFB86BAB14051BA0C83FF.xkm
[ 391.906] (II) XKB: reuse xkmfile /var/lib/xkb/server-5CBD5B10CEC815928ACEFB86BAB14051BA0C83FF.xkm
[ 391.909] (II) XKB: reuse xkmfile /var/lib/xkb/server-5CBD5B10CEC815928ACEFB86BAB14051BA0C83FF.xkm
[ 391.914] (II) XKB: reuse xkmfile /var/lib/xkb/server-5CBD5B10CEC815928ACEFB86BAB14051BA0C83FF.xkm
[ 391.919] (II) XKB: reuse xkmfile /var/lib/xkb/server-5CBD5B10CEC815928ACEFB86BAB14051BA0C83FF.xkm
[ 391.922] (II) XKB: reuse xkmfile /var/lib/xkb/server-5CBD5B10CEC815928ACEFB86BAB14051BA0C83FF.xkm
[ 391.926] (II) XKB: reuse xkmfile /var/lib/xkb/server-5CBD5B10CEC815928ACEFB86BAB14051BA0C83FF.xkm
[ 391.929] (II) XKB: reuse xkmfile /var/lib/xkb/server-5CBD5B10CEC815928ACEFB86BAB14051BA0C83FF.xkm
[ 391.933] (II) XKB: reuse xkmfile /var/lib/xkb/server-5CBD5B10CEC815928ACEFB86BAB14051BA0C83FF.xkm
jani@saegusa:~$ grep ”XKB: reuse xkmfile /var/lib/xkb/server-” /var/log/Xorg.0.log | wc -l
1507
(Interestingly I now notice that the number of those lines seems to be constant: the above was copy+paste from terminal just now, and when I posed Question #188982 on 2012-02-27, the result was 1507 also.)
Just to add that all the icons in Elements panel, not just arrowheads, are expanded, unlike text that ignores Page zoom. Other icons, ugly as they appear when zoomed, do seem to function though.
Steps to reproduce:
1. Start Chromium with new (temporary) profile
2. Go to chrome://settings/advanced
3. Set Page zoom to 500%
4. For any page with content, open the Elements panel
5. Try to expand/shrink elements
What happens:
With the expanding/shrinking arrowheads zoomed 500%, but with code still at default zoom, it’s extremely difficult to hit the arrowhead in the right spot to expand/shrink elements. Depending on the selected Page zoom level the actual hotspot may even fall completely outside the arrowhead graphic (to the left from it).
What I expect to happen:
For the arrowheads and the code to both follow the Page zoom setting or ignore it, and either way, for the arrowhead graphic to function as the actual hotspot for expanding/shrinking elements.
I still don’t have a surefire recipe for reproducing this, but it seems especially prone to occur when I have multiple Gnome terminal windows open, or one with multiple tabs in it, in addition to other apps. I have a gut feeling it’s triggered 4/5 times by switching from something else into the set of Gnome terminal windows (with the mouse, via launcher).
I went back in Precise kernels [1] all the way back to 3.0.0-12.20. There seem to be no easy answers: now even 3.0.0-12.20 crashes with -intel.
I think this either means that the hardware’s broken, or that the issue has been lurking in kernels all the way back to (at least) 3.0.0-12.20, and was only triggered by some early Precise updates (during the time window I described above). As I said, it (definitely) wasn’t there when I filed Bug #903831 on 2011-12-13 (because I couldn’t have gotten far enough to trigger that bug with this on the way).
I’ll attach shots of current results with the early Precise kernels below just in case there’s anything useful there.
I think I’ll try ruling out hardware failure with Oneiric, either with the live disc (if that uses -intel) or by reinstalling.
* [1] https://launchpad.net/ubuntu/precise/+source/linux/
V3.3-rc6 still crashes, irregardless of RC6 being enabled/disabled.
That’s a negative: this one persists.
Confirming: the fix works.
With persistent booting I was able to get a panic [1] showing with 3.3.0-030300rc4, and it looks the same as what the dmesg I posted in #29 [2] showed: print_bad_pte+0x187/0x1e0 is on top the Trace. Despite the numerous boots I was still unable to reproduce the initial printk+0x2d/0x2f, so it may be fixed in Main or masked by the print_bad_pte+0x187/0x1e0 (though this still is based only on two datapoints in a frustratingly random issue).
Whether RC6 is enabled or disabled doesn’t seem to have bearing on this. 3.2.0-17 produces printk+0x2d/0x2f either way [3], and 3.2.0-18.28 also panics, though less consistently: I was only able to produce a sure printk+0x2d/0x2f once [4], with 3.2.0-18.28 non-pae. Mostly the errors fail to reveal themselves, and when they do, they are different from printk+0x2d/0x2f but also from each other: a couple of times a warn_slowpath_common+0x72/0xa0 (as in Bug #917668, though the hardware and pointers are different) occurred [5], and once it was a Bad page map [6] in unity-greeter.
* [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/926007/comments/32
* [2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/926007/comments/29
* [3] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/926007/comments/33
* [4] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/926007/comments/34
* [5] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/926007/comments/35
* [6] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/926007/comments/36