I've got this all typed in and I see in dmesg that there are some CD read errors. I have seen these before with what appear to be incorrectly created squashfs CD's. The panic / oops may indeed be caused by a CD error. <EDIT> I tested the CD with the test CD boot option and it passed. </EDIT>
This is when running the i386 Natty (11.04) daily live (development) CD dated I believe 2011-01-27 on a very stable Dual core (Intel 925 dual core (AMD64 capable), ECS (Via) P4M800PRO, 2 gigs, Asus Geforce 3 AGP) system that I just want to get better OpenGL running on. (Hoping to find better OpenGL support in Natty.) It happened as the desktop was coming up. No icons or task bars appeared before the error, but the background had been painted for perhaps 30 seconds (wild guess).
This system exhibits the "no human readable MCE decoding support on this CPU type" issue at boot up into this live Natty CD and I had to use "nomce" in the kernel boot options line to get past it. I also recall that with previous kernels on Lucid (AMD64) this stable system always generates an MCE at 300 seconds after boot in dmesg. I researched it before and didn't find anything useful.
I use this system for 12 hours every day (with Maverick lately) and have no lockups or corruptions at all.
With the Natty daily CD, this system also exhibits the "it seems you do not have the hardware requirements to run unity" issue, perhaps because it has an old monitor that these later kernels (at least the later ones, maybe the earlier ones too) have a hard time finding the EDID on. On my hard drive upgrade from Lucid to Maverick I had to make an xorg.conf with some horizontal and vertical monitor timing ranges before it would let me use a reasonable screen resolution and refresh rate. In Maverick, the refresh rate was 0 before this and (I forget the tool) said it got an EDID error trying to get info from the monitor.
Looking at dmesg, I see that I have an easycap (video to USB adapter) plugged in (with no video source though). The easycap device works fine under previous versions of Ubuntu (sourceforge driver). I notice though that it was detected as the FOUR-CVBS (4 video input) hardware version which is incorrect if that matters. It is the single CVBS version.
If I had to guess at possible causes, I would point first to the CD read errors (that I now see in the dmesg) (I need to retest reading the CD on this drive from my stable Maverick), <EDIT> CD tested OK </EDIT> then to the benign MCE that always happened at 300 seconds (at least with earlier Ubuntus) <EDIT> Maverick also produces this benign MCE at 300 seconds (and not again till reboot) </EDIT> and I suspect that is related to the "no human readable MCE decoding support on this CPU type" that I now get with this Natty development version.
This is the first time I have tried the early Natty.
ProblemType: Crash
DistroRelease: Ubuntu 11.04
Package: nux-tools 0.9.16-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.37-12.26-generic 2.6.37
Uname: Linux 2.6.37-12-generic i686
Architecture: i386
Date: Sat Jan 29 02:18:49 2011
Disassembly: => 0x0: Cannot access memory at address 0x0
ExecutablePath: /usr/lib/nux/unity_support_test
LiveMediaBuild: Ubuntu 11.04 "Natty Narwhal" - Alpha i386 (20110127)
ProcCmdline: /usr/lib/nux/unity_support_test
ProcEnviron:
LANGUAGE=en_US.UTF-8:en
LANG=en_US.UTF-8
LC_MESSAGES=en_AG.utf8
SHELL=/bin/bash
SegvAnalysis:
Segfault happened at: 0x0: Cannot access memory at address 0x0
PC (0x00000000) not located in a known VMA region (needed executable region)!
SegvReason: executing NULL VMA
Signal: 11
SourcePackage: nux
StacktraceTop:
?? ()
nux::IOpenGLAsmVertexShader::IOpenGLAsmVertexShader(nux::NString) () from /usr/lib/libnux-graphics-0.9.so.0
nux::GpuDevice::CreateAsmVertexShader(nux::IOpenGLAsmVertexShader**) () from /usr/lib/libnux-graphics-0.9.so.0
nux::GpuDevice::CreateAsmVertexShader() () from /usr/lib/libnux-graphics-0.9.so.0
nux::IOpenGLAsmShaderProgram::IOpenGLAsmShaderProgram(nux::NString) () from /usr/lib/libnux-graphics-0.9.so.0
Title: unity_support_test crashed with SIGSEGV in nux::IOpenGLAsmVertexShader::IOpenGLAsmVertexShader()
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare
XsessionErrors:
(nm-applet:3138): Gdk-CRITICAL **: IA__gdk_window_thaw_toplevel_updates_libgtk_only: assertion `private->update_and_descendants_freeze_count > 0' failed
(nautilus:3115): GConf-CRITICAL **: gconf_value_free: assertion `value != NULL' failed
I tested the CD in the same drive; without cleaning or even removing it. I tested it with the live CD boot option that tests the CD. It passed. I had to use the nomce kernel command line option to get even the simple test to boot. I recall though that I do NOT have to use "nomce" for the memory test option on the live CD.
Maverick continues the tradition of logging an MCE in dmesg at 300 seconds:
[ 300.040038] Machine check events logged