Re: 2.6.10 dies when X uses G550

[Jon Smirl <jonsmirl@gmail.com>]

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