[prev in list] [next in list] [prev in thread] [next in thread]
List: dri-users
Subject: Re: [Dri-users] mach64 DRI XF86Config question
From: Leif Delgass <ldelgass () retinalburn ! net>
Date: 2003-03-11 19:32:57
[Download RAW message or body]
I'd suggest testing without xdm. Try starting the server from a text
console with startx. The best way to do this is probably to edit
/etc/inittab to make runlevel 3 the default and reboot. Also, I think
you're still missing some output from the kernel module. You should see a
dump of the ringbuffer contents after the "mach64_ring_idle failed!"
message. You might be able to capture more of the info, and get more
verbose output, by turning on debug output in the drm:
- Exit X to a text console or reboot to runlevel 3.
- Become root.
- 'rmmod mach64' if it's still loaded.
- (Re)load the drm module with debugging:
% modprobe mach64 drm_opts=debug
- Redirect kernel messages to a file:
% cat /proc/kmsg > kmsg.log
- Open a new text console and startx as a normal user.
Then after the lockup, if possible: kill glxgears or whatever you're
testing with, exit the X server, then stop the cat process. You might
still lose a bit of the output this way, but it won't fill up your system
log and you'll get a cleaner, more verbose log.
At any rate, it looks like the lockup is still present with the unpatched
branch source.
--Leif
On 11 Mar 2003, Dave D. wrote:
> Whoops...Leif, sorry about this, scratch that last email.
> For some reason when I started XDM back up and tried it again
> (running glxgears and getting a lock-up) from my user account on
> my lombard, I got this in the kernel log:
>
> Mar 11 13:22:18 [kernel] Memory BAT mapping: BAT2=256Mb, BAT3=64Mb,
> residual: 0Mb
> Mar 11 13:22:19 [kernel] phy registers:
> Mar 11 13:26:21 [kernel] [drm] descriptor ring: cpu addr 0xd05c0000, bus
> addr: 0x105c0000
> Mar 11 13:26:44 [kernel] [drm]
> Mar 11 13:26:46 [kernel] [drm] mach64_ring_idle failed!
> GUI_STAT=0x00800201
> Mar 11 13:27:04 [kernel] [drm] descriptor ring: cpu addr 0xcf67c000, bus
> addr: 0x0f67c000
> Mar 11 13:30:41 [kernel] [drm]
> Mar 11 13:30:43 [kernel] [drm] mach64_ring_idle failed!
> GUI_STAT=0x00800201
> Mar 11 13:33:09 [kernel] [drm]
> Mar 11 13:33:11 [kernel] [drm] mach64_ring_idle failed!
> GUI_STAT=0x00800201
> Mar 11 13:37:46 [kernel] [drm] mach64_ring_idle failed!
> GUI_STAT=0x00800201
>
> So I must have some permission weirdness/log config stuff wrong.
>
> Anyways, take a look, tell me if it is helpful, and I'll try
> the patch you sent last time.
>
> Thanks,
> Dave
>
>
>
> On Tue, 2003-03-11 at 13:50, Dave D. wrote:
> > Hi Leif,
> >
> > I'm finally getting around to trying some of this stuff.
> >
> > I'm having problems getting any messages from X to my kernel
> > logs having set DMAMode to "async" and gotten X to freeze up
> > (temporarily) with glxgears. I'm using Gentoo, and I'm using
> > Metalog which I've been very lazy about configuring, so that
> > might have something to do with it...so unless you have a
> > quick idea about why I'm not getting any error messages from
> > drm I'm going to assume I need to do some configuring to get
> > X to send the right messages to my logs. HOWEVER, I did note
> > that at some point in the past, I got these messages in my
> > kernel log:
> >
> > Mar 8 12:37:06 [kernel] Memory BAT mapping: BAT2=256Mb, BAT3=64Mb,
> > residual: 0Mb
> > Mar 8 12:37:06 [kernel] phy registers:
> > Mar 8 12:37:17 [kernel] [drm] descriptor ring: cpu addr 0xd0f64000, bus
> > addr: 0x10f64000
> >
> > However, I don't know what I had going then...sorry about this
> > confusion. Basically, I need to figure out what the deal is with
> > drm writing to my logs before I can give you any info. If you have
> > any insight into this, let me know, or else, I can just move on to
> > patching the CVS source I have, recompiling the drm module, and
> > trying again...let me know what is best to help you out with testing.
> >
> > Thanks,
> > Dave
> >
> >
> >
> > On Wed, 2003-03-05 at 14:31, Leif Delgass wrote:
> > > On 5 Mar 2003, Dave D. wrote:
> > >
> > > > On Wed, 2003-03-05 at 02:19, Leif Delgass wrote:
> > > > > On 4 Mar 2003, Dave D. wrote:
> > > > >
> > > > > > Hi folks,
> > > > > >
> > > > > > I'm using Leif's mach64 dri branch, mach64-0-0-6-branch.
> > > > >
> > > > > I just want to point out that the mach64 driver is the combined work of
> > > > > Gareth Hughes, Jose Fonseca, and myself. If you're talking about the code
> > > > > in DRI cvs, you can just call it the DRI mach64 driver. ;)
> > > >
> > > > My apologies to all, credit where credit is due!
> > > >
> > > >
> > > > > I'm running the branch on top of 4.2.0 right now, so I don't think that's
> > > > > a problem.
> > > >
> > > > Okay, that's good to know. I would like to understand more about
> > > > the meanings of version numbers in X though.
> > >
> > > When you build from the DRI tree, you end up with the X server binary and
> > > driver modules matching the version of XFree86 that the DRI tree is based
> > > on (in this case 4.2.99.2). Other libraries and modules not directly
> > > related to DRI will come from your original X install. So for example,
> > > you won't be able to use the RandR extension unless the libXrandr library
> > > from your X install is recent enough. Having the X server binary and
> > > driver modules match eliminates most of the potential incompatibilities,
> > > but there's still the potential for problems if the original X install is
> > > significantly older then the version of X in the DRI tree. I'm not sure
> > > if there's any hard and fast rule regarding differing version numbers that
> > > would gaurantee compatibility. The mach64 branch will be updated to 4.3.0
> > > once the merge to the DRI trunk happens.
> > >
> > > > > Could you post your XF86Config? It sounds like a syntax problem in the
> > > > > config. It should look something like:
> > > > >
> > > > > Section "Device"
> > > > > [...]
> > > > > Driver "ati"
> > > > > Option "DMAMode" "mmio"
> > > > > [...]
> > > > > EndSection
> > > >
> > > > Ah...all I needed was some quotes, doh! Thanks for this little
> > > > snippet, it was the missing information for me I guess.
> > > >
> > > > Glxgears is running fine now, and I'm getting a pretty consistent
> > > > ~147 fps for this.
> > >
> > > Ok, good -- I figured it might be something like that.
> > >
> > > > > The recent discussion about a PCI posting problem in the Radeon driver has
> > > > > got me thinking again about the problem with DMA on ppc in the mach64
> > > > > driver. Would you be willing to try applying a patch or two to the DRM
> > > > > in the mach64-0-0-6-branch and testing DMA?
> > > >
> > > > I would be glad to; just let me know how I can go about doing this.
> > > >
> > > > Dave
> > >
> > > OK, that would be great. First off, I should say that have to be prepared
> > > for a few lockups and reboots when testing DMA. A journalled filesystem
> > > makes this a bit less painful, but isn't a requirement. Also, if you
> > > normally use xdm/gdm/kdm, I'd recommend switching to runlevel 3 and
> > > testing with startx. If you have remote access to the test system with
> > > ssh, this can also be useful if the X server locks up, but the system is
> > > still responsive.
> > >
> > > I guess the first thing to do is to test DMA with the current DRM, to see
> > > if anything has changed since this was last tested. Try changing the
> > > DMAMode option to "async" and restart the X server. You can start off by
> > > trying some of the Mesa demos: glxgears, tunnel, etc. If/when you get a
> > > lockup, the best thing is to restart from a powered-off state, to make
> > > sure the card gets fully reset. If you have remote access and can log in
> > > after the lockup, make a copy of the system log (the drm will write some
> > > debugging info to the log on a lockup) and halt the system before powering
> > > up again.
> > >
> > > Assuming that you get a lockup on the first test (which you probably
> > > will), try applying the attached patch:
> > >
> > > 1. copy the diff file to
> > > xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel in your build
> > > tree
> > >
> > > 2. Apply the patch with: "patch -p0 < dma-testing1.diff"
> > >
> > > 3. Rebuild the drm: "make -f Makefile.linux clean mach64.o"
> > >
> > > 4. Install the new drm as root: "cp mach64.o /lib/modules/`uname -r`/kernel/drivers/char/drm/
> > >
> > > 5. Exit X and unload the mach64 module as root: "rmmod mach64"
> > >
> > > 6. Run startx (as a normal user) and test. Check the system log for
> > > messages with "[drm]"
> > >
> > > Depending on what kind of output you get in the system log, it might be
> > > useful to turn on debugging in the drm, but I can explain that later
> > > depending on how the test goes.
>
--
Leif Delgass
http://www.retinalburn.net
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Dri-users mailing list
Dri-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-users
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic