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

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

[Andreas Hartmann]

Helge Hafting schrieb:
> On Fri, Jan 21, 2005 at 09:05:12PM +0100, Andreas Hartmann wrote:
>> Hello Helge,
>> 
>> Helge Hafting schrieb:
>> > On Sun, Jan 16, 2005 at 10:41:23PM +1100, Dave Airlie wrote:
>> >> > 
>> >> > I'm fine with adding this code, but we still don't know if this is the
>> >> > cause of his problem. The debug output can determine if this really is
>> >> > the source of the problem or if it is somewhere else.
>> >> > 
>> >> 
>> >> I actually doubt it is this stuff.. my guess is that it is something
>> >> nasty like ACPI breaking int10 for X or something like that... it
>> >> seems a lot more subtle than the usually things that break when we
>> >> mess with the DRM :-)
>> 
>> Which glibc do you use? I have problems with glibc 2.3.4, kernel 2.4.x and
>> X / Xorg while executing the int10-code of X. glibc 2.3.3 works fine for
>> me. But I could find another posting, which describes, that there are even
>> problems with glibc 2.3.3 and kernel 2.4.x.
>> 
>> It's new for me, that there could be problems with kernelversions of 2.6, too.
>> 
>> Therefore, it would be really interessting to know, which glibc version
>> you are using.
>> 
> I use glibc 2.3.2 from debian testing (or unstable).  
> This is not the problem though, because a reboot into 2.6.8.1 makes
> X work without crashing.  The crash only happens with 2.6.9-rc2
> or later kernels.

Did you try another version of glibc?

> So the only way glibc could be the culprit, is if the newer kernel
> exports some new interface that this glibc manages to mess up.  Still,
> even a buggy glibc shouldn't hang the kernel anyway.

That's certainly correct.

> Such issues
> could crash (all) user apps, but shouldn't prevent the machine from
> responding to sysrq sequences.

You emphasized the differences of the effects. But there is one reason in
all cases which I know: int10 crashes X or even the whole kernel.

I could debug the problem to the following point:

--------------------------------------------------------------------------
static int
vm86_rep(struct vm86_struct *ptr)
{
    int __res;

#ifdef __PIC__
    /* When compiling with -fPIC, we can't use asm constraint "b" because
       %ebx is already taken by gcc. */
    __asm__ __volatile__("pushl %%ebx\n\t"
                         "movl %2,%%ebx\n\t"
                         "movl %1,%%eax\n\t"
                         "int $0x80\n\t"
                         "popl %%ebx"
                         :"=a" (__res)
                         :"n" ((int)113), "r" ((struct vm86_struct *)ptr));
#else
    __asm__ __volatile__("int $0x80\n\t"
                         :"=a" (__res):"a" ((int)113),
                         "b" ((struct vm86_struct *)ptr));
#endif
/* Comment from me */
xf86MsgVerb(X_INFO,3,"my comment\n");
            if (__res < 0) {
                errno = -__res;
                __res = -1;
            }
            else errno = 0;
            return __res;
}

#endif
-----------------------------------------------------------------------

I could see, that X crashes in glibc 2.3.4 with kernel 2.4.x (not with
kernel 2.6.x, x <= 10, x > 10 not tested) during the first malloc syscall
after int10 to execute the function
xf86MsgVerb(X_INFO,3,"my comment\n");


The crashes depend on different versions of used software:

glibc 2.3.3 or 2.3.4 with kernel 2.4.x
glibc 2.3.2 with kernel > 2.6.9rc2

I asked a X developper, but he couldn't help until now, too.


I can't say, if glibc or the kernel could be the problem. You can't relate
it reliable neither to glibc nor to the kernel nor to X. Therefore, it
_seems_ to me, nobody really cares about the problem.

I'm willing to help to find the problem - but I'm neither a kernel
developper, nor a glibc developper nor a X developper. I'm depending on
the support of the developpers.

