[RV350] xrandr exposes invalid 1360x768 mode

lshw returns:

    description: Computer
    product: Shadow-K8
    vendor: eMachine
    version: VT8385/VT8235
    serial: N3045 600 13449
    width: 32 bits
    capabilities: smbios-2.3 dmi-2.3 smp-1.4 smp
    configuration: boot=oem-specific cpus=1 uuid=00D87B91-2564-0010-A21B-7F070E37DCA3
  *-core
       description: Motherboard
       product: Shadow-K8
       vendor: eMachine
       physical id: 0
       version: KBC Revision: 3308
       serial: None
     *-firmware
          description: BIOS
          vendor: Phoenix
          physical id: 0
          version: 0F05.P00 (03/26/2004)
          size: 96KiB
          capacity: 448KiB
          capabilities: isa pci pcmcia pnp apm upgrade shadowing escd cdboot bootselect socketedrom acpi usb agp smartbattery biosbootspecification
     *-cpu
          description: CPU
          product: Mobile AMD Athlon(tm) 64 Processor 3200+
          vendor: Advanced Micro Devices [AMD]
          physical id: 4
          bus info: cpu@0
          version: 15.4.10
          slot: Socket 754
          size: 2GHz
          capacity: 2500MHz
          width: 64 bits
          capabilities: boot fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext x86-64 3dnowext 3dnow up cpufreq
        *-cache:0
             description: L1 cache
             physical id: 7
             slot: L1 Cache
             size: 128KiB
             capacity: 128KiB
             capabilities: synchronous internal write-back instruction
        *-cache:1
             description: L2 cache
             physical id: 8
             slot: L2 Cache
             size: 1MiB
             capacity: 1MiB
             capabilities: synchronous internal write-through data
     *-memory
          description: System Memory
          physical id: a
          slot: System board or motherboard
          size: 1280MiB
        *-bank:0
             description: DIMM DRAM Synchronous
             physical id: 0
             slot: M1
             size: 1GiB
             width: 64 bits
        *-bank:1
             description: DIMM DRAM Synchronous
             physical id: 1
             slot: M2
             size: 256MiB
             width: 64 bits
     *-pci:0
          description: Host bridge
          product: VT8385 [K8T800 AGP] Host Bridge
          vendor: VIA Technologies, Inc.
          physical id: 100
          bus info: pci@0000:00:00.0
          version: 01
          width: 32 bits
          clock: 66MHz
          configuration: driver=agpgart-amd64 latency=8
          resources: irq:0 memory:e0000000-efffffff
        *-pci
             description: PCI bridge
             product: VT8237 PCI bridge [K8T800/K8T890 South]
             vendor: VIA Technologies, Inc.
             physical id: 1
             bus info: pci@0000:00:01.0
             version: 00
             width: 32 bits
             clock: 66MHz
             capabilities: pci pm normal_decode bus_master cap_list
             resources: ioport:2000(size=4096) memory:d0100000-d01fffff memory:d8000000-dfffffff
           *-display
                description: VGA compatible controller
      ...

Thanks for your bug report. The logs show that you are using packages from the xorg-edgers PPA. Can you please attach the log files from using standard packages (for instance running the live CD)? If you can access network and the text console in this case, you can run "apport-collect 643118" to have the relevant files uploaded.

The log in comment 2 is from using the standard packages, and it does not have the error messages seen in the other files. Did you see the stripes in this case? I think the result in the 4 other cases should be quite different.

I can't even install from a LiveCD. The xorg-edgers was because I was trying to see if that would help the problem. I purged those packages now.

Even the LiveCD of the dailybuild had this issue. Do you want me to reinstall the beta and get the updates to reproduce the logs, or do you want the logs I have that reflect the PPA being purged. The PPA didn't help at all.

Let me clarify. I can't install from a daily build with updates. The Beta works fine, it's the updates that killed the install.

Thanks, that we have a defined CD version that works and a later one that does not work means that it should be possible to narrow down exactly which package update broke.

1. On the updated broken system, do you still have old kernels installed that you can try from the grub menu? This will show if a kernel upgrade broke it.

2. Run the working live CD, update xserver-xorg-video-ati and xserver-xorg-video-radeon on it and see if it breaks (after logging out and in again). If it does not:
3. Update xserver-xorg-core and see if it breaks now. Updating this package might force the updating of many other packages though.

BTW, the log which is most interesting is the one corresponding to the broken session. Not a working log nor one corresponding to some failsafe configuration.

Tormod, If I'm understanding you correctly I should boot the life CD and run the update in a temporary environment, the log out and in to see if it broke?

I don't know which logs are which. Tell me which one you want and I'll get it.

