ATI ES1000 515e not recognized

[gian]

Binary package hint: xorg

Dapper works with Section "Device" Driver=vesa
Edgy doesn't work, even with matching xorg.conf:
/etc/init.d/gdm restart
gives
Gnome stopped ok
Gnome started FAILED

[Cristian Aravena Romero (caravena)]

Thanks for taking the time to report this bug. Unfortunately we can't fix it, because your description didn't include enough information.

Please include the information requested from https://help.ubuntu.com/community/DebuggingXAutoconfiguration as separate attachments.

[gian (glsarto)]

Cristian Aravena Romero wrote:
> Thanks for taking the time to report this bug. Unfortunately we can't
> fix it, because your description didn't include enough information.
>
> Please include the information requested from
> https://help.ubuntu.com/community/DebuggingXAutoconfiguration as
> separate attachments.
>
>
Cristian,

I managed to bypass this issue doing the following:

/sudo nano /etc/X11/xorg.conf/

changed driver from "ati" to "vesa"

/sudo shutdown -r now

/somehow the display was correct and could perform the install.

thank you very much for your kind message.

I hope this information is useful to you.

My pc is an Acer Altos G320.

regards,
-GianLuca

[Timo Aaltonen (tjaalton)]

GianLuca: if you want this to be fixed, you should provide more info like Cristian asked.

[gian (glsarto)]

Timo Aaltonen wrote:
> GianLuca: if you want this to be fixed, you should provide more info
> like Cristian asked.
>
> ** Changed in: xorg (Ubuntu)
> Status: Unconfirmed => Needs Info
>
>
Timo,

I'll try over the week-end to gather the info you need.

regards,
-GianLuca

[gian (glsarto)]

Here is how it goes.
Insert 6.10 live cd, screen ok, select keyboard, safe graphics, 1024x768x16; boot goes on till screen becomes black, with quick flashes. Open console with ctrl-alt-f1.

lspci -n
00:00.0 0600: 8086:2778
00:1c.0 0604: 8086:27d0 (rev 01)
00:1c.4 0604: 8086:27e0 (rev 01)
00:1c.5 0604: 8086:27e2 (rev 01)
00:1d.0 0c03: 8086:27c8 (rev 01)
00:1d.1 0c03: 8086:27c9 (rev 01)
00:1d.2 0c03: 8086:27ca (rev 01)
00:1d.3 0c03: 8086:27cb (rev 01)
00:1d.7 0c03: 8086:27cc (rev 01)
00:1e.0 0604: 8086:244e (rev e1)
00:1f.0 0601: 8086:27b8 (rev 01)
00:1f.1 0101: 8086:27df (rev 01)
00:1f.2 0101: 8086:27c0 (rev 01)
00:1f.3 0c05: 8086:27da (rev 01)
03:00.0 0200: 8086:108b (rev 03)
04:04.0 0300: 1002:515e (rev 02)
04:05.0 0200: 8086:1076 (rev 05)

discover
ES1000 (RN50) XFree86 ati 1002515e

xresprobe ati
id: L15C
res: 1024x768 832x624 800x600 720x400 640x480
freq: 31-60 56-75
disptype: crt

xorg.conf
# /etc/X11/xorg.conf (xorg X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the /etc/X11/xorg.conf manual page.
# (Type "man /etc/X11/xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
# sudo dpkg-reconfigure -phigh xserver-xorg

Section "Files"
 FontPath "/usr/share/X11/fonts/misc"
 FontPath "/usr/share/X11/fonts/cyrillic"
 FontPath "/usr/share/X11/fonts/100dpi/:unscaled"
 FontPath "/usr/share/X11/fonts/75dpi/:unscaled"
 FontPath "/usr/share/X11/fonts/Type1"
 FontPath "/usr/share/X11/fonts/100dpi"
 FontPath "/usr/share/X11/fonts/75dpi"
 FontPath "/usr/share/fonts/X11/misc"
 # path to defoma fonts
 FontPath "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType"
EndSection

Section "Module"
 Load "i2c"
 Load "bitmap"
 Load "ddc"
 Load "dri"
 Load "extmod"
 Load "freetype"
 Load "glx"
 Load "int10"
 Load "type1"
 Load "vbe"
EndSection

Section "InputDevice"
 Identifier "Generic Keyboard"
 Driver "kbd"
 Option "CoreKeyboard"
 Option "XkbRules" "xorg"
 Option "XkbModel" "pc105"
 Option "XkbLayout" "it"
 Option "XkbOptions" "lv3:ralt_switch"
EndSection