I think, there should work one developper of each application together to
find the problem. I could ask a X developper, which I know, if he is
willing to help to find the problem together with a developper from the
kernel and from the glibc (I don't know, who to ask from the glibc-team).


Kind regards,
Andreas Hartmann

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

[Dave Airlie]

> >>
> 
> That's certainly correct.
> 
> > Such issues
> > could crash (all) user apps, but shouldn't prevent the machine from
> > responding to sysrq sequences.
> 
> You emphasized the differences of the effects. But there is one reason in
> all cases which I know: int10 crashes X or even the whole kernel.
> 
> I could debug the problem to the following point:
> 
> 
> I could see, that X crashes in glibc 2.3.4 with kernel 2.4.x (not with
> kernel 2.6.x, x <= 10, x > 10 not tested) during the first malloc syscall
> after int10 to execute the function
> xf86MsgVerb(X_INFO,3,"my comment\n");
> 
> The crashes depend on different versions of used software:
> 
> glibc 2.3.3 or 2.3.4 with kernel 2.4.x
> glibc 2.3.2 with kernel > 2.6.9rc2
> 


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..

Dave.

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

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

[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

[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

[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

[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]

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 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 G550

[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 tried this. I already reported that X came up on the radeon.
I could not run X on the G550, now that it was "secondary",
but the crash was different from the radeon crash.

The logs with secondary radeon used to end like this:
(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


The logs for secondary G550 ends like this, with or without int10
(--) MGA(0): Pseudo-DMA transfer window at 0xF3000000
(==) MGA(0): BIOS at 0xC0000
(WW) MGA(0): Video BIOS info block not detected!
(II) MGA(0): MGABios.RamdacType = 0x0
(==) MGA(0): Write-combining range (0xf0000000,0x2000000)
(--) MGA(0): VideoRAM: 2048 kByte
(II) Loading sub module "ddc"
(II) LoadModule: "ddc"
(II) Reloading /usr/X11R6/lib/modules/libddc.a
(II) Loading sub module "i2c"
(II) LoadModule: "i2c"
(II) Loading /usr/X11R6/lib/modules/libi2c.a
(II) Module i2c: vendor="The XFree86 Project"
        compiled for 4.3.0.1, module version = 1.2.0
        ABI class: XFree86 Video Driver, version 0.6
(==) MGA(0): Write-combining range (0xf0000000,0x200000)
(II) MGA(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000
(II) MGA(0): I2C bus "DDC" initialized.
(II) MGA(0): I2C device "DDC:ddc2" registered at address 0xA0.
(II) MGA(0): I2C device "DDC:ddc2" removed.
(II) MGA(0): I2C Monitor info: (nil)
(II) MGA(0): end of I2C Monitor info

The video bios is apparently not detected at all, and therefore not run.

The kernel doesn't actually hang, only X gets stuck.  sysrq+T
dumped stack traces for all tasks except the xserver.  For X,
there was only one line identifying the xserver process and the fact
that it was Running.  No stack dump.  I managed to kill all tasks
and have init proceeding into init 2.  

So I wonder - is Debians X 4.3.0.1 buggy, or the kernel?
The fact remains that the newer kernels locks up while trying to use the
secondary radeon, while it actually works with 2.6.8.1.

Well, actually 2.6.8.1 is a bit unstable once 3D stuff starts on the
radeon - but it is only the radeon xserver that locks up in an
infinite loop after a while. Other processes remain responsive.

Helge Hafting

Re: 2.6.10 dies when X uses G550

[Jon Smirl]

This appears to me to be a problem with the drivers in the X server.
DRM isn't active yet so I don't think the problem is there. There may
have been a kernel change that caused BIOS reset to stop working.

X does nasty things to the PCI bus from user space and there are many
ways that X and the kernel could interfere with each other. Maybe some
one that owns a PCI video card and a Matrox G550 can step through this
in a debugger and see what is happening.

You can look at the contents in of the video BIOS ROMs in recent
kernels. Go into sys and find your video card. echo 1 >rom. That will
enable the rom access code. You can then hexdump the ROM contents.

This is a small program for running a reset on video cards. It will
reset all of your cards. You might want to try running it. If it hangs
it will be easier to debug than an X server.
ftp://ftp.scitechsoft.com/devel/obsolete/x86emu/x86emu-0.8.tar.gz

I added the X server dev list on the CC.


On Fri, 4 Feb 2005 04:43:04 +0100, Helge Hafting <helgehaf@aitel.hist.no> wrote:
> 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 tried this. I already reported that X came up on the radeon.
> I could not run X on the G550, now that it was "secondary",
> but the crash was different from the radeon crash.
> 
> The logs with secondary radeon used to end like this:
> (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
> 
> The logs for secondary G550 ends like this, with or without int10
> (--) MGA(0): Pseudo-DMA transfer window at 0xF3000000
> (==) MGA(0): BIOS at 0xC0000
> (WW) MGA(0): Video BIOS info block not detected!
> (II) MGA(0): MGABios.RamdacType = 0x0
> (==) MGA(0): Write-combining range (0xf0000000,0x2000000)
> (--) MGA(0): VideoRAM: 2048 kByte
> (II) Loading sub module "ddc"
> (II) LoadModule: "ddc"
> (II) Reloading /usr/X11R6/lib/modules/libddc.a
> (II) Loading sub module "i2c"
> (II) LoadModule: "i2c"
> (II) Loading /usr/X11R6/lib/modules/libi2c.a
> (II) Module i2c: vendor="The XFree86 Project"
>         compiled for 4.3.0.1, module version = 1.2.0
>         ABI class: XFree86 Video Driver, version 0.6
> (==) MGA(0): Write-combining range (0xf0000000,0x200000)
> (II) MGA(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000
> (II) MGA(0): I2C bus "DDC" initialized.
> (II) MGA(0): I2C device "DDC:ddc2" registered at address 0xA0.
> (II) MGA(0): I2C device "DDC:ddc2" removed.
> (II) MGA(0): I2C Monitor info: (nil)
> (II) MGA(0): end of I2C Monitor info
> 
> The video bios is apparently not detected at all, and therefore not run.
> 
> The kernel doesn't actually hang, only X gets stuck.  sysrq+T
> dumped stack traces for all tasks except the xserver.  For X,
> there was only one line identifying the xserver process and the fact
> that it was Running.  No stack dump.  I managed to kill all tasks
> and have init proceeding into init 2.
> 
> So I wonder - is Debians X 4.3.0.1 buggy, or the kernel?
> The fact remains that the newer kernels locks up while trying to use the
> secondary radeon, while it actually works with 2.6.8.1.
> 
> Well, actually 2.6.8.1 is a bit unstable once 3D stuff starts on the
> radeon - but it is only the radeon xserver that locks up in an
> infinite loop after a while. Other processes remain responsive.
> 
> Helge Hafting
> 


-- 
Jon Smirl
jonsmirl@gmail.com

Re: 2.6.10 dies when X uses G550

[Dave Airlie]

> The logs with secondary radeon used to end like this:
> (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
> 
> The logs for secondary G550 ends like this, with or without int10
> (--) MGA(0): Pseudo-DMA transfer window at 0xF3000000
> (==) MGA(0): BIOS at 0xC0000
> (WW) MGA(0): Video BIOS info block not detected!
> (II) MGA(0): MGABios.RamdacType = 0x0
> (==) MGA(0): Write-combining range (0xf0000000,0x2000000)
> (--) MGA(0): VideoRAM: 2048 kByte
> (II) Loading sub module "ddc"
> (II) LoadModule: "ddc"
> (II) Reloading /usr/X11R6/lib/modules/libddc.a
> (II) Loading sub module "i2c"
> (II) LoadModule: "i2c"
> (II) Loading /usr/X11R6/lib/modules/libi2c.a
> (II) Module i2c: vendor="The XFree86 Project"
>         compiled for 4.3.0.1, module version = 1.2.0
>         ABI class: XFree86 Video Driver, version 0.6
> (==) MGA(0): Write-combining range (0xf0000000,0x200000)
> (II) MGA(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000
> (II) MGA(0): I2C bus "DDC" initialized.
> (II) MGA(0): I2C device "DDC:ddc2" registered at address 0xA0.
> (II) MGA(0): I2C device "DDC:ddc2" removed.
> (II) MGA(0): I2C Monitor info: (nil)
> (II) MGA(0): end of I2C Monitor info
> 
> The video bios is apparently not detected at all, and therefore not run.
> 
> The kernel doesn't actually hang, only X gets stuck.  sysrq+T
> dumped stack traces for all tasks except the xserver.  For X,
> there was only one line identifying the xserver process and the fact
> that it was Running.  No stack dump.  I managed to kill all tasks
> and have init proceeding into init 2.
> 
> So I wonder - is Debians X 4.3.0.1 buggy, or the kernel?
> The fact remains that the newer kernels locks up while trying to use the
> secondary radeon, while it actually works with 2.6.8.1.

I've had some luck in reproducing this, however I've had to retask my
test machine to find some hangs in my real life application (can run
for 5 or 6 days without crashing :-), so I might get back to looking
for this at some stage but when is anybodys guess, all I did was take
a Radeon AGP card, and a  PCI SiS crappy card and ran X on 2.6.10 and
it hung....

Dave.

Re: 2.6.10 dies when X uses G550

[Dave Airlie]

https://bugs.freedesktop.org/show_bug.cgi?id=2431

might have something to do with this...

Dave.

On Fri, 4 Feb 2005 16:57:50 +1100, Dave Airlie <airlied@gmail.com> wrote:
> > The logs with secondary radeon used to end like this:
> > (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
> >
> > The logs for secondary G550 ends like this, with or without int10
> > (--) MGA(0): Pseudo-DMA transfer window at 0xF3000000
> > (==) MGA(0): BIOS at 0xC0000
> > (WW) MGA(0): Video BIOS info block not detected!
> > (II) MGA(0): MGABios.RamdacType = 0x0
> > (==) MGA(0): Write-combining range (0xf0000000,0x2000000)
> > (--) MGA(0): VideoRAM: 2048 kByte
> > (II) Loading sub module "ddc"
> > (II) LoadModule: "ddc"
> > (II) Reloading /usr/X11R6/lib/modules/libddc.a
> > (II) Loading sub module "i2c"
> > (II) LoadModule: "i2c"
> > (II) Loading /usr/X11R6/lib/modules/libi2c.a
> > (II) Module i2c: vendor="The XFree86 Project"
> >         compiled for 4.3.0.1, module version = 1.2.0
> >         ABI class: XFree86 Video Driver, version 0.6
> > (==) MGA(0): Write-combining range (0xf0000000,0x200000)
> > (II) MGA(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000
> > (II) MGA(0): I2C bus "DDC" initialized.
> > (II) MGA(0): I2C device "DDC:ddc2" registered at address 0xA0.
> > (II) MGA(0): I2C device "DDC:ddc2" removed.
> > (II) MGA(0): I2C Monitor info: (nil)
> > (II) MGA(0): end of I2C Monitor info
> >
> > The video bios is apparently not detected at all, and therefore not run.
> >
> > The kernel doesn't actually hang, only X gets stuck.  sysrq+T
> > dumped stack traces for all tasks except the xserver.  For X,
> > there was only one line identifying the xserver process and the fact
> > that it was Running.  No stack dump.  I managed to kill all tasks
> > and have init proceeding into init 2.
> >
> > So I wonder - is Debians X 4.3.0.1 buggy, or the kernel?
> > The fact remains that the newer kernels locks up while trying to use the
> > secondary radeon, while it actually works with 2.6.8.1.
> 
> I've had some luck in reproducing this, however I've had to retask my
> test machine to find some hangs in my real life application (can run
> for 5 or 6 days without crashing :-), so I might get back to looking
> for this at some stage but when is anybodys guess, all I did was take
> a Radeon AGP card, and a  PCI SiS crappy card and ran X on 2.6.10 and
> it hung....
> 
> Dave.
>

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, binary search result

[Andreas Hartmann]

Hello Helge,

Helge Hafting schrieb:
> On Sun, Jan 16, 2005 at 10:41:23PM +1100, Dave Airlie wrote:
>> > 
>> > I'm fine with adding this code, but we still don't know if this is the
>> > cause of his problem. The debug output can determine if this really is
>> > the source of the problem or if it is somewhere else.
>> > 
>> 
>> I actually doubt it is this stuff.. my guess is that it is something
>> nasty like ACPI breaking int10 for X or something like that... it
>> seems a lot more subtle than the usually things that break when we
>> mess with the DRM :-)

Which glibc do you use? I have problems with glibc 2.3.4, kernel 2.4.x and
X / Xorg while executing the int10-code of X. glibc 2.3.3 works fine for
me. But I could find another posting, which describes, that there are even
problems with glibc 2.3.3 and kernel 2.4.x.

It's new for me, that there could be problems with kernelversions of 2.6, too.

Therefore, it would be really interessting to know, which glibc version
you are using.


Kind regards,
Andreas Hartmann

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

[Helge Hafting]

On Fri, Jan 21, 2005 at 09:05:12PM +0100, Andreas Hartmann wrote:
> Hello Helge,
> 
> Helge Hafting schrieb:
> > On Sun, Jan 16, 2005 at 10:41:23PM +1100, Dave Airlie wrote:
> >> > 
> >> > I'm fine with adding this code, but we still don't know if this is the
> >> > cause of his problem. The debug output can determine if this really is
> >> > the source of the problem or if it is somewhere else.
> >> > 
> >> 
> >> I actually doubt it is this stuff.. my guess is that it is something
> >> nasty like ACPI breaking int10 for X or something like that... it
> >> seems a lot more subtle than the usually things that break when we
> >> mess with the DRM :-)
> 
> Which glibc do you use? I have problems with glibc 2.3.4, kernel 2.4.x and
> X / Xorg while executing the int10-code of X. glibc 2.3.3 works fine for
> me. But I could find another posting, which describes, that there are even
> problems with glibc 2.3.3 and kernel 2.4.x.
> 
> It's new for me, that there could be problems with kernelversions of 2.6, too.
> 
> Therefore, it would be really interessting to know, which glibc version
> you are using.
> 
I use glibc 2.3.2 from debian testing (or unstable).  
This is not the problem though, because a reboot into 2.6.8.1 makes
X work without crashing.  The crash only happens with 2.6.9-rc2
or later kernels.  

So the only way glibc could be the culprit, is if the newer kernel
exports some new interface that this glibc manages to mess up.  Still,
even a buggy glibc shouldn't hang the kernel anyway.  Such issues
could crash (all) user apps, but shouldn't prevent the machine from
responding to sysrq sequences.

Helge Hafting

2.6.10 dies when X tries to initialize PCI radeon 9200 SE

[Helge Hafting]

2.6.10 boots fine, but is killed by the X server when it
tries to initialize my PCI radeon 9200 SE.  This problem exists
in 2.6.9 too, but not in 2.6.8.1.  So I'm stuck with that version currently.

The problem seems to be access to the card bios, X uses
int10 bios calls to initialize the card.

Helge Hafting

2.6.10 dies when X tries to initialize PCI radeon 9200 SE

[John covici]

I am getting something similar -- the X process gets stuck in some
kind of system call, but I can login from the network and shut the
system down, but I cannot change the console from the X to a text
console.

on Thursday 01/13/2005 Helge Hafting(helge.hafting@hist.no) wrote
 > 2.6.10 boots fine, but is killed by the X server when it
 > tries to initialize my PCI radeon 9200 SE.  This problem exists
 > in 2.6.9 too, but not in 2.6.8.1.  So I'm stuck with that version currently.
 > 
 > The problem seems to be access to the card bios, X uses
 > int10 bios calls to initialize the card.
 > 
 > Helge Hafting
 > -
 > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 > the body of a message to majordomo@vger.kernel.org
 > More majordomo info at  http://vger.kernel.org/majordomo-info.html
 > Please read the FAQ at  http://www.tux.org/lkml/

-- 
         John Covici
         covici@ccs.covici.com

Re: 2.6.10 dies when X tries to initialize PCI radeon 9200 SE

[Dave Airlie]

> on Thursday 01/13/2005 Helge Hafting(helge.hafting@hist.no) wrote
>  > 2.6.10 boots fine, but is killed by the X server when it
>  > tries to initialize my PCI radeon 9200 SE.  This problem exists
>  > in 2.6.9 too, but not in 2.6.8.1.  So I'm stuck with that version currently.
>  >
>  > The problem seems to be access to the card bios, X uses
>  > int10 bios calls to initialize the card.
>  >

Do you have DRM enabled if so can you turn it off.. same with radeonfb
or vesafb...

Dave.

Re: 2.6.10 dies when X tries to initialize PCI radeon 9200 SE

[Helge Hafting]

On Fri, Jan 14, 2005 at 08:06:09AM +1100, Dave Airlie wrote:
> > on Thursday 01/13/2005 Helge Hafting(helge.hafting@hist.no) wrote
> >  > 2.6.10 boots fine, but is killed by the X server when it
> >  > tries to initialize my PCI radeon 9200 SE.  This problem exists
> >  > in 2.6.9 too, but not in 2.6.8.1.  So I'm stuck with that version currently.
> >  >
> >  > The problem seems to be access to the card bios, X uses
> >  > int10 bios calls to initialize the card.
> >  >
> 
> Do you have DRM enabled if so can you turn it off.. same with radeonfb
> or vesafb...
> 

Some more data:
2.6.10 with agp and drm (drm for radeon & matrox) - dies with X on radeon
2.6.10 with drm (for radeon) no agp               - runs X fine!
2.6.10 with agp and no drm at all                 - dies with X on radeon
2.6.10 no agp no drm                              - runs X, but no 3d of course


2.6.10 with drm and no agp couldn't use matrox drm because that one 
needs agp to compile.


This is a bit strange.  I can't run X on the radoen PCI card if AGP is compiled,
but X and the kernel is not supposed to use AGP in this case because it is a
pci card!  Seems very strange to me, particularly considering that 2.6.8.1 
is able to run with both agp and drm.


I've mounted /var synchronously so as to get the most of the crash log.  It ends
like this:

(II) RADEON(0): Using 8 bits per RGB (8 bit DAC)
(II) Loading sub module "int10"
(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

A normal non-crashing run looks like this:
(II) RADEON(0): Using 8 bits per RGB (8 bit DAC)
(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
(--) RADEON(0): Chipset: "ATI Radeon 9200SE 5964 (AGP)" (ChipID = 0x5964)
(--) RADEON(0): Linear framebuffer at 0xe0000000
(--) RADEON(0): VideoRAM: 131072 kByte (64 bit DDR SDRAM)
(II) RADEON(0): PCI card detected
(II) Loading sub module "ddc"
(II) LoadModule: "ddc"

(and so on)

Another item that may be interesting:
>From the log, it looks like DRM failed to load for the PCI card when
AGP wasn't present.  Odd - it couldn't use AGP anyway.  
Maybe the explanation is that the xserver erroneously believes that it is
an agp card?  The log contains this:

(--) Chipset ATI Radeon 9200SE 5964 (AGP) found

It _is_ an "ATI Radeon 9200 SE", but it is definitely not an AGP card.
I don't know wether the X server is mistaken, or if it merely is a
wrong message.  I don't think X should hang the kernel this way, even
if it opens the AGP device by mistake.  AGP is normally in use by the 
matrox card and should be unavailable anyway.

Any further ideas?�  More things to try?  It'd be nice to get 3D on these
newer kernels too. :-)  I can post full logs if that's interesting.

Helge Hafting

Re: 2.6.10 dies when X tries to initialize PCI radeon 9200 SE

[Dave Airlie]

> Some more data:
> 2.6.10 with agp and drm (drm for radeon & matrox) - dies with X on radeon
> 2.6.10 with drm (for radeon) no agp               - runs X fine!
> 2.6.10 with agp and no drm at all                 - dies with X on radeon
> 2.6.10 no agp no drm                              - runs X, but no 3d of course
> 
> 2.6.10 with drm and no agp couldn't use matrox drm because that one
> needs agp to compile.
> 
> This is a bit strange.  I can't run X on the radoen PCI card if AGP is compiled,
> but X and the kernel is not supposed to use AGP in this case because it is a
> pci card!  Seems very strange to me, particularly considering that 2.6.8.1
> is able to run with both agp and drm.
> 
> I've mounted /var synchronously so as to get the most of the crash log.  It ends
> like this:
> 
> (II) RADEON(0): Using 8 bits per RGB (8 bit DAC)
> (II) Loading sub module "int10"
> (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
> 
> A normal non-crashing run looks like this:
> (II) RADEON(0): Using 8 bits per RGB (8 bit DAC)
> (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
> (--) RADEON(0): Chipset: "ATI Radeon 9200SE 5964 (AGP)" (ChipID = 0x5964)
> (--) RADEON(0): Linear framebuffer at 0xe0000000
> (--) RADEON(0): VideoRAM: 131072 kByte (64 bit DDR SDRAM)
> (II) RADEON(0): PCI card detected
> (II) Loading sub module "ddc"
> (II) LoadModule: "ddc"
> 
> (and so on)
> 
> Another item that may be interesting:
> From the log, it looks like DRM failed to load for the PCI card when
> AGP wasn't present.  Odd - it couldn't use AGP anyway.
> Maybe the explanation is that the xserver erroneously believes that it is
> an agp card?  The log contains this:
> 
> (--) Chipset ATI Radeon 9200SE 5964 (AGP) found
> 
> It _is_ an "ATI Radeon 9200 SE", but it is definitely not an AGP card.
> I don't know wether the X server is mistaken, or if it merely is a
> wrong message.  I don't think X should hang the kernel this way, even
> if it opens the AGP device by mistake.  AGP is normally in use by the
> matrox card and should be unavailable anyway.

Well the problem with a lot of ATI chips is they can be put onto
either an AGP or PCI card and work fine, so chips which are AGP chips
can end up on PCI cards...

I've cc'ed Jon Smirl who has a similiar setup (or has at least an AGP
and PCI radeon on his machine).... Jon can you try 2.6.10 on your
setup and see does it work?

it sounds like something may have broken the int10 stuff, but I've no
idea what, the only other thing I can think to recommend doing is an
binary search say starting at 2.6.9-rc1 and maybe using the -bk
snapshots to nail down exactly when it went wrong....

Dave.

Re: 2.6.10 dies when X tries to initialize PCI radeon 9200 SE

[Helge Hafting]

On Sun, Jan 16, 2005 at 09:08:38PM +1100, Dave Airlie wrote:

> Well the problem with a lot of ATI chips is they can be put onto
> either an AGP or PCI card and work fine, so chips which are AGP chips
> can end up on PCI cards...
> 
X uses chip ID to guess wether it is an AGP or PCI card?  Ouch.
Doesn�'t the kernel know very well how the card is connected,
couldn't X get this from the same interfaces "lspci" uses?

> it sounds like something may have broken the int10 stuff, but I've no
> idea what, the only other thing I can think to recommend doing is an
> binary search say starting at 2.6.9-rc1 and maybe using the -bk
> snapshots to nail down exactly when it went wrong....

That�'s an option.  It'll take time though, it is a multiuser machin; 
I can compile all the kernels I want but rebooting isn't
that popular.

Helge Hafting

Re: 2.6.10 dies when X tries to initialize PCI radeon 9200 SE

[Jon Smirl]

you need to check the output from "modprobe drm debug=1" "modprobe
radeon" and see if drm is misidentifying the board as AGP. We don't
want to fix something if it isn't broken.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: 2.6.10 dies when X tries to initialize PCI radeon 9200 SE

[Dave Airlie]

> you need to check the output from "modprobe drm debug=1" "modprobe
> radeon" and see if drm is misidentifying the board as AGP. We don't
> want to fix something if it isn't broken.


have a look at bug 255 in fd.o bugzilla, this was what was wrong with
the original code, I'd seriously think about putting this code into
the radeon drm not the old stuff..

Dave.

Re: 2.6.10 dies when X tries to initialize PCI radeon 9200 SE

[Jon Smirl]

On Sun, 16 Jan 2005 22:07:13 +1100, Dave Airlie <airlied@gmail.com> wrote:
> > you need to check the output from "modprobe drm debug=1" "modprobe
> > radeon" and see if drm is misidentifying the board as AGP. We don't
> > want to fix something if it isn't broken.
> 
> 
> have a look at bug 255 in fd.o bugzilla, this was what was wrong with
> the original code, I'd seriously think about putting this code into
> the radeon drm not the old stuff..
> 
> Dave.
> 

I'm fine with adding this code, but we still don't know if this is the
cause of his problem. The debug output can determine if this really is
the source of the problem or if it is somewhere else.


-- 
Jon Smirl
jonsmirl@gmail.com

Re: 2.6.10 dies when X tries to initialize PCI radeon 9200 SE

[Dave Airlie]

> 
> I'm fine with adding this code, but we still don't know if this is the
> cause of his problem. The debug output can determine if this really is
> the source of the problem or if it is somewhere else.
> 

I actually doubt it is this stuff.. my guess is that it is something
nasty like ACPI breaking int10 for X or something like that... it
seems a lot more subtle than the usually things that break when we
mess with the DRM :-)

Dave.

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

[Helge Hafting]

On Sun, Jan 16, 2005 at 10:41:23PM +1100, Dave Airlie wrote:
> > 
> > I'm fine with adding this code, but we still don't know if this is the
> > cause of his problem. The debug output can determine if this really is
> > the source of the problem or if it is somewhere else.
> > 
> 
> I actually doubt it is this stuff.. my guess is that it is something
> nasty like ACPI breaking int10 for X or something like that... it
> seems a lot more subtle than the usually things that break when we
> mess with the DRM :-)
> 
The search was a short one.  
2.6.9-rc1 works fine, just like 2.6.8.1
2.6.9-rc2 crashes.  I didn't find any kernel revisions between those two.

It is interesting to note that the 2.6.9 crash was a bit different.
X got a bit further according to the log.
During the test, everything stopped, but the machine wasn't completely
dead like it usually is.  Numlock actually toggled the LED, but the screen was 
black and I could not break out of X with ctrl+alt+backspace. So I tried to 
switch consoles, and the kernel died a bit more.  No more numlock LED
toggling, but sysrq+S+U+B actually worked.  The discs synced and
the thing booted.  Hm, perhaps  X always got a bit further, but
now the disc sync preserved more of the log?

Here is how it ended (I have all of it if necessary):

(==) RADEON(0): Write-combining range (0xe0000000,0x8000000)
(II) RADEON(0): Wrote: rd=12, fd=120, pd=1
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (Unknown error 999)
drmOpenDevice: open result is -1, (Unknown error 999)
drmOpenDevice: Open failed
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (Unknown error 999)
drmOpenDevice: open result is -1, (Unknown error 999)
drmOpenDevice: Open failed
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
drmGetBusid returned ''
(II) RADEON(0): [drm] loaded kernel module for "radeon" driver
(II) RADEON(0): [drm] created "radeon" driver at busid "PCI:0:8:0"
(II) RADEON(0): [drm] added 8192 byte SAREA at 0xe0920000
(II) RADEON(0): [drm] mapped SAREA 0xe0920000 to 0xafd8c000
(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 0xe097d000
(II) RADEON(0): [pci] ring handle = 0xe097d000
(II) RADEON(0): [pci] Ring mapped at 0xafc8b000
(II) RADEON(0): [pci] Ring contents 0x00000000
(II) RADEON(0): [pci] ring read ptr handle = 0xe0a7e000
(II) RADEON(0): [pci] Ring read ptr mapped at 0xafc8a000
(II) RADEON(0): [pci] Ring read ptr contents 0x00000000
(II) RADEON(0): [pci] vertex/indirect buffers handle = 0xe0a7f000
(II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0xafa8a000
(II) RADEON(0): [pci] Vertex/indirect buffers contents 0x00000000
(II) RADEON(0): [pci] GART texture map handle = 0xe0c7f000
(II) RADEON(0): [pci] GART Texture map mapped at 0xaf5aa000
(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)
(II) RADEON(0): Reserved area from (0,1024) to (1280,1026)
(II) RADEON(0): Largest offscreen area available: 1280 x 7165
(II) RADEON(0): Will use back buffer at offset 0x1400000
(II) RADEON(0): Will use depth buffer at offset 0x1900000
(II) RADEON(0): Will use 100352 kb for textures at offset 0x1e00000
(II) RADEON(0): Using XFree86 Acceleration Architecture (XAA)
        Screen to screen bit blits
        Solid filled rectangles
        8x8 mono pattern filled rectangles
        Indirect CPU to Screen color expansion
        Solid Lines
        Scanline Image Writes
        Offscreen Pixmaps
        Setting up tile and stipple cache:
                32 128x128 slots
                32 256x256 slots
                16 512x512 slots
(II) RADEON(0): Acceleration enabled
(==) RADEON(0): Backing store disabled
(==) RADEON(0): Silken mouse enabled
(II) RADEON(0): Using hardware cursor (scanline 1026)
(II) RADEON(0): Largest offscreen area available: 1280 x 7161
(**) Option "dpms"
(**) RADEON(0): DPMS enabled
(WW) RADEON(0): Option "DynamicClocks" is not used
(II) RADEON(0): X context handle = 0x00000001
(II) RADEON(0): [drm] installed DRM signal handler
(II) RADEON(0): [DRI] installation complete
(II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers


I hope this can be of help,
Helge Hafting

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

[John covici]

Makes sense to me -- I went from 6.8 to 6.9rc2 and that is I think
when my X died.  Now mine is an APG not PCI, but it may be related.
 
on Friday 01/21/2005 Helge Hafting(helgehaf@aitel.hist.no) wrote
 > On Sun, Jan 16, 2005 at 10:41:23PM +1100, Dave Airlie wrote:
 > > > 
 > > > I'm fine with adding this code, but we still don't know if this is the
 > > > cause of his problem. The debug output can determine if this really is
 > > > the source of the problem or if it is somewhere else.
 > > > 
 > > 
 > > I actually doubt it is this stuff.. my guess is that it is something
 > > nasty like ACPI breaking int10 for X or something like that... it
 > > seems a lot more subtle than the usually things that break when we
 > > mess with the DRM :-)
 > > 
 > The search was a short one.  
 > 2.6.9-rc1 works fine, just like 2.6.8.1
 > 2.6.9-rc2 crashes.  I didn't find any kernel revisions between those two.
 > 
 > It is interesting to note that the 2.6.9 crash was a bit different.
 > X got a bit further according to the log.
 > During the test, everything stopped, but the machine wasn't completely
 > dead like it usually is.  Numlock actually toggled the LED, but the screen was 
 > black and I could not break out of X with ctrl+alt+backspace. So I tried to 
 > switch consoles, and the kernel died a bit more.  No more numlock LED
 > toggling, but sysrq+S+U+B actually worked.  The discs synced and
 > the thing booted.  Hm, perhaps  X always got a bit further, but
 > now the disc sync preserved more of the log?
 > 
 > Here is how it ended (I have all of it if necessary):
 > 
 > (==) RADEON(0): Write-combining range (0xe0000000,0x8000000)
 > (II) RADEON(0): Wrote: rd=12, fd=120, pd=1
 > drmOpenDevice: minor is 0
 > drmOpenDevice: node name is /dev/dri/card0
 > drmOpenDevice: open result is -1, (Unknown error 999)
 > drmOpenDevice: open result is -1, (Unknown error 999)
 > drmOpenDevice: Open failed
 > drmOpenDevice: minor is 0
 > drmOpenDevice: node name is /dev/dri/card0
 > drmOpenDevice: open result is -1, (Unknown error 999)
 > drmOpenDevice: open result is -1, (Unknown error 999)
 > drmOpenDevice: Open failed
 > drmOpenDevice: minor is 0
 > drmOpenDevice: node name is /dev/dri/card0
 > drmOpenDevice: open result is 6, (OK)
 > drmGetBusid returned ''
 > (II) RADEON(0): [drm] loaded kernel module for "radeon" driver
 > (II) RADEON(0): [drm] created "radeon" driver at busid "PCI:0:8:0"
 > (II) RADEON(0): [drm] added 8192 byte SAREA at 0xe0920000
 > (II) RADEON(0): [drm] mapped SAREA 0xe0920000 to 0xafd8c000
 > (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 0xe097d000
 > (II) RADEON(0): [pci] ring handle = 0xe097d000
 > (II) RADEON(0): [pci] Ring mapped at 0xafc8b000
 > (II) RADEON(0): [pci] Ring contents 0x00000000
 > (II) RADEON(0): [pci] ring read ptr handle = 0xe0a7e000
 > (II) RADEON(0): [pci] Ring read ptr mapped at 0xafc8a000
 > (II) RADEON(0): [pci] Ring read ptr contents 0x00000000
 > (II) RADEON(0): [pci] vertex/indirect buffers handle = 0xe0a7f000
 > (II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0xafa8a000
 > (II) RADEON(0): [pci] Vertex/indirect buffers contents 0x00000000
 > (II) RADEON(0): [pci] GART texture map handle = 0xe0c7f000
 > (II) RADEON(0): [pci] GART Texture map mapped at 0xaf5aa000
 > (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)
 > (II) RADEON(0): Reserved area from (0,1024) to (1280,1026)
 > (II) RADEON(0): Largest offscreen area available: 1280 x 7165
 > (II) RADEON(0): Will use back buffer at offset 0x1400000
 > (II) RADEON(0): Will use depth buffer at offset 0x1900000
 > (II) RADEON(0): Will use 100352 kb for textures at offset 0x1e00000
 > (II) RADEON(0): Using XFree86 Acceleration Architecture (XAA)
 >         Screen to screen bit blits
 >         Solid filled rectangles
 >         8x8 mono pattern filled rectangles
 >         Indirect CPU to Screen color expansion
 >         Solid Lines
 >         Scanline Image Writes
 >         Offscreen Pixmaps
 >         Setting up tile and stipple cache:
 >                 32 128x128 slots
 >                 32 256x256 slots
 >                 16 512x512 slots
 > (II) RADEON(0): Acceleration enabled
 > (==) RADEON(0): Backing store disabled
 > (==) RADEON(0): Silken mouse enabled
 > (II) RADEON(0): Using hardware cursor (scanline 1026)
 > (II) RADEON(0): Largest offscreen area available: 1280 x 7161
 > (**) Option "dpms"
 > (**) RADEON(0): DPMS enabled
 > (WW) RADEON(0): Option "DynamicClocks" is not used
 > (II) RADEON(0): X context handle = 0x00000001
 > (II) RADEON(0): [drm] installed DRM signal handler
 > (II) RADEON(0): [DRI] installation complete
 > (II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers
 > 
 > 
 > I hope this can be of help,
 > Helge Hafting
 > -
 > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 > the body of a message to majordomo@vger.kernel.org
 > More majordomo info at  http://vger.kernel.org/majordomo-info.html
 > Please read the FAQ at  http://www.tux.org/lkml/

-- 
Your life is like a penny -- how are you going to spend it?

         John Covici
         covici@ccs.covici.com