GL-related crash w/ X 4.3 & kernel 2.6

GL-related crash w/ X 4.3 & kernel 2.6

[Matthew Wilcox]

I'm not terribly familiar with how X and the kernel interact, so please
bear with me if I used the wrong terms.

The slow way to reproduce the problem:
	Run glxgears and do other things.  Eventually X will stop responding.
	Took a few hours.

The fast way:
	Run flightgear.  This typically locks up within a minute or two.

I can still ssh into the machine.  Running top typically shows either
X or the application hogging 99% of the CPU.  The mouse pointer still
moves on the screen, but the focus will not change to any other X app.
The window manager does not respond.

The machine is a zx2000 workstation with a Radeon 7000/VE card.  Kernel is
2.6.0 plus some additional changes (mostly jgarzik's latest netdrivers
patch) [but it's happened with other 2.6 kernels].  The X server is
Debian's 4.3.0-0pre1v5 [but it's happened with other 4.3.0 releases].

First, can anyone else reproduce this or not, and with what other
combinations of X, kernel, hardware, etc?

Second, since neither strace nor gdb is willing to cooperate in helping
to track this down, can anyone more knowledgable than I about the ways
of GL suggest how to start debugging this?

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: GL-related crash w/ X 4.3 & kernel 2.6

[David Mosberger]

