Can't get out of VESA...

[internalkernel]

I have an:

ATI Technologies Inc M24 1P [Radeon Mobility X600]

currently on Jaunty. I tried installing the 9.6 drivers, and I know it's not supported - this laptop is a litle over 3 years old, I figured I didn't have to check if my card was supported. That was my first mistake... So, I got a memory allocation error upon module insertion.

So, I uninstalled it and this is where it started getting weird. The open source Radeon driver wouldn't load by default even when I would specify it... and then X would just hang before the log in screen. I could still SSH into the machine, and top showed Xorg eating 100% CPU. The machine itself (other than SSH) was completely unresponsive to anything.

I figured maybe there were some left over ATI modules/crap in there, checked my xorg.conf, did the dpkg --purge, etc. - couldn't figure it out. The load I had on the machine was old, and alot of other people had been using it... so, I decided it was time for a re-install anyways. But, the problem persisted even after a clean install of Jaunty; which has worked flawlessly in the past. In fact, the livecd exhibited the same issue unless I specified "Safe Graphics Mode". Which of course left me using the VESA module.

I then began trying some more solutions, updated X (to the latest experimental PPA), tried Tormold's Radeon driver... nothing helped. Then I tried to use the LiveCD of Intrepid as a test, which had a version of X that was compatible with the last supported release of Catalyst for my card. However, Intrepid had the same issues. So... to satisfy my own morbid curiosity at this point, I started playing with Hardy. The radeon driver would actually load on Hardy, X started and seemed to be okay... However, the screen was filled with garbage - blocks of pixels would flash red. But, at least it was working... So, I tried to install the Catalyst 9.3 (last supported release) in Hardy... and I got the same garbage filled pixelation on the screen.

I've checked through log files and it showed no errors in loading the radeon module, in fact everything looked exactly as it should... but this all leaves me at a total loss. I'm stuck with the VESA module right now... and I'm starting to think that I somehow fried the card. My only option is to consider a hardware issue - although, then I should have some issues using VESA as well.

I'm totally open to suggestions at this point, because I have no idea... I have some logs and my xorg - pretty standard stuff though...

Has anyone even heard of something like this happening?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
lspci -v
01:00.0 VGA compatible controller: ATI Technologies Inc M24 1P [Radeon Mobility X600]
Subsystem: Hewlett-Packard Company Device 3082
Flags: bus master, fast devsel, latency 0, IRQ 10
Memory at c0000000 (32-bit, prefetchable) [size=256M]
I/O ports at 4000 [size=256]
Memory at b0100000 (32-bit, non-prefetchable) [size=64K]
[virtual] Expansion ROM at b0120000 [disabled] [size=128K]
Capabilities: [50] Power Management version 2
Capabilities: [58] Express Endpoint, MSI 00
Capabilities: [80] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
Capabilities: [100] Advanced Error Reporting <?>
Kernel modules: radeonfb


~Thanks!

[bridgman]

You mentioned you started with Jaunty; which driver were you running with before installing Catalyst 9.6 and what functionality did you have ?

[Kano]

9-3 is the last driver thats possible to install. trying anything newer must fail.

[internalkernel]

You mentioned you started with Jaunty; which driver were you running with before installing Catalyst 9.6 and what functionality did you have ?

Jaunty was very good at detecting my hardware and installing the Open Source Radeon driver right out of the box. The Radeon driver was good enough for the most part, basic 3D functionality - nothing sexy. At the very least it gave me my native resolution (1440x900), right now I'm stuck at 1024x768.

Now, Jaunty still autodetects the card however when it loads the Radeon driver... the machine pretty much freezes. No keyboard response whatsoever, and if I SSH into it from another machine - Xorg is cooking my CPU.

9-3 is the last driver thats possible to install. trying anything newer must fail.

And fail it does... go figure a 3 year old laptop wouldn't be supported anymore. At one point I rolled BACK to Intrepid so that I could use 9.3, and I got the same results with Xorg eating my CPU.

~~~~~
I want to blame this on Xorg, however this has always worked before... This problem only came up after attempting (stupidly) to install 9.6.