Section "InputDevice"
 Identifier "Configured Mouse"
 Driver "mouse"
 Option "CorePointer"
 Option "Device" "/dev/input/mice"
 Option "Protocol" "ExplorerPS/2"
 Option "ZAxisMapping" "4 5"
 Option "Emulate3Buttons" "true"
EndSection

Section "InputDevice"
  Driver "wacom"
  Identifier "stylus"
  Option "Device" "/dev/wacom" # Change to
                                                      # /dev/input/event
                                                      # for USB
  Option "Type" "stylus"
  Option "ForceDevice" "ISDV4" # Tablet PC ONLY
EndSection

Section "InputDevice"
  Driver "wacom"
  Identifier "eraser"
  Option "Device" "/dev/wacom" # Change to
                               ...

[Ls-colby-gwirynybyd (ls-colby-gwirynybyd)]

os is freebsd 6.2 stable - xorg 7.3 built from ports source using portupgrade -R xorg.

compiler switches -O2 march=athlon-tbird -pipe

xorg was built without incident.

startx after build fails.

xorg log file follows:

_XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
_XSERVTransOpen: transport open failed for inet6/venice.gwirynybyd.com:0
_XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6

X.Org X Server 1.4.0
Release Date: 5 September 2007
X Protocol Version 11, Revision 0
Build Operating System: FreeBSD 6.2-STABLE i386
Current Operating System: FreeBSD venice.gwirynybyd.com 6.2-STABLE FreeBSD 6.2-STABLE #0: Sun May 13 16:34:21 PDT 2007 <email address hidden>:/usr/obj/usr/src/sys/VENICE-1 i386
Build Date: 18 September 2007 03:08:41PM

 Before reporting problems, check http://wiki.x.org
 to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
 (++) from command line, (!!) notice, (II) informational,
 (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Wed Sep 19 09:29:49 2007
(==) Using config file: "/etc/X11/xorg.conf"
(==) ServerLayout "Simple Layout"
(**) |-->Screen "Screen 1" (0)
(**) | |-->Monitor "My Monitor"
(**) | |-->Device "** ATI Radeon (generic) [radeon]"
(**) |-->Input Device "Mouse1"
(**) |-->Input Device "Keyboard1"
(==) Automatically adding devices
(==) Automatically enabling devices
(WW) `fonts.dir' not found (or not valid) in "/usr/local/lib/X11/fonts/local/".
 Entry deleted from font path.
 (Run 'mkfontdir' on "/usr/local/lib/X11/fonts/local/").
(==) Including the default font path /usr/local/lib/X11/fonts/misc/,/usr/local/lib/X11/fonts/TTF/,/usr/local/lib/X11/fonts/OTF,/usr/local/lib/X11/fonts/Type1/,/usr/local/lib/X11/fonts/100dpi/,/usr/local/lib/X11/fonts/75dpi/.
(**) FontPath set to:
 /usr/local/lib/X11/fonts/misc/,
 /usr/local/lib/X11/fonts/TTF/,
 /usr/local/lib/X11/fonts/OTF,
 /usr/local/lib/X11/fonts/Type1/,
 /usr/local/lib/X11/fonts/100dpi/,
 /usr/local/lib/X11/fonts/75dpi/,
 /usr/local/lib/X11/fonts/dejavu,
 /usr/local/lib/X11/fonts/webfonts,
 /usr/local/lib/X11/fonts/bitstream-vera,
 /usr/local/lib/X11/fonts/misc/,
 /usr/local/lib/X11/fonts/TTF/,
 /usr/local/lib/X11/fonts/OTF,
 /usr/local/lib/X11/fonts/Type1/,
 /usr/local/lib/X11/fonts/100dpi/,
 /usr/local/lib/X11/fonts/75dpi/
(==) RgbPath set to "/usr/local/share/X11/rgb"
(==) ModulePath set to "/usr/local/lib/xorg/modules"
(II) Loader magic: 0x81ccb00
(II) Module ABI versions:
 X.Org ANSI C Emulation: 0.3
 X.Org Video Driver: 2.0
 X.Org XInput driver : 2.0
 X.Org Server Extension : 0.3
 X.Org Font Renderer : 0.5
(II) Loader running on freebsd
(II) LoadModule: "pcidata"
(II) Loading /usr/local/lib/xorg/modules//libpcidata.so
(II) Module pcidata: vendor="X.Org Foundation"
 compiled for 1.4.0, module version = 1.0.0
 ABI class: X.Org Video Driver, version 2.0
(--) Using syscons driver with X support (version 2.0)
(--) using VT number 9

(II) PCI: Probing config type using method 1
(II) PCI: Config type is 1
(II) PCI: stages = 0x03, oldVal1 = 0x00000000, mode1Res1...

[agd5f (agd5f)]

I'm assuming this is a single headed radeon? It seems to be lacking a connector table and is getting the default connector setup. I probably need to add a special case fall back for single crtc chips.

[agd5f (agd5f)]

Can you try again with ati git master or 6.7.193?

[Timo Aaltonen (tjaalton)]

Gian: Please try 7.10 beta (out in a few days), or a daily live-cd. It has a much improved ATI driver.

[gian (glsarto)]

thanks a lot for your message, I will.

[Joachim Frieben (jfrieben)]

The same happens for the current 'Fedora' development tree, see

  https://bugzilla.redhat.com/show_bug.cgi?id=261021

and references herein. So, this bug is not restricted to 'FreeBSD' but also afflicts 'GNU/Linux' systems.

[Joachim Frieben (jfrieben)]

Issue persists for all 6.7.x driver versions including 6.7.194 as well as the current 'git' tree as of 2007-09-29.

Hardware setup consists of an ATI Radeon AIW (ATI Technologies Inc Radeon R100 QD [Radeon 7200]) to which an HP A4576A 21" CRT is connected via the analog VGA D-SUB15 connector. This configuration never caused problems up to driver version 6.6.3.

[Joachim Frieben (jfrieben)]

Created an attachment (id=11819)
Xorg.0.log for ATI driver version 6.7.194

[agd5f (agd5f)]

Can you get a backtrace of the crash with gdb?

[Joachim Frieben (jfrieben)]

Created an attachment (id=11838)
GDB output for ATI driver version 6.7.194

[agd5f (agd5f)]

*** Bug 12296 has been marked as a duplicate of this bug. ***

[agd5f (agd5f)]

I should have a fix for this in the next few days (as soon as I get some time).

[agd5f (agd5f)]

This should be fixed, but there may be other places where the code falls down on single crtc cards (I don't actually have one to test). If you find any other problems let me know.

commit: 0ca184c3c35032df39ea7ce5d2d4aba1a97b6426

[Jisakiel (jisakiel)]

Works partially for me. After adding a GIT-enabled overlay (primozic's) and recompiling libdrm and xf86-video-ati the xserver starts, seems like with the dpi changed and only at 75Hz -but that's a whole different can of worms, same as trying EXA ;), and my xorg.conf is mostly automatic detection as I reported on the duplicate https://bugs.freedesktop.org/show_bug.cgi?id=12296 .

However: if after starting X I change to a VT the server hangs and leaves the screen in standby mode. That didn't happen before with 6.6.3. It doesn't hang my system fully though: when I xstart-ed I couldn't do anything but rebooting by ctrl-alt-sys-b as my screen was in standby and changing the VT didn't work. However if started by gdm it rebooted itself perfectly after a while (still in standby until the server started).

As said in #12296, I'm using 2.6.22-kamikaze9 with radeonfb and xserver 1.4-r2 from portage; just libdrm and xf86-video-ati are from git (as specified in the dependencies of the ebuild; if that could be a source of problem I can pull everything from git instead with the 9999 ebuilds). I didn't rebuild nothing but the ati driver after emerging git's libdrm and I have debug desactivated, so this should still not be a confirmed problem - so I will recompile everything ASAP with it and without fomit-frame-pointer (mesa, mesa-progs, x11-drm, xorg-server, libdrm). By now the backtrace is meaningless:

(II) AIGLX: Suspending AIGLX clients for VT switch
disable montype: 1
(II) RADEON(0): RADEONRestoreMemMapRegisters() :
(II) RADEON(0): MC_FB_LOCATION : 0xffff0000
(II) RADEON(0): MC_AGP_LOCATION : 0x003fffc0
finished PLL1

Backtrace:
0: /usr/bin/X(xf86SigHandler+0x82) [0x80d3312]

Fatal server error:
Caught signal 11. Server aborting

(II) Mouse1-usb-0000:00:02.0-3.2/input0: Off
(II) UnloadModule: "evdev"
(II) Keyboard1-usb-0000:00:02.0-3.4/input0: Off
(II) UnloadModule: "evdev"
(II) Keyboard1-usb-0000:00:02.0-3.4/input1: Off
(II) UnloadModule: "evdev"
(II) AIGLX: Suspending AIGLX clients for VT switch
disable montype: 1
(II) RADEON(0): RADEONRestoreMemMapRegisters() :
(II) RADEON(0): MC_FB_LOCATION : 0xffff0000
(II) RADEON(0): MC_AGP_LOCATION : 0x003fffc0
finished PLL1

This can be just a matter of rebuilding so I won't panic yet :D, or perhaps another tiny change somewhere else as said.

[Joachim Frieben (jfrieben)]

After rebuilding the 'xorg-x11-drv-ati-6.7.194-2.fc8' driver package on an otherwise up to date 'Fedora rawhide' system, the X server starts up correctly which means that the main issue has gone away. However, the X server now ignores the 1400x1050 mode entry in xorg.xonf and defaults to 1280x1024 at 85Hz which it didn't do before. After removing the 1400x1050 mode entry from xorg.conf, the X server still defaults to 1280x1024 at 85Hz but at least now, the GNOME display preferences allow the user to change the resolution to 1600x1200 at 75 Hz whereas before, only lower resolutions were present. However, the 1400x1050 mode has disappeared completely. It has to be added though that the Fedora X server has been patched, so this observation might not apply to upstream Xorg.
Note that the monitor device is an HP A4576A 21" CRT for which 1400x1050 is the natural resolution both in terms of DPI and aspect ratio (4/3).
When switching to a virtual console, the monitor powers off. It is still possible to switch back to vt7 but then, the X server simply restarts. It is also possible to reboot the system via ctrl-alt-del. It seems that switching to a virtual console makes the X server crash as already reported in comment #11. The relevant entries in Xorg.0.log related to the crash are:

(II) AIGLX: Suspending AIGLX clients for VT switch
disable montype: 1
(II) RADEON(0): RADEONRestoreMemMapRegisters() :
(II) RADEON(0): MC_FB_LOCATION : 0xffff0000
(II) RADEON(0): MC_AGP_LOCATION : 0x003fffc0
finished PLL1

Backtrace:
0: /usr/bin/X(xf86SigHandler+0x81) [0x80cdf21]
1: [0x12d420]
2: /lib/libc.so.6 [0x3532a8]
3: /usr/lib/xorg/modules/drivers//radeon_drv.so(RADEONLeaveVT+0x65) [0x505315]
4: /usr/lib/xorg/modules//libxaa.so [0x5bacc7]
5: /usr/bin/X [0x80b34cd]
6: /usr/lib/xorg/modules/extensions//libglx.so [0x49df8f]
7: /usr/bin/X(xf86Wakeup+0x289) [0x80cf509]
8: /usr/bin/X(WakeupHandler+0x59) [0x808c859]
9: /usr/bin/X(WaitForSomething+0x1ae) [0x81b60ae]
10: /usr/bin/X(Dispatch+0x8d) [0x808864d]
11: /usr/bin/X(main+0x495) [0x80704a5]
12: /lib/libc.so.6(__libc_start_main+0xe0) [0x214320]
13: /usr/bin/X(FontFileCompleteXLFD+0x1f1) [0x806f791]

Fatal server error:
Caught signal 11. Server aborting

(II) AIGLX: Suspending AIGLX clients for VT switch
disable montype: 1
(II) RADEON(0): RADEONRestoreMemMapRegisters() :
(II) RADEON(0): MC_FB_LOCATION : 0xffff0000
(II) RADEON(0): MC_AGP_LOCATION : 0x003fffc0
finished PLL1

[agd5f (agd5f)]

(In reply to comment #12)
> After rebuilding the 'xorg-x11-drv-ati-6.7.194-2.fc8' driver package on an
> otherwise up to date 'Fedora rawhide' system, the X server starts up correctly
> which means that the main issue has gone away. However, the X server now
> ignores the 1400x1050 mode entry in xorg.xonf and defaults to 1280x1024 at 85Hz
> which it didn't do before.

Can you attach your xorg log? I suspect your monitor doesn't have a mode in the edid for 1400x1050. The edid's preferred mode is probably 1280x1024@85, that's why it's getting set to that by default. you can manually add the 1400x1050 mode:
xrandr --newmode <1400x1050 modeline>
xrandr --addmode VGA-0 <1400x1050 mode name>

At the moment I only add the screen modes to the LVDS output (and even then I probably shouldn't). The problem is, with randr, which output to you want the screen modes added to? You may not want them on all outputs. You should be able to add a monitor section for each output and add the modes you want there, but I'm not sure the server adds them properly (I need to double check that).

Finally, can you attach the backtrace from the new VT switch crash?

[Jisakiel (jisakiel)]

As I feared rebuilding everything didn't help; I still get the crash when switching as happens to #12. However I can't get a proper backtrace; after rebuilding without fomit-frame-pointer and with debug enabled and crashing while switching, the Xorg log still only shows

(II) AIGLX: Suspending AIGLX clients for VT switch
disable montype: 1
(II) RADEON(0): RADEONRestoreMemMapRegisters() :
(II) RADEON(0): MC_FB_LOCATION : 0xd3ffd000
(II) RADEON(0): MC_AGP_LOCATION : 0xd87fd800
finished PLL1

Backtrace:
0: /usr/bin/X(xf86SigHandler+0x7e) [0x80d179e]
1: [0xffffe420]

Fatal server error:
Caught signal 11. Server aborting

(II) Mouse1-usb-0000:00:02.0-3.2/input0: Off
(II) UnloadModule: "evdev"
(II) Keyboard1-usb-0000:00:02.0-3.4/input0: Off
(II) UnloadModule: "evdev"
(II) Keyboard1-usb-0000:00:02.0-3.4/input1: Off
(II) UnloadModule: "evdev"
(II) AIGLX: Suspending AIGLX clients for VT switch
disable montype: 1
(II) RADEON(0): RADEONRestoreMemMapRegisters() :
(II) RADEON(0): MC_FB_LOCATION : 0xd3ffd000
(II) RADEON(0): MC_AGP_LOCATION : 0xd87fd800
finished PLL1

Trying to debug via gdb didn't work neither; when attaching to the server it hangs it with error 0xffffe410 in __kernel_vsyscall () and backtrace

#0 0xffffe410 in __kernel_vsyscall ()

#1 0x48e7118d in ___newselect_nocancel () from /lib/libc.so.6

#2 0x081adac1 in WaitForSomething (pClientsReady=0xafcf5300) at WaitFor.c:235

#3 0x0808d3c2 in Dispatch () at dispatch.c:425

#4 0x08074c65 in main (argc=9, argv=0xafcf5834, envp=0x0) at main.c:452

I guess that is a problem of my own system, but I accept any suggestions to get a proper bt. I'll attach a full gdb log of this non-completely-related crash though, and wait for further news.

[Jisakiel (jisakiel)]

Created an attachment (id=11877)
GDB bt of crash when tried to attach

[Michel-tungstengraphics (michel-tungstengraphics)]

(In reply to comment #14)
> Trying to debug via gdb didn't work neither; when attaching to the server it
> hangs it with error 0xffffe410 in __kernel_vsyscall () and backtrace

Where does it say error? :) It's just the backtrace at the time gdb attaches to the process, which implicitly stops its execution. At that point, enter

handle SIGUSR1 nostop

to make gdb ignore the signals involved in VT switches, then

continue

to continue execution of the X server. Then get the backtrace once it hits the SIGSEGV.

[Jisakiel (jisakiel)]

> Where does it say error? :) It's just the backtrace at the time gdb attaches to
> the process, which implicitly stops its execution.

Ok, sorry about that :*), I'm not that used to gdb yet. After the handle and continuing, when I change to a VT I get the following gdb log:

Program received signal SIGSEGV, Segmentation fault.

[Switching to Thread -1477245248 (LWP 13740)]

0x48eed2d0 in main_arena () from /lib/libc.so.6

(gdb) bt f

#0 0x48eed2d0 in main_arena () from /lib/libc.so.6

No symbol table info available.

#1 0x00000000 in ?? ()

No symbol table info available.

(gdb) continue

Continuing.

Program received signal SIGSEGV, Segmentation fault.

0x48eed2d0 in main_arena () from /lib/libc.so.6

(gdb) bt

#0 0x48eed2d0 in main_arena () from /lib/libc.so.6

#1 0xa7de8aff in RADEONRestore (pScrn=0x82186b8) at radeon_driver.c:5388

#2 0xa7de8ea5 in RADEONLeaveVT (scrnIndex=0, flags=0) at radeon_driver.c:5794

#3 0xa7c2fbe5 in XAALeaveVT (index=0, flags=0) at xaaInit.c:694

#4 0x080bb91a in xf86XVLeaveVT (index=0, flags=0) at xf86xv.c:1278

#5 0xa7eb510f in ?? () from /usr/lib/xorg/modules/extensions//libglx.so

#6 0x00000000 in ?? ()

The first sigsegv seems inside glibc, as I have to continue to get the xorg one. Unfortunately I don't have glibc with USE=debug; if necesary I will recompile it but I foresee major breakage, even not changing versions if I do that. Just in case, glibc is 2.6.1 with useflags (glibc-omitfp nls -debug -glibc-compat20 -hardened -multilib -profile -selinux).

As I saw something about XAA I tried with EXA instead, but the backtrace is pretty much the same, just without the XAALeaveVT line:

(gdb) bt

#0 0x48eed2d0 in main_arena () from /lib/libc.so.6

#1 0xa7dadaff in RADEONRestore (pScrn=0x82186b8) at radeon_driver.c:5388

#2 0xa7dadea5 in RADEONLeaveVT (scrnIndex=0, flags=0) at radeon_driver.c:5794

#3 0x080bb91a in xf86XVLeaveVT (index=0, flags=0) at xf86xv.c:1278

#4 0xa7e7a10f in ?? () from /usr/lib/xorg/modules/extensions//libglx.so

#5 0x00000000 in ?? ()

[Joachim Frieben (jfrieben)]

Created an attachment (id=11892)
Xorg.0.log for ATI Radeon 7200 connected to HP A4576A 21" CRT and git radeon driver

(In reply to comment #13)
> Can you attach your xorg log? I suspect your monitor doesn't have a mode in
> the edid for 1400x1050. The edid's preferred mode is probably 1280x1024@85,
> that's why it's getting set to that by default. you can manually add the
> 1400x1050 mode:
> xrandr --newmode <1400x1050 modeline>
> xrandr --addmode VGA-0 <1400x1050 mode name>

Ok, I will try that. I'm simply surprised that a section like

Section "Screen"
        Identifier "Screen0"
        Device "Videocard0"
        DefaultDepth 24
        SubSection "Display"
                Viewport 0 0
                Depth 24
                Modes "1400x1050"
        EndSubSection
EndSection

doesn't work anymore. All this EDID/xrandr magic is certainly great but when the user decides to overrule this autodetection stuff [following standard xorg.conf conventions], one would expect his choices to be honoured.

Concerning the crash backtrace when switching to a virtual console, I'm on a single node network, and the Xdbg script trick devised at the FDO pages doesn't seem to work here because the X server will not even start up, so it's impossible to switch to a virtual console in order to trigger the segmentation fault. The monitor simply powers off upon start of the X server. Any hint howto proceed any further? The Xdgb script is:

-----------------------------------------------------------------
#!/bin/sh

#GDB
#XSERVER

ARGS=$*
PID=$$

test -z "$GDB" && GDB=gdb
test -z "$XSERVER" && XSERVER=/usr/bin/Xorg

cat > /tmp/.dbgfile.$PID << HERE
file $XSERVER
set args $ARGS
handle SIGUSR1 nostop
handle SIGUSR2 nostop
handle SIGPIPE nostop
run
module
bt
cont
quit
HERE

$GDB -silent < /tmp/.dbgfile.$PID &> /tmp/gdb_log.$PID

rm -f /tmp/.dbgfile.$PID
echo "Log written to: /tmp/gdb_log.$PID"
-----------------------------------------------------------------

[James Troup (elmo)]

We have seen this on both a DL385 G2 and an ML370 with an ATI ES1000 with gutsy beta.

[Bryce Harrington (bryce)]

elmo, I've seen several reports and patches upstream about ES1000 issues, but it's not clear which matches this particular case. Can you attach the following to help narrow down which bug we're seeing?

 1. /var/log/Xorg.0.log and /var/log/gdm/\:0.log after a failure
 2. `lspci -nn`
 3. `sudo ddcprobe`

Also, if possible could you test booting the hardware with either a Feisty CD or an early Tribe CD (like Tribe 4 or before). If it turns out that it works in this case, then my best guess is that you're seeing this bug rather than what gian's seeing:

 https://bugs.freedesktop.org/show_bug.cgi?id=12490 - special case needed for single crtc chips with the -ati 6.7.x series, including 6.7.194.

I ruled out the following as either particular to unrelated hardware or having different symptoms, but am including them here for curiosity's sake:

https://bugs.freedesktop.org/show_bug.cgi?id=12543 - DMX stretching on Dell servers
https://bugs.freedesktop.org/show_bug.cgi?id=5766 - screen corruption at high resolutions
https://bugs.freedesktop.org/show_bug.cgi?id=11300 - Sun server KVM limits res to 1024x768

[agd5f (agd5f)]

I fixed some more issues tonight. let me know if the latest from ati git helps.

[Bryce Harrington (bryce)]

Here is a .deb of the patch posted for upstream bug 12490:
http://people.ubuntu.com/~bryce/Testing/ati-bug86072/

Note that while this fixed the immediate problem of x not starting up, the bug reporters were experiencing a number of additional problems, such as a freeze up when switching to ttys, and missing some higher resolutions. I don't know if these will affect us, but if they do, fixes are pending for them.

[agd5f (agd5f)]

(In reply to comment #18)

> Ok, I will try that. I'm simply surprised that a section like
>
> Section "Screen"
> Identifier "Screen0"
> Device "Videocard0"
> DefaultDepth 24
> SubSection "Display"
> Viewport 0 0
> Depth 24
> Modes "1400x1050"
> EndSubSection
> EndSection
>
> doesn't work anymore. All this EDID/xrandr magic is certainly great but when
> the user decides to overrule this autodetection stuff [following standard
> xorg.conf conventions], one would expect his choices to be honoured.

thus is the price of progress. In the randr world the xorg.conf changes a bit as the screen section no longer maps to a single monitor. While on a card like yours with a single crtc and output it's easy to wonder why the mode listed there doesn't get added, but consider a card with a local LVDS panel, a DVI port, a VGA port, and a TV out port. Which output should be mode get added to? all of them? what if your laptop panel only supports 1024x768? Also when you say 1400x1050 what mode exactly do you mean 1400x1050@60Hz? 1400x10505@85Hz? 72Hz? With randr you can assign hardcoded/overridden monitor sections to each output, e.g.,

Section "Device"
        Identifier "My Radeon"
        Driver "ati"
        Option "Monitor-VGA-0" "My Monitor"
EndSection

Section "Monitor"
        Identifier "My Monitor"
        ...
EndSection

within the monitor section you can specify new modelines you want to use as well as specify the orientation of the monitor in relation to the other monitors driven by the same card (in the case of dualhead cards). Unfortunately, I think there are still some issues to be worked out with this method in the xserver. See this page for more:
http://www.intellinuxgraphics.org/dualhead.html

[Joachim Frieben (jfrieben)]

(In reply to comment #19)
> I fixed some more issues tonight. let me know if the latest from ati git
> helps.

Most definitely: I have rebuilt 'the xorg-x11-drv-ati-6.7.194-2.fc8' driver package using a tar-ball produced from the current git tree, and now I'm actually able to switch between X and virtual consoles at will without crash. Great work!
The issue thus seems to be solved, I now have to get familiar with the new Xrandr stuff though ..

[agd5f (agd5f)]

(In reply to comment #21)

> Most definitely: I have rebuilt 'the xorg-x11-drv-ati-6.7.194-2.fc8' driver
> package using a tar-ball produced from the current git tree, and now I'm
> actually able to switch between X and virtual consoles at will without crash.
> Great work!

Excellent! I'll go ahead and close this bug then.

> The issue thus seems to be solved, I now have to get familiar with the new
> Xrandr stuff though ..

There may be some issues there as well. Let me know if you run into anything, I need to review that stuff better myself. I think the xserver may need some fixes.

[Nick Moffitt (nick-moffitt)]

I'm not entirely sure what all the interactions are here, but trying an amd64 build of the packages Bryce just posted does cause the video to come up (although with the gamma set very hot so that it looked massively overexposed on our freaky KVM), but for some reason the mouse input does not work any more (It did under vesa). Is this a known regression in that patch?

[Bryce Harrington (bryce)]

Hi Nick,

Thanks for testing the patch; since the video came up, that suggests we're on the right track, and that your issue is likely indeed to be fdo 12490.

It looks like overnight alex took care of the remaining issues people had reported, and the bug is now closed as fixed. If he puts out a new release soonish, we may be able to pull that into Gutsy, else we can try putting in via an update. I'm reluctant to put this single patch in, since it sounds like it's incomplete by itself due to the gamma issues you're reporting.

Offhand I'd think the mouse issues are coincidental; as far as I know, video driver code and input driver code is isolated. I would suspect KVM quirkiness before the driver. With my avocent kvm I've noticed the mouse gets lost in certain circumstances, requiring the kvm to be reset and sometimes the computer system to also be restarted. So my guess would be that it's an unrelated issue. However if you can determine it's definitely due to this driver, let me know so we can get that reported.

[James Troup (elmo)]

Bryce Harrington <email address hidden> writes:

> Offhand I'd think the mouse issues are coincidental; as far as I
> know, video driver code and input driver code is isolated. I would
> suspect KVM quirkiness before the driver. With my avocent kvm I've
> noticed the mouse gets lost in certain circumstances, requiring the
> kvm to be reset and sometimes the computer system to also be
> restarted. So my guess would be that it's an unrelated issue.
> However if you can determine it's definitely due to this driver, let
> me know so we can get that reported.

The KVM is driving 64 machines and the only time I've seen it lose the
mouse like this is with this patched package. I didn't believe it at
first either, until I saw/tested it myself.

If you can produce a package with all of Alex's patches, I'd be happy
/like to test it. Like I said on IRC, this video card is in all
modern HP server hardware and it worked on old releases (i.e. this is
a regression), so I think it'd be real shame to not fix this before
release.

--
James

[James Troup (elmo)]

James Troup <email address hidden> writes:

> If you can produce a package with all of Alex's patches, I'd be happy
> /like to test it. Like I said on IRC, this video card is in all
> modern HP server hardware and it worked on old releases (i.e. this is
> a regression), so I think it'd be real shame to not fix this before
> release.

(And by fix, I just mean get X working at all, if Alex's fixes are too
 invasive for this stage of the release and it mean we have to resort
 to falling back to vesa for these cards, that's also fine by me.)

--
James

[Tormod Volden (tormodvolden)]

> If you can produce a package with all of Alex's patches, I'd be happy/ like to test it.

All of Alex's patches are in the -tv6 version from https://wiki.ubuntu.com/XorgOnTheEdge

[Bryce Harrington (bryce)]

Here you go:

http://tormod.freeshell.org/linux/ati/xserver-xorg-video-ati_6.7.194-1ubuntu1tv6_i386.deb

Tormod's packages basically backport all the changes from git into our -ati package, so this should be pretty close to what's in the -ati git HEAD (and nothing else).

[Timo Aaltonen (tjaalton)]

Marking as "fix committed", since upstream commit 0ca184c3c35032df39ea7ce5d2d4aba1a97b6426 fixes this issue.

[Timo Aaltonen (tjaalton)]

xserver-xorg-video-ati (1:6.7.194-1ubuntu2) gutsy; urgency=low

  [ Timo Aaltonen ]
  * Add some patches from git master which fix a number of important
    bugs. Also add a new patch (10) which has not yet been merged
    upstream.

  [ Tormod Volden ]
  * debian/patches/02_mode_code_cleanup.diff:
    - Prerequisite for patch 03.
    "RADEON: more clean up of mode code"
    (fd.o commit 21593d04d222b05dbba9abd31eaa3bfb91d999b6)
  * debian/patches/03_LVDS_mode_validation.diff:
    - Prerequisite for patch 07.
    "RADEON: more work on LVDS mode validation and fixups"
    (fd.o commit 99ceaefa18c6e07b55106cca0ea8996fa73667be)
  * debian/patches/04_remove_cruft.diff
    - Removes two unused functions.
    "RADEON: remove cruft"
    (fd.o commit dcc376e2d2a13329dd03f1bc4b471329757a6f5f)
  * debian/patches/05_ext_tdms_table.diff
    - Prerequisite for patch 09.
    "RADEON: add support for ext tmds table and ext tmds chip init"
    (fd.o commit 22519fde1e002f28d6036d448fcd18452d00f1bb)
  * debian/patches/06_initdispbandwidth.diff:
    "RADEON: fix RADEONInitDispBandwidth() on single crtc cards"
    (LP: #86072, #144011)
    (fd.o commit 0ca184c3c35032df39ea7ce5d2d4aba1a97b6426)
  * debian/patches/07_sort_out_LVDS_modes.diff:
    - Prerequisite for patch 09.
    "RADEON: Finally sort out LVDS modes"
    (fd.o commit cc0c2d8e61600652b1f9cb3dc49db2ef62b1e40d)
  * debian/patches/08_disable_dri_rc410.diff:
    "rc410: disable DRI by default due to it not working"
    (LP: #144297)
    (fd.o commit d808781d48adf01e80b5bb476bae2d2f599030f1)
  * debian/patches/09_mode_and_output_fixes.diff:
    "RADEON: final fix for RMX/LVDS"
    (LP: #132716)
    (fd.o commit 597dffce9bdc200003d0be880235258386a0bdd7)
    "RADEON: minor fixes for external TMDS"
    (fd.o commit bfede412b3a3cd11769a580b167c528734146096)
    "RADEON: remove RADEONSaveMode()"
    (fd.o commit 5f5c4e6ad61c45c24f1443b91b4bc5375efdebc0)
    "RADEON: more fixes for single crtc chips"
    (fd.o commit b6bda79f72df5e5bf9c6b71fa3298e765da506bd)
    "RADEON: remove some cruft"
    (fd.o commit 3a958ba136c3fae5a4ddd56373ac7cd47046f10e)
  * debian/patches/10_disable_dri_rs485.diff
    - disable DRI on RS485 (the driver mistakenly lists it as RS482)
      (LP: #139241)

 -- Timo Aaltonen <email address hidden> Sat, 6 Oct 2007 01:52:08 +0300