Sure, will do.

Bryce; no problem (and thanks for your working on this), for me the fbdev workaround is good enough to work and live with on this setup. If others affected by this feel differently, do take over with upstream.

Ah, sorry about that, I thought you wanted both updated logs from Lucid *and* tests with newer versions.

I just gave the current 12.04 Beta a spin and am happy to report that the issue seems to have been fixed there: despite my best efforts I couldn’t make it crash with the gallery site. It did remain somewhat sluggish to browse but the Oops never occurred.

I cannot get X working with the latest Mainline build for Lucid (2.6.35-rc1-lucid [1]) nor with linux-image-generic-lts-backport-maverick (which I figured I’d also try, as it’s also a build of 2.6.35). Both end with ”[drm] failed to open device” and ”No devices detected” in the log (I’ll attach one to this comment).

If I’m interpreting Nouveau Wiki’s Troubleshooting document [2] and the logs correctly, KMS is working (fb0 is there), which means there’s ”a version mismatch between the Nouveau DRM and libdrm”. Any help there would (also) be appreciated.

*[1] http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.35-rc1-lucid/
*[2] http://nouveau.freedesktop.org/wiki/TroubleShooting#Xorg_fails_to_start_with_.22.28EE.29_.5Bdrm.5D_failed_to_open_device.22

Whoopsie, looks like I sent the updated logs twice. Oh well.

I’ll test upstream next.

@d3mia7, maybe you could try 3.3 too? FWIW, I haven’t seen this since installing 3.3.0-030300rc4-generic a month ago now. If your system’s prone to freeze this way, testing 3.3 could provide further evidence as to whether the issue’s fixed upstream.

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 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.

My summary’s crap because this is difficult to summarize, hopefully the explanation below makes it clearer. I have little understanding of kernel internals, so I’ll first just try and describe the symptom as it appears.

I’ve come across an issue on my Fujitsu Siemens Amilo M7400 laptop with wistron_btns that is triggered by certain kernels, and once triggered, seems to affect all subsequent attempts to reboot with -pae kernels until a non-pae kernel is booted. I initially reported this on Launchpad [1].

I can currently trigger the issue by (cold or re-) booting 3.2.0-14-pae (these are Ubuntu’s packaged kernels) or by booting (for example) 3.3.0-030300rc4-generic-pae in recovery mode (= ”ro recovery nomodeset”). The recovery boot seems to work normally, but the 3.2.0-14-pae boot already exhibits the failure: it seemingly freezes. (More about the exact nature of ”failure” below.)

Once I’ve triggered the issue, rebooting with any -pae kernel fails similar to how 3.2.0-14-pae behaves irregardless of preceding boots.

I can ”fix” this by booting a non-pae kernel (which never fails). After that subsequent reboots with -pae kernels (apart from 3.2.0-14-pae) no longer fail — not until I do any of the triggering actions again.

Now, the ”failure” looks like a freeze, but it’s actually just an extreme slowdown. With patience, I can actually have the boot finish and can inspect logs. Dmesg reveals that wistron_btns is repeating ”Unknown key code 10” over and over.

If I comment wistron_btns out of /etc/modules so that it isn’t loaded, the issue goes away, meaning I can no longer trigger it.

As I said, I have little understanding of kernel bugs, so what I say next may be completely off, but the way I’ve interpreted this is that the ”brokenness” is actually hidden in the hardware, in something controlled by wistron_btns. Booting 3.2.0-14-pae/recovery booting any -pay puts the controller(?) in a ”broken” state from which a -pae kernel can’t recover, but a non-pae kernel can. And although -pae kernels later than 3.2.0-14 can’t recover a ”broken” controller, they also cannot put it into that ”broken” state (which is a good turn of development).

I’ll be happy to provide more info as requested. I’m attaching dmesg output for
starters.

* [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/926012