Okay so I booted the beta CD and upgraded the 2 packages above. I logged out and in again without rebooting. I did not experience the problem so it must be something else?

Yes, that's correct. Just run the update-manager in the live CD session (maybe you have to configure Software Sources, in all cases you'll just need the normal "main" component). Then only update the packages in question. After logging out, log in again with username "ubuntu" and empty password.

For which logs to get you can for instance look at the timestamp of the log file and correlate it with the time when you had the broken screen.

Okay, I updated and logged out/in as indicated above. This did not break the system.

How about if I delete all the logs while I'm in the liveCD, then boot using the broken system. Then boot with the liveCD again and post the logs it created?

Right, then it is not these packages. When you have ruled out the kernel, -ati/-radeon and xserver-xorg-core, try the mesa packages (libgl1-mesa-dri and -glx) and libdrm.

To get the right log the easiest way, if you can switch to a text console while the X screen is broken, log in on the text console and copy the current log: cp /var/log/Xorg.0.log ~/Xorg.broken.txt

I'm going to try the other packages now. Here is some move information I found out though. After doing those updates, the screen is not exactly banded as described this time. The bands are the desktop switcher squares, as conformed by watching the strange movements when I do an ctrl+alt+right arrow and so forth. Also I noticed that moving my fingers on the mouse pad caused a solid vertical line to move from left to right. As though it is a giant cursor that I'm seeing. Also the colors reflect the colors of the desktop.

It's almost like I'm looking at the desktop on such a scale that it looks like bands of color. Now, keep in mind that this DOES differ from the install with ALL the updates, and it DOES differ from the LiveCD which looks exactly like a full install with all the updates. I'll test as indicated above and report back.

I tried the mesa packages and that wasn't it. The drm package doesn't show an upgrade available from the BETA CD. How do I go about testing the kernel from a LiveCD, or do I try to downgrade from the installed version?

Okay, I wiped off my HD and re-installed the BETA with NO updates. Tell me how to best proceed for trouble shooting this thing. If I install all the updates, the system will be broke.

Did you already test the kernel as of point 1 in comment 11 above?

Now that you have your working Beta installed, start with updating the kernel and reboot to see if it breaks. Then do -ati/-radeon, xorg-server-core and mesa packages as before.

If we rule out all the graphic driver packages (including kernel), we will have to look at packages like plymouth which might affect how the graphics is initialized.

Once the system is broken, we will hopefully know exactly which package broke it. To further diagnose the problem, some tricks on https://wiki.ubuntu.com/X/NonGraphicalBoot can be useful, like the "Booting LiveCD Without X" section which also applies to an installed system. (Note that the "Bypassing/Disabling gdm" section is outdated now that we use upstart instead of init/rc scripts.)

BTW, which configuration or situation are you describing in comment 19?

In comment 19 I was referring to running the LiveCD - Daily Build from yesterday. Regarding the trying the kernel, I'm about to do that now.

Okay, so I updated the kernel packages and it worked fine. Now I'm going to upgrade the same packages we did on the livecd and see how that goes.

I just finished updating all the packages mentioned here and those don't seem to have broken anything except Plymouth. Now I just get a black screen with a blinking cursor while it's loading (no splash screen). Everything else is working, what packages do you suggest I try next?

Wellll..... I upgraded a bunch of packages I thought were trivial regarding graphics and desktop and it's broke again with the same issue... I upgraded all the printing related files and the games related files. How would you suggest I figure this one out? Should I reinstall and and test 1 update at a time (there are 426 of them), or is there some other way to narrow this down?

Can you please give us the exact time you had everything working and when it broke, and attach your dpkg.log here?

Did you reboot in between those update batches? Some package updates (especially those who trigger an "initrd" rebuild) may cause issues to appear first after a reboot.

Please try the debugging from earlier comments (esp. comment 22) and attach the "broken" logs.

Everything was working at 1407. Then I downloaded several updates and rebooted at 1510 to a broken system.

I did reboot after the xserver packages, the kernel packages, the mesa graphics packages and everything you mentioned in posts 11 and 22.

Then I did a HUGE batch of updates all at once. I thought they were printing (CUPS) packages and Gnome games packages mostly. I figured those would be safe to upgrade and shorten the list. I must have ticked something else not intended and it was the broken package.

I hope I can figure this out without having to install all 426+ packages one at a time and rebooting after each. If I must do that, I suppose I should get started soon. I'll wait until I here from you before I proceed with anything else.

In comment 12, 15, 18, 22 (and 28) I asked about debugging logs, and I meant the (failing) Xorg.0.log in particular. Also dmesg output can be useful.

Did you keep the dpkg.log from your original installation? If you know which day the system broke, it should narrow down the number of packages quite a bit if you were updating regularly.