Is it possible that the driver changed something on the physical card, some firmware or something? I'm grabbing at straws... I know.

Thanks for the help...

[bridgman]

Is it possible that the driver changed something on the physical card, some firmware or something? I'm grabbing at straws... I know.

The driver and installer update a lot of files but don't play with any nonvolatile memory on the card. Was your reinstall of Jaunty "complete" in the sense that the partitions were wiped and everything was reloaded from scratch, or is there a chance that something was left over from the previous install ?

[MartjeB]

Now, Jaunty still autodetects the card however when it loads the Radeon driver... the machine pretty much freezes. No keyboard response whatsoever, and if I SSH into it from another machine - Xorg is cooking my CPU.
Try radeonhd:
sudo apt-get install xserver-xorg-video-radeonhd
Driver "radeonhd"
It may be a bug in radeon.

[internalkernel]

The driver and installer update a lot of files but don't play with any nonvolatile memory on the card. Was your reinstall of Jaunty "complete" in the sense that the partitions were wiped and everything was reloaded from scratch, or is there a chance that something was left over from the previous install ?

/boot, and / are always wiped and formatted... /home is rarely. But, I get this consistent behavior through a LiveCD as well.

If it did have to do with my /home partition, I should still be able to get to the login screen - but Xorg locks up the machine as soon as GDM starts. I don't even get a chance to login.

What's worse is that (through SSH and top) I can see Xorg eating my CPU, killing it does nothing. The machine is still "usable" in the sense that anything I try to do takes forever of course... I can kill gdm, but Xorg turns into a zombie...

~~
Output from Top:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3223 root 20 0 591m 8040 4836 R 108 0.5 3:04.01 Xorg
3170 root 20 0 5180 1804 1592 S 48 0.1 1:21.11 hald-addon-stor
3643 root 20 0 2448 1184 912 R 44 0.1 0:15.47 top
1 root 20 0 3084 1888 564 S 0 0.1 0:01.23 init

[internalkernel]

Try radeonhd:
It may be a bug in radeon.

I went that direction for a bit as well... I usually install all ati/radeon drivers, and then specify ati in the xorg.conf - technically that's a driver wrapper and should load the correct module depending on my hardware. BUT... out of desperation, I manually put the driver in.

Here's a snippet from Xorg.0.log with radeonhd specified in xorg.conf:
(II) LoadModule: "radeonhd"
(II) Loading /usr/lib/xorg/modules/drivers//radeonhd_drv.so
dlopen: /usr/lib/xorg/modules/drivers//radeonhd_drv.so: file too short
(EE) Failed to load /usr/lib/xorg/modules/drivers//radeonhd_drv.so
(II) UnloadModule: "radeonhd"
(EE) Failed to load module "radeonhd" (loader failed, 7)
(EE) No drivers available.

I'm thinking I may bump up to the "xorg-edgers fresh X crack" ppa and see if I get any results from that...

[bridgman]

OK, let's start switching things off and try to see what function is causing the problem. Run "man radeon" and look through the output to find the xorg conf option to disable acceleration. Put that in your xorg.conf and start again.

Radeonhd won't work for your GPU btw; the radeonhd driver starts at 5xx and goes up from there, but the X600 is a 3xx part.

[legume]

Is it possible that the driver changed something on the physical card, some firmware or something? I'm grabbing at straws... I know.


Also grabbing at straws, but if you haven't already, try taking the battery out for a while.

[internalkernel]

OK, let's start switching things off and try to see what function is causing the problem. Run "man radeon" and look through the output to find the xorg conf option to disable acceleration. Put that in your xorg.conf and start again.

Started with dpkg -reconfigure -phigh xserver-xorg to get a clean xorg.conf... Then added:

Section "Device"
Identifier "Configured Video Device"
Driver "radeon"
Option "NoAccel" "true"
Option "UseFBDev" "true"
EndSection

UseFBDev true - came from the dpkg -reconfigure, so I left it...

The result... OMG... I have native resolution again... I can't believe I didn't think about trying that, but I'll be the first to admit I've been stabbing in the dark...

