[Bug 18335] New: [855GM regression] broken DRI with newer drivers
http://bugs.freedesktop.org/show_bug.cgi?id=18335 Summary: [855GM regression] broken DRI with newer drivers Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/i915 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] Created an attachment (id=19988) -- (http://bugs.freedesktop.org/attachment.cgi?id=19988) Xorg.0.log $ LIBGL_DEBUG=1 glxgears libGL error: Can't open configuration file /etc/drirc: No such file or directory. Failed to initialize TTM buffer manager. Falling back to classic. [intel_init_bufmgr:500] Error initializing buffer manager. X Error of failed request: BadAlloc (insufficient resources for operation) Major opcode of failed request: 155 (GLX) Minor opcode of failed request: 3 (X_GLXCreateContext) Serial number of failed request: 30 Current serial number in output stream: 32 kernel: 2.6.26 libdrm: 2.4.1 (same with 2.4.0 too) mesa: 7.2 intel: 2.5.0 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 11938] New: Switch to VESA mode hangs on HD4850
http://bugzilla.kernel.org/show_bug.cgi?id=11938 Summary: Switch to VESA mode hangs on HD4850 Product: Drivers Version: 2.5 KernelVersion: 2.6.27.4 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI) AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Latest working kernel version: 2.6.19 Earliest failing kernel version: No idea Distribution: Debian Lenny Hardware Environment: Athlon X2 5600, Asus m2m32ws prof, 4GB, HD4580 gfx Software Environment: Problem Description: I habe a new Club 3D ATI HD4850 (OC edition), that refuses to activate VESA mode. I don't get an error message, it just hangs forever with x.org 7.2 vesa driver. Also no boot time logo or in fact text output when compliling for framebuffer and seting vga=anything in the mode question. Reboot with CTRL-ALD-DEL still works, which is nice. The strange thing is that it worked for 2 days or so and then stopped, despite no updates to the Linux installation that I can recall. (I also run XP on this machine, if the Windows driver can screw the card up so that even removal and re-instertion does not help, that may be the source of the problem...). I tried with the lates non DVD Knoppix, and it works. That is Kernel 2.6.19. Unfortunately I cannot compile a kernel this old on Lenny (dome linking error at the end). I downloaded all the Changelogs between 2.6.19 and 2.4.27.4 and looked for VESA, but could not identify a change that is likely to have caused this problem. Any advice as which kernels I should try? Any debugging advice? Side note: The ATI drivers do not work with 2.6.27.* either, and I rather would not use them anyways. Steps to reproduce: Compile kernel with VESA framebuffer support, see system not display any text after switching to VESA mode. Not hang, as rebooting still works, just no display. Also see hanging forever with x.org 7.2 VESA driver. -- Configure bugmail: http://bugzilla.kernel.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 the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 11938] Switch to VESA mode hangs on HD4850
http://bugzilla.kernel.org/show_bug.cgi?id=11938 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED], [EMAIL PROTECTED] Regression|0 |1 --- Comment #1 from [EMAIL PROTECTED] 2008-11-01 17:38 --- eww, ugly. How can something work for two days then magically stop? Perhaps some mysterious hardware failure? The best I can suggest wold be a git bisection search (http://www.kernel.org/doc/local/git-quick.html), which will be fairly painful. -- Configure bugmail: http://bugzilla.kernel.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 the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 18347] New: intelReadPixels needs to wait for hardware
http://bugs.freedesktop.org/show_bug.cgi?id=18347 Summary: intelReadPixels needs to wait for hardware Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/i915 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] Created an attachment (id=20001) -- (http://bugs.freedesktop.org/attachment.cgi?id=20001) Patch as described With the current intel driver, small 1x1 pixel reads often (perhaps even usually) give the wrong result. I think the problem is that when the code falls back to _swrast_ReadPixels(), it doesn't wait for the GPU to finish. The patch I'll attach here adds an intelFinish() call before calling _swrast_ReadPixels(). It fixes the problems I'm observing. Comments: - I think the intelFlush() call at the beginning of of intelReadPixels() can be removed. do_blit_readpixels() calls intelFlush() itself, as does intelFinish(). Performance difference for doing so is probably minimal. - intelFinish() does a bit more than is necessary, since it waits for rendering to all color buffers to finish, not just the one we are going to read from. Seems unlikely to matter, since presumably the last thing done before glReadPixels() is to render to the buffer you are going to read from. - I don't see where do_blit_readpixels() waits for the blit it emitted to finish, but I don't have a test case for that code path, and maybe that happens implicitly or in the upper layers. - I don't know the code at all, so please double check for sanity :-) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
