Recently in Xorg and kernel mode setting issues for Intel video (especially i830m) Category

Update: I checked in my dmesg, and somewhere in the boot process Ubuntu Lucid is automatically turning off kernel mode setting for my Intel 830m-running (82830 CGC) laptop (emphasis mine):

steven@toshiba-ubuntu:~$ dmesg | grep drm
[ 0.000000] Linux version 2.6.32-22-generic (buildd@rothera) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #33-Ubuntu SMP Wed Apr 28 13:27:30 UTC 2010 (Ubuntu 2.6.32-22.33-generic 2.6.32.11+drm33.2)
[ 2.112751] [drm] Initialized drm 1.1.0 20060810
[ 2.182073] [drm] i915 disabling kernel modesetting for known bad device.
[ 2.192838] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
steven@toshiba-ubuntu:~$

I've been turning off KMS in all Linux distributions for quite some time (OK, maybe the past three months). But recently I've experimented with removing i915.modeset=0 manually from Grub in Ubuntu Lucid, and everything is working as well as before.

Today I edited my Grub configuration (still using the Ubuntu Grub2 community page as a reference) and removed the line turning off KMS entirely.

Looking at the dmesg above, kernel mode setting hasn't been "fixed" for older Intel video, but at least the kernel knows not to turn it on when you're running an i915-type chipset (of which i810 is seemingly a subset).

This is how things should have been handled from the beginning. Better late than never — this remains huge for Linux — and for Ubuntu. Why? Because the potential new user with affected Intel chipsets can now grab a live CD, start up Ubuntu and actually have it work. They won't be stopped and immediately turned off by a totally black screen.

As a user with a little experience, I know about turning off KMS, but if I was coming to Linux with no experience whatsoever, I'd think Ubuntu and/or Linux was a big load of crap (what, the SCREEN doesn't WORK? ... you've got to be KIDDING ME).

This change isn't a technological breakthrough, but it's a huge step forward for Linux (and Ubuntu) uptake among potential users, and I thank whoever is responsible for bringing sanity back to Linux and Xorg.

In addition to his first e-mail to me, David Gurvich adds more about his experiences with Intel i830m video in Linux and PC-BSD/FreeBSD:

I did think the problems with FreeBSD were due to using PC-BSD and installing a lightweight desktop on top. After testing with a bare install that turns out to not be the case and the issue is with FreeBSD and has nothing to do with the scripts that PC-BSD uses.

I have not tested OpenBSD but most of the wireless drivers on FreeBSD have been ported from there. I suspect there is a difference between the two that causes these drivers to crash the system on FreeBSD. The primary reason that I was interested in FreeBSD was ZFS support and wanted to setup a file server. The network issue stopped that in it's tracks.

There is a graphical network tool in the FreeBSD ports that seems to work ok but most of my settings were with wpa_supplicant and rc.conf. I believe that PC-BSD has it's own graphical network configuration tool but didn't use that.

Flash does have issues on FreeBSD and I don't recommend installing the linux compatibility to use flash. Instead, use wine with a windows browser. There is a memory leak in the linux flashplugin on FreeBSD that will eventually cause your system to freeze until you kill nspluginwrapper. The same technique may work on OpenBSD.

I have tried Fedora 12 on this laptop and that worked somewhat after tweaking a number of parameters. By somewhat I mean that I had random Xorg crashes and the tweaks simply mitigated the frequency. I gave F12 about 2 months but just could not take the crashes. Fedora 12 is working well on the other systems that I've installed it on but there was a problem with one that had ATI video which required building an xorg module from git.

I am currently using Arch linux on the X30 and, since configuring the boot parameters with 'nomodeset' and locking the xf86-video-intel driver to 2.9.1, have not had any issues with video. The main problem has been with the networking scripts and I am still not sure what the issue is there but installing wicd-1.7 seems to have worked around that. I am impressed with the speed vs Fedora 12. The reason I am impressed is that, prior to Arch, Fedora 12 had been among the fastest distributions on the X30 with a useable firefox in under 2 minutes. The X30 from startup to a working firefox connection takes 45 seconds in Arch.

The main issue I will have with Arch is likely the very reason Arch is so responsive. Rolling releases don't keep old packages around and new versions can cause random failures on working systems. That means that I will need to maintain a list of packages that should not be upraded and be careful on upgrades. Nothing new to anyone who has used Gentoo.

I've currently had Arch installed on the X30 for a month and have had no issues to deal with since the video and networking were fixed. The livecd boots to a text console and I recommend looking at the arch installation guide. Pretty much everything needs to be configured but the wiki makes that simple.

David Gurvich

David, you hit on a number of important points. I will definitely try Fedora 12 to see how it works with i830m, and I agree with you that Arch is an excellent choice. I've written many times about how the Arch community has been a great resource for me in solving my X issues with i830m all the way from Debian Lenny through now.

I neglected to mention ZFS in FreeBSD. That certainly is something to recommend in its favor. There's also a project bringing journaling to soft updates in FreeBSD's UFS filesystem that I heard about in this BSD Talk episode.

I'm not terribly happy about Flash being so problematic in FreeBSD. I forget all the trouble I had with the Opera browser in OpenBSD. That browser and its Flash plugin uses OpenBSD's Linux compatibility layer, and I was eventually able to stop most crashes by changing a parameter in Opera.

Here's what I'm hoping for:

