[SOLVED] Video (mplayer?) crashes the OS, PC loops forever with garbage on screen, even REISUB fails. Help with error logs, please
Linux - DesktopThis forum is for the discussion of all Linux Software used in a desktop context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Video (mplayer?) crashes the OS, PC loops forever with garbage on screen, even REISUB fails. Help with error logs, please
tl;dr version: Some tips on keywords for finding video/xorg related errors related with a complete crash that leaves the PC looping with something that looks like an ASCII kaleidoscope, full screen, unresponsive. Seems CPU-heavy. This kind of situation/symptom even has a technical name? Not even "REISUB" resets it, it requires to actually shut the power. Scary. BTW, can we set-up xorg.log so that it has time and date in the beginning of every line, like kernel.log? Thanks.
Hopefully a not-that-long version that may add something relevant if anyone is interested:
It does not happen that regularly that I'm expecting to fix it within the week or month, if it's even something I could fix myself, for now I'm just asking for clues for sorts of things I should look at different logs.
I'm not sure it "really" looks like ASCII kaleidoscope, it's just the faint impression I have while I'm freaking out trying to change to a different TTY, REISUB, power off -- actually not even the ACPI button thing works, it has to be really a bare-cable shut down.
It only happened a few times when I've left the PC playing videos unattended, came back, and it was in this scary situation. So it's hard to pinpoint some sort of video format or whatever. Definitely nothing in high resolution or anything. The closest thing I have to a culprit suspect is "mplayer".
At kernel.log it seems that nothing happened. With Xorg.0.log it's more complicated as it lacks that convenience of a time/date "line header", having instead that "nonsensical" number. The most "obvious" thing, "errors" and "warnings" ("(EE)", "(WW)") show only on unrelated things, tablet configurations, missing font directories, things that happen all the time and are essentially ignored.
For while the closest thing to a "solution" would be that I'll use just mpv instead and hope it doesn't happen, but I'd like to investigate a little bit further when I have time, specially if it still happens regardless of the player. Hence, asking for keywords and related terminology. Thanks.
You're apparently worked up about something. You seem anxious to preserve your crash, because most people who want to fix things give logs, output, details of the system, a link to the offending video(s), video details, kernel version, etc. How do we reproduce your error?
On a side note, crashes of the nature you describe sometimes involve a hardware element: a memory error; disk dodginess; cpu overheating; even doubtful logic levels (although that's not straightforward to track down).
If REISUB doesn't work, that means it's been disabled (which is the sort of thing Debian tends to do, like disabling the firewall): it should always work. Just for fun, try it on your computer when it's actually working normally.
If it's not regular, the problem probably isn't a program. Try launching the suspects, like mplayer, from the terminal. If there's anything hinky, there'll be a message left when you shut them down. Minor warnings are common, but things like "CRITICAL", "may cause a crash", or "this should not happen" obviously need to be taken seriously.
After the crash, use the log-file viewer to see the latest messages file in /var/log and look for anything relevant.
Test your memory. Grub should give you that option, or you can use most live Linux disks (SystemRescueCD certainly, and that's worth having anyway), or you can install and run something like memtester.
If all else fails, then there's probably a graphics chip/card problem. I don't know any reliable way of testing that with software: that would be one for the computer repair shop.
You're apparently worked up about something. You seem anxious to preserve your crash, because most people who want to fix things give logs, output, details of the system, a link to the offending video(s), video details, kernel version, etc. How do we reproduce your error?
I just thought that a massive log-dumping would just waste everyone's time, specially because I don't quite know from which part to start, in some logs. The same for the other details, it would be a massive data-dump that probably wouldn't help that much, or, would require quite a long time to analyze, which I think it's a bit too much to ask. Specially because it may even be something that would solve "by itself" with further upgrades, then it would sort of be looking for something that isn't even there.
The videos are mostly downloaded from youtube, a few of them reencoded with x264 and/or lame/aac to make the files smaller (with avidemux or handbrake, mostly). I'll eventually try to reproduce the thing by playing those while I'm still next to the PC to see it happening.
Quote:
On a side note, crashes of the nature you describe sometimes involve a hardware element: a memory error; disk dodginess; cpu overheating; even doubtful logic levels (although that's not straightforward to track down).
I didn't think of that. I think it even may even expand the possible sources of error, it never occurred to me that perhaps there was something heavy scheduled for cron at the same time, that, for whatever reason, I don't usually run or, won't always lead to this sort of crash.
If REISUB doesn't work, that means it's been disabled (which is the sort of thing Debian tends to do, like disabling the firewall): it should always work. Just for fun, try it on your computer when it's actually working normally.
It does work on normal circumstances, I do it more "regularly" than ideally when I don't pay attention to the number of tabs I have opened, eventually crossing the threshold of irrecoverable sluggishness.
I find kind of unlikely that there's something that is disabling it on purpose on these instances, or this particular last instance, which is the one I'm sure REISUB didn't work. I think it was a result of the system having gone completely awry and no longer in control.
Quote:
If it's not regular, the problem probably isn't a program. Try launching the suspects, like mplayer, from the terminal. If there's anything hinky, there'll be a message left when you shut them down. Minor warnings are common, but things like "CRITICAL", "may cause a crash", or "this should not happen" obviously need to be taken seriously.
After the crash, use the log-file viewer to see the latest messages file in /var/log and look for anything relevant.
Test your memory. Grub should give you that option, or you can use most live Linux disks (SystemRescueCD certainly, and that's worth having anyway), or you can install and run something like memtester.
If all else fails, then there's probably a graphics chip/card problem. I don't know any reliable way of testing that with software: that would be one for the computer repair shop.
Thanks. "CRITICAL" and "this should not happen", I'll remember that. It's still not "kaleidoscope-like awful crash", but already gives me something to work with.
If REISUB is enabled and your crash prevents it working, that sounds more like a hardware problem to me: "raising elephants" is supposed to stop any software that runs amuck.
Looks like a video driver issue (Linux does not habitually crash from high cpu workloads, it just becomes slower). Usually video driver. Since opengl is involved, it might be caused by opengl libs (but a system crash should not happen so the effective bug is in the kernel driver itself). Also if happens in one program, it would probably in other circumstances.
-Check memory for defects. Although if you only have issues with these workloads, i am sceptical about this but you never know.
Provide info (besides debian version and if you use backported software if you use stable):
1. What video card and drivers do you use? Kernel version, libdrm, opengl implementation version (mesa for open source or nvidia/ati driver version for proprietary), xorg.conf (or other xorg-related) tweaks. Also do you use any hardware decoding methods (vo=gl eliminates vdpau, but intel has a vo-independent decoder) - note that hardware decoding is only used if explicitly enabled.
2. What xorg version do you use?
3. what DE you use (and what, if any compositing method)?
4. Logs: dmesg and /var/log/Xorg.0.log would help too (but wrapped into [code] tags as they tend to be long)
5. kernel boot switches if any.
6. Since when this issue appeared? Is it related to some event like an update of some component like kernel mesa/video drivers/xorg? This might not seem important, but it does happen that some part of the driver chain is upgraded (especially in distros like debian testing/sid), other components are not and you might have issues.
BTW mplayer AFAIK is not really maintained anymore, it is effectively replaced by mpv (which works even in smplayer as a backend). But this does not mean that the kernel driver is off the hook.
Issues affecting X server, including its input and video drivers might give an illusion of a locked/crashed machine as it is not responding to input. So to eliminate them as a potential cause, I would approach it like this:
- I would connect another machine via SSH.
- I would play s/mplayer via terminal. Better still if you can invoke that under tmux/screen session so you can reattach the session on the other machine.
- If the machine "crashes", you can tell as you have an active SSH session.
- Now I can tell if the machine is still responsive
- You can then reattach the the tmux session once the correct $DISPLAY has been set.
- check the logs, dmesg etc.
Trying to "grep -i" those alarming phrases on all logs didn't give any result, which I think further suggests a hardware issue, even though perhaps triggered by an opengl driver bug or something.
Quote:
Originally Posted by DavidMcCann
If REISUB is enabled and your crash prevents it working, that sounds more like a hardware problem to me: "raising elephants" is supposed to stop any software that runs amuck.
I've indeed found someone asking about a problem with a similar description (screen corruption), including REISUB not working, and it seems that the problem was hardware, memory specifically, for him at least. I've run memtest+ and it didn't report any problem, though. But perhaps the slots need cleaning or something.
As shown in this video, my computer has been crashing lately. Despite appearances to the contrary, it's unresponsive. It doesn't respond to keystrokes--including the Magic SysRq sequences, assuming I've converted them properly to my keyboard configuration. Sometimes it appears that the mouse will move, but I can't login via SSH. I'm left to reboot by cycling the power, as I can't find any other way out.
The difference is that, at least at the point I saw it, there was no longer a visible mouse arrow.
Quote:
Originally Posted by c0wb0y
Issues affecting X server, including its input and video drivers might give an illusion of a locked/crashed machine as it is not responding to input. So to eliminate them as a potential cause, I would approach it like this:
- I would connect another machine via SSH.
- I would play s/mplayer via terminal. Better still if you can invoke that under tmux/screen session so you can reattach the session on the other machine.
- If the machine "crashes", you can tell as you have an active SSH session.
- Now I can tell if the machine is still responsive
- You can then reattach the the tmux session once the correct $DISPLAY has been set.
- check the logs, dmesg etc.
That's a very ingenious way of figuring the whole thing out, but unfortunately it's not something I can reproduce "on demand", at the same time I don't have another available PC to use all the time, just in case, but I'll try to remember that idea if I eventually face something more reproducible!
I'll post most of the info you're asking just in case someone else is having a similar problem, hopefully it could help them, but I'm sort of half-way giving up, since it's so sporadic and rare.
Quote:
Looks like a video driver issue (Linux does not habitually crash from high cpu workloads, it just becomes slower). Usually video driver. Since opengl is involved, it might be caused by opengl libs (but a system crash should not happen so the effective bug is in the kernel driver itself). Also if happens in one program, it would probably in other circumstances.
-Check memory for defects. Although if you only have issues with these workloads, i am sceptical about this but you never know.
Memtest+ gave me some relief in this regard, even though I'm not excluding some intermittent poor contact due to dust, old slots, or something.
Quote:
Provide info (besides debian version and if you use backported software if you use stable):
1. What video card and drivers do you use? Kernel version, libdrm, opengl implementation version (mesa for open source or nvidia/ati driver version for proprietary), xorg.conf (or other xorg-related) tweaks. Also do you use any hardware decoding methods (vo=gl eliminates vdpau, but intel has a vo-independent decoder) - note that hardware decoding is only used if explicitly enabled.
2. What xorg version do you use?
4.8.0-1-amd64 #1 SMP Debian 4.8.5-1 (2016-10-28) x86_64 GNU/Linux - but it almost certainly occurred in previou(s) version(s), and maybe not even in this most recent one, I unfortunately don't keep track of when exactly I've upgraded. The same applies for any other possibly related package.
Code:
ii libopengl0-glvnd-nvidia:amd64 367.57-2 amd64 Vendor neutral GL dispatch library -- libOpenGL
ii libopengl0-glvnd-nvidia:i386 367.57-2 i386 Vendor neutral GL dispatch library -- libOpenGL
ii libqt4-opengl:amd64 4:4.8.7+dfsg-11 amd64 Qt 4 OpenGL module
ii libqt5opengl5:amd64 5.7.1~20161021+dfsg-6 amd64 Qt 5 OpenGL module
ii python-opengl 3.1.0+dfsg-1 all Python bindings to OpenGL (Python 2)
ii python-pyside.qtopengl 1.2.2-2+b1 amd64 Qt 4 OpenGL module - Python bindings
ii mplayer 2:1.3.0-4 amd64 movie player for Unix-like systems
ii libdrm-amdgpu1:amd64 2.4.73-1 amd64 Userspace interface to amdgpu-specific kernel DRM services -- runtime
ii libdrm-amdgpu1:i386 2.4.73-1 i386 Userspace interface to amdgpu-specific kernel DRM services -- runtime
ii libdrm-dev:amd64 2.4.73-1 amd64 Userspace interface to kernel DRM services -- development files
ii libdrm-intel1:amd64 2.4.73-1 amd64 Userspace interface to intel-specific kernel DRM services -- runtime
ii libdrm-intel1:i386 2.4.73-1 i386 Userspace interface to intel-specific kernel DRM services -- runtime
ii libdrm-nouveau2:amd64 2.4.73-1 amd64 Userspace interface to nouveau-specific kernel DRM services -- runtime
ii libdrm-nouveau2:i386 2.4.73-1 i386 Userspace interface to nouveau-specific kernel DRM services -- runtime
ii libdrm-radeon1:amd64 2.4.73-1 amd64 Userspace interface to radeon-specific kernel DRM services -- runtime
ii libdrm-radeon1:i386 2.4.73-1 i386 Userspace interface to radeon-specific kernel DRM services -- runtime
ii libdrm2:amd64 2.4.73-1 amd64 Userspace interface to kernel DRM services -- runtime
ii libdrm2:i386 2.4.73-1 i386 Userspace interface to kernel DRM services -- runtime
ii libgles1-mesa:amd64 12.0.4-2 amd64 free implementation of the OpenGL|ES 1.x API -- runtime
ii libgles2-mesa:amd64 12.0.4-2 amd64 free implementation of the OpenGL|ES 2.x API -- runtime
ii libgl1-mesa-glx:amd64 12.0.4-2 amd64 free implementation of the OpenGL API -- GLX runtime
ii libgl1-mesa-glx:i386 12.0.4-2 i386 free implementation of the OpenGL API -- GLX runtime
ii libva-glx1:amd64 1.7.3-2 amd64 Video Acceleration (VA) API for Linux -- GLX runtime
ii libxcb-glx0:amd64 1.12-1 amd64 X C Binding, glx extension
ii libxcb-glx0:i386 1.12-1 i386 X C Binding, glx extension
ii libxcb-glx0-dev:amd64 1.12-1 amd64 X C Binding, glx extension, development files
ii libvdpau-va-gl1:amd64 0.4.2-1 amd64 VDPAU driver with OpenGL/VAAPI backend
ii libvdpau1:amd64 1.1.1-5 amd64 Video Decode and Presentation API for Unix (libraries)
ii libvdpau1:i386 1.1.1-5 i386 Video Decode and Presentation API for Unix (libraries)
ii libv4lconvert0:amd64 1.10.1-1 amd64 Video4linux frame format conversion library
ii libv4lconvert0:i386 1.10.1-1 i386 Video4linux frame format conversion library
ii libva-drm1:amd64 1.7.3-2 amd64 Video Acceleration (VA) API for Linux -- DRM runtime
ii libva-drm1:i386 1.7.3-2 i386 Video Acceleration (VA) API for Linux -- DRM runtime
ii libva-egl1:amd64 1.7.3-2 amd64 Video Acceleration (VA) API for Linux -- EGL runtime
ii libva-glx1:amd64 1.7.3-2 amd64 Video Acceleration (VA) API for Linux -- GLX runtime
ii libva-tpi1:amd64 1.7.3-2 amd64 Video Acceleration (VA) API for Linux -- TPI runtime
ii libva-wayland1:amd64 1.7.3-2 amd64 Video Acceleration (VA) API for Linux -- Wayland runtime
ii libva-x11-1:amd64 1.7.3-2 amd64 Video Acceleration (VA) API for Linux -- X11 runtime
ii libva-x11-1:i386 1.7.3-2 i386 Video Acceleration (VA) API for Linux -- X11 runtime
ii libva1:amd64 1.7.3-2 amd64 Video Acceleration (VA) API for Linux -- runtime
ii libva1:i386 1.7.3-2 i386 Video Acceleration (VA) API for Linux -- runtime
ii xorg 1:7.7+16 amd64 X.Org X Window System
ii xserver-xorg 1:7.7+16 amd64 X.Org X server
ii xserver-xorg-core 2:1.18.4-2 amd64 Xorg X server - core server
ii xserver-xorg-video-fbdev 1:0.4.4-1+b4 amd64 X.Org X server -- fbdev display driver
ii xserver-xorg-video-intel 2:2.99.917+git20161105-1 amd64 X.Org X server -- Intel i8xx, i9xx display driver
ii xserver-xorg-video-mach64 6.9.5-1+b1 amd64 X.Org X server -- ATI Mach64 display driver
ii xserver-xorg-video-mga 1:1.6.4-2 amd64 X.Org X server -- MGA display driver
ii xserver-xorg-video-neomagic 1:1.2.9-1+b1 amd64 X.Org X server -- Neomagic display driver
ii xserver-xorg-video-openchrome 1:0.3.3+git20160310-1 amd64 X.Org X server -- VIA display driver
ii xserver-xorg-video-r128 6.10.1-2 amd64 X.Org X server -- ATI r128 display driver
ii xserver-xorg-video-savage 1:2.3.8-2 amd64 X.Org X server -- Savage display driver
ii xserver-xorg-video-sisusb 1:0.9.6-2+b4 amd64 X.Org X server -- SiS USB display driver
ii xserver-xorg-video-tdfx 1:1.4.6-2 amd64 X.Org X server -- tdfx display driver
ii xserver-xorg-video-trident 1:1.3.7-2 amd64 X.Org X server -- Trident display driver
ii xserver-xorg-video-vesa 1:2.3.4-1+b1 amd64 X.Org X server -- VESA display driver
ii xserver-xorg-video-vmware 1:13.2.1-1 amd64 X.Org X server -- VMware display driver
(nvidia and non-intel or non-generic packages are either some weird dependency of some softwares like abiword, or just part of meta-packages installed by default, that I haven't uninstalled yet)
Xorg.conf:
(where I believe "sna" is not the default "accelmethod", so it's another possible source of trouble, even though I've been using it for years with no trouble "besides that" -- I actually said that "sna solved some issues" with video back in 2013, result, in my blog here. Same hardware, except for just half of the memory I have now (4GB), with an added module). Back ten I didn't have this "tiling" set to "true" though. Even though there are options commented out, I haven't being playing with those options during the time the crashes happened, xorg.conf was pretty much like that all the time. I don't know why I have those options that I think are defaults (glx, dri) explicitly activated...
3. what DE you use (and what, if any compositing method)?
Plain Openbox, but lately I've been using xcompmgmr, I'm glad someone pointed this aspect of compositing, as now I sort of remember it I had the impression it gave me some sort of issue before, perhaps even with video itself, even though nothing that extreme. But maybe it was something else entirely, like messing up with windows' focus, like not being able to click in certain windows as I'd expect.
Code:
ii libxcomposite-dev 1:0.4.4-1 amd64 X11 Composite extension library (development headers)
ii libxcomposite1:amd64 1:0.4.4-1 amd64 X11 Composite extension library
ii libxcomposite1:i386 1:0.4.4-1 i386 X11 Composite extension library
ii xcompmgr 1.1.7-1 amd64 X composition manager
Quote:
4. Logs: dmesg and /var/log/Xorg.0.log would help too (but wrapped into [code] tags as they tend to be long)
That makes me kind of guilty of wasting space on the internets, specially as I don't know which log file or interval are the ones when the crash ocurred. Dmesg I think can be ruled out entirely, doesn't it, as it didn't happen "right now"? The latest Xorg.0.log seems clean, only mentining mundane configuration errors and minor things. I'll post it on some of those plain text hosts as it blows the forum's character limit.
Xorg.1.log, in the other hand, has some "interesting" errors, which I can't really tell if is related with the crash or something else I might have been doing at that time. I'd guess it's the crash, or "a" crash or something though, as I don't remember having been playing with xorg last month. I had changed the DM, though, which perhaps might have resulted in some temporary misconfiguration that I later solved.
Code:
Xorg.1.log:[ 49530.472] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied
Xorg.1.log:[ 49532.592] (EE) intel(0): [drm] failed to set drm interface version: Permission denied [13].
Xorg.1.log:[ 49532.592] (EE) intel(0): Failed to claim DRM device.
Xorg.1.log:[ 49532.592] (EE) Screen(s) found, but none have a usable configuration.
Xorg.1.log:[ 49532.592] (EE)
Xorg.1.log:[ 49532.592] (EE) no screens found(EE)
Xorg.1.log:[ 49532.592] (EE)
Xorg.1.log:[ 49532.592] (EE) Please also check the log file at "/var/log/Xorg.1.log" for additional information.
Xorg.1.log:[ 49532.592] (EE)
Xorg.1.log:[ 49532.600] (EE) Server terminated with error (1). Closing log file.
Xorg.1.log.old:[ 49530.423] (EE) intel(0): [drm] failed to set drm interface version: Permission denied [13].
Xorg.1.log.old:[ 49530.423] (EE) intel(0): Failed to claim DRM device.
Xorg.1.log.old:[ 49530.423] (EE) Screen(s) found, but none have a usable configuration.
Xorg.1.log.old:[ 49530.423] (EE)
Xorg.1.log.old:[ 49530.423] (EE) no screens found(EE)
Xorg.1.log.old:[ 49530.423] (EE)
Xorg.1.log.old:[ 49530.423] (EE) Please also check the log file at "/var/log/Xorg.1.log" for additional information.
Xorg.1.log.old:[ 49530.423] (EE)
Xorg.1.log.old:[ 49530.443] (EE) Server terminated with error (1). Closing log file.
Xorg.2.log:[ 29238.241] (EE) systemd-logind: failed to get session: PID 18057 does not belong to any known session
Xorg.2.log:[ 29238.242] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied
Xorg.2.log:[ 29238.499] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied
If "memory" is a possible origin candidate, I guess that then even zswap may be the real culprit here. "Funny" how my initial evaluation was perhaps excessively narrow on possibilities.
6. Since when this issue appeared? Is it related to some event like an update of some component like kernel mesa/video drivers/xorg? This might not seem important, but it does happen that some part of the driver chain is upgraded (especially in distros like debian testing/sid), other components are not and you might have issues.
Hard to tell, as it's not something that have happened consistently, but not more than four times, maybe just two or three. I guess it all happened more or less spread throughout the past year, but perhaps more "precisely" the last semester. That's why I think it's probably very unlikely that I'll be able to "fix" it, unless it starts to happen more consistently by itself, in which case it would possibly help to narrow down the cause, as I try to make everything as "default" as possible, even though I guess the odds would be that the hardware is deteriorating. I guess I could try to run a few other "mplayer stress tests", though, see if I can repeat it, but I'm afraid it will be a long waste of time.
I can't believe just now it occurred to me that in the past few months I've been using almost exclusively not this current Debian install, but Ubuntu! I wish I could recall if it happened also with Ubuntu. The last instance was definitely with Debian, though. That scores one more point in favor of the odds for hardware issues, even though it could have really been just with Debian. The funny thing is, as both distros are "related", having happened in both wouldn't still rule out a software trigger though.
Quote:
BTW mplayer AFAIK is not really maintained anymore, it is effectively replaced by mpv (which works even in smplayer as a backend). But this does not mean that the kernel driver is off the hook.
Yeah, I mostly use mpv now, I recall I've tried mplayer as mpv was also having a different issue with some of these videos, like not starting the next one the playlist, and/or having just sound for some reason. Also, kind of skipping some "random" parts of the video, jumping forward intermittently. Not in general, but only with some videos I've reencoded, but seemed to play just fine until about the last two versions of mpv.
So... that's it. I'm "giving up" for now, unless that which I posted now somehow provides someone with an obvious answer, "just comment out the hideous-crash=true on xorg.bugs.conf". But hopefully it can give clues just in case someone has something similar. I think I won't mark as "solved" to not falsely raise hopes for those poor souls, though.
Unfortunately you seem to have an old intel chip. They don't seem to be very stable with newer kernels (if they ever were). I saw linux on x3100 and x4500 series chips and it was not working very well (i mean the driver crashed here and there). These chips gave "integrated graphics" a bad name...
What you can do is try to not use compositing at all.
PS/OT:
Newer series i currently use(d) linux on (2000/3000/4600 and even 530) are much better. But i have to say AMD OSS drivers are better than intel (at least for the r600g IGP generations) both stability and desktop experience-wise (yeah, better gaming too, at least on Linux).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