So what next, the issue is now totally reproducible - NoAccell fixes it... I'd like to get a fully functional card back. :)

~~~
Thanks to everyone who has chimed in here!

[bridgman]

I'm a bit suspicious about that fbdev option, will check.

EDIT - all indications are that you should not have the UseFBDev option turned on. It does seem to help with some non-ATI GPUs, however.

Can you pastebin your dmesg output ? Let's see if the drm is coming up OK.

[internalkernel]

pastebin as requested: http://pastebin.ca/1522174

I pulled the relevant parts below, in case you don't want to dig through all of it...

#:~$ dmesg |grep drm
[ 10.596553] [drm] Initialized drm 1.1.0 20060810
[ 10.614962] [drm] Initialized radeon 1.30.0 20080528 for 0000:01:00.0 on minor 0
#:~$ dmesg |grep radeon
[ 1.637946] radeonfb 0000:01:00.0: power state changed by ACPI to D0
[ 1.637962] radeonfb 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 1.638356] radeonfb: Retrieved PLL infos from BIOS
[ 1.638361] radeonfb: Reference=27.00 MHz (RefDiv=6) Memory=400.00 Mhz, System=250.00 MHz
[ 1.638366] radeonfb: PLL min 20000 max 40000
[ 3.149013] radeonfb: Monitor 1 type LCD found
[ 3.149017] radeonfb: Monitor 2 type no found
[ 3.149024] radeonfb: panel ID string: QDS
[ 3.149028] radeonfb: detected LVDS panel size from BIOS: 1440x900
[ 3.149031] radeondb: BIOS provided dividers will be used
[ 3.228009] radeonfb: Dynamic Clock Power Management enabled
[ 3.228536] radeonfb (0000:01:00.0): ATI Radeon 3150 "1P"
[ 10.614366] radeonfb 0000:01:00.0: setting latency timer to 64
[ 10.614962] [drm] Initialized radeon 1.30.0 20080528 for 0000:01:00.0 on minor 0

Perhaps the FBdev came in because the radeonfb driver is in use...

[bridgman]

Arggh ! Get rid of radeonfb; that's probably what is causing all your problems.

[Ant P.]

