[Bug 5784] savage DRI: kernel oops when running glxgears in second X.org session
http://bugzilla.kernel.org/show_bug.cgi?id=5784 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||PATCH_ALREADY_AVAILABLE --- Additional Comments From [EMAIL PROTECTED] 2005-12-29 08:54 --- Tried http://dri.freedesktop.org/snapshots/savage-20051220-linux.i386.tar.bz2 and the kernel oops went away. I am glad that this was solved, but also annoyed that this drm version is not being pushed into the main kernel tree. Thanks anyway for the links. --- 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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5148] [r300] Stale texture data used on first rendering
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=5148 --- Additional Comments From [EMAIL PROTECTED] 2005-12-30 22:42 --- Shouldn't be Z, since this demo (and texenv as well, afaik) doesn't use Z. -- 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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5784] savage DRI: kernel oops when running glxgears in second X.org session
http://bugzilla.kernel.org/show_bug.cgi?id=5784 --- Additional Comments From [EMAIL PROTECTED] 2005-12-30 02:26 --- I have found out that not the very update to DRM version 1.0.1 keeps Mesa from segfaulting. As a matter of fact, what made the difference for me was loading the savage.ko module explicitly. Appending modprobe savage to rc.sysinit makes it impossible for me to reproduce the segmentation faults reported earlier. Before, I loaded the compiled savage.ko built from current DRI snapshots and corresponding to DRM version 1.0.1 via insmod. However, even loading the original kernel module delivered as part of kernel 2.6.14-1.1653_FC4 and corresponding to DRM version 1.0.0 makes the reported behaviour disappear. When you tried out the new DRM version, did you load the module by hand via insmod or did you copy it to /lib/modules/`uname -r`/kernel/drivers/char/drm? As pointed out above, even the current module works. At least when you modprobe it in rc.sysinit as I did. Setting the status to RESOLVED PATCH_ALREADY_AVAILABLE is hence a bit premature because after updating the kernel DRM, one might still encounter the reported problem. --- 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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5784] savage DRI: kernel oops when running glxgears in second X.org session
http://bugzilla.kernel.org/show_bug.cgi?id=5784 --- Additional Comments From [EMAIL PROTECTED] 2005-12-30 04:14 --- Essentially the same problem occurs after bootig from a Ubuntu 6.04 alpha Live CD. The (modular) X server release is 7.0.0 RC4. The bug is thus not Red Hat specific. I have been able to trigger one segmentation fault aborting the X session. Most of the time however, the glxgears window simply remains black. After a couple of seconds, glxgears aborts. There is an error message in dmesg: [4295522.874000] [drm:savage_bci_wait_event_shadow] *ERROR* failed! which points a the origin of the trouble. --- 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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5784] savage DRI: kernel oops when running glxgears in second X.org session
http://bugzilla.kernel.org/show_bug.cgi?id=5784 --- Additional Comments From [EMAIL PROTECTED] 2005-12-30 02:19 --- It is going into the kernel.. I'm just not sure whats changed.. my git tree might have it already in it... the savage driver hasn't moved in 4 months or so... --- 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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5417] i915: initial scissor rect is empty
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=5417 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-12-30 23:59 --- Thanks for the test program - always a big help! Seems like there were a couple of problems in core mesa and the driver. I've committed fixes in both places. -- 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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5784] savage DRI: kernel oops when running glxgears in second X.org session
http://bugzilla.kernel.org/show_bug.cgi?id=5784 --- Additional Comments From [EMAIL PROTECTED] 2005-12-30 05:08 --- After rebuilding drm.ko and savage.ko from the current DRI snapshot savage-20051220-linux.i386.tar.bz2 and pushing the kernel modules into /lib/modules/`uname -r`/kernel/drivers/char/drm, I am not able to reproduce kernel oopses or segmentation faults as before. This seems to indicate that a corresponding kernel tree update might actually resolve the issue. In contrast with previous cases, I have spotted an aditional entry in /var/log/dmesg which reads: [drm] Used old pci detect: framebuffer loaded Hopefully, integration of the dri.freedesktop.org branch into the kernel tree and subsequent modifications won't alter the status quo. --- 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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FreeBSD CURRENT + DRM + agp_ati
Am Donnerstag, den 29.12.2005, 20:40 -0500 schrieb Adam K Kirchhoff: [snip] What's really bizarre, however, is that if I set hw.dri.0.debug to 1, glxgears gets roughly 200 FPS, faster than software Mesa, but slower than it can get (undoubtedly due to the massive amounts of debugging information that the kernel is logging). I tried a few more GL programs, all from the xscreensaver package. glforestfire also appear to display less than a frame per second. Same with flip-flop and flyingtoasters. flurry, on the other hand, is quite smooth and the FPS meter shows roughly 30 fps. Any ideas? Thanks! So not only does setting the debug sysctl seem to affect the framerate, so does displaying the framerate within the application. If I launch any of those xscreensaver apps with the -fps option (including flurry, glforestfire, flipflop, queens, and flyingtoasters), I get quite reasonable framerates. If I launch them without the -fps option, I get 1 FPS if I'm lucky (and I mean that literally... The window only updates itself once every second, if that). -fps causes a software fallback which implies a glFinish. Without -fps it hits no software fallbacks and interrupt-based frame-throttling will be used. Maybe interrupts get lost so that you time-out in the frame-throttling code (radeon_wait_irq has a 3-second time-out ATM). That would explain low frame rates. With debugging output the waiting condition is probably true when it gets to radeon_wait_irq most of the time, so it doesn't have to wait - no time-out. Can you try playing with the fthrottle_mode option to test that theory anyway. fthrottle_mode=0 glxgears would run glxgears with busy-waiting instead of interrupts. Regards, Felix Here's the output from 'glxgears -info' with LIBGL_DEBUG set to verbose: [ [EMAIL PROTECTED] - ~ ]: glxgears -info libGL: XF86DRIGetClientDriverName: 4.0.1 radeon (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/radeon_dri.so drmOpenByBusid: Searching for BusID pci::01:05.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: drmGetBusid reports pci::01:05.0 libGL error: Can't open configuration file /etc/drirc: No such file or directory. GL_MAX_VIEWPORT_DIMS=4096/4096 GL_RENDERER = Mesa DRI Radeon 20051013 AGP 4x NO-TCL GL_VERSION= 1.3 Mesa 6.5 GL_VENDOR = Tungsten Graphics, Inc. GL_EXTENSIONS = GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_logic_op GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_EXT_convolution GL_EXT_copy_texture GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_histogram GL_EXT_packed_depth_stencil GL_EXT_packed_pixels GL_EXT_polygon_offset GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_stencil_wrap GL_EXT_subtexture GL_EXT_texture GL_EXT_texture3D GL_EXT_texture_compression_s3tc GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_rectangle GL_EXT_vertex_array GL_APPLE_packed_pixels GL_ATI_texture_env_combine3 GL_ATI_texture_mirror_once GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_MESA_ycbcr_texture GL_MESA_window_pos GL_NV_blend_square GL_NV_light_max_exponent GL_NV_texture_rectangle GL_NV_texgen_reflection GL_OES_read_format GL_SGI_color_matrix GL_SGI_color_table GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_S3_s3tc 177 frames in 7.0 seconds = 25.286 FPS 4 frames in 6.0 seconds = 0.667 FPS 7 frames in 7.0 seconds = 1.000 FPS Adam -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FreeBSD CURRENT + DRM + agp_ati
Felix Kühling wrote: Am Donnerstag, den 29.12.2005, 20:40 -0500 schrieb Adam K Kirchhoff: [snip] What's really bizarre, however, is that if I set hw.dri.0.debug to 1, glxgears gets roughly 200 FPS, faster than software Mesa, but slower than it can get (undoubtedly due to the massive amounts of debugging information that the kernel is logging). I tried a few more GL programs, all from the xscreensaver package. glforestfire also appear to display less than a frame per second. Same with flip-flop and flyingtoasters. flurry, on the other hand, is quite smooth and the FPS meter shows roughly 30 fps. Any ideas? Thanks! So not only does setting the debug sysctl seem to affect the framerate, so does displaying the framerate within the application. If I launch any of those xscreensaver apps with the -fps option (including flurry, glforestfire, flipflop, queens, and flyingtoasters), I get quite reasonable framerates. If I launch them without the -fps option, I get 1 FPS if I'm lucky (and I mean that literally... The window only updates itself once every second, if that). -fps causes a software fallback which implies a glFinish. Without -fps it hits no software fallbacks and interrupt-based frame-throttling will be used. Maybe interrupts get lost so that you time-out in the frame-throttling code (radeon_wait_irq has a 3-second time-out ATM). That would explain low frame rates. With debugging output the waiting condition is probably true when it gets to radeon_wait_irq most of the time, so it doesn't have to wait - no time-out. Can you try playing with the fthrottle_mode option to test that theory anyway. fthrottle_mode=0 glxgears would run glxgears with busy-waiting instead of interrupts. Regards, Felix glxgears (and the few other GL apps I've just tried) runs much more like expected with fthrottle_mode set to 0 :-) Adam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
DRI card reinitialization after suspend
Howdy all! What is the present status of S3 suspend support in the DRI? I ask because my laptop locks up with a scrambled screen on resume from S3 standby when using the radeon driver with DRI enabled. This is a known problem with the DRI drivers and as such, at least one workaround has be devised. Supposedly, starting an X server before switching to the original X session after resume prevents the freeze, although I have been unable to verify this. Is there some missing code for state restoration/reinitialization of the card? I thought these (http://cpbotha.net/dri_resume.html) patches were supposed to solve the What would be the best way to start debugging this problem (littering the code with debug outputs sent over the network perhaps?)? What can I do (code) to make suspend support more reliable on the R300? Thanks a ton. - Ben P.S. R300 RENDER support is coming along nicely, although I have up to this point be primarily writing test-bench code so that I might better understand the workings of the card. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI card reinitialization after suspend
On Fri, 2005-12-30 at 13:27 -0500, Ben Gamari wrote: Howdy all! What is the present status of S3 suspend support in the DRI? I ask because my laptop locks up with a scrambled screen on resume from S3 standby when using the radeon driver with DRI enabled. This is a known problem with the DRI drivers and as such, at least one workaround has be devised. Supposedly, starting an X server before switching to the original X session after resume prevents the freeze, although I have been unable to verify this. Is there some missing code for state restoration/reinitialization of the card? I thought these (http://cpbotha.net/dri_resume.html) patches were supposed to solve the What would be the best way to start debugging this problem (littering the code with debug outputs sent over the network perhaps?)? What can I do (code) to make suspend support more reliable on the R300? Thanks a ton. Well, the DRI is supposed to be reinitialized by X from EnterVT() which is called when the system restores the VC of the server on wakeup from sleep... However, I've been having issue with that code. In fact, it's possible that your problem is related to the problems I'm trying to fix of MC_FB_LOCATION and MC_AGP_LOCATION being set to crap and overwritten in potentially conflicting ways between the server and the DRM (among others). P.S. R300 RENDER support is coming along nicely, although I have up to this point be primarily writing test-bench code so that I might better understand the workings of the card. Excellent ! --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