>>>>> On Mon, 29 Dec 2003 19:41:44 +0000, Matthew Wilcox <willy@debian.org> said:

  Matthew> The machine is a zx2000 workstation with a Radeon 7000/VE
  Matthew> card.  Kernel is 2.6.0 plus some additional changes (mostly
  Matthew> jgarzik's latest netdrivers patch) [but it's happened with
  Matthew> other 2.6 kernels].  The X server is Debian's 4.3.0-0pre1v5
  Matthew> [but it's happened with other 4.3.0 releases].

Do you have DRI enabled?  I pretty much had given up on Radeon hw
accelleration, because if failed for me in the same manner on both x86
and ia64.  Perhaps things have improved in the meantime?

Hardware-accellerated OpenGL did work fine for me with Nvidia until
the recent glibc upgrade forced me to turn it off for now.  I hadn't
tried FlightGear though.

>>>>> On Mon, 29 Dec 2003 19:41:44 +0000, Matthew Wilcox <willy@debian.org> said:

  Matthew> Second, since neither strace nor gdb is willing to
  Matthew> cooperate in helping to track this down, can anyone more
  Matthew> knowledgable than I about the ways of GL suggest how to
  Matthew> start debugging this?

You mean you can't use gdb to attach to the CPU-hogging processes?  My
guess would be that the server and the app get stuck trying to acquire
a lock, which is incidentally an area that the Radeon DRI driver had
problems with in the past.

	--david

Re: GL-related crash w/ X 4.3 & kernel 2.6

[Matthew Wilcox]

On Mon, Dec 29, 2003 at 11:57:32AM -0800, David Mosberger wrote:
> >>>>> On Mon, 29 Dec 2003 19:41:44 +0000, Matthew Wilcox <willy@debian.org> said:
> 
>   Matthew> The machine is a zx2000 workstation with a Radeon 7000/VE
>   Matthew> card.  Kernel is 2.6.0 plus some additional changes (mostly
>   Matthew> jgarzik's latest netdrivers patch) [but it's happened with
>   Matthew> other 2.6 kernels].  The X server is Debian's 4.3.0-0pre1v5
>   Matthew> [but it's happened with other 4.3.0 releases].
> 
> Do you have DRI enabled?  I pretty much had given up on Radeon hw
> accelleration, because if failed for me in the same manner on both x86
> and ia64.  Perhaps things have improved in the meantime?

Yes, I do have hardware acceleration turned on.  It's just not practical
to try playing a 3d game without it.  As a metric, ISTR glxgears going
from something like 80 to 600 frames per second from software to hardware
acceleration.

>   Matthew> Second, since neither strace nor gdb is willing to
>   Matthew> cooperate in helping to track this down, can anyone more
>   Matthew> knowledgable than I about the ways of GL suggest how to
>   Matthew> start debugging this?
> 
> You mean you can't use gdb to attach to the CPU-hogging processes?  My
> guess would be that the server and the app get stuck trying to acquire
> a lock, which is incidentally an area that the Radeon DRI driver had
> problems with in the past.

It's certainly consistent with their behaviour -- spinning waiting for
a lock.  I guess the next step is to try a 2.4 kernel so I can see if
the kernel is failing to release a lock or if the X server/application
is the one doing the Bad Thing.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: GL-related crash w/ X 4.3 & kernel 2.6

[David Mosberger]

>>>>> On Mon, 29 Dec 2003 20:51:20 +0000, Matthew Wilcox <willy@debian.org> said:

  >>  You mean you can't use gdb to attach to the CPU-hogging
  >> processes?  My guess would be that the server and the app get
  >> stuck trying to acquire a lock, which is incidentally an area
  >> that the Radeon DRI driver had problems with in the past.

  Matthew> It's certainly consistent with their behaviour -- spinning
  Matthew> waiting for a lock.  I guess the next step is to try a 2.4
  Matthew> kernel so I can see if the kernel is failing to release a
  Matthew> lock or if the X server/application is the one doing the
  Matthew> Bad Thing.

I just tried DRI with a radeon 7000 again and am still getting the
same old error message when inserting the radeon kernel module:

[drm] Initialized radeon 1.9.0 20020828 on minor 0
[drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held
[drm:radeon_unlock] *ERROR* Process 968 using kernel context 0

This is the same error message I saw on an x86 machine with a radeon
chip.  I don't think AGP is available after this error message, so
something must be different in your setup.  Can you confirm that you
didn't get the same kind of drm error when loading radeon.ko?

	--david

Re: GL-related crash w/ X 4.3 & kernel 2.6

[Matthew Wilcox]

On Mon, Dec 29, 2003 at 01:40:12PM -0800, David Mosberger wrote:
> I just tried DRI with a radeon 7000 again and am still getting the
> same old error message when inserting the radeon kernel module:
> 
> [drm] Initialized radeon 1.9.0 20020828 on minor 0
> [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held
> [drm:radeon_unlock] *ERROR* Process 968 using kernel context 0
> 
> This is the same error message I saw on an x86 machine with a radeon
> chip.  I don't think AGP is available after this error message, so
> something must be different in your setup.  Can you confirm that you
> didn't get the same kind of drm error when loading radeon.ko?

I have it built-in rather than modular, but yes, I get:

Linux agpgart interface v0.100 (c) Dave Jones
agpgart: HP ZX1 IOC: IOPDIR shared with sba_iommu
agpgart: Maximum main memory to use for agp memory: 3861M
agpgart: AGP aperture is 512M @ 0x60000000
agpgart: Detected HP ZX1 HWP0003 AGP chipset (iocþd01000, lbaþd20000)
[drm] Initialized radeon 1.9.0 20020828 on minor 0
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled

Though while I'm looking at dmesg, I also see:

agpgart: Putting AGP V2 device at 0000:00:00.0 into 1x mode

I should look into that.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: GL-related crash w/ X 4.3 & kernel 2.6

[Stephane Eranian]

Matthew,

We got 3d acceleration to work just fine on a ZX2000 with 2.6.1
and Debian/testing. Flightgear works fine, no lock ups. 

The video card is a Radeon 7200 (R100 QD), we've loaded the hp_agp 
and radeon modules.

Have you tried with 2.6.1?


On Mon, Dec 29, 2003 at 07:41:44PM +0000, Matthew Wilcox wrote:
> 
> I'm not terribly familiar with how X and the kernel interact, so please
> bear with me if I used the wrong terms.
> 
> The slow way to reproduce the problem:
> 	Run glxgears and do other things.  Eventually X will stop responding.
> 	Took a few hours.
> 
> The fast way:
> 	Run flightgear.  This typically locks up within a minute or two.
> 
> I can still ssh into the machine.  Running top typically shows either
> X or the application hogging 99% of the CPU.  The mouse pointer still
> moves on the screen, but the focus will not change to any other X app.
> The window manager does not respond.
> 
> The machine is a zx2000 workstation with a Radeon 7000/VE card.  Kernel is
> 2.6.0 plus some additional changes (mostly jgarzik's latest netdrivers
> patch) [but it's happened with other 2.6 kernels].  The X server is
> Debian's 4.3.0-0pre1v5 [but it's happened with other 4.3.0 releases].
> 
> First, can anyone else reproduce this or not, and with what other
> combinations of X, kernel, hardware, etc?
> 
> Second, since neither strace nor gdb is willing to cooperate in helping
> to track this down, can anyone more knowledgable than I about the ways
> of GL suggest how to start debugging this?
> 
> -- 
> "Next the statesmen will invent cheap lies, putting the blame upon 
> the nation that is attacked, and every man will be glad of those
> conscience-soothing falsities, and will diligently study them, and refuse
> to examine any refutations of them; and thus he will by and by convince 
> himself that the war is just, and will thank God for the better sleep 
> he enjoys after this process of grotesque self-deception." -- Mark Twain
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

-Stephane