I'll get the Xorg.0.log - Since I've booted into the failsafe mode, can I boot into the regular mode (that doesn't work) to create the needed entries, the boot to the live CD to get the logs?

How do i get dmsg output? From the ORIGINAL installation... No.

Please use the "xinit" trick from the wiki page in comment 22, which also produces an xrandr.txt file. Copy the new Xorg.0.log like I said in comment 18. Run "dmesg > dmesg.txt". Then use failsafe mode to attach all three files here.

Once the screen is scrambled, you can still switch to a text console with ctrl-alt-F1, right?

Gotcha... I'll do this tonight when I get back home.

I never could get the system to boot again and ended up reinstalling the BETA. I started installing the updates a couple at a time and found that 1 of the 4 packages are responsible. Can you tell me how to narrow it down to 1, and take the appropriate steps to get it fixed?

I would bet on the gnome-settings-dameon. The three log files could probably confirm that and help to see what is going wrong. Try also to downgrade this package if possible, or even upgrade it on a live CD session.

As it turns out the buggy package is for sure the gnome-settings-daemon. I wasn't able to make the broken install work properly by downloading a deb with a different version, but I was able to break an install and the BETA LiveCD simply by updating this package.

Further, another clean install of the beta and then version locking the gnome-settings-daemon kept it alive even after all other updates were applied.

I'm guessing I should file a new bug report on this package.

Thanks for all the help and advice.

I filed another bug report here:

https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/649534

There is no need to file a report, it is still the same bug. But now it is really time you post those log files I keep asking for :)

Looking at the time of the bug reporter's first post on the forums, it must have happened with gnome-settings-daemon 2.31.91-0ubuntu2 or 2.31.91-0ubuntu3. I would guess one of these changes is to be blamed:
  * debian/patches/08_xrandr_command.patch:
    - still call gnome-display-properties to configure the display, the
      control center changes didn't land this cycle (lp: #631761)
  * debian/gnome-settings-daemon.gconf-defaults:
    - turn on external screens by default

Okay, log files on the way. I just need to know if I should upgrade the package and let it break the system before I send them. I would image log files from a working system wouldn't be what you are looking for.

It would be perfect to have both to compare them. You can still get the old, working version here: https://edge.launchpad.net/ubuntu/+source/gnome-settings-daemon/2.31.91-0ubuntu1/+build/1945029 so that you revert to a working system again.

Here are the logs from the working system. Let me know if anything needs to be added.

-Charles

Thanks. Just attach each file as-is next time, it is easier for developers to look at it this way. Server disk space is not an issue!

Can you now please attach Xorg.0.log and xrandr.txt from a broken setup? Make sure you have the working version of the package downloaded, so you can simply reinstall it on the console with: sudo dpkg -i gnome-settings-daemon_2.31.91-0ubuntu1_i386.deb

Okay, Here are the logs from the broken system. All I did to break it was install the gnome-settings-deamon.

-Charles

I reinstalled the gnome-settings-deamon from the link you provided and now the system is working again. Thanks. I have version locked it and will wait for further instructions or information.

Can you please try to install 2.31.91-0ubuntu2 and see if it breaks? I am not sure if -2 or -3 introduced the problem.

I realize that the above "xinit" trick is no good for collecting the "broken" files, since it is the gnome-settings-daemon that upsets things, and xinit does not launch it...

Can you please also try the following:
Install the newest, broken package again. Then run these command:
 cd /usr/share/gdm/autostart/LoginWindow
 sudo mv gnome-settings-daemon.desktop gnome-settings-daemon.desktop.disabled
Now restart your computer. This time you should see the login screen, but it will break again as soon as you log in to a normal Gnome session. Is this correct?

It works just fine with -2 it's -3 that causes the problem. I'll try the other test now...

Renaming the file had no effect on anything.

OK, rename it back (I am not sure if this file is being used anyway), and try this command instead:
 sudo -u gdm gconftool-2 --type=bool --set /apps/gnome_settings_daemon/xrandr/turn_on_external_monitors_at_startup false
This should hopefully give you a login screen even with the "bad" package version installed. If so, you can run this on the console as your own user:
 gconftool-2 --type=bool --set /apps/gnome_settings_daemon/xrandr/turn_on_external_monitors_at_startup false
and then be able to log in to Gnome as well.

If the above is correct, it seems like a normally harmless change in gnome-settings-daemon triggered a bug in the radeon driver.

I did this wrong the first time. I tried it again and it does exactly as you predicted. I'll try the other tests now and report back.

'Can you please also try the following:
Install the newest, broken package again. Then run these command:
 cd /usr/share/gdm/autostart/LoginWindow
 sudo mv gnome-settings-daemon.desktop gnome-settings-daemon.desktop.disabled
