Hey,

just wanted to let you know, that i am not yet happy with it. My
apologies for burdening this list, with this awesome unrelated bug. I
understand everybody not willing to dig into this mess. :)

Am Thu, 06 Jun 2013 13:27:35 +0200
schrieb Uli Schlachter <[email protected]>:

> Hi,
> 
> On 06.06.2013 04:25, kardan wrote:
> [...]
> > and have some strange effects. when a window is redrawn. for ~some
> > moments it looks like switching display in framebuffer mode.
> > for xterm this becomes static when the window is maximized und
> > demaximized again. Half of the screen shows vertical yellow stripes.
> > They disappear when I swtich the workspace or drag the window
> > around.
>
> In X11, a window manager just manages windows. This means that it
> only places windows and is not involved in drawing windows. At most,
> it could try forcing a window to redraw itself.
> 
> You could try starting awesome with --no-argb. If this makes the bug
> disappear, then this is definitely a bug in your video driver. If the
> bug stays, I still can only imagine this being a video driver bug.
> Sorry.

The described effect completely disappaered.
 
> > Also awesome behaved way more lazily than before the upgrade.
> > Switching between workspaces and back needs around 1sec to redraw
> > the window. There was something regarding this delay on the list
> > but I am not using no dmenu as well.
> 
> Option 1 here is again: Try starting awesome with --no-argb. If this
> makes the bug disappear, your video driver is being awfully slow with
> ARGB visuals. Option 2 here is that more stuff is done in lua now and
> this lua code is a little slower than the old C code. However, this
> should only matter for drawing the wibox and thus does not matter
> much on tag switch...

The good news is, the described delay on workspace switches has gone.
The bad news is, Xorg consumes 100% of my already sparse cpu time and
the cursor freezes periodically. Only switching to tty and back restores
the display.

> > This is not recent hardware (ibm T23), but it worked smooth so far.
> > 01:00.0 VGA compatible controller [0300]: S3 Inc. SuperSavage IX/C
> > SDR [5333:8c2e] (rev 05)
> 
> Wow.

Well, this time i am not on the winner side. To make a long story
short: DRI is deprecated for savage and has been bemoved.

  (EE) [drm] Could not set DRM device bus ID.
  (EE) SAVAGE(0): [drm] DRIScreenInit failed.  Disabling DRI.
  (EE) SAVAGE(0): DRI isn't enabled
  (EE) AIGLX error: dlopen of /usr/lib/i386-linux-gnu/dri/savage_dri.so
failed (/usr/lib/i386-linux-gnu/dri/savage_dri.so: cannot open shared
object file: No such file or directory)

# export MESA_DEBUG=verbose
# export LIBGL_DEBUG=verbose
# glxinfo
direct rendering: Yes
OpenGL renderer string: Gallium 0.4 on softpipe
    GL_NV_conditional_render, GL_AMD_conservative_depth,
libGL error: dlopen ${ORIGIN}/dri/savage_dri.so failed
(${ORIGIN}/dri/savage_dri.so: cannot open shared object file: No such
file or directory)

# glxgears
50 frames in 5.0 seconds =  9.973 FPS

That is not awesome.

It has been said [1], that libgl1-mesa-dri has savage_dri.so but it was
dropped in 8.0.1 [2] as beeing declared deprecated by upstream [3]
(e4344161bd) in Aug 2011.[4]
[1] https://systemausfall.org/wikis/howto/Debian_on_IBM_T23#DRI
[2]
http://ftp-master.metadata.debian.org/changelogs//main/m/mesa/mesa_8.0.5-4_changelog
[3] http://mesa3d.sourceforge.net/systems.html
[4]
http://cgit.freedesktop.org/mesa/mesa/commit/?id=e4344161bde2e24fcfba65d30d58f087bd8bf94d

Maybe you have some fun with my Xorg.1.log. There is
definitively something strange going on: 
http://paste.debian.net/9619

