[Bug 4714] New: OpenGL applications and some X-windows functions cause machine to be unresponsive.
http://bugzilla.kernel.org/show_bug.cgi?id=4714 Summary: OpenGL applications and some X-windows functions cause machine to be unresponsive. Kernel Version: 2.6.11 -- 2.6.12-rc5 Status: NEW Severity: normal Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Distribution: Gentoo Hardware Environment: Dual Athlon 1.2ghz, ATI R128, AMD760MPX Software Environment: Xorg X11, 6.8.2, fvwm, any OpenGl game. Problem Description: Playing an openGl application, or even manipulating a desktop pop-up menu while an OpenGL application is active causes the machine to become totally unresponsive except for the mouse for exactly ten seconds or some multiple thereof... I suspect this is a kernel bug because running Xosview on the secondary videocard/monitor -- which also freezes, suggests that one of the two processors is in "system" mode for the entire duration... I suspect it's a deadlock in the kernel and a 10 second watchdog timer is recovering the thing... Applications appear to be working normally during these outages but are unable to send data to the screen. Steps to reproduce: Run any OpenGL application for a few minutes. -- it hangs... --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] on lockups
On Sun, 2005-06-05 at 14:45 -0400, Vladimir Dergachev wrote: > >> Yes, however it is convenient to do so. > >> > >> The point is that AGP base address will not normally overlap the location > >> of system RAM. This is, of course, only reasonable for 32 bit systems.. > > > > I understand that part, but it's not what I meant. What I mean is this: You > > said, RADEON_MC_AGP_LOCATION is used to program where AGP is in the card's > > address space, and that's all fine and makes sense. > > > > However, we are *also* programming dev->agp->base into a register called > > RADEON_AGP_BASE. What is the meaning of that register? > > AFAIK this offset is used by PCI GART. When PCI GART is on this offset > specifies location of "AGP-like" space. No, it's the address of the AGP aperture on the _bus_, (the value you were talking about earlier) though it's sometimes just 0. Ben. --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] on lockups
On Sun, 2005-06-05 at 20:16 +0200, Nicolai Haehnle wrote: > I understand that part, but it's not what I meant. What I mean is this: You > said, RADEON_MC_AGP_LOCATION is used to program where AGP is in the card's > address space, and that's all fine and makes sense. > > However, we are *also* programming dev->agp->base into a register called > RADEON_AGP_BASE. What is the meaning of that register? That is the base of AGP cycles on the bus. Ben. --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] on lockups
> Yes, however it is convenient to do so. > > The point is that AGP base address will not normally overlap the location > of system RAM. This is, of course, only reasonable for 32 bit systems.. It will overlap it on all PowerMac's (where it will be 0) Ben. --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] on lockups
> > My understanding is that AGP only does transfers system RAM -> video RAM > > and all transfers in the opposite direction have to use plain PCI > > transfers at least as far as the bus is concerned. > > You mean system RAM -> graphics card, right? Does this mean that the > graphics card cannot always write into memory that falls within > RADEON_MC_AGP_LOCATION? Actually, that depends on the chipset. Some chipsets do support it, some don't. I don't think this capability is currently exposed by our AGP infrastructure. > > It could be anything. However, the recommended way to program the memory > > controller is to set the BASE of video memory to its physical PCI address > > and to put AGP memory where it is mirrored by the AGP GART, as, > > presumably, this does not overlap with system RAM or any of other > > sensitive areas. > > > > My understanding is that dev->agp->base is the address where the AGP GART > > mirrors the pieces of system RAM comprising AGP space. > > Yes, that's my understanding, too. But what is the Radeon's business knowing > that address? Why does it need to know this address? I thought this was CPU > address space, not card address space. No, the AGP aperture base is known to the radeon since the AGP cycles issued by the radeon must "land" in the proper area. However, it's programmed once for all in the card. But it can't be set to the same value as the "CPU" view of it neither. The reason is that there may not be any valid "CPU" view of it. On some chipsets, the AGP aperture is not accessible at all by the CPU. On those platforms, the aperture is made visible by remapping all pages that are bound to it into a single linear virtual mapping (using the MMU), not by mapping in the physical AGP aperture. In fact, on some chipsets, the AGP base has to be 0 (without however conflicting with PCI accesses as these chipsets, afaik, only go through the GART for pure AGP transactions). Ben. --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] on lockups
On Sun, 2005-06-05 at 09:58 -0400, Vladimir Dergachev wrote: > >> Which way can memory controller be misprogrammed ? The part that concerns > >> us are positions of Video RAM, AGP and System Ram in Radeon address space. > >> (these are specified by RADEON_MC_AGP_LOCATION, RADEON_MC_FB_LOCATION). > >> > >> The memory controller *always* assumes that system RAM (accessible via > >> PCI) starts at 0. So, if RADEON_MC_FB_LOCATION, for example, is set to 0 > >> then we have video RAM overlapping system RAM. > > > > Yup, and that is not recommended. We program it differently on r200 but > > for some reason, X still does that hack to put it down at 0 on r300. > > I wonder why. I always assumed that r300 should behave similarly to r200 - > at least I can't see where the switch is. I certainly have not put any > switches to change the behaviour (unless it was a mistake). I think people originally had problems with the r200 code on r300, which might be related to the use of tiled mode by the firmware on some r300 based setups (at least on macs). It seems that just mucking around MC_FB_* etc... without actually disabling or reconfiguring tiling properly locks up the card. I think we need to be smarter here. We probably need to change MC_FB_LOCATION etc... in the actual mode set sequence (and thus save/restore them on console switch). We should probably make sure nothing is accessing memory while doing the change (that is set the proper bits to disable access to MC by the CRTC, which should be easy in the mode setting which is already wrapped in blanks). > >> Note that old driver was able to test whether mirroring works, so it > >> would correspond to behaviour of RV350 cards. It could be that R300 cards > >> are more touchy in this regard. > > > > Might be worth trying to fallback to non-mirrored setup and see if that > > helps. > > The most puzzling thing is that lockup is not immediate (as I would have > expected) and that it works on some chips.. > > best > > Vladimir Dergachev > > > > > Ben. > > > > > > > > > > --- > > This SF.Net email is sponsored by: NEC IT Guy Games. How far can you > > shotput > > a projector? How fast can you ride your desk chair down the office luge > > track? > > If you want to score the big prize, get to know the little guy. > > Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 > > -- > > ___ > > Dri-devel mailing list > > Dri-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/dri-devel > > --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] 'texwrap' sigfaults during pressing 'b'
Dieter Nützel wrote: progs/tests> ./texwrap Texture Border Size = 1 Speicherschutzverletzung (core dumped) This is still #2516 (rasterization fallbacks cause segfaults), though the backtrace output has slightly changed due to changes to the t_vertex code. Roland --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2241] implement GL_ARB_texture_cube_map in radeon driver
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2241 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #1986 is|0 |1 obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2005-06-05 12:05 --- Created an attachment (id=2830) --> (https://bugs.freedesktop.org/attachment.cgi?id=2830&action=view) mesa_radeon_cubemap_20050605_3.diff.txt patch against current Mesa CVS HEAD -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] on lockups
Yes, however it is convenient to do so. The point is that AGP base address will not normally overlap the location of system RAM. This is, of course, only reasonable for 32 bit systems.. I understand that part, but it's not what I meant. What I mean is this: You said, RADEON_MC_AGP_LOCATION is used to program where AGP is in the card's address space, and that's all fine and makes sense. However, we are *also* programming dev->agp->base into a register called RADEON_AGP_BASE. What is the meaning of that register? AFAIK this offset is used by PCI GART. When PCI GART is on this offset specifies location of "AGP-like" space. best Vladimir Dergachev cu, Nicolai --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] on lockups
On Sunday 05 June 2005 20:07, Vladimir Dergachev wrote: > >> My understanding is that dev->agp->base is the address where the AGP GART > >> mirrors the pieces of system RAM comprising AGP space. > > > > Yes, that's my understanding, too. But what is the Radeon's business knowing > > that address? Why does it need to know this address? I thought this was CPU > > address space, not card address space. > > Yes, however it is convenient to do so. > > The point is that AGP base address will not normally overlap the location > of system RAM. This is, of course, only reasonable for 32 bit systems.. I understand that part, but it's not what I meant. What I mean is this: You said, RADEON_MC_AGP_LOCATION is used to program where AGP is in the card's address space, and that's all fine and makes sense. However, we are *also* programming dev->agp->base into a register called RADEON_AGP_BASE. What is the meaning of that register? cu, Nicolai pgpmkn1hvrepD.pgp Description: PGP signature
Re: [R300] on lockups
This register is programmed to a value that falls within the AGP area (as defined by RADEON_MC_AGP_LOCATION) if I understand the code correctly. My understanding is that AGP only does transfers system RAM -> video RAM and all transfers in the opposite direction have to use plain PCI transfers at least as far as the bus is concerned. You mean system RAM -> graphics card, right? Does this mean that the graphics card cannot always write into memory that falls within RADEON_MC_AGP_LOCATION? I don't think we can rely on this. My understanding is that dev->agp->base is the address where the AGP GART mirrors the pieces of system RAM comprising AGP space. Yes, that's my understanding, too. But what is the Radeon's business knowing that address? Why does it need to know this address? I thought this was CPU address space, not card address space. Yes, however it is convenient to do so. The point is that AGP base address will not normally overlap the location of system RAM. This is, of course, only reasonable for 32 bit systems.. best Vladimir Dergachev cu, Nicolai --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] on lockups
On Sunday 05 June 2005 15:55, Vladimir Dergachev wrote: > On Sat, 4 Jun 2005, Nicolai Haehnle wrote: > >> > >> The mirroring works as follows: each time scratch register is written > > the > >> radeon controller uses PCI to write their value to a specific location in > >> system memory. > > > > Are you sure it uses PCI? I'm assuming that the destination address for > > scratch writeback is controlled by the RADEON_SCRATCH_ADDR register. This > > register is programmed to a value that falls within the AGP area (as > > defined by RADEON_MC_AGP_LOCATION) if I understand the code correctly. > > My understanding is that AGP only does transfers system RAM -> video RAM > and all transfers in the opposite direction have to use plain PCI > transfers at least as far as the bus is concerned. You mean system RAM -> graphics card, right? Does this mean that the graphics card cannot always write into memory that falls within RADEON_MC_AGP_LOCATION? > It could be that AGP GART can still decode addresses for writes to system > memory, I guess this depends on a particular architecture. > > One of the reasons to look forward to PCI Express is that it is > bi-directional, unlike AGP. > > > > >> This, of course, would not work if the memory controller is > > misprogrammed > >> - which was the cause of failures. > >> > >> Which way can memory controller be misprogrammed ? The part that > > concerns > >> us are positions of Video RAM, AGP and System Ram in Radeon address space. > >> (these are specified by RADEON_MC_AGP_LOCATION, RADEON_MC_FB_LOCATION). > > > > What's the meaning of RADEON_AGP_BASE, by the way? It is programmed to > > dev->agp->base, which is AFAIK an address from the kernel's address space. > > That doesn't make much sense to me. > > It could be anything. However, the recommended way to program the memory > controller is to set the BASE of video memory to its physical PCI address > and to put AGP memory where it is mirrored by the AGP GART, as, > presumably, this does not overlap with system RAM or any of other > sensitive areas. > > My understanding is that dev->agp->base is the address where the AGP GART > mirrors the pieces of system RAM comprising AGP space. Yes, that's my understanding, too. But what is the Radeon's business knowing that address? Why does it need to know this address? I thought this was CPU address space, not card address space. cu, Nicolai pgpmw9nGNctUV.pgp Description: PGP signature
[r200] quake3-smp hangs in futex (current Mesa DRI not SMP ready?)
games/quake3> ltrace ./quake3-smp.x86
.
.
.
memcpy(0x08938ad6, "GL_SUN_slice_accum", 18) = 0x08938ad6
memcpy(0x0892d1b8, "GL_ARB_depth_texture GL_ARB_draw"..., 3026) = 0x0892d1b8
free(0x08937f18) =
pthread_mutex_unlock(0x44b9dce4, 129, 0xbfffe2d4, 0xbfffe2d8, 0) = 0
memset(0xbfffe380, '\000', 188) = 0xbfffe380
--- SIGINT (Interrupt) ---
+++ killed by SIGINT +++
games/quake3> strace ./quake3-smp.x86
.
.
.
brk(0x8cc3000) = 0x8cc3000
brk(0) = 0x8cc3000
brk(0x8ce7000) = 0x8ce7000
mmap2(NULL, 495616, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x4968c000
gettimeofday({1117990206, 773019}, NULL) = 0
futex(0x892d060, FUTEX_WAIT, 2, NULL
Thanks,
Dieter
---
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[r200] 'texwrap' sigfaults during pressing 'b'
progs/tests> ./texwrap Texture Border Size = 1 Speicherschutzverletzung (core dumped) progs/tests> l core -rw---1 nuetzel users 6156288 2005-06-05 17:59 core Loaded symbols for /usr/lib/libtxc_dxtn.so Reading symbols from /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2...done. Loaded symbols for /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 #0 0x405f4d2a in update_input_ptrs (ctx=0x0, start=0) at tnl/t_vertex.c:386 386 a[j].inputptr = ((GLubyte *)vptr->data) + start * vptr->stride; (gdb) bt #0 0x405f4d2a in update_input_ptrs (ctx=0x0, start=0) at tnl/t_vertex.c:386 #1 0x405f4dd6 in _tnl_build_vertices (ctx=0x805f490, start=0, end=0, newinputs=4294967295) at tnl/t_vertex.c:408 #2 0x405e985e in run_render (ctx=0x805f490, stage=0x81fc864) at tnl/t_vb_render.c:295 #3 0x405e0961 in _tnl_run_pipeline (ctx=0x805f490) at tnl/t_pipeline.c:159 #4 0x405570df in r200WrapRunPipeline (ctx=0x805f490) at r200_state.c:2316 #5 0x40600b88 in _tnl_flush_vtx (ctx=0x805f490) at tnl/t_vtx_exec.c:277 #6 0x405fc424 in _tnl_FlushVertices (ctx=0x805f490, flags=1) at tnl/t_vtx_api.c:842 #7 0x4056a213 in r200FlushVertices (ctx=0x805f490, flags=1) at r200_swtcl.c:903 #8 0x40661b7f in _mesa_set_enable (ctx=0x805f490, cap=3553, state=0 '\0') at main/enable.c:610 #9 0x40662f37 in _mesa_Disable (cap=0) at main/enable.c:1058 #10 0x08049228 in Display () at texwrap.c:172 #11 0x4004a0b3 in processWindowWorkList (window=0x80536c0) at glut_event.c:1297 #12 0x4004a12d in __glutProcessWindowWorkLists () at glut_event.c:1344 #13 0x4004a17d in glutMainLoop () at glut_event.c:1365 #14 0x080496a8 in main (argc=1, argv=0xbfffefc4) at texwrap.c:301 (gdb) info registers eax0x0 0 ecx0x0 0 edx0x0 0 ebx0x0 0 esp0xbfffec10 0xbfffec10 ebp0xbfffec38 0xbfffec38 esi0x81fdf6c136306540 edi0x81fdf58136306520 eip0x405f4d2a 0x405f4d2a eflags 0x10246 66118 cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 Thanks, Dieter --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] on lockups
On Sun, 5 Jun 2005, Jerome Glisse wrote: Note that old driver was able to test whether mirroring works, so it would correspond to behaviour of RV350 cards. It could be that R300 cards are more touchy in this regard. Might be worth trying to fallback to non-mirrored setup and see if that helps. Was wondering were this stuff is setup, drm ? Xorg driver ? dri driver ? Or is there a simple option to fallback :) I think this is inside DRM driver. Search for string "Writeback doesn't seem to work everywhere, test it first" inside the file radeon_cp.c best Vladimir Dergachev Jerome --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2365] ATI IGP9100 with dri enabled in blender corrupts screen
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2365 --- Additional Comments From [EMAIL PROTECTED] 2005-06-05 07:27 --- any news about this bug ? :) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] on lockups
> > Note that old driver was able to test whether mirroring works, so it > > would correspond to behaviour of RV350 cards. It could be that R300 cards > > are more touchy in this regard. > > Might be worth trying to fallback to non-mirrored setup and see if that > helps. Was wondering were this stuff is setup, drm ? Xorg driver ? dri driver ? Or is there a simple option to fallback :) Jerome --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] on lockups
Vladimir Dergachev schrieb: > > My understanding is that AGP only does transfers system RAM -> video RAM > and all transfers in the opposite direction have to use plain PCI > transfers at least as far as the bus is concerned. AGP can do both. Every AGP compliant device has to support the System RAM -> video RAM part. The other one is optional. Optional not only in the graphics card but in the northbridge, so there are some cheap chipsets that don't support it. This lead to many card manufacturers not supporting it in their cards and drivers. Highend graphics cards like the Wildcat support it. Philipp --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] on lockups
Which way can memory controller be misprogrammed ? The part that concerns us are positions of Video RAM, AGP and System Ram in Radeon address space. (these are specified by RADEON_MC_AGP_LOCATION, RADEON_MC_FB_LOCATION). The memory controller *always* assumes that system RAM (accessible via PCI) starts at 0. So, if RADEON_MC_FB_LOCATION, for example, is set to 0 then we have video RAM overlapping system RAM. Yup, and that is not recommended. We program it differently on r200 but for some reason, X still does that hack to put it down at 0 on r300. I wonder why. I always assumed that r300 should behave similarly to r200 - at least I can't see where the switch is. I certainly have not put any switches to change the behaviour (unless it was a mistake). Note that old driver was able to test whether mirroring works, so it would correspond to behaviour of RV350 cards. It could be that R300 cards are more touchy in this regard. Might be worth trying to fallback to non-mirrored setup and see if that helps. The most puzzling thing is that lockup is not immediate (as I would have expected) and that it works on some chips.. best Vladimir Dergachev Ben. --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] on lockups
On Sat, 4 Jun 2005, Nicolai Haehnle wrote: The mirroring works as follows: each time scratch register is written the radeon controller uses PCI to write their value to a specific location in system memory. Are you sure it uses PCI? I'm assuming that the destination address for scratch writeback is controlled by the RADEON_SCRATCH_ADDR register. This register is programmed to a value that falls within the AGP area (as defined by RADEON_MC_AGP_LOCATION) if I understand the code correctly. My understanding is that AGP only does transfers system RAM -> video RAM and all transfers in the opposite direction have to use plain PCI transfers at least as far as the bus is concerned. It could be that AGP GART can still decode addresses for writes to system memory, I guess this depends on a particular architecture. One of the reasons to look forward to PCI Express is that it is bi-directional, unlike AGP. This, of course, would not work if the memory controller is misprogrammed - which was the cause of failures. Which way can memory controller be misprogrammed ? The part that concerns us are positions of Video RAM, AGP and System Ram in Radeon address space. (these are specified by RADEON_MC_AGP_LOCATION, RADEON_MC_FB_LOCATION). What's the meaning of RADEON_AGP_BASE, by the way? It is programmed to dev->agp->base, which is AFAIK an address from the kernel's address space. That doesn't make much sense to me. It could be anything. However, the recommended way to program the memory controller is to set the BASE of video memory to its physical PCI address and to put AGP memory where it is mirrored by the AGP GART, as, presumably, this does not overlap with system RAM or any of other sensitive areas. My understanding is that dev->agp->base is the address where the AGP GART mirrors the pieces of system RAM comprising AGP space. Of course, these are somewhat bogus on 64 bit system. The memory controller *always* assumes that system RAM (accessible via PCI) starts at 0. So, if RADEON_MC_FB_LOCATION, for example, is set to 0 then we have video RAM overlapping system RAM. However, the size of video RAM is usually much smaller than the size of system RAM. So if the scratch registers image in system memory had small physical address you might get a lockup and if it was high you don't. You also would be more likely to get a lockup when load on system memory increased. Hmm. The way RADEON_MC_(FB|AGP)_LOCATION are programmed, it seems to be like they actually consist of two 16 bit fields, one indicating the start of the FB/AGP area, the other indicating the end. They are always programmed in rather large memory units. Do you know what happens when the programmed size of the FB area is larger than the physical size of video RAM? What happens when the programmed size of the AGP area is larger than the size of the AGP aperture? This problem has been fixed for plain Radeon drivers, but it could be that something similar is manifesting again on R300.. How did that fix work? Eventually the DRM driver was able to reprogram memory controller on request. So by default it used the usual setup (DISPLAY_BASE at 0) and it switched to reasonable setup when requested. The reasons for such behaviour are: * older mesa drivers did not know about reprogramming (and drm is separate from Mesa) * framebuffer does not know about reprogramming * *all* video BIOSes that I have seen always set DISPLAY_BASE to 0. so this is a "safe" mode (which completely precludes DMA from/to the first N megabytes of system memory where N is the size of video aperture). best Vladimir Dergachev cu, Nicolai --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
