[RV100 QY] intrepid alpha 6: no signal during install on AGP system

It might be useful to indicate what hardware (esp. motherboard and video card and monitor) you are using, as well as things like the monitor refresh rate and how you are plugged in (DVI/VGA)

What changes did you have to make in hardy in xorg.conf to get it to work? Also is it possible to run lspci from the command line on that machine (e.g. using hardy) and attaching the output here? Thanks.

I changed my xorg.conf some time ago because I found that my particular monitor doesn't work well with DDC and certain acceleration options make my graphics card unhappy. It may have been as far back as Dapper but definitely in Feisty it was like this. My installation procedure for new releases through Hardy has been to install in "safe video mode", then reboot in safe video mode (or text mode), copy over my old xorg.conf, and reboot in normal mode.

The problem as I see it is that safe video mode install no longer works - having to do this extra work with my xorg.conf does not bother me, as long as I can install.

I have attached my

Last line above should read "I have attached my lspci output". Here is xorg.conf for your review. I don't think it's very interesting - the important part is replacing the driver with vesa. I wish I could remember why I needed to do this - a radeon driver bug was involved, I think. Maybe it's resolved now.

Can you attach your /var/log/Xorg.0.log and /var/log/Xorg.0.log.old from after attempting to boot with the -ati driver specified in xorg.conf? Also, please attach `lspci -vvnn`; the default lspci output doesn't include al lthe pci id numbers we need.

Another thing to try is disabling compiz; sometimes X boots up properly without it.

Thanks, Bryce. I will try to get this information for you on my current Hardy environment. Just to be certain, though, I should clarify that this is a problem with Intrepid install and I have no way of getting log files from that (to my knowledge). Having to use the vesa driver under Hardy isn't bothering me...

This Xorg log was produced when I specified "ati" as the driver instead of "vesa" in xorg.conf. The symptom (monitor power down with blinking LED) is identical to when I attempt to install Intrepid in safe video mode.

This Xorg log is the one produced when I use the "vesa" driver, i.e., when I use the xorg.conf I attached previously. In this one everything is fine.

The output of "lspci -vvnn" (as root)

Based on other bug reports I went ahead and did some experiments. I can tell you that:

1) disabling dri and glx allows me to see video, although the quality is poor
2) AGPMode appears to have no effect
3) "ignore LVDS" doesn't help either

Thanks for testing all those things.

One other thing to test, is to leave dri and glx enabled, but disable compiz (and easy way is to 'chmod -x /usr/bin/compiz') and see how that looks.

In fact compiz is not even installed on my machine... I'm a KDE 3.5.9 user (KDE4 video quality was terrible, the subject of a different bug). Hopefully this will change with Intrepid.

What driver is used during "safe video mode" install? I'm really not that concerned about getting radeon to work at this time, but not being able to install Intrepid is a bummer. Thanks.

The failsafe mode uses the vesa driver.

In that case this isn't really an ati bug, is it? Although I'd be delighted for that to finally work.

I filed this bug as "kubuntu-meta" thinking perhaps "safe video" (failsafe?) was not choosing the vesa driver in Intrepid.

Perhaps this is a case of bug 261977

I don't believe so. It seems that 261977 is a case of a specific nVidia driver being chosen for a device it does not support. However, there is a bit in there about the nv driver claiming a device, and preventing vesa from subsequently doing so itself... that could be related if the analogy to ati holds.

In other news I have the radeon driver *almost* working - by removing the Modes information and disabling only "glx", I get a good image at the proper resolution, but with a bad flicker event about every 10 seconds. xorg.conf attached if you have any suggestions - successful vesa config is exactly that with driver changed to "vesa" and no "AccelMode EXA". I am up and running with Intrepid Beta now via the alternate install CD (text mode).

I got exactly the same problem (I think) with my ATI Radeon 3850 (not fixed under final version), but my bug has been tagged as "duplicate" of the "nv bug"...

261977 was actually a problem in the xserver's logic for selecting the driver for a card. Basically, there was a routine that looked up the card's pci id to see what driver to use, and if it didn't find one - meaning the driver didn't support the card, it left it blank. Later on, there was some other (older) logic that kicked in if no driver had been selected, that picked the driver based on the vendor name, -nv for nVidia hardware, -ati for ATI hardware. It tends to afflict -nv more since there's a lot more hardware -nv doesn't support, but in theory it could also affect -ati.