There's a 99% chance bridgman's right here, since I just had almost the same problem (http://www.phoronix.com/forums/showthread.php?t=18389)...

[internalkernel]

Arggh ! Get rid of radeonfb; that's probably what is causing all your problems.

I so wish it was that simple, but radeonfb was something I had just started playing with today... I've removed it from the startup, and blacklisted in blacklist-framebuffers.conf as per a normal install.

dmesg produces the same output without radeonfb, drm initializes...etc. Still no love on getting any form of acceleration to work.

I'm trying various option out of the radeon manual... I'll post if I have any luck.

Where do you think the problem is stemming from? Xorg, radeon, my hardware, my config?

And thanks for the help... and patience. it is appreciated...

[bridgman]

have you also removed the "UseFBDev" option ?

Turn that off if it's not already off, then power down, restart, start up X and post xorg log + dmesg output along with a summary of what isn't right.

[internalkernel]

have you also removed the "UseFBDev" option ?
Turn that off if it's not already off, then power down, restart, start up X and post xorg log + dmesg output along with a summary of what isn't right.

My Device section from xorg.conf (UseFBDev option removed):
Section "Device"
Identifier "Configured Video Device"
Driver "radeon"
Option "NoAccel" "true"
EndSection

Xorg.0.log: http://pastebin.ca/1522415
Fresh Dmesg: http://pastebin.ca/1522417

The issue at this point is without "NoAccel" set to "true" in xorg.conf, Xorg will eat my CPU (100%) and locks the machine up. I'd love to get back to a fully functional card...

thanks again...

[bridgman]

We need xorg log and dmesg from when it's *not* working (ie without the NoAccel option) to figure out what's wrong :D

Not sure what the default accel method was in 6.12.1, might still be XAA, but try adding Option "AccelMethod" "XAA" in the device section just to be safe.

[internalkernel]

We need xorg log and dmesg from when it's *not* working (ie without the NoAccel option) to figure out what's wrong :D

Not sure what the default accel method was in 6.12.1, might still be XAA, but try adding Option "AccelMethod" "XAA" in the device section just to be safe.

Surely that would help... the non-functional one... it's been a long day.

The default according to radeon manual and Xorg.0.log is EXA - I tried specifying XAA - and Xorg.0.log said it wasn't supported for this model type and to use EXA. So, at this point, I just removed the "NoAccel" option and let it choose what it wanted...

Here's some new info...
Xorg.0.log: http://pastebin.ca/1522454
Dmesg: http://pastebin.ca/1522455

thanks again...

[bridgman]

Thanks. Looking at it now.

BTW I expect the message was actually that XAA *Render* was not supported (ie a specific function within XAA) -- XAA itself should be supported just fine, not the Render commands.

[bridgman]

Hmmm. No obvious problems there, everything looks fine.

Maybe try XAA and see if that helps.

Looks like you are running a non-standard kernel; did you rebuild/update the kernel at some point ?

[internalkernel]

Thanks. Looking at it now.

BTW I expect the message was actually that XAA *Render* was not supported (ie a specific function within XAA) -- XAA itself should be supported just fine, not the Render commands.

On that you are correct... but Xorg still locks up.

(II) RADEON(0): XAA Render acceleration unsupported on Radeon 9500/9700 and newer. Please use EXA instead.

In regards to the kernel - it's the kernel out of TuxOnIce ppa. It's the stock Ubuntu kernel with modules for hibernating through TuxOnIce.

[bridgman]

OK... are you running some kind of non-standard kernel ? If so when did you change it relative to when you started having problems ? I was under the impression you were running vanilla Jaunty...

[internalkernel]

I've always used TuxOnIce kernels with this computer, with all my boxes actually.

But, for the purposes of this experiment I'd be happy to boot into the previous kernel - 2.6.28-11 - and still the same issue.

I saw no issues with xorg log either... which is another reason this is so baffling for me.

[bridgman]

Isn't Jaunty 2.6.28-13 ?

Can you just walk me through the sequence of events again when you re-installed Jaunty ? I had been under the impression this was vanilla Jaunty, ie nothing changed. Was anything else changed from stock ?

[internalkernel]

Most recent vanilla Jaunty is 2.6.28.15.20 - from Jaunty Proposed and currently the one I will be booting into from now on. I have grub set to the TuxOnIce patched kernel for hibernation support.

The first time I ever installed Jaunty on this laptop, everything "just worked". It was a first for my ATI card, desktop effects and all that was working fine. I've reinstalled at least twice since then for various reasons and never had a problem with the video.

Replaced this laptop with a smaller one for traveling, and left the problem child at home... it had been used by friends, wife, and finally the kids. They wanted to play a certain game at one point, which really was not functional with the Open Source Radeon driver. So, I went and found the latest ATI (9.6) - it had been a while since I had messed with installing it... Didn't read anything really - I know, I'm still kicking myself for it...

Got a memory cannot be allocated error when the fglrx module went to insert... so I removed it, dpkg --purge, killed /usr/share/ati, replaced my backed up xorg.conf and rebooted. That was when this problem cropped up. After about an hour and a half of trying to figure out WTF, I decided to wipe the system... I always have a solid backup, so it never takes more than 30 minutes...

But... no love and here we are... dealing with the same issue. This issue comes up with livecd's as well - which makes me start to think it's a hardware problem...

I've tried rolling back to Intrepid with Catalyst 9.3, upgrading to xorg-edgers, I even rolled back to Hardy... which is where I had the most luck. I'm about to install Windows just to see what the hell happens. I just can bear the thought... ;)

The process I go through after an install, is just to update sources.list with a few ppa's (none that affect Xorg TuxOnIce is the only one with a flavored kernel), uncomment proposed and backports, etc. Upgrade... Replace a few config files in /etc from my back up - ssh, nfs, stuff like that...

thanks for the help... Whenever you want to call it a night feel free to do so...

[bridgman]

Here's my problem. I know the drivers usually work with everything stock (ie download 9.04, install, run). I don't know how well everything works on a non-standard system, and nothing in the stack is sufficiently verbose to effectively debug a mystery problem.

