From: Steven W. <srw...@ya...> - 2002-07-23 18:06:09
|
On Tue, Jul 23, 2002 at 07:05:14PM +0200, Charl P. Botha wrote: > Michel D?nzer and I spent some more time on this bug today. After having > mucked around with some of the AGP settings (with no success), I did a pre- > and post-crash "lspci -vvv". The video card was leaving bus mastering mode > when X switched to the console! It seems this is the root of the VT > switching bug, at least on my system. At least this specific condition is > easy to test for on the systems of users that experience this crash. > > So, appended is a patch that changes the RADEONEnterVT code in > radeon_driver.c so that it re-enables bus mastering mode. Michel has tested > it on his TiBook (which doesn't have the problem) and the patch doesn't seem > to break anything. > > Please apply to the DRI trunk and XFree86 CVS if you think this is > applicable. If you can keep my name in the source, I'll be even happer. > Yes, small things amuse small minds. ;) I have just tried your fix with a Radeon 7500 QW and have gotten some interesting, and perhaps hopeful, results. To summarize, this patch seems only the make the lock-ups less reproducible. Sometimes it takes 3, sometimes four, sometimes 2. I don't think I've gotten a lock on the first switch, yet. I'm using the radeonfb; I'll have to attempt without. Additionally, I'd like to see what, if any, effect XVidMode has, as it changed the situation before the fix. However, using radeonfb and with XVidMode enable, the lock-up IS STILL THERE. But I have a feeling you are now much closer. -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell This concept of "wuv" confuses and infuriates us! -- Lur of Omicron Persei VIII |
From: Charl P. B. <c.p...@it...> - 2002-07-23 18:43:57
|
On Tue, Jul 23, 2002 at 01:04:56PM -0500, Steven Walter wrote: > > So, appended is a patch that changes the RADEONEnterVT code in > > radeon_driver.c so that it re-enables bus mastering mode. Michel has tested > > it on his TiBook (which doesn't have the problem) and the patch doesn't seem > > to break anything. > > > > Please apply to the DRI trunk and XFree86 CVS if you think this is > > applicable. If you can keep my name in the source, I'll be even happer. > > Yes, small things amuse small minds. ;) > > I have just tried your fix with a Radeon 7500 QW and have gotten some > interesting, and perhaps hopeful, results. > > To summarize, this patch seems only the make the lock-ups less > reproducible. Sometimes it takes 3, sometimes four, sometimes 2. I > don't think I've gotten a lock on the first switch, yet. I'm using the > radeonfb; I'll have to attempt without. > > Additionally, I'd like to see what, if any, effect XVidMode has, as it > changed the situation before the fix. > > However, using radeonfb and with XVidMode enable, the lock-up IS STILL > THERE. But I have a feeling you are now much closer. Hmm, can you do a lspci -vvv before and after the crash? (if you have a machine from which you can ssh in to the crashed machine) In addition, also do a lspci -vvv just after you've switched to the VT. Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ |
From: Steven W. <srw...@ya...> - 2002-07-23 19:01:57
Attachments:
lspci-1
|
On Tue, Jul 23, 2002 at 08:43:28PM +0200, Charl P. Botha wrote: > Hmm, can you do a lspci -vvv before and after the crash? (if you have a > machine from which you can ssh in to the crashed machine) In addition, also > do a lspci -vvv just after you've switched to the VT. Attached are the results of lspci -vvv before a vt switch, i.e., from within X. The results of lspci after switching to vt1 are identical. Additionally, after the lock occurs, I cannot log in via serial console. Nor does kdb respond--the system is totally wedged. -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell This concept of "wuv" confuses and infuriates us! -- Lur of Omicron Persei VIII |
From: Charl P. B. <c.p...@it...> - 2002-07-23 19:07:07
|
On Tue, Jul 23, 2002 at 02:01:02PM -0500, Steven Walter wrote: > Attached are the results of lspci -vvv before a vt switch, i.e., from > within X. The results of lspci after switching to vt1 are identical. > Additionally, after the lock occurs, I cannot log in via serial console. > Nor does kdb respond--the system is totally wedged. > -- > -Steven > In a time of universal deceit, telling the truth is a revolutionary act. > -- George Orwell > This concept of "wuv" confuses and infuriates us! > -- Lur of Omicron Persei VIII > 01:05.0 VGA compatible controller: ATI Technologies Inc: Unknown device 5157 (prog-if 00 [VGA]) > Subsystem: Unknown device 174b:7161 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- ^^^^^^^^^^ the important bit... Does lspci -vvv also have BusMaster+ (and NOT BusMaster-) when you're still in the VT, i.e. before switching back to X? Also, which patch are you using? You XFree86.log and XF86Config-4 would also be highly appreciated. :) Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ |
From: Steven W. <srw...@ya...> - 2002-07-23 19:12:01
|
On Tue, Jul 23, 2002 at 09:05:16PM +0200, Charl P. Botha wrote: > > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- > ^^^^^^^^^^ the important bit... > > Does lspci -vvv also have BusMaster+ (and NOT BusMaster-) when you're still > in the VT, i.e. before switching back to X? Also, which patch are you > using? You XFree86.log and XF86Config-4 would also be highly appreciated. :) Config and log sent in a prior mail. Yes, that is the same. Not only did I specifically check that myself, but that's the kind of thing that 'diff' is really good at noticing ;-) I ran diff between the two versions, and it said they were identical. If it would put you more at ease, I could make sure the md5sums of both match <g> I'm beginning to think that we are working with more than one issue here. To remove any other variables, I will update my DRI trunk. -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell This concept of "wuv" confuses and infuriates us! -- Lur of Omicron Persei VIII |
From: Charl P. B. <c.p...@it...> - 2002-07-23 19:16:56
|
On Tue, Jul 23, 2002 at 02:11:23PM -0500, Steven Walter wrote: > > using? You XFree86.log and XF86Config-4 would also be highly appreciated. :) > > Config and log sent in a prior mail. > > Yes, that is the same. Not only did I specifically check that myself, > but that's the kind of thing that 'diff' is really good at noticing ;-) > I ran diff between the two versions, and it said they were identical. > If it would put you more at ease, I could make sure the md5sums of both > match <g> > > I'm beginning to think that we are working with more than one issue > here. To remove any other variables, I will update my DRI trunk. Your log looks pretty normal. I'm assuming that you're using at least 2.4.x agpgart and the DRM module from the DRI trunk (i.e. version 1.4.0, I think). Whatever the case may be, the fact that you're locking hard make me wonder. I don't know about what though. :) BTW, you have tried without the vidmode extension? -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ |
From: Charl P. B. <c.p...@it...> - 2002-07-23 19:08:59
|
On Tue, Jul 23, 2002 at 02:01:02PM -0500, Steven Walter wrote: > Attached are the results of lspci -vvv before a vt switch, i.e., from > within X. The results of lspci after switching to vt1 are identical. > Additionally, after the lock occurs, I cannot log in via serial console. > Nor does kdb respond--the system is totally wedged. One more thing... this is not consistent with what we were seeing of this crash. In all cases that I know of, the system was still reachable by network. -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ |
From: Steven W. <srw...@ya...> - 2002-07-23 18:48:16
|
On Tue, Jul 23, 2002 at 01:04:56PM -0500, Steven Walter wrote: > I have just tried your fix with a Radeon 7500 QW and have gotten some > interesting, and perhaps hopeful, results. > > To summarize, this patch seems only the make the lock-ups less > reproducible. Sometimes it takes 3, sometimes four, sometimes 2. I > don't think I've gotten a lock on the first switch, yet. I'm using the > radeonfb; I'll have to attempt without. > > Additionally, I'd like to see what, if any, effect XVidMode has, as it > changed the situation before the fix. > > However, using radeonfb and with XVidMode enable, the lock-up IS STILL > THERE. But I have a feeling you are now much closer. Okay, I have tried without xvidmode and without radeonfb, and the lockups still occur. Additionally, I have induced the lock-up on the first VT switch. Really, all this patch has accomplished for me is that sometimes, the patch occurs on the 3rd or 4th vt-switch, instead of reproducibly the first as before. It was noted that this patch was tried on a machine that didn't experience the problem, and that nothing broke. Has anyone actually tried the patch on a machine with the problem, and have the problem solved? If not, it seems to me that this patch doesn't buy us all that much. -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell This concept of "wuv" confuses and infuriates us! -- Lur of Omicron Persei VIII |
From: Charl P. B. <c.p...@it...> - 2002-07-23 18:59:15
|
On Tue, Jul 23, 2002 at 01:46:34PM -0500, Steven Walter wrote: > On Tue, Jul 23, 2002 at 01:04:56PM -0500, Steven Walter wrote: > > To summarize, this patch seems only the make the lock-ups less > > reproducible. Sometimes it takes 3, sometimes four, sometimes 2. I > > don't think I've gotten a lock on the first switch, yet. I'm using the > > radeonfb; I'll have to attempt without. > > > > Additionally, I'd like to see what, if any, effect XVidMode has, as it > > changed the situation before the fix. > > > > However, using radeonfb and with XVidMode enable, the lock-up IS STILL > > THERE. But I have a feeling you are now much closer. > > Okay, I have tried without xvidmode and without radeonfb, and the > lockups still occur. Additionally, I have induced the lock-up on the > first VT switch. > > Really, all this patch has accomplished for me is that sometimes, the > patch occurs on the 3rd or 4th vt-switch, instead of reproducibly the > first as before. > > It was noted that this patch was tried on a machine that didn't > experience the problem, and that nothing broke. Has anyone actually > tried the patch on a machine with the problem, and have the problem > solved? If not, it seems to me that this patch doesn't buy us all that > much. I have just tested on my laptop which had the problem (and which is why I started spending time on this in the first time). I've just done 13 VT switches, with and without glxgears running and have not been able to induce the crash. I'm even getting tired of VT switching... ;) Which patch are you using? The one I sent, or the one Michel committed? I am concerned (and Michel, correct me if I'm blundering) that the DRI commit has the bus master enable AFTER RADEONEngineRestore(). I am still interested to see the 3 lspci -vvv's, your XF86Config-4 and your XFree86.log. Thanks, Char -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ |
From: Carlos O'D. <ca...@ba...> - 2002-07-23 20:02:23
|
dri-devel, Just coming out of the woodwork to post a few ideas... It would be interesting to see if bus mastering gets disabled on any other PCI devices? Anyone have a PCI logic analyzer? :) Would it be the norm to expect that a VT switch (going through though the BIOS) would cause a BM disable in order to cancel pending transactions (similar to soft reset)? > > I have just tested on my laptop which had the problem (and which is why I > started spending time on this in the first time). I've just done 13 VT > switches, with and without glxgears running and have not been able to induce > the crash. I'm even getting tired of VT switching... ;) > > Which patch are you using? The one I sent, or the one Michel committed? I > am concerned (and Michel, correct me if I'm blundering) that the DRI commit > has the bus master enable AFTER RADEONEngineRestore(). The card can still be a PCI target and receive transations, it just can't initiate them until the BM enable call. If X is expecting that the card do memory reads or dma by itself, then you have a problem? :) > I am still interested to see the 3 lspci -vvv's, your XF86Config-4 and your > XFree86.log. > Thanks, > Char Cheers, Carlos. |
From: Charl P. B. <c.p...@it...> - 2002-07-23 20:29:45
|
On Tue, Jul 23, 2002 at 08:57:29PM +0200, Charl P. Botha wrote: > Which patch are you using? The one I sent, or the one Michel committed? I > am concerned (and Michel, correct me if I'm blundering) that the DRI commit > has the bus master enable AFTER RADEONEngineRestore(). I've tested with Michel's DRI commit and it's rock-solid. I can NOT make the machine crash by VT switching, no matter how many times I switch to VT and back. I even did the hitherto unthinkable (with this Radeon) and switched with a Viewperf 6.1.2 benchmark running. More testing anyone? Happiness, Charl Ps. Now on to making agpgart + dri work with swsusp, which was the whole point of this exercise. -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ |
From: Dieter <Die...@ha...> - 2002-07-23 18:08:51
|
On Tuesday 23 July 2002 19:52, Michel Dänzer wrote: > On Tue, 2002-07-23 at 19:05, Charl P. Botha wrote: > > Dear list, > > > > On Tue, Jul 16, 2002 at 11:02:05PM +0200, Charl P. Botha wrote: > > > This is just to add another sample to the Radeon switch to VT and back > > > X freeze bug, which is apparently known. > > > > Michel Dänzer and I spent some more time on this bug today. After having > > mucked around with some of the AGP settings (with no success), I did a > > pre- and post-crash "lspci -vvv". The video card was leaving bus > > mastering mode when X switched to the console! It seems this is the root > > of the VT switching bug, at least on my system. At least this specific > > condition is easy to test for on the systems of users that experience > > this crash. > > > > So, appended is a patch that changes the RADEONEnterVT code in > > radeon_driver.c so that it re-enables bus mastering mode. Michel has > > tested it on his TiBook (which doesn't have the problem) and the patch > > doesn't seem to break anything. > > > > Please apply to the DRI trunk and XFree86 CVS if you think this is > > applicable. > > I've committed a slightly modified version to the DRI trunk. Thanks for > putting all the time and energy into tracking this down! > > Now I wonder if the other drivers need the same; a recent r128 report > sounds similar, so I'll move it there as well, but what about the > others? Does anyone have an idea why bus mastering gets disabled? Michel, please send me your different one. I'll test it on the r200-0-1-branch with my 8500 QL and dual Athlon. Good work! -Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science @home: Die...@ha... |
From: Michel <mi...@da...> - 2002-07-23 21:34:04
Attachments:
radeon-busmaster.diff
|
On Tue, 2002-07-23 at 20:08, Dieter N=FCtzel wrote: > On Tuesday 23 July 2002 19:52, Michel D=E4nzer wrote: > > On Tue, 2002-07-23 at 19:05, Charl P. Botha wrote: > > > Dear list, > > > > > > On Tue, Jul 16, 2002 at 11:02:05PM +0200, Charl P. Botha wrote: > > > > This is just to add another sample to the Radeon switch to VT and b= ack > > > > X freeze bug, which is apparently known. > > > > > > Michel D=E4nzer and I spent some more time on this bug today. After = having > > > mucked around with some of the AGP settings (with no success), I did = a > > > pre- and post-crash "lspci -vvv". The video card was leaving bus > > > mastering mode when X switched to the console! It seems this is the = root > > > of the VT switching bug, at least on my system. At least this specif= ic > > > condition is easy to test for on the systems of users that experience > > > this crash. > > > > > > So, appended is a patch that changes the RADEONEnterVT code in > > > radeon_driver.c so that it re-enables bus mastering mode. Michel has > > > tested it on his TiBook (which doesn't have the problem) and the patc= h > > > doesn't seem to break anything. > > > > > > Please apply to the DRI trunk and XFree86 CVS if you think this is > > > applicable. > > > > I've committed a slightly modified version to the DRI trunk. Thanks for > > putting all the time and energy into tracking this down! > > > > Now I wonder if the other drivers need the same; a recent r128 report > > sounds similar, so I'll move it there as well, but what about the > > others? Does anyone have an idea why bus mastering gets disabled? >=20 > Michel, >=20 > please send me your different one. > I'll test it on the r200-0-1-branch with my 8500 QL and dual Athlon. Attached. --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
From: Dieter <Die...@ha...> - 2002-07-23 23:09:31
|
On Tuesday 23 July 2002 23:33, Michel Dänzer wrote: > On Tue, 2002-07-23 at 20:08, Dieter Nützel wrote: > > On Tuesday 23 July 2002 19:52, Michel Dänzer wrote: > > > On Tue, 2002-07-23 at 19:05, Charl P. Botha wrote: > > > > Dear list, > > > > > > > > On Tue, Jul 16, 2002 at 11:02:05PM +0200, Charl P. Botha wrote: > > > > > This is just to add another sample to the Radeon switch to VT and > > > > > back X freeze bug, which is apparently known. > > > > > > > > Michel Dänzer and I spent some more time on this bug today. After > > > > having mucked around with some of the AGP settings (with no success), > > > > I did a pre- and post-crash "lspci -vvv". The video card was leaving > > > > bus mastering mode when X switched to the console! It seems this is > > > > the root of the VT switching bug, at least on my system. At least > > > > this specific condition is easy to test for on the systems of users > > > > that experience this crash. > > > > > > > > So, appended is a patch that changes the RADEONEnterVT code in > > > > radeon_driver.c so that it re-enables bus mastering mode. Michel has > > > > tested it on his TiBook (which doesn't have the problem) and the > > > > patch doesn't seem to break anything. > > > > > > > > Please apply to the DRI trunk and XFree86 CVS if you think this is > > > > applicable. > > > > > > I've committed a slightly modified version to the DRI trunk. Thanks for > > > putting all the time and energy into tracking this down! > > > > > > Now I wonder if the other drivers need the same; a recent r128 report > > > sounds similar, so I'll move it there as well, but what about the > > > others? Does anyone have an idea why bus mastering gets disabled? > > > > Michel, > > > > please send me your different one. > > I'll test it on the r200-0-1-branch with my 8500 QL and dual Athlon. > > Attached. You guys are so GREAT! I've greped it from the trunk before you sent it and r200-0-1-branch is up and running. I can even switch VT forth and back when gears or Q3 are running. Mplayer with Xv extention was running, too. Weird thing was that the lspci -vvv output is always the same. Before VT switch after it with and without your patch? But it works and that is great. dual Athlon MP 1900+ MSI K7D Master-L (MS-6501, v1.0), AMD 760 MPX 1 GB DDR-SDRAM 266 CL ATI powered Radeon 8500 QL 00:00.0 Host bridge: Advanced Micro Devices [AMD]: Unknown device 700c (rev 11) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR- Latency: 32 Region 0: Memory at e8000000 (32-bit, prefetchable) [size=64M] Region 1: Memory at f0100000 (32-bit, prefetchable) [size=4K] Region 2: I/O ports at c400 [disabled] [size=4] Capabilities: [a0] AGP version 2.0 Status: RQ=15 SBA+ 64bit- FW- Rate=x1,x2 Command: RQ=0 SBA+ AGP+ 64bit- FW- Rate=<none> 01:05.0 VGA compatible controller: ATI Technologies Inc: Unknown device 514c (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc: Unknown device 013a Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 32 (2000ns min), cache line size 08 Interrupt: pin A routed to IRQ 17 Region 0: Memory at e0000000 (32-bit, prefetchable) [size=128M] Region 1: I/O ports at b000 [size=256] Region 2: Memory at ed000000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at <unassigned> [disabled] [size=128K] Capabilities: [58] AGP version 2.0 Status: RQ=47 SBA+ 64bit- FW+ Rate=x1,x2 Command: RQ=15 SBA+ AGP+ 64bit- FW- Rate=<none> Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- cat /proc/pci PCI devices found: Bus 0, device 0, function 0: Host bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] System Controller (rev 17). Master Capable. Latency=32. Prefetchable 32 bit memory at 0xe8000000 [0xebffffff]. Prefetchable 32 bit memory at 0xf0100000 [0xf0100fff]. I/O at 0xc400 [0xc403]. Bus 0, device 1, function 0: PCI bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] AGP Bridge (rev 0). Master Capable. Latency=32. Min Gnt=14. Bus 1, device 5, function 0: VGA compatible controller: ATI Technologies Inc Radeon QL (rev 0). IRQ 17. Master Capable. Latency=32. Min Gnt=8. Prefetchable 32 bit memory at 0xe0000000 [0xe7ffffff]. I/O at 0xb000 [0xb0ff]. Non-prefetchable 32 bit memory at 0xed000000 [0xed00ffff]. cat /proc/mtrr reg00: base=0x00000000 ( 0MB), size=1024MB: write-back, count=1 reg01: base=0xee000000 (3808MB), size= 4KB: write-combining, count=1 reg02: base=0xe0000000 (3584MB), size= 64MB: write-combining, count=2 reg05: base=0xe8000000 (3712MB), size= 64MB: write-combining, count=2 Now back to the clipping bug. > > > It seems to be window/context clipping. > > > I can move gears and gloss around in anyway over and behind normal KDE > > > windows but when every I try to move isosurf or trispd X locks like I've > > > posted. Same when I move a KDE Konsole over the trispd. > > This rather sounds like the lockup related to clipping which Tim > recently fixed or at least worked around on the trunk. Where do I have to look? When I move a glx window X locks up and symptoms are like described before. I have to blindly type reboot at the console to get VGA back. Page flip and Keith's performance counters do some window/background flickering. Thanks, Dieter |
From: Dieter <Die...@ha...> - 2002-07-23 23:35:21
|
On Wednesday 24 July 2002 01:09, Dieter Nützel wrote: > On Tuesday 23 July 2002 23:33, Michel Dänzer wrote: > > On Tue, 2002-07-23 at 20:08, Dieter Nützel wrote: > > > On Tuesday 23 July 2002 19:52, Michel Dänzer wrote: > > > > On Tue, 2002-07-23 at 19:05, Charl P. Botha wrote: > > > > > Dear list, > > > > > > > > > > On Tue, Jul 16, 2002 at 11:02:05PM +0200, Charl P. Botha wrote: > > > > > > This is just to add another sample to the Radeon switch to VT and > > > > > > back X freeze bug, which is apparently known. [-] > Now back to the clipping bug. > > > > > It seems to be window/context clipping. > > > > I can move gears and gloss around in anyway over and behind normal > > > > KDE windows but when every I try to move isosurf or trispd X locks > > > > like I've posted. Same when I move a KDE Konsole over the trispd. > > > > This rather sounds like the lockup related to clipping which Tim > > recently fixed or at least worked around on the trunk. > > Where do I have to look? > When I move a glx window X locks up and symptoms are like described before. > I have to blindly type reboot at the console to get VGA back. Addition: The "console" screen looks like a frozen copy of the latest X screen but I could relogin with xdm for two times. DRI was working. But after the next lockup I've tried moving ipers around I got only indirect rendering. Mesa/demos> ./glinfo GL_VERSION: 1.3 Mesa 4.0.3 GL_EXTENSIONS: GL_ARB_imaging GL_ARB_multitexture GL_ARB_texture_border_clamp GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_transpose_matrix GL_EXT_abgr GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_lod_bias GL_RENDERER: Mesa GLX Indirect GL_VENDOR: Mesa project: www.mesa3d.org GLU_VERSION: 1.3 GLU_EXTENSIONS: GLU_EXT_nurbs_tessellator GLU_EXT_object_space_tess GLUT_API_VERSION: 3 GLUT_XLIB_IMPLEMENTATION: 15 -Dieter |
From: Michel <mi...@da...> - 2002-07-24 00:14:23
|
On Wed, 2002-07-24 at 01:09, Dieter N=FCtzel wrote: > > > > It seems to be window/context clipping. > > > > I can move gears and gloss around in anyway over and behind normal = KDE > > > > windows but when every I try to move isosurf or trispd X locks like= I've > > > > posted. Same when I move a KDE Konsole over the trispd. > > > > This rather sounds like the lockup related to clipping which Tim > > recently fixed or at least worked around on the trunk. >=20 > Where do I have to look? programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/radeon_state.c, radeon_emit_packet3_cliprect(). BTW the dri-patches list is useful for this kind of information. > When I move a glx window X locks up and symptoms are like described befor= e. > I have to blindly type reboot at the console to get VGA back. I think Tim's fix addresses partly obscured 3D windows, but try and see. :) > Page flip and Keith's performance counters do some window/background=20 > flickering. Yes, pageflipping has issues. That's why it's still an option you have to enable. Or does this only happen with the performance counters? --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
From: Dieter <Die...@ha...> - 2002-07-24 14:51:27
|
On Wednesday 24 July 2002 02:14, Michel Dänzer wrote: > On Wed, 2002-07-24 at 01:09, Dieter Nützel wrote: > > > > > It seems to be window/context clipping. > > > > > I can move gears and gloss around in anyway over and behind normal > > > > > KDE windows but when every I try to move isosurf or trispd X locks > > > > > like I've posted. Same when I move a KDE Konsole over the trispd. > > > > > > This rather sounds like the lockup related to clipping which Tim > > > recently fixed or at least worked around on the trunk. > > > > Where do I have to look? > > programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/radeon_state.c, > radeon_emit_packet3_cliprect(). BTW the dri-patches list is useful for > this kind of information. Yes;-) But I've found the code in dri-devel. > > When I move a glx window X locks up and symptoms are like described > > before. I have to blindly type reboot at the console to get VGA back. > > I think Tim's fix addresses partly obscured 3D windows, but try and see. Didn't helped. > > Page flip and Keith's performance counters do some window/background > > flickering. > > Yes, pageflipping has issues. That's why it's still an option you have > to enable. Or does this only happen with the performance counters? It's on per default in the r200 tree. I'll try without, now. Thanks, Dieter |
From: Keith W. <ke...@tu...> - 2002-07-28 11:51:28
|
> > >>Page flip and Keith's performance counters do some window/background >>flickering. >> > > Yes, pageflipping has issues. That's why it's still an option you have > to enable. Or does this only happen with the performance counters? The issue that Dieter is probably seeing is the same as the flicker you get if you do a 'CTRL-ALT-{+-}' to change the mode on the fly, or if you use the mouse to pan around inside the virtual screen. Basically the X server clobbers a register that is set by the kernel. Keith |
From: Dieter <Die...@ha...> - 2002-07-28 16:53:09
|
On Sunday 28 July 2002 13:51, Keith Whitwell wrote: > >>Page flip and Keith's performance counters do some window/background > >>flickering. > > > > Yes, pageflipping has issues. That's why it's still an option you have > > to enable. Or does this only happen with the performance counters? > > The issue that Dieter is probably seeing is the same as the flicker you get > if you do a 'CTRL-ALT-{+-}' to change the mode on the fly, Sorry, Keith. A big NO, here. I "only" see the flicker as part of the "former" glx context "area" (window size and place) or the opposite (the background, root screen). It looks like a buffer issue. Ipers show them up, too. But I even can't drag ipers (or trispd) around 'cause X locks up immediately. When I drag gears around I have flickering yellow, brown and white bars laying all over the place. A screen refresh even during running gears fix it. I can switch back and forth VT's/X or change the mode on the fly (CTRL-ALT-{+-}) as many times I want without any flickering. All with the Xv extention enabled (Keith Packard) and playing some multi media content (mpeg with mplayer for example). Regards, Dieter BTW I own a Radeon 8500 QL (64 MB DDR-SDRAM, manufactured by PowerColor) with full feature support (SVGA, dual head, video editing etc.), now. Here are the lspci differences to my former test version: Entwicklung/OpenGL> diff lspci-Rüdiger.log lspci.log 10c10 < Command: RQ=0 SBA+ AGP+ 64bit- FW- Rate=<none> --- > Command: RQ=0 SBA+ AGP+ 64bit- FW- Rate=x2 50c50 < Subsystem: ATI Technologies Inc: Unknown device 013a --- > Subsystem: C.P. Technology Co. Ltd: Unknown device 2034 61c61 < Command: RQ=15 SBA+ AGP+ 64bit- FW- Rate=<none> --- > Command: RQ=15 SBA+ AGP+ 64bit- FW- Rate=x2 01:05.0 VGA compatible controller: ATI Technologies Inc: Unknown device 514c (prog-if 00 [VGA]) Subsystem: C.P. Technology Co. Ltd: Unknown device 2034 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 32 (2000ns min), cache line size 08 Interrupt: pin A routed to IRQ 17 Region 0: Memory at e0000000 (32-bit, prefetchable) [size=128M] Region 1: I/O ports at b000 [size=256] Region 2: Memory at ed000000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at <unassigned> [disabled] [size=128K] Capabilities: [58] AGP version 2.0 Status: RQ=47 SBA+ 64bit- FW+ Rate=x1,x2 Command: RQ=15 SBA+ AGP+ 64bit- FW- Rate=x2 Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Bus 1, device 5, function 0: VGA compatible controller: ATI Technologies Inc Radeon QL (rev 0). IRQ 17. Master Capable. Latency=32. Min Gnt=8. Prefetchable 32 bit memory at 0xe0000000 [0xe7ffffff]. I/O at 0xb000 [0xb0ff]. Non-prefetchable 32 bit memory at 0xed000000 [0xed00ffff]. |