[xorg] Re: [xorg] Intel 2.2.1 release planning

[Alan W. Irwin]

On 2007-12-26 12:10-0800 Alan W. Irwin wrote:

> Is there any additional news to report about this planned release, Jesse?
>
> I was very happy that the previous X lockup I got for 2.2.0 (for my ASUS
> P5K-V g33 chipset without ADD2 card) was solved by an earlier and also your
> latest patch attached to bug 13196. On one occasion for your earlier patch I
> did try switching to a console (with ctrl-ALT-F1 on KDE) which worked fine,
> but then when switching back to X, there were some strange X errors (certain
> KDE applications/windows froze) so I had to shutdown X (KDE logout) and
> start over with startx.  I have been unable to reproduce the problem just
> now with your latest patch, but even if the problem still existed I would
> settle for the result since it is such an improvement over 2.2.0 where X was
> completely inaccessible to me.

Hmm. Just discovered that there still is a problem with switching to console
and back.  It was fine for a while (long enough to write the above), but
then KDE became unreliable.  In particular, kicker froze so the logout icon
I have there quit working, I could not switch between desktops, etc.
Eventually, I logged out of KDE another way (using the logout icon
accessible from the right-click menu), but that didn't work cleanly so I had
to do a lot of kills of KDE commands and also the startx command by hand
afterwards.

Note, KDE is normally completely reliable for me.  For example, normally
when I logout that cleanly kills all KDE and X tasks.  I only run into the
above kind of trouble if I switch to console and back to X (just once is
required to show the problem, but it seems to take a few minutes after the
switch back to X for the trouble to develop).  Note, this is a production
box so I don't want to be restarting X a lot since it interrupts my own
work, but if you have one or two important tests you would like me to run to
help get to the bottom of the console/X switching trouble on my Intel
hardware, let me know.

> My own feeling is you should go ahead an release 2.2.1 so long as the vast
> majority of your testers find it is an improvement over 2.2.0 (as in my
> particular case) and it works on all the Intel chipsets personally available
> to you.  Of course, you wont get widespread testing until you make the
> release so I realize you are in something of a catch 22, but if there is
> some screwup with certain chipsets for 2.2.1 there is always 2.2.2 to fix
> it.  :-)

I will stick by this.  Obviously your fixes are less than perfect for my
particular hardware, but they are still much better than 2.2.0, and I can
avoid switching to the console and back to X (which I do rarely in any case)
until you get the fundamental switch problem sorted out.  Normally, I can
stay in X/KDE for a week without any signs of trouble except for the
well-known memory leak in the latest (Debian unstable) X which consumes
memory at the rate of roughly 2MB/hour or ~350MB/week.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________