Now restart your computer. This time you should see the login screen, but it will break again as soon as you log in to a normal Gnome session. Is this correct?'

Okay, so I used the first method of renaming the gnome-settings-daemon.desktop and got to the login screen.

Then I used the recovery console and typed in the command:
gconftool-2 --type=bool --set /apps/gnome_settings_daemon/xrandr/turn_on_external_monitors_at_startup false

Then I exited the recovery console and continues to login to Gnome as usual.

It all worked as you described... Thanks.

Can you please make new "broken" log files as follows: Rerun the gconftool command as your user, but now with "true" at the end. When you log in again, it should be broken. Switch to a console with ctrl-alt-F1 and log in and run:
 xrandr --verbose -d :0 > xrandr.broken.txt
 cp /var/log/Xorg.0.log Xorg.0.log.broken.txt
Now you can run gconftool with "false" to make it work again, and restart gdm with: sudo restart gdm

Make sure you rename back the gnome-settings-daemon.desktop file so that all installed files are like they should be. The "sudo -u gdm ..." command above should make sure you can see the login screen anyway.

Here are the logs.

Thanks! The logs show that both 1280x800 and 1360x768 are detected as valid modes, and the X server chooses 1280x800 as the preferred mode, which also works fine. However, gnome-settings-daemon (if turn_on_external_monitors_at_startup is true) forces the 1360x786 mode which does not work.

I am not sure if the driver is at fault for exposing a non-supported mode of 1360x786 (although the kernel detects that the LCD panel size is 1280x800 pixels), or if it is wrong of gnome-settings-daemon to select a non-preferred mode. Or both...

So what happens now?

1280x800 is the highest possible on this system.

FYI - I'll be going into the hospital for surgery so I won't be able to work on this anymore for several days. If you ask for information and I don't reply, it's because I won't be able to.

-Charles

It seems like similar issues have been discovered in bug 640807 so more people are looking at it. When you have the possibility, try booting with the boot option (added to the grub kernel line) radeon.modeset=0 to check if this is a bug in the kernel video driver only.

Also try this, suggested in the other bug report: you can run "sudo touch /var/lib/gdm/gsd-debug-randr" and restart gdm and you will get a debug log /var/lib/gdm/gsd-debug-randr.log with details on what g-s-d is doing

Best wishes for your surgery!

@ Tormod,

I've commented at #640807, brief recap: with Intel i945 and a 22" Hanns-G LCD. The LCD just posts the warning: "Input signal out of range".

After that I can get no screen output at all until I reboot, but if I wait I do hear the drum roll so I assume that I'm booted. I'm reasonably sure that I'd selected "auto-login".

Anyway, since I can get to gui, nor even a TTY, I tried this in a chroot:

lance@lance-desktop:~$ sudo mount /dev/sda16 /mnt && sudo mount --bind /dev /mnt/dev && sudo mount --bind /proc /mnt/proc && sudo mount --bind /sys /mnt/sys && sudo mount --bind /dev/pts /mnt/dev/pts && sudo cp /etc/resolv.conf /mnt/etc/resolv.conf && sudo chroot /mnt
[sudo] password for lance:
root@lance-desktop:/# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu maverick (development branch)
Release: 10.10
Codename: maverick
root@lance-desktop:/# touch /var/lib/gdm/gsd-debug-randr

Then I rebooted, got the expected "out-of-range" warning, waited for the "drum-roll", and rebooted using the reset button. But I get no log in "gsd-debug-randr":

root@lance-desktop:/# ls /var/lib/gdm/gsd-debug-randr
/var/lib/gdm/gsd-debug-randr
root@lance-desktop:/# ls /var/lib/gdm
gsd-debug-randr
root@lance-desktop:/# cat /var/lib/gdm/gsd-debug-randr.log
cat: /var/lib/gdm/gsd-debug-randr.log: No such file or directory

I've even snooped using Nautilus and see no log??????????

But, I'm undeniably far outside my comfort zone here.

The change in g-s-d that triggered the broken screen will be reverted (in post-release updates), so the screen will come up like it should. There is however a bug in the video drivers that allows a broken screen mode to be selected.

crjackson, once you have recovered we can try to fix this. Please try radeon.modeset=0 and also try the newest kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/ when you have a chance. Get the Xorg.0.log, dmesg, and xrandr output in both cases.

Tom, I know it's been a long time but I've had some serious health issues. Please tell me what I need to do if more information is needed at this point. The release shipped with some changes as a result (I think) of this bug post and others and it seemed to cure my particular issue.

Is more information required or is the bug considered obsolete now?

crjackson, glad to see you are back in business! Please see comment 66, there is probably still a video driver bug, although it does not have the same consequences as earlier.

This version has expired