• People smarter than me will figure this out and either make allowances in the kernel and xorg, or will create some other kind of mechanism that doesn't leave users of Intel 830m video chips out in the cold
• HTML 5 will sooner than later take hold with an open video codec and return Flash to what it's good at, which is little applications that I can safely ignore, and stop doing what it's bad at, which is delivering video that can better be handled by a plethora of other formats. The easiest way for this to happen would be for Google to open-source the on2 video codec it recently acquired. (Except that Google already converted the entire YouTube library to the loved-by-Apple patent-encumbered H.264.)

  I've run BSD before, and if Linux/Xorg throws Intel 830m under the bus, I'll be an enthusiastic user of any system that doesn't follow along.

Reader David Gurvich writes the following:

Hello,

I also have a system that uses the i830m chipset for graphics, the Thinkpad X30. All of the problems are related to kernel mode setting, particularly your current one. The new xorg video driver eliminates all user mode setting and is useless on systems that use i830. I've never gotten kernel mode setting to work with i830 systems and now that is the only option on new installs.

The only solution has been to install the 2.9.1 driver. That works for now but I am worried about future releases of Xorg that will not work with this driver. I suspect that I will need to maintain my own branch of Xorg. That will probably require a personal repository that includes older kernels, hal, and dbus along with any associated libraries.

My hope is that FreeBSD will have improved enough in user latency and other areas that I will be able to use that when the time comes. I have tried PC-BSD but the default install is too slow for daily use. I thought the problem might have been KDE4 but the issue persisted with a lightweight desktop environment. There are also some issues with hardware that don't exist on Linux. The one that springs to mind is my system locking up completely when the wireless card can't find a network on boot.

Thank you,

David Gurvich

Yeah, I'm not the only person hacked off about this. Here's what I wrote to David (knowing also that I'd run here as well):

Starting with Ubuntu Karmic and up through Lucid Alpha 2, and including Debian Sid (via Sidux 2009-04) at the end of 2009, I've been able to turn off kernel mode setting and get X to work.

So it was extremely disturbing to find that turning off kernel mode setting in Lucid Alpha 3 didn't work. Very disturbing.

I spent 6 months running OpenBSD 4.4 as my primary OS on this i830m laptop, and I didn't have any performance issues running both the stock Fvwm2 window manager as well as Xfce. The whole thing blew up when I upgraded to OpenBSD 4.5, and yes it was Xorg-related, but I've since tested OpenBSd 4.6 via the BSDanywhere and Jggimi live CDs, and Xorg is working again (can't remember if I needed an xorg.conf, but it must've either been easy to roll it together, or I'd have remembered.

The problems for me with OpenBSD are a) Flash 7 only (and only in Opera) b) too difficult to upgrade (which might be overcome if I can figure it out) c) hard to install Java (although I've done it and probably have the binary package I created in the process squirreled away on this hard drive) and d) no journaling filesystem, and on this creaky old hardware I lose power enough that all the fsck-ing I need to do in OpenBSD's FFS is relatively painful.

Not that I won't return to OpenBSD ...

FreeBSD is supposed to be much, much faster in every respect. There was a Phoronix test recently in which FreeBSD didn't blow Linux out of the proverbial water but did do OK. And it has at least Flash 9, precompiled Java packages, a much longer support cycle than OpenBSD, Ubuntu or Fedora.

If you tried PC-BSD but used, say, Fluxbox instead of KDE, I imagine the system would be much slower than if you installed vanilla FreeBSD and added the desktop environment and applications yourself. At least that's the theory anyway.

I don't know how FreeBSD uses memory, but I can tell you for sure that Linux and OpenBSD use it much differently. Linux seems to want to grab as much memory as possible and reserve it for whatever uses it thinks it's going to have. I don't know how this affects system performance - it could improve it, or it could hurt it. I'm really not sure.

But OpenBSD is very sparing on the memory it uses. I ran 768 MB for that six months in OpenBSD 4.4 and don't think I ever tapped the swap space even once. Now with 1 GB in both Ubuntu (Hardy, Karmic) and Debian (Lenny), the machine isn't relying heavily on swap but does use a little bit of it at least a little bit of the time. Again, I'm not sure which scenario is better for performance (or how FreeBSD factors into all of this), but it's at least a curiosity.

David, I don't know if you've tried Fedora 12 yet. I downloaded the image but haven't had a chance yet to burn it. Like you I'm looking for any bright spot in this whole mess. I don't know who to blame: the kernel team or Xorg (or the distros themselves). Intel i830m video can't be so obscure that nobody is suffering from this, and I can imagine hundreds or thousands of potential users being turned off when they can't get the live CD to boot to anything but a blank screen.

Before I forget to mention it, my experience with wireless on this platform with OpenBSD at least, is the opposite of what happened to you. Not only did wireless perform better with absolutely no crashes, I also was able to more easily configure my cheap NIC with a Ralink chipset in OpenBSD before I could get it working in Linux.

And crashes with wireless were precisely the reason I upgraded from Ubuntu Hardy to Karmic. I think a kernel update in Hardy eventually fixed the problem (I still have a Hardy i830m laptop running and can test this), and I wish I had stayed with it on the other i830m laptop. But networking in OpenBSD at least is a relative pleasure; networking and drivers are very important to the developers, so they get a lot of attention. However, you can't use the GUI tools like NetworkManager, I think, because of the vast differences in configuration between BSD and Linux (I could be wrong about this). Learning manual network configuration isn't the worst thing in the world.