Dell OptiPlex 9010 UEFI Problem?
If you ready my previous post, you already know that I’ve had frustrating issues with lock-ups in Ubuntu 12.04 on my new Dell OptiPlex 9010, and perhaps related oddities with errors reported in memtest86+. I opened a support ticket with Dell, and they shipped me a replacement system, which arrived today. The spoiler: it didn’t fix my problems. However, in the course of determining that fact, I may have further isolated the issue.
My memtest86+ runs were all turning up clean to start out, and I was getting uncharacteristically optimistic. I ran a couple times with the included RAM, then tweaked various BIOS settings, and had another clean run. I installed my 16 GiB of Crucial RAM, and ran a few more memtest86+ passes (from cold boot, with Ethernet connected) that turned up clean. Finally, I swapped the hard drive and SSD from the original system into the new machine, and was going to boot into the OS.
Upon my first boot, though, I realized I needed to enable UEFI in the BIOS in order to boot into Ubuntu, since that’s how I’d installed. That came with the [un]fortunate realization that another variable had just simultaneously changed in my grand experiment, but I was off to run memtest86+ again. I was crushed to see the same errors appear upon that first run that had plagued my first system (~245 MiB). That did, at least, give me a grand idea for an additional experiment, though: I switched the BIOS back to the Legacy
setting (from UEFI), and re-ran memtest86+. Lo and behold, the errors went away. I ran it again from a cold boot to be sure, and the errors were still gone. I switched back to UEFI, and the errors came back.
I don’t really understand all this, but I thought that UEFI being enabled in the BIOS shouldn’t really matter for memtest86+, since it’s not UEFI-enabled/aware, as far as I know. In my mind, anyhow, this really points at a Dell BIOS/UEFI bug. What do you think the chances are that they’ll acknowledge that and actually be able to fix it?
Anyway…
Since that fix could take quite a while (maybe arrive approximately…never?), I still want to try to move forward. Armed with this new finding/hypothesis, my current plan is to leave the system in Legacy
boot mode, replace my EFI partition with a bios_grub partition, replace grub-efi with grub-pc, and see if the system is more stable like that.
Any other thoughts?
Tags: Dell OptiPlex 9010, error, linux, ubuntu
Are you working with the Optiplex 9010 All in One?
I just found your site via google. I’m also experiencing random system freezes (like the one you described) on my brand new Dell Inspiron One 23″ All-in-One Desktop running Ubuntu 12.04 64-bit. I was considering returning mine and getting the Optiplex 9010 All in One (simply because it is certified for Ubuntu), but now I’m having second thoughts. I’m still fooling around with mine, trying to get it working with Ubuntu 12.04 64-bit.
Almost everything works perfectly out of the box, except for the freezes. Will start toying with UEFI after I get some sleep.
Keep us posted, will check back.
I have the small-form-factor 9010, not the all-in-one, though I suspect they probably all use the same BIOS/UEFI. I’ll write up more details later, but my attempt this weekend to fix everything by switching from UEFI to Legacy BIOS didn’t seem to fix the lock-ups. I have since then installed the 3.4 kernel linked in the first post’s comments, and haven’t had a lock-up in the ensuing ~15 hours, but haven’t explicitly tried to reproduce the lock-up either (since I was actually trying to get some work done, imagine that).
Updated kernel to 3.4 and things look a lot smoother. Apparently, many people are getting the same system lockup with Ubuntu 12.04. It’s something in the Ivy Bridge code. A fix should be rolled out by the end of July (2012).
Have been testing the all-in-one 9010 using Scientific Linux 6.2. Build appeared to work fine but all-in-one display blanked. Using nomodeset as a kernel boot option helped a bit… but then the screen blanks again on GUI logout. The Scientific Linux 6.3 liveCD did not give a noticeably better result. SL 6.2 Kernel in use is 2.6.32-220.23.1.el6.x86_64 and X is xorg-x11-server-Xorg-1.10.6-1.sl6.x86_64.
I’d be interested to know whether there’s been a fix for this yet?
I am also interested in a fix. I have tried everything and the best result is an inconsistent log in screen.