[M6-LY] System freeze with DefaultDepth 16

After I change from ubuntulooks to clearlooks, it seems okay.

Regarding the steps to replicate the bug, the correct steps are:
a) run pan
b) update a newsgroup
c) quickly open task manager, stop the update task (using the stop icon)
d) click on the "trash" icon
e) system is frozen, e.g. mouse not moving, even ctrl-alt-f1 does not work

wrong button click

The "wrong button click" comment above refers to my error in adding "ubuntu" to "affects", i only wanted to add "ubuntulooks"

Needs debugging trace and/or terminal output.

ed-ong,

Thanks for reporting your program crash. Unfortunately, your bug report needs some more info for someone to act on it.

Please follow the instructions on this page: https://wiki.ubuntu.com/DebuggingSystemCrash to help you debug the crash. If that doesn't help, or if you have any further questions, please post a comment.

If you're successful in obtaining a debug trace of the crash, please add it to this report as an attachment.

Thank you,

Tarik

I am not able to collect any information, it seems to be a hard freeze.
However, I have changed to "vesa" instead of "ati" driver in xorg.conf and that seems to clear up the problem.

I will update the main description.

The radeon mobility M6 is extremely unstable -- especially if using its opengl capability.

Please comment if someone has got that chip working with opengl.

ed-ong,

When you switched to "vesa" did you also try to use ubuntulooks again and repeat the procedure that caused the crash? If you have not, can please try that?

Thank you,

Tarik

I am using ubuntulooks with "vesa", and it is stable. No crashes for 3 days now.

Separately, my problems with "ati" does not seem 3D related, I have tried disabling "dri" and "glx" modules and it still crashes.

I cannot reproduce the issue reported in the original bug report post regarding gtk2-engines-ubuntulooks and pan under Dapper. I'm using the i810 driver. It would be proper to reassign this issue to the ati driver, xserver-xorg-driver-ati.

I had a few hours today, so I tried installing older drivers, and found that it is ok in ati_6.5.7.3-0ubuntu2, and the issue starts occuring in ati_6.5.7.3-0ubuntu3.

An a more technical note, I saw that 6.5.7.3-0ubuntu3 had some fix in radeon_accel.c in regards to some random bogus DMA issue, so i recompiled it without the fix (e.g using the radeon_accel.c from 6.5.7.3-0ubuntu2). With that compile, the crash occurs ImmediatelY upon hitting the trash icon.
Please note, I am NoT claiming the bugs are the same, but hopefully they are somewhat related and can help narrow down the issue.

A got this bug, but not on specific task. Just using any programa (OpenOffice, Gaim, Firefox) i can run no more them 10 minutes after that my gnome go crazy and freeze.

I am using 6.06 on a COMPAQ PRESARIO 2500, chipset ATI IGP 345M.

Can anyone confirm whether the situation has improved with this new version:

xserver-xorg-driver-ati (1:6.5.7.3-0ubuntu7) dapper; urgency=low

  * Update from the ati-1.0-stable branch that makes this driver
    exactly the same as 6.5.8 from upstream.

 -- Fabio M. Di Nitto <email address hidden> Mon, 01 May 2006 06:39:47 +0200

Still freezing for me.

Btw, if dont get a freeze when clicking on the trash icon, I just need to resize the pan "task manager" window a few times to induce the freeze.

With driver "vesa" it work's fine, but until may/2, still doesn't work
with either "radeon" or "ati".

Rivaldo

 Matt Zimmerman escreveu:
> Can anyone confirm whether the situation has improved with this new version:
>
> xserver-xorg-driver-ati (1:6.5.7.3-0ubuntu7) dapper; urgency=low
>
> * Update from the ati-1.0-stable branch that makes this driver
> exactly the same as 6.5.8 from upstream.
>
> -- Fabio M. Di Nitto <email address hidden> Mon, 01 May 2006 06:39:47 +0200
>
>

