linux-solo: drmCreateContext fails in DRM_IOCTL_ADD_CTX
hI - I'm trying to run linux-solo on Ubuntu 5.10 with kernel 2.6.15.1. This machine is a PIII and has an AGP radeon 9200SE (Rv280). I can boot into X and get direct rendering with this kernel and (newly compiled) modules. My drm modules are from cvs ca. 1/25/2006 I run the server and test app as root. I run sample_server, and all appears OK (using radeon_dri.so driver lib in miniglx.conf): [EMAIL PROTECTED]:/home/pdev/src/solo/Mesa/progs/miniglx# [miniglx] probed chipset 0x5964 got MMIOAddress 0xb7dfc000 offset 134217728 shared virtual width is 1280 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmGetBusid returned '' [drm] added 8192 byte SAREA at 0xd089b000 [drm] mapped SAREA 0xd089b000 to 0xb7dfa000, size 8192 [drm] framebuffer handle = 0xe000 [drm] register handle = 0xff8f [gart] AGP enabled at 2x [gart] 8192 kB allocated with handle 0x0001 [gart] ring handle = 0xf800 [gart] ring read ptr handle = 0xf8101000 [gart] vertex/indirect buffers handle = 0xf8102000 [gart] AGP texture map handle = 0xf8302000 Using 8 MB AGP aperture Using 1 MB for the ring buffer Using 2 MB for vertex/indirect buffers Using 1 MB for AGP textures Will use back buffer at offset 0x60 Will use depth buffer at offset 0xb0 Will use 114688 kb for textures at offset 0x100 in drmCreateContext [drm] Added 32 65536 byte vertex/indirect buffers [drm] dma control initialized, using IRQ 11 [drm] Initialized kernel gart heap manager, 5111808 color tiling disabled page flipping disabled [miniglx] Setting mode: visible 1280x1024 virtual 1280x1024x32 [miniglx] Readback mode: visible 1280x1024 virtual 1280x1024x32 RADEONEngineRestore Next I try to run miniglxtest (again as root) but get an error -- glxCreateContext fails, ultimately in drmCreateContext [EMAIL PROTECTED]:/home/pdev/src/solo/Mesa/progs/miniglx# ./miniglxtest [miniglx] probed chipset 0x5964 CreateNotify drmOpenByBusid: Searching for BusID PCI:1:0:0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: drmGetBusid reports PCI:1:0:0 Authorize - magic 1 drmCreateContext: err in ioctl, errno=13 >>> drmCreateContext failed Error: glXCreateContext failed DestroyNotify I trace the code to drm/libdrm/xf86drm.c: drmCreateContext In that method is an ioctl call, ioctl(fd, DRM_IOCTL_ADD_CTX, &ctx) Now I'm at my limit of understanding. I've placed some dbg stmts in the ioctl function (drm/linux-core/drm_context.c: drm_addctx()), and the ioctl method _appears_ to run to completion and return 0 (hence success). (I see these outputs in dmesg.) A check inside drmCreateContext shows that an error (13) is in fact returned by that method. An strace shows the following at the ioctl call: ioctl(4, 0xc0086420, 0xbfd0d758)= -1 EACCES (Permission denied) Well, I believe that, though I don't understand why I'm getting this error. I've read some comments on dri-devl from last summer regarding DRM and root/non-root privs. Could I be getting caught up by those requirements? Can anyone suggest how I debug/solve this problem? Thanks, Dan --- 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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5341] System locks up when starting X w/ DRI on a Radeon RV370 (X300)
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=5341 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #4488|text/plaini |text/plain mime type|| -- 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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5341] System locks up when starting X w/ DRI on a Radeon RV370 (X300)
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=5341 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #4488|application/octet-stream|text/plaini mime type|| -- 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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5341] System locks up when starting X w/ DRI on a Radeon RV370 (X300)
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=5341 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #4206 is|0 |1 obsolete|| Attachment #4214 is|0 |1 obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2006-01-28 05:08 --- Created an attachment (id=4488) --> (https://bugs.freedesktop.org/attachment.cgi?id=4488&action=view) new full debug messages from FreeBSD from serial console -- 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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5341] System locks up when starting X w/ DRI on a Radeon RV370 (X300)
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=5341 --- Additional Comments From [EMAIL PROTECTED] 2006-01-28 05:05 --- I got my X600 working under Linux/i386 with Ben's latests patches. I haven't tried it without them yet. However, DRI still doesn't work under FreeBSD/amd64. I had my serial console attached and got quite a lot debug data. It crashes in radeon_cp_init_ring_buffer() with gpf. I'll try to compile a debug kernel with all fancy debug data and find out the exact location. -- 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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Announce] DRIconf 0.9.0 released
Am Freitag, den 27.01.2006, 17:45 +0100 schrieb Michel Dänzer: > On Thu, 2006-01-26 at 23:24 -0500, Felix Kühling wrote: > > > > It is my pleasure to announce a new release of DRIconf, version 0.9.0 of > > the DRI configuration applet. The source and installation instructions > > can be found on the project homepage at > > http://dri.freedesktop.org/wiki/DriConf. Note that updated pre-packaged > > versions for Linux distributions are not available yet. > > The .deb is at http://incoming.debian.org/ now and will be in sid within > 24 hours. :) Nice. :-) > > > > This version introduces a completely redesigned user interface that is > > intended to be both simpler and more intuitive. If the old user > > interface resembled the GNOME configuration editor then the new one > > looks and feels much more like a configuration applet. Thus the big > > change in the version number. > > FWIW, I like the new UI much better (it reminded me that I > unintentionally overrode some settings for some apps :). My only > suggestion would be to hide the default settings in both parts of the > UI, on the one hand so that it'll pick up changes to the default values, > and on the other hand because it would tidy up the upper part IMO. Matthew suggested to make the option descriptions shorter and add longer descriptions in a tool tip. That would tidy up the upper part but you'd still have the overview of all options. It may require a change in the drivers, though, and possibly a change of the configuration infrastructure itself. I'm going to look into this. I believe I can do this without breaking compatibility between old/new drivers and DRIconf version. > On a > slightly related note, a drag bar between the parts to change their > relative height might be nice. I don't like the drag-bar. In the old UI it tended to mess up the automatic widget space allocation and forced me to hard-code some widget and window sizes in pixels. If this is really an issue I might break out the application settings into a separate dialog instead. > > > Thanks for this great update, keep 'em coming! :) > Thanks for the feedback! Regards, Felix -- | 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://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Announce] DRIconf 0.9.0 released
On Thu, 2006-01-26 at 23:24 -0500, Felix Kühling wrote: > > It is my pleasure to announce a new release of DRIconf, version 0.9.0 of > the DRI configuration applet. The source and installation instructions > can be found on the project homepage at > http://dri.freedesktop.org/wiki/DriConf. Note that updated pre-packaged > versions for Linux distributions are not available yet. The .deb is at http://incoming.debian.org/ now and will be in sid within 24 hours. :) > This version introduces a completely redesigned user interface that is > intended to be both simpler and more intuitive. If the old user > interface resembled the GNOME configuration editor then the new one > looks and feels much more like a configuration applet. Thus the big > change in the version number. FWIW, I like the new UI much better (it reminded me that I unintentionally overrode some settings for some apps :). My only suggestion would be to hide the default settings in both parts of the UI, on the one hand so that it'll pick up changes to the default values, and on the other hand because it would tidy up the upper part IMO. On a slightly related note, a drag bar between the parts to change their relative height might be nice. Thanks for this great update, keep 'em coming! :) -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- 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://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: status
On Fri, 2006-01-27 at 08:47 +0100, Helge Hafting wrote: > Kristoffer wrote: > > > I'm thinking of trying the radeon driver again, but i'm wondering > > wether or not it will ever catch up with the fglrx driver on speed? > > You worry about speed, I wonder if it ever will catch up with software > rendering on stability. Graphichs acceleration, (and the occational > prerelease kernel) is the only that ever crash my machines. And yes, > I use sw rendering on any machine that have an occational hang. > > In either case, blame it on lack of documentation. I'll agree that this explains some stability issues, but IME performance is usually more a matter of the engineering effort spent on driver optimizations that aren't necessarily hardware specific. YMMV. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- 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://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes
> There should be no need to check for info->cursor_offset == 0 in the > cursor functions. Longer term, I think we should just reserve a static > FB region for the cursor upfront instead of going through all these > hoops with EXA. I had some dodgy stuff happening at things like shutdown/entervt/leavevt, so I preferred being extra-safe there, though they might indeed not be necessary. > Also, unless I'm missing something, you're removing the code that forces > the display priority to high for Radeon 7200. Oops ? Where did I miss that ? (which bit of code specifically ? If it's the hack that was in SetFBLocation, it's now in the bandwidth calc) > > > http://gate.crashing.org/~benh/radeon-memmap-drm-3.diff > > The way you handle backwards compatibility here is brilliant, thanks. > The only minor issue I see is that the setparam ioctl can be called by > unprivileged clients, but that applies to the existing colour tiling > part as well, and it may not be a problem thanks to the offset fixups. I'm not 100% sure yet of whta the clients may or may not do here, I'd be very happy if you could double check that part :) Ben. --- 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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage IX/Thinkpad T20: Lockup with DMA / Driver broken if bpp!=16
On 1/27/06, Michael Karcher <[EMAIL PROTECTED]> wrote: > Am Donnerstag, den 26.01.2006, 22:31 +0100 schrieb Michael Karcher: > > Am Donnerstag, den 26.01.2006, 14:05 -0700 schrieb Brian Paul: > > > I don't have a Savage card to test anything myself. Looks like the > > > driver's ColorMask code depends on the card model. Which card are you > > > using? > > As the subject says, it is a Savage IX built into a Thinkpad T20. I > > probably should add that I am using 16bpp, which makes bitmask errors > > possible. > I now tried other depths, which just showed another bunch of problems. > If I switch to 24bpp, I get really funny colors in 2D mode, they change > with the xgamma setting. I guess the gamma correction tables are messed > up. 3D acceleration produces very strange results (picture width > horizontally half of what it should be, distorted geometry and colors) > which give the impression that some part of hard- or software is > assuming 2 bytes per pixel instead of four. > Software fallback (as Felix mentioned) in the red/blue stereo case works > OK (except for the funny colors already seen in 2D), and looks the same > as with LIBGL_ALWAYS_INDIRECT, but of course it is slow. > > After that experience I tried 15bpp. In this case 2D looks quite OK. The > gradient in the window title of my sawfish theme looks a bit odd with > too much red mixed in some steps, but that might be an application bug. > 3D acceleration does not work correctly, as warning messages of libgl > already say "driver claims to not support visual 0x..". The output of 3D > acceleration looks like it is meant for 16bpp. Software fallback in the > red/blue-stereo case does *not* work correctly: The image width doubles, > and at some time the application crashes. It looks like rendering for > 32bpp, which might be OK. > Only depth 16 and 24 are accelerated. Alex > A final note to the 16bpp case: The performance of xmakemol and the > User-to-system CPU usage ratio seem to indicate the software fallback, > so the question remains: Why is the output wrong? > > Michael Karcher > > --- 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://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage IX/Thinkpad T20: Lockup with DMA
On 1/27/06, Michael Karcher <[EMAIL PROTECTED]> wrote: > Am Donnerstag, den 26.01.2006, 13:38 -0500 schrieb Alex Deucher: > > On 1/26/06, Michael Karcher <[EMAIL PROTECTED]> wrote: > > > Hello DRI developers, > > > > > > on my ThinkPad T20, I experience Lockups with either type of DMA, be it > > > Vertex DMA or AGP texture access. With and > > > glxgears runs perfectly, as does glxinfo, whereas > > > ppracer locks up the system at start (supposedly because of using AGP > > > texturing). If I add , everything works as > > > expected. > > It's a known problem with savage based thinkpads and AGP. I was never > > able to track it down. you might try messing with the shadowstatus > > option. I want to say that may be related, but it's been a while > > since I looked into it. > > I already use ShadowStatus on, as the machine locked up on around 70% of > X server start attempts (with DRI on) if I didn't (The lockup was even > before the video memory is cleared). I didn't explicitly mention it, > because ShadowStatus on is the default option if DRI is enabled for > quite some time now. > > However, thanks for that hint. I was going to say try forcing it off (I think the windows driver does this on thinkpads), but if you get lockups, I guess that's not an option. Alex > > Regards, > Michael Karcher > > --- 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://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5737] Textrel in radeon_dri.so prevents useful modules for hardened systems
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=5737 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2006-01-28 01:02 --- Well, I got past it I think. It is exactly as was said in comment #2, the thing isn't precompiled. It had not linked against the textrel freee libGL.so.1.2 that existed in my build, however, so radeon_dri.so actually had a textrel from that library. At least I _think_ that's what happened. This is cleared - I now have a textrel free radeon_dri.so installed everywhere it matters. But I still can't load the kernel modules unrecognised symbol drm_cleanup_pci -- 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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage IX/Thinkpad T20: Lockup with DMA / Driver broken if bpp!=16
Am Freitag, den 27.01.2006, 11:33 +0100 schrieb Michael Karcher: > Am Donnerstag, den 26.01.2006, 22:31 +0100 schrieb Michael Karcher: > > Am Donnerstag, den 26.01.2006, 14:05 -0700 schrieb Brian Paul: > > > I don't have a Savage card to test anything myself. Looks like the > > > driver's ColorMask code depends on the card model. Which card are you > > > using? > > As the subject says, it is a Savage IX built into a Thinkpad T20. I > > probably should add that I am using 16bpp, which makes bitmask errors > > possible. > I now tried other depths, which just showed another bunch of problems. > If I switch to 24bpp, I get really funny colors in 2D mode, they change > with the xgamma setting. I guess the gamma correction tables are messed > up. 3D acceleration produces very strange results (picture width > horizontally half of what it should be, distorted geometry and colors) > which give the impression that some part of hard- or software is > assuming 2 bytes per pixel instead of four. > Software fallback (as Felix mentioned) in the red/blue stereo case works > OK (except for the funny colors already seen in 2D), and looks the same > as with LIBGL_ALWAYS_INDIRECT, but of course it is slow. If the color depth makes a difference then it could be related to the z-buffer depth or maybe color dithering. There is nothing you can do about the z-buffer depth (on Savage4 you could experiment with a floating-point z-buffer). But try disabling color dithering in DRIconf. Regards, Felix > > After that experience I tried 15bpp. In this case 2D looks quite OK. The > gradient in the window title of my sawfish theme looks a bit odd with > too much red mixed in some steps, but that might be an application bug. > 3D acceleration does not work correctly, as warning messages of libgl > already say "driver claims to not support visual 0x..". The output of 3D > acceleration looks like it is meant for 16bpp. Software fallback in the > red/blue-stereo case does *not* work correctly: The image width doubles, > and at some time the application crashes. It looks like rendering for > 32bpp, which might be OK. > > A final note to the 16bpp case: The performance of xmakemol and the > User-to-system CPU usage ratio seem to indicate the software fallback, > so the question remains: Why is the output wrong? > > Michael Karcher > > > > --- > 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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > -- > ___ > Dri-devel mailing list > Dri-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel > > -- | 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://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes
Hi Ben, haven't got around to testing the patches, but they basically look good to me. Some comments: On Fri, 2006-01-27 at 12:15 +1100, Benjamin Herrenschmidt wrote: > > > http://gate.crashing.org/~benh/radeon-memmap-7.0-2.diff There should be no need to check for info->cursor_offset == 0 in the cursor functions. Longer term, I think we should just reserve a static FB region for the cursor upfront instead of going through all these hoops with EXA. Also, unless I'm missing something, you're removing the code that forces the display priority to high for Radeon 7200. > http://gate.crashing.org/~benh/radeon-memmap-drm-3.diff The way you handle backwards compatibility here is brilliant, thanks. The only minor issue I see is that the setparam ioctl can be called by unprivileged clients, but that applies to the existing colour tiling part as well, and it may not be a problem thanks to the offset fixups. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- 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://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes
On Fri, 2006-01-27 at 12:52 +0100, Michel Dänzer wrote: > > On Fri, 2006-01-27 at 12:15 +1100, Benjamin Herrenschmidt wrote: > > > > > http://gate.crashing.org/~benh/radeon-memmap-7.0-2.diff > > There should be no need to check for info->cursor_offset == 0 in the > cursor functions. ... with current xserver/xorg CVS. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- 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://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5737] Textrel in radeon_dri.so prevents useful modules for hardened systems
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=5737
--- Additional Comments From [EMAIL PROTECTED] 2006-01-27 22:10 ---
Let's clarify. I'm no programmer. I'm a user. I'm not into making political
points anywhere. I was reporting what (from my viewpoint) was a bug, in that
textrels are in the latest cvs. I installed a cvs client and checked out the
source yesterday, and textrels were compiled into that.
Xorg-6.9.0 was built with the patch on bug 4197 applied to mesa
I found a textrel in
The radeon tarball radeon-20060125-linux.i386, (precompiled radeon_dri.so)
the cvs compiled from source, and
xcbuild/lib/GL/mesa/drivers/dri/radeon
Because of this, DRI will never work here. I have a version og libGL.so.1.2
without textrels or assembler and I, and all users of hardened systems, would
love a patch or workaround and accept the speed penalty without complaint. As it
is, I get this: ('modprobe radeon ' issued as a command)
Jan 27 18:30:34 genius kernel: kobject_register failed for drm (-17)
Jan 27 18:30:34 genius kernel: [kobject_register+107/128]
Jan 27 18:30:34 genius kernel: [mod_sysfs_setup+80/192]
Jan 27 18:30:34 genius kernel: [load_module+2700/2944]
Jan 27 18:30:34 genius kernel: [sys_init_module+133/512]
Jan 27 18:30:34 genius kernel: [syscall_call+7/11]
Jan 27 18:30:50 genius kernel: kobject_register failed for drm (-17)
Jan 27 18:30:50 genius kernel: [kobject_register+107/128]
Jan 27 18:30:50 genius kernel: [mod_sysfs_setup+80/192]
Jan 27 18:30:50 genius kernel: [load_module+2700/2944]
Jan 27 18:30:50 genius kernel: [sys_init_module+133/512]
Jan 27 18:30:50 genius kernel: [syscall_call+7/11]
Jan 27 18:30:50 genius kernel: radeon: Unknown symbol drm_cleanup_pci
That last line worries me. drm.ko is loaded first, as loading it manually first
produces the same errors as 'modprobe radeon'.
Libs with TEXTRELs won't load here. End of story. Kernel modules are compiled
with CC="gcc -no-pie -fno-stack-protector-all" to maintain consistency with
the kernel compile. Hardened LFS compiles X this way
http://www.linuxfromscratch.org/hlfs/view/unstable/glibc/x/xorg.html
I have all the sed commands, none of those patches, but the patch from bug 4197
and a few incidental workarounds (bug #5582)
If you guys did a version once every few months that is textrel free, I'm sure
that would satisfy all hardened system users. Or hang patches somewhere.
Or perhaps an extra Makefile target. We just want to get going.
--
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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: front/back buffer offsets in DRM
On Mon, 28 Nov 2005 02:59:05 +0100 Roland Scheidegger <[EMAIL PROTECTED]> wrote: > Felix Kühling wrote: > >>>Whats the point of doing these operations in DRM anyway? > >>>Personally I would just pull out as much code from there as possible. > >> > >>I was wondering about that too. There may be some reason for doing > >>those things in the kernel, but I don't know of any. > > > > > > At least on some hardware buffer clearing and swapping is done by the 2D > > engine. Instead of exposing the necessary functionality through some > > generic blit or fill ioctls, specific clear and swap operations were > > implemented. The fact that the Xserver provides the offsets and pitches > > adds some sense of security by preventing untrusted clients from > > overwriting random memory. > > > > I believe it should be possible to replace clear and swap ioctls with > > generic blit and fill ioctls that do some range checking on their > > arguments. > You can't do that for "special" clears like the hyperz fast z clear on > radeons. It could probably still be moved to userspace though, but I'm > not too sure it makes a lot of sense. I think better long term plan would be to simulate 2d operations via standard opengl operations. That way we would get CopyTexSubImage* and similar operations accelerated with far less effort than by writing driver specific routines to do it. I agree on keeping the 2d routines around but you have to see that they are very limited in sense of what you can do with them. Another thing that bothers me is the amount of duplicate code around. radeon_cp_texture(), texrects uploads, and buffer swaps are just same operations done differently. -- Aapo Tahkola --- 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://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage IX/Thinkpad T20: Lockup with DMA
Am Donnerstag, den 26.01.2006, 13:38 -0500 schrieb Alex Deucher: > On 1/26/06, Michael Karcher <[EMAIL PROTECTED]> wrote: > > Hello DRI developers, > > > > on my ThinkPad T20, I experience Lockups with either type of DMA, be it > > Vertex DMA or AGP texture access. With and > > glxgears runs perfectly, as does glxinfo, whereas > > ppracer locks up the system at start (supposedly because of using AGP > > texturing). If I add , everything works as > > expected. > It's a known problem with savage based thinkpads and AGP. I was never > able to track it down. you might try messing with the shadowstatus > option. I want to say that may be related, but it's been a while > since I looked into it. I already use ShadowStatus on, as the machine locked up on around 70% of X server start attempts (with DRI on) if I didn't (The lockup was even before the video memory is cleared). I didn't explicitly mention it, because ShadowStatus on is the default option if DRI is enabled for quite some time now. However, thanks for that hint. Regards, Michael Karcher --- 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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage IX/Thinkpad T20: Lockup with DMA / Driver broken if bpp!=16
Am Donnerstag, den 26.01.2006, 22:31 +0100 schrieb Michael Karcher: > Am Donnerstag, den 26.01.2006, 14:05 -0700 schrieb Brian Paul: > > I don't have a Savage card to test anything myself. Looks like the > > driver's ColorMask code depends on the card model. Which card are you > > using? > As the subject says, it is a Savage IX built into a Thinkpad T20. I > probably should add that I am using 16bpp, which makes bitmask errors > possible. I now tried other depths, which just showed another bunch of problems. If I switch to 24bpp, I get really funny colors in 2D mode, they change with the xgamma setting. I guess the gamma correction tables are messed up. 3D acceleration produces very strange results (picture width horizontally half of what it should be, distorted geometry and colors) which give the impression that some part of hard- or software is assuming 2 bytes per pixel instead of four. Software fallback (as Felix mentioned) in the red/blue stereo case works OK (except for the funny colors already seen in 2D), and looks the same as with LIBGL_ALWAYS_INDIRECT, but of course it is slow. After that experience I tried 15bpp. In this case 2D looks quite OK. The gradient in the window title of my sawfish theme looks a bit odd with too much red mixed in some steps, but that might be an application bug. 3D acceleration does not work correctly, as warning messages of libgl already say "driver claims to not support visual 0x..". The output of 3D acceleration looks like it is meant for 16bpp. Software fallback in the red/blue-stereo case does *not* work correctly: The image width doubles, and at some time the application crashes. It looks like rendering for 32bpp, which might be OK. A final note to the 16bpp case: The performance of xmakemol and the User-to-system CPU usage ratio seem to indicate the software fallback, so the question remains: Why is the output wrong? Michael Karcher --- 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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: status
Kristoffer wrote: I'm thinking of trying the radeon driver again, but i'm wondering wether or not it will ever catch up with the fglrx driver on speed? You worry about speed, I wonder if it ever will catch up with software rendering on stability. Graphichs acceleration, (and the occational prerelease kernel) is the only that ever crash my machines. And yes, I use sw rendering on any machine that have an occational hang. In either case, blame it on lack of documentation. Helge Hafting --- 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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
