Re: 2.6.10 dies when X uses PCI radeon 9200 SE, further binary search result

Re: 2.6.10 dies when X uses PCI radeon 9200 SE, further binary search result

[Zoltan Boszormenyi]

> On Sun, Jan 30, 2005 at 10:05:16AM -0500, Jon Smirl wrote:
>> I just checked out on current Linus BK with my AGP Radeon 9000 which
>> is pretty close to a 9200. Everything is working fine.
>> 
>> I notice from his logs that he is running a PCI radeon, not an AGP
>> one. Didn't someone make some changes to the PCI radeon memory
>> management code recently? I run a PCI R128 and that is still working.
>> DRM debug output might give more clues.
>> 
> Yes, it is a PCI radeon.  And the machine has an AGP slot
> too, which is used by a matrox G550.  This AGP card was not
> used in the test, (other than being the VGA console).
> Note that there is no crash if I don't compile 
> AGP support, so the crash is related to AGP somehow even though
> AGP is not supposed to be used in this case.
> 
> As I start X (on the radeon) I notice that the VGA console 
> I'm using (on the G550 AGP) goes black.  I see no need for that either,
> the radeon display is a _different_ device so why black out 
> the vgacon?  Could the problem lurk there somehow?
> 
> Helge Hafting

I suspect it's the X server that makes your G550 go black.

XOrg-X11-6.8.2 RC1 or RC2 fixes that by introducing a VGAAccess
option for its radeon driver. I recompiled xorg-x11-6.8.1 with this
fix on my FC3 system. It made the only thing that annoyed me
using the linuxconsole.sf.net ruby patch go away.

I have a Radeon 7000VE PCI and a Radeon 9200SE AGP8x.
Every time I logged out on the first X ( localhost:0 ),
it made the other one (localhost:1) go blank.

With the above mentioned fix (that I collected from the XOrg devel
mailing list and was made by Ben Herrenschmidt) applied to XOrg
and using

Option "VGAAccess" "on"

on the card that is set up for VGA by the BIOS and

Option "VGAAccess" "off"

on the other, this problem went away. This modification disables
using the "vgahw" module in XOrg and unfortunately only applicable
to the radeon driver. BTW this patch was made for specifically
for systems that don't use vgacon, like PPC that don't even have
legacy VGA and for others that use radeonfb.

I guess the VGA routing patch and X cooperation will also
solve "the other VGA(s) in the system go blank when I fire up X"
in a generic way, not only for Radeons.

Best regards,
Zoltán Böszörményi

Re: 2.6.10 dies when X uses PCI radeon 9200 SE, further binary search result

[Helge Hafting]

On Sun, Jan 30, 2005 at 12:05:27PM -0500, Jon Smirl wrote:
> On Sun, 30 Jan 2005 17:32:41 +0100, Helge Hafting
> <helgehaf@aitel.hist.no> wrote:
> > Yes, it is a PCI radeon.  And the machine has an AGP slot
> > too, which is used by a matrox G550.  This AGP card was not
> > used in the test, (other than being the VGA console).
> > Note that there is no crash if I don't compile
> > AGP support, so the crash is related to AGP somehow even though
> > AGP is not supposed to be used in this case.
> 
> Can you set the PCI card to be primary in your BIOS or remove the AGP
> card, and then see if it works? It could be that X's video reset code
> for secondary PCI cards is broken.
> 
I set the PCI card to primary, and kept the AGP card. Then I booted up
2.6.9-rc3 which normally crashes hard when X starts.  

But now X came up just fine on the radeon!  The log indicates
no problems with drm either, I did not get a "pci oom".
I didn't actually test with glxgears, but drm came up according
to the logs.
I did not change the X setup, so the pci card was initialized by
int10 although that wasn't necessary this time.


I have not yet tested wether the AGP card works in this configuration, my
user was impatient so I had to restore a known working configuration.

Helge Hafting

Re: 2.6.10 dies when X uses PCI radeon 9200 SE, further binary search result

[Jon Smirl]

On Sun, 30 Jan 2005 17:32:41 +0100, Helge Hafting
<helgehaf@aitel.hist.no> wrote:
> Yes, it is a PCI radeon.  And the machine has an AGP slot
> too, which is used by a matrox G550.  This AGP card was not
> used in the test, (other than being the VGA console).
> Note that there is no crash if I don't compile
> AGP support, so the crash is related to AGP somehow even though
> AGP is not supposed to be used in this case.