I have this bug too. I have a Sony Vaio Z1 with a 16MB ATI Radeon M6 LY chipset. The current ATI driver produces artifacts on some of the buttons in various apps, mainly Evolution, Pan and J-Pilot (J-Pilot is the most severe). Running the display at 24 bit results in feezes which can only be cured with a hard reset. I originally reported this as an evolution fault, but it is obviously an ATI driver issue. After dropping the colour depth, the artifacts remain, but the system has not frozen once.

Adam

I have both a 16MB ATI M6 LY (Vaio Z1) and an 8MB M6 LY (Compaq Evo) -- both which cause hard locks with the default xorg.conf file as of 18/06/2006 and have done for some time (Flight 2 was the last release which didn't cause it) regardless if I use the 'ati' or 'radeon' driver.

Paul, I'm not sure what is causing it. I have a Vaio Z1 too. I have
stopped the hard locks by dropping the colour depth to 16bit. There are
still artifacts on a lot of the mouse over buttons, in several
applications, so it is most likely an xorg problem. Anyway, the locks
will disappear if you drop the colour depth.

Cheers,
Adam

On Thu, 2006-05-18 at 05:26 +0000, Paul Drain wrote:

> I have both a 16MB ATI M6 LY (Vaio Z1) and an 8MB M6 LY (Compaq Evo) --
> both which cause hard locks with the default xorg.conf file as of
> 18/06/2006 and have done for some time (Flight 2 was the last release
> which didn't cause it) regardless if I use the 'ati' or 'radeon' driver.
>

Adam,

Thanks for the information. Dropping the color depth to 16 does indeed fix the hard locks on both systems, suspend-to-whatever, the screensaver, OOo and firefox can all run without hanging the system now.

First time i've been able to use my machine for more than a few hours without a hardlock in months.

As for the artifacts, I have no idea why, but after adding:

Option "AGPMode" "2"

To the Device section of my xorg.conf file (found on one of the numerous 'how to get performance out of your ATI card sites' out there) -- everything seems to work normally.

Hi Paul,

Glad your system has become more stable. I tried adding the AGPmode
switch into my conf file, but no good. I still have artefacts on some of
the buttons. (Currently in evolution the +0, Normal and justify left
buttons have different coloured pixels on them. If I fly the mouse over
them, they clear up.)

I wish I new how to write drivers, because this is one issue which is
driving me insane. The system was fine under Breezy, albeit without 3D,
which I still don't have. All I can do is sit back and hope these gun
programmers can suss it out.

Cheers,

Adam

On Fri, 2006-05-19 at 01:57 +0000, Paul Drain wrote:

> Adam,
>
> Thanks for the information. Dropping the color depth to 16 does indeed
> fix the hard locks on both systems, suspend-to-whatever, the
> screensaver, OOo and firefox can all run without hanging the system now.
>
> First time i've been able to use my machine for more than a few hours
> without a hardlock in months.
>
> As for the artifacts, I have no idea why, but after adding:
>
> Option "AGPMode" "2"
>
> To the Device section of my xorg.conf file (found on one of the numerous
> 'how to get performance out of your ATI card sites' out there) --
> everything seems to work normally.
>

Hi Adam,

Well, it lasted *longer* -- but last night the VAIO box just crashed with a hard lock after launching a 3D app, then switching to a console and back again.

Not really into 3D myself, so I ammended the Module section of my xorg.conf to comment out:

# Load "glx"

(On my Compaq, i've also commented out the "i2c" module, because my Xorg.0.log file kept complaining about it not being useful)

Which seems to disable direct rendering altogether -- hopefully fixing the lockup

I'm watching into the same problem for a Dell C610 laptop with a 16MB Radeon Mobility M6 LY. I have had a crash since upgrading to Dapper yesterday, and artifacts in the buttons (mostly vertical or horizontal dashed lines at regular intervals). The artifacts appear consistently on the "Help" and "Close" buttons of the update-manager, or in the "Help", "Cancel" and "OK" of the network-admin. Moving the mouse over the buttons redisplays them correctly.

The system worked previously with no problems in Breezy before the upgrade. After the crash no traces of it are left at the system logs, or Xorg log. No response to SysRq either.

I seem to have no glx problems (gl screensavers work fine). I lowered my display depth to 16bpp to see if it helps with the crashes. However, the "AGPMode" setting didn't help solving the artifacts.

I've been having the same problem as well ever since the Beta came out. The system locks up and it won't do anything. The AGPMode comment that was left got me thinking and I did some poking around.

I've got a Compaq Evo N600c with 512 Megs of RAM. That card is an ATI Radeon Molbity M6 LY. The lsmod command comes up with the following two modules (among others):

intel_agp 24700 1
agpgart 36784 1 intel_agp

I checked with the dmesg command and it produced the following three lines:

[4294698.307000] Linux agpgart interface v0.101 (c) Dave Jones
[4294698.314000] agpgart: Detected an Intel 830M Chipset.
[4294698.329000] agpgart: AGP aperture is 256M @ 0x60000000

Now I know in the previous version of Ubuntu, my card used the radeon module. I believe there is also an ati-agp module. Are these on-board chips getting detected incorrectly?

I went back to my system and deleted (moved actually) the intel_agp.ko file from

   /lib/modules/2.6.15-23-686/kernel/drivers/char/agp

I also added "radeon" to /etc/modules

So far I've had no additional problems with the radeon driver.

Adam R.

"Possible fix" should be "Possible Workaround" and I forgot to add that I rebooted afterwards. I've now been running in Dual Head mode with s 1024x768x16 screen and a 1280x1024x16 screen without any problems for over an hour now. I've tried MPlayer, Firefox, Firefox + Flash 7.0 r63, Firefox + MPlayer Plugin, a couple 3D Screen Savers, and so far no problems whatsoever.

FYI, I've included my xorg.conf below. This is a lightly modified version from the one that was generated during the install to run a dual head configuration. Primary screen is the laptop and secondary is the monitor.

# /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"
 # 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" "pc104"
 Option "XkbLayout" "us"
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"
 Identifier "Synaptics Touchpad"
 Driver "synaptics"
 Option "SendCoreEvents" "true"
 Option "Device" "/dev/psaux"
 Option "Protocol" "auto-dev"
 Option "HorizScrollDelta" "0"
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
                                                      # /dev/input/event
                                                 ...

I'm getting the hardlock to manifest itself when using supertux, even with --sdl option. Typically, I get a hard lock after 1-3 starts of supertux. Previously this laptop was running FC5 and we never saw the hardlock issue.

I have not implemented any of the workarounds in this thread yet, but I did try Paul's unofficial deb, and still got the hard lock.

dan

And just when I though everything was going so well for me...

After the last kernel update to 2.6.15-25-686, I had another hardlock while running Firefox., and this is after I went and removed intel-agp.ko from the available modules. Same symptoms as before, no networking, no way to escape to the console.

So system was

Ubuntu 6.06 LTS
linux-2.6.15-25-686-image 2.6.15-25.43
Xserver-xorg 7.0.0-0ubuntu45
Firefox 1.5.dfsg+1.5.0.4-0ubuntu6.06
Plugins include:
              Shockwave Flash 7.0 r63
              Mplayer + w32codecs

I had moved the intel-agp.ko module from
    /lib/modules/2.6.15-25-686/kernel/drivers/char/agp/
and ran depmod to update module dependencies.

Force loaded the radeon module using /etc/modules
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
radeon
lp
psmouse

My xorg.conf file was configured to use Xinerama (DRI/DRM was loaded, but supposedly ignored) and provide two screens: LVDMS @ 1024X768X16 and CRT @ 1280X1024X16:
# /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"
 # path to defoma fonts
 FontPath "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType"
EndSection

Section "Module"
 Load "i2c"
 Load "bitmap"
 Load "ddc"
 Load "dde"
 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" "pc104"
 Option "XkbLayout" "us"
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"
 Identifier "Synaptics Touchpad"
 Driver "synaptics"
 Option "SendCoreEvents" "true"
 Option "Device" "/dev/psaux"
 Option "Protocol" "auto-dev"
 Option "HorizScrollDelta" "0"
EndSection

Section "Device"
 Identifier "Radeon0...

I can confirm the above problem: I use a Vaio Z1 with ATI Radeon Mobility M6 LY running Dapper with all updates.
There are regular complete lockups where only reboot is possible. When I change from the ati to the vesa driver the system becomes perfectly stable.

When switching to 'vesa' driver, supertux still displayed as a garbled mix of diagonal lines, but there was no hard freeze. Switching back to 'ati' and setting default depth to 16 *seems* to have alleviated the problem, although this is obviously not an optimal solution.

If anyone is still affected by this problem, i've put up a replacement package for xorg and a replacement kernel package for x86 platforms.

With them installed, i've had no lockups for the entire week (either on my Compaq or the VAIO, both of which exhibited the problem).

Currently [*], these are at:

http://64.71.152.24/

(* because the main FTP server is constantly full and may time-out)

Currently running the patch created by Paul. Great that someone has taken this problem seriously. All working well now, machine has been running over the last two days. Hibernate, suspend also fine. Now all I need to get sorted is 3D support ;)

Screen res 1400 x 1050
Colour depth 24 bit

Good job Paul.

What would be really useful is a description of what is different in Paul's packages from the stock Ubuntu ones. Without that bit of information, you folks will have to keep using his deb's.

I had some hard locks on my Thinpad T30's ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500]. I resolved it by adding
        Option "SWcursor" "on"
        Option "AGPMode" "1"
        Option "RenderAccel" "0"
to my /etc/X11/xorg.conf

I haven't scientifically tested to find out which option is the critical one.

If I were a betting man, i'd say RenderAccel would be the one that would be the most likely of the three, a Xorg.log file comparason between one with RenderAccel on and off would be interesting though.

Paul,

re:http://64.71.152.24/

Way to violate the GPL. I'll pay you the 5 Australian dollars when you give the same amount to every developer who contributed to your linux system.

Paul: distributing a modified kernel binary and then charging for source access is a violation of the GPL. From the GPL FAQ:

  Does the GPL allow me to charge a fee for downloading the program from my site?
    Yes. You can charge any fee you wish for distributing a copy of the program. If you distribute binaries by download, you must provide "equivalent access" to download the source--therefore, the fee to download source may not be greater than the fee to download the binary.
    (http://www.gnu.org/licenses/gpl-faq.html#DoesTheGPLAllowDownloadFee)

The X.Org license does not have this restriction, so I believe that charging separately for access to the modified ATI driver source is your right.

Here's the diff of /var/log/Xorg.0.log. The "old" version has RenderAccel=0 set, the "new" version has RenderAccel=0 commented out.

diff -u Xorg.0.log.SWcursor-on.AGPMode-1.RenderAccel-0 Xorg.0.log.SWcursor-on.AGPMode-1 > xorg.diff

Just had my first X lockup in a long time, so it appears that renderaccel=0 is the solution for me. I've now commented out SWCursor and AGPMode and reenabled RenderAccel=0 for the time being.

I have been running Paul's patch, but eventually the system froze. I'm not sure if this was an update to xorg or not. reneraccel makes no diff here, I still get hard locks if I set the depth above 16bit. This is a real killer of a bug, and given the amount of these ATi chips out there, I was hoping it wouldn't have taken so long to sort out.
I here rumours of people managing to get 3D acceleration out of their machines under Linux, but I have never seen it, and cannot replicate their success on my machine.
I'm at my wits end with this bug, and it is disappointing that for Ubuntu this is of low priority. Given that the driver worked fine in Breezy (still no 3D), there must be a way to find out what changed?
If I can help with testing on my machine, then great, send me the files. If you want logs, forget it, the system freezes and there is nothing to give.

Cheers,

Adam

We seem to have a +1/-1 on whether the alternate deb works.

Paul Drain: do you have the (source) patch that people have been testing?

Can people check whether this is still occuring in edgy with the newer Xorg?

Thanks for the advice Michael. I will give this a go. The issue is, I
HAVE TO use 16bit. If I could use 24, then I'd be much happier. I only
wish I knew more about this APGart memory thingy, because I am positive
that this is where everything is going wrong.

Cheers,

Adam

On Tue, 2006-11-07 at 07:48 +0000, Michael R. Head wrote:

> Bug 14911 talks about the firefox issue. Long story short, if you want to use 16bit mode for 3D, just put
> export XLIB_SKIP_ARGB_VISUALS=1
> in /etc/firefox/firefoxrc, and flash won't crash anymore.
>

Hi ed-ong. Could you check if you experience the original problem, without special X.org options, in Ubuntu 6.10?

Hi Timo. Without the special options, on the default install, it works good.

However, if I change the DefaultDepth to 16 , i can get the problem.
(On the default install, the DefaultDepth is 24)

ed-ong, have you tested Feisty? Do you still have trouble with DefaultDepth 16?

The crash still occurs on DefaultDepth 16.

Now I think it actually has to do with DRI, I commented out the Module "dri" and "glx" and I was not able to crash the software.

The difference with Depth 24 is that, at depth 24, the dri module is not loaded because of insufficient memory.

Can you please attach the Xorg.0.log from a crash (running with DRI on depth 16)?

Is anyone still having this problem on more recent versions of Ubuntu? Could someone please test it against the Gutsy Live CD? You can download an ISO of one of the recent tribe Live CD's here: http://cdimage.ubuntu.com/releases/gutsy/

I haven't experienced this problem since the release of Edgy (I think), and certainly not since Feisty came out. Gutsy runs fine, too.

I am still able to get a system freeze at defaultDepth 16. At depth 16 DRI is on (at depth 24 there is not enough memory for DRI).
I can then freeze the system by running glxgears, and moving the window around.

Having said that, I myself do NOT have any requirements for defaultDepth 16 or DRI (just wanted to try some of the desktop effects).
I would not object if defaultDepth 16 is not supported for an 8Megabyte M6.

I have included Xorg.0.log for reference,

with the recent update in gutsy to 195 the ati driver stopped working for me period, 194 would freeze X occasionally, but with 195 i simply get a grey screen that is flickering. Disabling DRI and GLX didnt fix the problem. The hardware works with the vesa driver. the settings are 1024x768 at 24 bit, with enough mem to handle the resolution

rexy: please see bug 150278, there is a proposed fix available soon.

Oh crap! Here we go again. Is this dejevu or what? I have just refused to install the update just in case. Has anyone else installed the update successfully? This is not what I was expecting after all this time. I will give it a go if people who were affected by the problem last time can assure me that we are not repeating history.

Cheers,

Adam

Adam: rexy's recent problem had nothing to do with this bug. If you upgrade and notice any problems, please file a new bug or check the list of open bugs and follow up if you find a match.

No you're right, it isn't the same problem at all. Instead I have two
bands running down the screen, one at centre and one at the right. So
yes, the driver has changed something, and not for the better. I will
file a new report. I will downgrade the package in the meantime.

Adam

On Mon, 2007-10-08 at 09:09 +0000, Timo Aaltonen wrote:

> Adam: rexy's recent problem had nothing to do with this bug. If you
> upgrade and notice any problems, please file a new bug or check the list
> of open bugs and follow up if you find a match.
>

ed-ong: Please try Hardy alpha6 if you can still make it hang with 16bit depth.

It still hangs, i'm afraid.

Thanks for taking the time to report this bug and helping to make Ubuntu better. In the development cycle for Intrepid there have been some vast improvements in the open source ati video driver and we could use your help testing them. Could you please download the latest Alpha CD image of Intrepid and test this particular bug just using the Live CD? You can find the latest image at http://www.ubuntu.com/testing . Your testing can help make Ubuntu and the open source ati driver even better! Thanks in advance.

ed-ong, given that your problem occurs with DRI enabled, perhaps your AGPMode setting is incorrect. Can you try setting:

Section "Device"
   ...
   Option "AGPMode" "2"
EndSection

Also try values 1, 4, and 8 (4 is typically the default). If one of those settings fix it, we may be able to quirk your hardware to use that value instead of the default. In this case please provide the following info so we can quirk it:

  * AGPMode value needed
  * Make/Model of laptop or motherboard
  * Output of lspci -vvnn
  * Is the system all factory hardware, or have any parts been replaced?
  * Is there an AGP Mode in the system BIOS?
    - If so, is it set to the factory default?

No luck, it still crashes with the new drivers. I have tried using AGPMode 1,2,4 (mode 8 is unavailable on this machine).
I tested with module version 6.9.0

Hi ed-ong,

Thanks for testing that, it rules out a common cause of these problems. Sorry to have you keep testing stuff over and over. :-) I think this bug should have gone upstream long ago. I'd like to do so now, but the first thing is that they will wish you to re-test against a newer version of the -ati driver.

I've uploaded the latest 6.11.0 driver to Jaunty the other day. When Alpha-5 comes out in a couple days, I would like to ask that you download and re-test it one more time. If you can reproduce the problem then we should forward it upstream.

ISOs are available at http://cdimages.ubuntu.com/releases/jaunty/

I dug into the changelog and see that there has been a fix to your chipset since the 6.9.0 release:

Date: Fri Aug 8 15:50:07 2008 -0400

    Fix VT switching on M6 chips

    Some M6 chips have a faulty MEM_SIZE register that in
    some cases reports 0 on 8 MB cards. On EnterVT we check
    the MEM_SIZE reg as a check to see if the card is posted or
    not. Since this reg returns 0, the driver attempts to post
    the card which can lead to a hang. Switch this to check if
    either crtc is active as is done in the bios init code.
    fixes bug http://bugs.freedesktop.org/show_bug.cgi?id=13994

However, the symptoms of this bug differ from what is reported here so I'm not entirely sure this fix would solve this freeze issue. But I think it would be helpful if you could re-test jaunty before we upstream the bug.

In addition, can you run the command `lspci -vvnn > lspci-vvnn.txt` and attach that output here?

Bryce, that fix (268c848130ec1770bb645a74197b6aca7fc95abc) got into Intrepid, see bug #148408.

Ah right. So testing either Intrepid or Jaunty would verify that fix.

I'd still like to see this re-tested against Jaunty in any case, since upstream will want to know if this issue still exists in their 6.11.0 release before working on it.

[Setting to incomplete pending test results for jaunty]

It still crashes while running glxgears with DRI enabled at 16 bit color depth.
I have attached xorg.0.log and lspci output.
I am running a Compaq Evo N160 notebook (manufacture 2001).

Hi ed-ong,

I've forwarded your bug upstream to https://bugs.freedesktop.org/show_bug.cgi?id=20477 - please subscribe to this bug in case upstream needs more information or wishes you to test something. Thanks ahead of time!

Hi ed,

Upstream suggests trying to force it to pci mode:

Option "BusType" "PCI"

Mind giving that a shot?

Sweet. The "bustype" "PCI" option works.
Thanks for all your effort, Bryce.

Okay, so this needs a quirk or something for forcing PCI I guess...

Thank you for your bug report. This bug has been reported to the developers of the software. You can track it and make comments at:

Hmm. Ed, it appears that upstream feels this was a kernel bug that has long since been solved, although the trail through the upstream reports is a bit tangled. Would you mind re-testing with Karmic and see if the issue can still be reproduced?

Hi Bryce, i have moved on, i am no longer using that computer. But, if you notice, it was reproducible in my March 2009 report, and it was fine after the ("bustype" "pci") change.

Okay thanks for getting back to me. I'm going to go ahead and assume whatever the problem was that it's solved now.

(If anyone else with similar hardware runs across this bug report, please file a NEW bug rather than reopening this one.)