[arch-general] Xorg 1.9 - This traing is going to hell.

[Gerhard Brauer]

On Thu, Sep 30, 2010 at 07:51:23PM +0400, Fess wrote:
> Well, i think, i should say some words.
> But some of you will say that i'm "out of line".
> So, i'll just dicribe details of the update.

I also have problems with XOrg 1.9 on my old Thinkpad T22 (savage
video chip). With the new version i could not switch between X and
tty consoles without a freeze of the system (only SysReq works). I
got small red lines on top of the screen if i switch from tty back
to X and then it freezes. No matter if i user framebuffer (vga=) or
not (savage driver don't uses KVM)
More badly was that also a resume from mem or disk suspend doesn't
work anymore, also a freeze.

Switching back to XOrg 1.8 (downgrade also the depended packages)
works fine again.
I think for myself this was the last XServer upgrade i will have
tried on this laptop.

[OT/Ranting on]
Last 1-2 years i'm realy getting more and more annoyed about the
quality of software developement on core things. I'm not saying this
is our/ArchLinux problem (ok, maybe 5% of bad packaging or similar).
IMHO the quality of upstream developers or developement processes are the
reason. I notice more and more "little" things with side-effects
which get broken from minor to minor upgrade, and i waste my time to
see which package may be the reason.
But every week <g> new "features" and concepts which will probably
break something on core/base functionality. Meanwhile mostly IMHO at
older hardware and often things which work fine in earlier software
versions. The problems related to XServer were so many last year(s),
since it becomes XOrg, i could not remember such behavior on the
"good old" xfree86 days. In the past one could say: If you have
older hardware and something works fine then this was "rock solid"
in the feature. But i have last 1,2 years (kernel and X related) so
many issues with tty/X switches, Fn-Keys which works and not, mouse
wheels and trackpoint failures, suspend/resume failures...

IMHO there are more and more "young developers", fresh from
university/school, who work on core things. Those have good ideas of
"features", they're hacking times faster than i could speak, but the
quality/stability of the core things is a pain. Ok, next developer.
His/her new ideas are primary, old failures won't got fixed (and
something other is broken). I'm not a developer, i have big respect
on all, but more and more things pisses me of on my linux
workstations the last years... (Maybe the reason for some things are
the compilers, too good on optimazing on "older" code... XOrg 1.9
savage driver is ~5k smaller than 1.8, maybe TTY/X switching was
optimized to /dev/null <g>)

- Kernel update on my T22 to 2.6.35 floods my log with drive not
ready/media errors of my swap partion (only the swap partition!)
New mkswap doesn't solve it. I'm too old to think that the surface
of my harddisk got broken the last 15min before the kernel upgrade.
So switched back to old kernel - same problem (swap is activated,
but log flood about media errors). Doing mkswap again under 2.6.33
(the last working version for others reasons), reboot anbd all is
fine again. Also a dd if=/dev/zero to the swap partition shows no
drive/media errors. But why on 2.6.35? WTF?

- 2.6.33 ist the last working version on which after a
suspend/resume my wireless device re-connects failure-less to a
access point(ath5k).

- 2.6.33, an older version of pm-utils and an older version of XOrg
was the last state where i could switch from X to tty (and back) and
when i could use the TTY's also after a resume. Before the above
mentioned new problems with XOrg 1.9 the switch to TTY was still
broken after suspend/resume.

- Fn-Keys for Suspend or toggle of X-backlight are broken since
weeks. I have to test every time new features bitmap of
thinkpad-acpi module on different kernel/pm-utils versions to enable
them working again...

- Since ~2.6.28 the bandwith of my ethernet device(e100) is reduced to 10%
of the maximum. Only if i use nohz=off as kernel param or if i
produce cpu load (100%) my bandwith goes up again. Last month i
found the "reason": it happens only if i have the speedstep-smi module
loaded! With ee100pro module i never have had such thing, also an
earlier 2.6.28 patchlevel works fine IIR... This is such an
interesting bug so i think i will report it to LKML...

These are some of the core things (for me, i don't care if my mpd is
broken) that makes me angry... ;-)
[OT/Ranting off]

Regards
        Gerhard (still alive)