[424121.912] [mi] EQ overflowing.  Additional events will be discarded
until existing events are processed.
[424121.912] Backtrace:
[424121.913] 0: X (xorg_backtrace+0x49) [0xb7761769]
[424121.913] 1: X (mieqEnqueue+0x22b) [0xb774005b]
[424121.914] 2: X (0xb75e4000+0x51405) [0xb7635405]
[424121.914] 3: X (xf86PostMotionEventM+0x24b) [0xb766f56b]
[424121.914] 4: /usr/lib/xorg/modules/input/evdev_drv.so (0xb6dec000+0x35ad) 
[0xb6def5ad]
[424121.914] 5: /usr/lib/xorg/modules/input/evdev_drv.so (0xb6dec000+0x4a2c) 
[0xb6df0a2c]
[424121.915] 6: X (0xb75e4000+0x7ac01) [0xb765ec01]
[424121.915] 7: X (0xb75e4000+0xa094a) [0xb768494a]
[424121.915] 8: (vdso) (__kernel_sigreturn+0x0) [0xb75c5400]
[424121.915] 9: /usr/lib/xorg/modules/drivers/savage_drv.so (0xb7021000+0xa119) 
[0xb702b119]
[424121.916] 10: /usr/lib/xorg/modules/drivers/savage_drv.so 
(0xb7021000+0x5ac6) [0xb7026ac6]
[424121.916] 11: /usr/lib/xorg/modules/libxaa.so (0xb6e42000+0x8bd6) 
[0xb6e4abd6]
[424121.916] 12: /usr/lib/xorg/modules/libxaa.so (0xb6e42000+0x558e3) 
[0xb6e978e3]
[424121.916] 13: X (0xb75e4000+0x10757b) [0xb76eb57b]
[424121.917] 14: X (0xb75e4000+0xf6a98) [0xb76daa98]
[424121.917] 15: X (miCompositeRects+0x99) [0xb76dabb9]
[424121.917] 16: /usr/lib/xorg/modules/libxaa.so (0xb6e42000+0x56377) 
[0xb6e98377]
[424121.917] 17: X (CompositeRects+0x78) [0xb76de708]
[424121.918] 18: X (0xb75e4000+0xfee81) [0xb76e2e81]
[424121.918] 19: X (0xb75e4000+0xfacae) [0xb76decae]
[424121.918] 20: X (0xb75e4000+0x3c375) [0xb7620375]
[424121.918] 21: X (0xb75e4000+0x29e95) [0xb760de95]
[424121.919] 22: /lib/i386-linux-gnu/i686/cmov/libc.so.6 
(__libc_start_main+0xe6) [0xb7279e46]
[424121.919] 23: X (0xb75e4000+0x2a1e9) [0xb760e1e9]

This repeats several times up to 1024 including some traces ..
[424121.919] [mi] These backtraces from mieqEnqueue may point to a
culprit higher up the stack.
[424121.928] [mi] mieq is *NOT* the cause.  It is a victim.
[424122.376] [mi] EQ overflow continuing.  100 events have been dropped.
[424125.795] [mi] Increasing EQ size to 512 to prevent dropped events.
[424125.797] [mi] EQ processing has resumed after 613 dropped events.
[424125.798] [mi] This may be caused my a misbehaving driver
monopolizing the server's resources.

Finally the machine hung up, kern.log last noted
  [426638.968872] input: Logitech USB Optical Mouse
as /devices/pci0000:00/0000:00:1d.1/usb2/2-1/2-1:1.0/input/input19
which is unlikely the reason for anything. 

After reboot I tried to gdb attach the started X which froze the system
repeatedly. Will try
[ 1852.448436] agpgart-intel 0000:00:00.0: AGP 2.0 bridge
[ 1852.448478] agpgart-intel 0000:00:00.0: putting AGP V2 device into 1x mode
[ 1852.448523] pci 0000:01:00.0: putting AGP V2 device into 1x mode
[ 1859.941798] mtrr: no MTRR for e8000000,1000000 found
[ 1861.074676] mtrr: base(0xe4000000) is not aligned on a size(0x5000000) 
boundary
[ 1861.074962] mtrr: base(0xe4000000) is not aligned on a size(0x5000000) 
boundary
[ 1861.075192] mtrr: base(0xe4000000) is not aligned on a size(0x5000000) 
boundary
This sequence appears multiple times and finally freezes with
  mtrr: no MTRR for e8000000,1000000 found