Can you set the PCI card to be primary in your BIOS or remove the AGP
card, and then see if it works? It could be that X's video reset code
for secondary PCI cards is broken.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: 2.6.10 dies when X uses PCI radeon 9200 SE, further binary search result

[Helge Hafting]

On Sun, Jan 30, 2005 at 10:05:16AM -0500, Jon Smirl wrote:
> I just checked out on current Linus BK with my AGP Radeon 9000 which
> is pretty close to a 9200. Everything is working fine.
> 
> I notice from his logs that he is running a PCI radeon, not an AGP
> one. Didn't someone make some changes to the PCI radeon memory
> management code recently? I run a PCI R128 and that is still working.
> DRM debug output might give more clues.
> 
Yes, it is a PCI radeon.  And the machine has an AGP slot
too, which is used by a matrox G550.  This AGP card was not
used in the test, (other than being the VGA console).
Note that there is no crash if I don't compile 
AGP support, so the crash is related to AGP somehow even though
AGP is not supposed to be used in this case.

As I start X (on the radeon) I notice that the VGA console 
I'm using (on the G550 AGP) goes black.  I see no need for that either,
the radeon display is a _different_ device so why black out 
the vgacon?  Could the problem lurk there somehow?

Helge Hafting

Re: 2.6.10 dies when X uses PCI radeon 9200 SE, further binary search result

[Jon Smirl]

Doesn't PCI:0:8:0 have to be on a PCI bus? AGP would look like
PCI:1:0:0 or PCI:2:0:0.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: 2.6.10 dies when X uses PCI radeon 9200 SE, further binary search result

[Jon Smirl]

I just checked out on current Linus BK with my AGP Radeon 9000 which
is pretty close to a 9200. Everything is working fine.

I notice from his logs that he is running a PCI radeon, not an AGP
one. Didn't someone make some changes to the PCI radeon memory
management code recently? I run a PCI R128 and that is still working.
DRM debug output might give more clues.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: 2.6.10 dies when X uses PCI radeon 9200 SE, further binary search result

[Jon Smirl]

On Sun, 30 Jan 2005 22:22:24 +1100, Dave Airlie <airlied@gmail.com> wrote:
> Just another guess, but Jon could the PCI ROM patch mess up X's access
> via the Int10 handler .. maybe if it isn't mapped properly..?

The ROM patch is inactive until you echo something to the sysfs ROM variable.

> 
> Dave.
> 


-- 
Jon Smirl
jonsmirl@gmail.com

Re: 2.6.10 dies when X uses PCI radeon 9200 SE, further binary search result

[Dave Airlie]

> 
> 
> After sorting out a stupid build problem, here is the result for
> the binary search for the crash.
> 2.6.9         crash
> 2.6.9-rc2     pci-oom
> 2.6.9-rc3     crash
> 2.6.9-rc2-bk7 crash
> 2.6.9-rc2-bk4 crash
> 2.6.9-rc2-bk2 pci-oom
> 2.6.9-rc2-bk3 krash in ifconfig
> 
> Up to 2.6.9-rc2-bk2 we don't get a crash, instead the X log shows this:
> 
> (EE) RADEON(0): [pci] Out of memory (-1007)
> 
> and gives up on drm in an orderly fashion.
> 2.6.9-rc2-bk4 crashes though.  As usual, the X log ends with:
> (II) LoadModule: "int10"
> (II) Reloading /usr/X11R6/lib/modules/linux/libint10.a
> (II) RADEON(0): initializing int10
> (**) RADEON(0): Option "InitPrimary" "on"
> (II) Truncating PCI BIOS Length to 53248
> 
> 2.6.9-rc2-bk3 wasn't tested further, because the kernel dies upon
> running "ifconfig" which must be some other temporary bug.
> X will probably be difficult without IPv4 anyway.
> 

Just another guess, but Jon could the PCI ROM patch mess up X's access
via the Int10 handler .. maybe if it isn't mapped properly..?

Dave.

Re: 2.6.10 dies when X uses PCI radeon 9200 SE, further binary search result

[Helge Hafting]

>> What is the most useful to do now?
>> Binary searching for the crash between bk15 and rc2?   Or:]
>
> I'd keep looking for the crash... the out of memory will probably
> disappear with a later snapshot..