Normally what we do in the case of mystery problems is go back to a known good configuration, which is "totally completely and unequivocally stock" 9.04 in your case. No PPAs, no kernels, no nothing. Not Jaunty Proposed. Nothing uncommented. No different config files.

Wipe, install, boot, see what happens and paste logs if it doesn't work the way you expect. Get it working and *then* customize.

Anything else is guessing, and I think we're running out of guesses :D

[internalkernel]

I absolutely and totally agree... and that's just what I've done when I boot into the LiveCd in safe mode, Alt+F1 over to console, rmmod video and output. Edit xorg.conf and replace "vesa" with "radeon", insmod radeon and restart X - and the machine locks up tight... I mean the livecd is about as stock as you can get... unless I'm missing something here - that should be it, correct? And since we've started this thread, I've tried adding the "NoAccel" option to the xorg.conf and it will work under those circumstances...

I'm starting to think this a hardware issue...

Interestingly enough, it will also work with the "DRI" option set to False. Seems to be the culprit... just have no idea what to do about it.

[bridgman]

No. Not liveCD. Not mmod video and edit config. Wipe, install, observe.

LiveCD is probably fine but I don't know that :D

Disabling DRI turns off most of the acceleration. It may turn off all acceleration with radeon, I forget. Does "man radeon" say anything about it ?

[internalkernel]

man radeon doesn't specifically say what it does, just that it enables or disables DRI.

I'll reinstall in the morning... vanilla install - no updates, get Xorg working anyway I can... my pile of homework :P

Thanks for all your help today... it is really appreciated, if nothing else I don't have to live in 1024x768 anymore... =)

[bridgman]

OK, see you tomorrow

[internalkernel]

Ok... fresh install... setup a new user, to rule out any profile issues as well. No updates have been applied yet, setup SSH access and that's it. Progress as of now:

Removed kernel parameter "xforcevesa" from grub boot line - had to install in safe graphics mode.

Replaced "vesa" with "radeon" in xorg.conf

reboot... and a really expensive paper-weight is what I have... =) I think it's important to note, that I setup a new user after this install. GDM is not set to auto-login, and the lock up happens before I even see a login screen. X flashes like it's about to start, and the machine locks up.

Xorg.0.log: http://pastebin.ca/1522944
Dmesg: http://pastebin.ca/1522945

for your perusal... no obvious errors, it should be working...

Had to add the Option "DRI" "false" to xorg.conf to get a desktop... Maybe it's just me, but the DRI option seems to be a bit more functional that the NoAccel option. I notice the difference when scrolling through Synaptic mostly. NoAccel is horrendous...

[nanonyme]

Just a wild guess but noticed from dmesg you're loading agpart so is it an AGP display card? If so, could try the normal radeon.agpmode=X switch to see if it affects the situation. (X is a numeric value, iirc -1 implies it's out of operation altogether)

[internalkernel]

Wild guesses are welcome! that's really all I have at this point anyways... :P

It's actually a PCIE card on a laptop (according to Xorg.log), not sure why agpgart loads - it also loads intel_agp as well... It's one of those things, it's just always been that way.

How would I use that switch? As a kernel parameter?

thanks for taking the time!

[legume]

How would I use that switch? As a kernel parameter?


I think that option is only for the kernel modesetting radeon module, if you aren't using that then instead you could try in the device section of your xorg.conf -

Option "BusType" "PCIE"

Edit: Although looking at your log it doesn't look like it would if you were really using AGP.

Perhaps you could blacklist the agp modules, /etc/modprobe.conf is where to do it for me, I am not sure where with distros.

[internalkernel]

I tried blacklisting both agp modules, intel_agp and agpgart - along with the option "BusType" PCIE in xorg.conf - but no love. Radeon doesn't seem to load without agpgart, but I left intel_agp blacklisted... still no difference.

I think I'm going to put an email into the Xorg mailing list and see if anyone has seen this behavior before. Xorg is the main issue here, what's causing the problem with Xorg is still unknown... but at least they may point me in the right direction.