> screen going blank on boot, with keyboard lockup
http://www.linuxforums.org/forum/ubuntu-linux/138490-ubuntu-8-10-screen-going-blank-boot-keyboard-lockup.html
This linux guru proposed nailing xserver-xorg-video-savage to
  2.2.1-2. Current is 2.3.4-1. I really don't like that idea for
  several reasons.

ii  xserver-xorg-video-savage            1:2.3.4-1
ii  libgl1-mesa-dri:i386                 8.0.5-4+deb7u2

Options:
* file a bug upstream https://bugs.freedesktop.org/ while probably
  nobody cares
* add a wishlist bug for DRI xserver-xorg-video-savage /
  libgl1-mesa-dri, which is also quite unlikely to be fixed.
* install mesa 0.8.1 from source and be happy with some xserver XP
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483989

Any suggesetions? I don't think, spending more time to collect info on
this is fertile. Maybe its time to pester [email protected].

< http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500281 (not mine)
> > Things are veeeryyyy slooooowwww, indeed!
> > It seems that the long-awaited xorg migration to testing caused my
> > already slow video chipset to become even slower with OpenGL
> > applications...   :-(
> Adding a WC MTRR manually might help. But you may have to boot with
> "nopat" on the kernel command-line first since the WC MTRR is ignored
> if the kernel sets UC- with PAT IIRC.
>
> /proc/mtrr lists some physical address ranges that are marked as
> write-combining (WC). It's possible to add new ranges writing in
> /proc/mtrr manually.
> If you don't know anything about all this, you should not try since
> doing something wrong may freeze the machine.
> 
> Brice

< http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528311 (DRI)
> > So the problem only happens in a second X server? That's expected,
> > only one X server can enable the DRI traditionally. Current Linux
> > kernels have support for multiple X servers with DRI enabled, but
> > the X driver needs to be modified to support it as well.
> > Looking closer at the X log file, apparently DRI initialization
> > works the first time but fails afterwards. So maybe the savage
> > driver doesn't properly de-initialize the DRI on a server reset.
> > Does the problem go away after restarting the X server? (If you're
> > using a display manager, just logging out and back in may not be
> > enough)
> 
> Actually it looks like it's working the first time somethings uses
> DRI, but then fails afterwards:

What also happens periodically is without any meaning to me:
[426637.302] (II) config/udev: removing device Logitech USB Optical Mouse
[426637.303] (II) evdev: Logitech USB Optical Mouse: Close
[426637.303] (II) UnloadModule: "evdev"
[426639.015] (II) config/udev: Adding input device Logitech USB Optical Mouse 
(/dev/input/mouse0)
[426639.015] (II) No input driver specified, ignoring this device.
[426639.015] (II) This device may have been added with another device file.
[426639.022] (II) config/udev: Adding input device Logitech USB Optical Mouse 
(/dev/input/event1)
[426639.022] (**) Logitech USB Optical Mouse: Applying InputClass "evdev 
pointer catchall"
[426639.022] (II) Using input driver 'evdev' for 'Logitech USB Optical Mouse'

Looking at this deeper would fill another pot, but there is a frequency
[425952.594] (--) SAVAGE(0): Chose mode 117 at 60Hz.
[426033.628] (II) Open ACPI successful (/var/run/acpid.socket)
[426033.629] (--) SAVAGE(0): Chose mode 117 at 60Hz.
[426112.039] (II) config/udev: removing device Logitech USB Optical
Mouse --
[426478.273] (--) SAVAGE(0): Chose mode 117 at 60Hz.
[426558.833] (II) Open ACPI successful (/var/run/acpid.socket)
[426558.833] (--) SAVAGE(0): Chose mode 117 at 60Hz.
[426637.302] (II) config/udev: removing device Logitech USB Optical
Mouse

Kardan

-- 
To unsubscribe, send mail to [email protected].

Reply via email to