After sorting out a stupid build problem, here is the result for
the binary search for the crash.
2.6.9         crash
2.6.9-rc2     pci-oom
2.6.9-rc3     crash
2.6.9-rc2-bk7 crash
2.6.9-rc2-bk4 crash
2.6.9-rc2-bk2 pci-oom
2.6.9-rc2-bk3 krash in ifconfig  

Up to 2.6.9-rc2-bk2 we don't get a crash, instead the X log shows this:

(EE) RADEON(0): [pci] Out of memory (-1007)

and gives up on drm in an orderly fashion.  
2.6.9-rc2-bk4 crashes though.  As usual, the X log ends with:
(II) LoadModule: "int10"
(II) Reloading /usr/X11R6/lib/modules/linux/libint10.a
(II) RADEON(0): initializing int10
(**) RADEON(0): Option "InitPrimary" "on"
(II) Truncating PCI BIOS Length to 53248


2.6.9-rc2-bk3 wasn't tested further, because the kernel dies upon
running "ifconfig" which must be some other temporary bug.
X will probably be difficult without IPv4 anyway.

Helge Hafting 

Re: 2.6.10 dies when X uses PCI radeon 9200 SE, further binary search result

[Helge Hafting]

Dave Airlie wrote:

>
>Well if you can track down which patch in -rc2 causes it then we can
>annoy the person who created it, if you build some kernels from the bk
>snapshots it might help as -rc2 is quite large vs -rc1..
>
>  
>
So far, 2.6.9-rc1-bk10 works (X starts without hang, log indicates drm 
works too).

2.6.9-rc1-bk15 started X without a hang, but failed drm according to the 
log:
(II) RADEON(0): [drm] created "radeon" driver at busid "PCI:0:8:0"
(II) RADEON(0): [drm] added 8192 byte SAREA at 0xe0932000
(II) RADEON(0): [drm] mapped SAREA 0xe0932000 to 0xafd8d000
(II) RADEON(0): [drm] framebuffer handle = 0xe0000000
(II) RADEON(0): [drm] added 1 reserved context for kernel
(EE) RADEON(0): [pci] Out of memory (-1007)
(II) RADEON(0): [drm] removed 1 reserved context for kernel
(II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xe0932000 at 0xafd8d000
(II) RADEON(0): Memory manager initialized to (0,0) (1280,8191)

A normal lok (bk10) looks like this:
(II) RADEON(0): [drm] created "radeon" driver at busid "PCI:0:8:0"
(II) RADEON(0): [drm] added 8192 byte SAREA at 0xe0932000
(II) RADEON(0): [drm] mapped SAREA 0xe0932000 to 0xafd8d000
(II) RADEON(0): [drm] framebuffer handle = 0xe0000000
(II) RADEON(0): [drm] added 1 reserved context for kernel
(II) RADEON(0): [pci] 8192 kB allocated with handle 0xe0935000
(II) RADEON(0): [pci] ring handle = 0xe0935000
(II) RADEON(0): [pci] Ring mapped at 0xafc8c000
(II) RADEON(0): [pci] Ring contents 0x00000000
(II) RADEON(0): [pci] ring read ptr handle = 0xe0a36000
(II) RADEON(0): [pci] Ring read ptr mapped at 0xafc8b000
(II) RADEON(0): [pci] Ring read ptr contents 0x00000000
(II) RADEON(0): [pci] vertex/indirect buffers handle = 0xe0a37000
(II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0xafa8b000
(II) RADEON(0): [pci] Vertex/indirect buffers contents 0x00000000
(II) RADEON(0): [pci] GART texture map handle = 0xe0c37000
(II) RADEON(0): [pci] GART Texture map mapped at 0xaf5ab000
(II) RADEON(0): [drm] register handle = 0xf6000000
(II) RADEON(0): [dri] Visual configs initialized
(II) RADEON(0): CP in BM mode
(II) RADEON(0): Using 8 MB GART aperture
(II) RADEON(0): Using 1 MB for the ring buffer
(II) RADEON(0): Using 2 MB for vertex/indirect buffers
(II) RADEON(0): Using 5 MB for GART textures
(II) RADEON(0): Memory manager initialized to (0,0) (1280,8191)


What is the most useful to do now?
Binary searching for the crash between bk15 and rc2?   Or:
Binary searching for the "out of memory" between bk10 and bk15?

Helge Hafting