Anyway... comment #14 sort of made me think of that bug. But since that problem is fixed, this is obviously something completely different.

Great to hear that you were able to get it to mostly work with EXA and disabling glx. I'm curious if EXA is really needed, or if it also works the same with XAA (the default)? We are considering switching to EXA as the default for Jaunty (see https://blueprints.edge.launchpad.net/ubuntu/+spec/radeon-change-xaa-to-exa), so I'm curious both if it fixes this issue, and if the flickering could be due to EXA.

Aha, I should have noticed this sooner - you've got an AGP system, and your symptoms almost exactly match a known issue with -ati on AGP. Please see https://wiki.ubuntu.com/X/Quirks#ATI AGP Mode Quirk

Please try this. In your xorg.conf, set the following:

    Option "AGPMode" "1"

Also try values 2, 4, 8. Sometimes your BIOS will include AGP settings - make sure it is set to the factory default for this testing (since we want to find a combo that works "out of the box").

Thanks for the suggestions, but it looks like specifying EXA vs. not specifying it makes no difference to my observations, nor do the AGPMode settings.

As for bug 261977, was it fixed after alpha 6? I haven't retried the "safe video" install since then. My current Intrepid build is off the alternate Beta CD plus online updates.

Jeff,

Yes, it was fixed fairly late in the release, post-beta. However if you've done the online updates you should have all the necessary bits and pieces. I'd appreciate it if you could re-try the safe video option, just to verify that issue is gone.

However, the -ati issues are the ones I'm more interested in getting squared away.

I've gone ahead and forwarded this issue upstream to https://bugs.freedesktop.org/show_bug.cgi?id=18871. Please subscribe to that bug report, in case upstream has additional questions or wishes you to test something. Thanks ahead of time!

Meanwhile, I've written a short troubleshooting guide for 'no signal' bugs, and it would be helpful if you could run through the steps, to see if you can get a functioning system at a lower resolution or something with glx enabled. If so, then that hints that there is an improper modeline being setup for your monitor.

Also, have you ever tested this with a different monitor? It would be a useful data point if the issue was seen to be specific to that monitor, vs. if it occurs with other monitors.

Thanks for the helpful suggestions and for forwarding my bug upstream. I'll be happy to participate in debugging as much as I can :) I don't have easy access to a second monitor, but can try to borrow one from work. I will also try installing from the released Intrepid CD.

I wasn't able to locate your troubleshooting guide - can you attach a link?

Thanks,
Jeff

I can now confirm that "safe graphics" mode is working on the desktop release CD.

This bug was reported in the Intrepid development cycle; removing regression-potential and marking as regression-release.

I finally got my hands on another monitor per Bryce's suggestion. The behavior is the same with one exception: the periodic flicker goes away. With the new monitor my observation is simply that enabling "glx" causes a blank screen and "RADEON(0): Idle timed out" messages in the log, while disabling it causes everything to work fine. As before, AccelMode and AGPMode have no effect. Could there be a glx issue with the RV100 hardware?

I've found another person with my same problem:

http://ubuntuforums.org/showthread.php?t=939603

I messaged him privately to see what happens if he disables "glx" and he confirms that it makes things work for him again.

So I think this is a general issue...

radeontool in Jaunty* can be used to assist in debugging this issue. After installing it, you run it like this:
    radeontool regmatch '*' > regdump_good.txt
    radeontool regmatch '*' > regdump_broke.txt

Run it two times. Once when you have a working screen (for any driver), and once in the broken case (either from the tty console or logged into the sick box remotely). Attach both of those to this bug report, and we can then forward this issue upstream. Thanks ahead of time!

For more info see https://wiki.ubuntu.com/X/Troubleshooting/BlankScreen

[* Note: radeontool is available in earlier versions of Ubuntu but is too old; if you need to run it on an older version of Ubuntu, you can obtain and build it from the upstream git tree at http://cgit.freedesktop.org/~airlied/radeontool/]

Bryce, thanks for your response. I built radeontool from source via git clone on my Intrepid system to avoid installation complexities. Results are attached.

The first file is the radeontool output with the vesa driver (clean visual, no glitching, no blank screen).

This second file is radeontool output with the ati driver but glx disabled (screen visible but glitches every 10 seconds).

This final radeontool output is with the ati driver and glx enabled (black screen). Thanks for your help.

As per the upstream bug comments this seems to be a kernel issue rather than X, so closing.