[patch] fix small memory leak in ttm_memory.c
I moved the allocation until after the check for (si-totalhigh == 0).
regards,
dan carpenter
Signed-off-by: Dan Carpenter erro...@gmail.com
--- orig/drivers/gpu/drm/ttm/ttm_memory.c 2009-11-28 07:05:54.0
+0200
+++ devel/drivers/gpu/drm/ttm/ttm_memory.c 2009-11-28 07:07:52.0
+0200
@@ -274,16 +274,17 @@ static int ttm_mem_init_kernel_zone(stru
static int ttm_mem_init_highmem_zone(struct ttm_mem_global *glob,
const struct sysinfo *si)
{
- struct ttm_mem_zone *zone = kzalloc(sizeof(*zone), GFP_KERNEL);
+ struct ttm_mem_zone *zone;
uint64_t mem;
int ret;
- if (unlikely(!zone))
- return -ENOMEM;
-
if (si-totalhigh == 0)
return 0;
+ zone = kzalloc(sizeof(*zone), GFP_KERNEL);
+ if (unlikely(!zone))
+ return -ENOMEM;
+
mem = si-totalram;
mem *= si-mem_unit;
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: PROBLEM: radeon, kernel = 2.6.32-rc6-git5, any mode switch on MacBookPro2, 2 is delayed by 130 seconds of black screen
Yes, fbcon is compiled in. grep CONSOLE /boot/config-2.6.32-rc8 CONFIG_NETCONSOLE=m CONFIG_NETCONSOLE_DYNAMIC=y CONFIG_CONSOLE_TRANSLATIONS=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_VT_HW_CONSOLE_BINDING is not set CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_CORE_CONSOLE=y # CONFIG_LP_CONSOLE is not set CONFIG_VIRTIO_CONSOLE=y CONFIG_VGA_CONSOLE=y CONFIG_MDA_CONSOLE=m CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y == # CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y CONFIG_A11Y_BRAILLE_CONSOLE=y Viktor On Thursday 26 November 2009 10:57:10 am Alex Deucher wrote: The distorted image is expected if you don't have fbcon loaded. This happens when the vga engines are disables, but the crtcs are still active. Do you still have long delay with fbcon loaded or compiled in? Alex -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Weird suspend/resume problem on HP nx6325 w/ openSUSE 11.2 w/ -rc8
On Thu, Nov 26, 2009 at 5:04 PM, Rafael J. Wysocki r...@sisk.pl wrote: On Sunday 22 November 2009, Dave Airlie wrote: On Sun, Nov 22, 2009 at 9:15 AM, Rafael J. Wysocki r...@sisk.pl wrote: Hi, I'm not really sure where this should be reported, but here it goes. After installing openSUSE 11.2 on my testbed nx6325 I noticed that resume (from suspend to RAM) stopped working on it. Apparently, it hanged while switching from the console back to X and the box remained completely unresponsive after that (it didn't even react to the magic sysrq). However, it used to work just fine with -rc7 and openSUSE 11.1, so I figured the problem was related to the new X driver, which is radeon module version 6.12.4 (xorg server 1.6.5). So, I started to investigate and found that after a suspend from a framebuffer console, the resume had always worked. However, when I switched from X to the framebuffer console, suspended, resumed and switched back to X, the box hanged immediately just like during resume after a suspend from under X. [There also were some problems when switching from X to the framebuffer console and back which seemd to be independent of suspend/resume (in short, the screen stays black after a switch from the framebuffer console to X and you need to kill X to fix this).] You are using radeonfb on it? or vesafb? vesafb first test is to try without either of those installed. That doesn't change the behavior AFAICS. From memory though that machines an Xpress 200M Yes, it has this one. which is the the worst graphics card for use with open drivers and has always caused no-end of pain. Too bad. :-( Its also mostly undocumented when it comes to errata and workarounds. Well, so I guess this is a hardware errata. Still, it worked with the older X, so I wonder if I can make the new X work like the old one? Best, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From over here I was running the stable kernel on a freshly built clfs system, with the latest xorg from git suspend worked as is. Then loading the latest git kernel noticed the lagging of the wake up. When I get a chance I'll do a bisect and see If I come up with anything. -- Justin P. Mattock -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25142] touhou 11/12 run very slow in wine
http://bugs.freedesktop.org/show_bug.cgi?id=25142 --- Comment #20 from Maciej Cencora m.cenc...@gmail.com 2009-11-28 03:38:12 PST --- (In reply to comment #19) (In reply to comment #18) Created an attachment (id=31510) -- (http://bugs.freedesktop.org/attachment.cgi?id=31510) [details] [details] openarena console output Hmm, something's wrong - no cs is printed on the exit (and that's what the patch I've asked you to apply does). I am sure I applied it. Do you have libdrm_radeon installed? Yes: checking for LIBDRM_RADEON... yes Also attaching openarena output where I notice also: Mesa: User error: GL_INVALID_ENUM in glTexParameter(param=0x0) Darn. Looks like cs printing isn't implemented for UMS. I'll try reproducing the bug locally. The problem seems to be UMS specific, so please use KMS for now. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 21501] Assertion `lvl-size 0' failed.
http://bugs.freedesktop.org/show_bug.cgi?id=21501 rem11_1...@yahoo.fr changed: What|Removed |Added Attachment #31476|0 |1 is obsolete|| Attachment #31478|0 |1 is obsolete|| --- Comment #18 from rem11_1...@yahoo.fr 2009-11-28 07:28:14 PST --- Created an attachment (id=31535) -- (http://bugs.freedesktop.org/attachment.cgi?id=31535) scourge log New log -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 21501] Assertion `lvl-size 0' failed.
http://bugs.freedesktop.org/show_bug.cgi?id=21501 pa...@rojtberg.net changed: What|Removed |Added CC||fran...@gmail.com --- Comment #19 from pa...@rojtberg.net 2009-11-28 07:53:22 PST --- *** Bug 24080 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24080] Darwinia crashes in rv670 when starting a level
http://bugs.freedesktop.org/show_bug.cgi?id=24080 pa...@rojtberg.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from pa...@rojtberg.net 2009-11-28 07:53:22 PST --- yes, it is still valid *** This bug has been marked as a duplicate of bug 21501 *** -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Fri, 2009-11-27 at 17:23 -0800, vehemens wrote: On Sunday 22 November 2009 01:01:10 Dave Airlie wrote: On Sun, Nov 22, 2009 at 7:10 PM, vehemens vehem...@verizon.net wrote: On Saturday 21 November 2009 20:09:53 Dave Airlie wrote: I see that you deleted bsd-core dispite the requests of a number of people that you do not. Its git, nobody has touched any of it in ages, and none of the BSD maintainers used it, you can just get it back by branching from the commit before its removal, if you think revival is needed, don't bring back linux-core when you do please. I already told the both of you that I was planning to use it on IRC, I just haven't had time to put anything in. In addition, he's asking for a repro to libdrm. The way I see it, is there were two choices: 1) repro to libdrm, add the changes, not piss people off 2) add the changes, repro to libdrm, piss people off I think we pissed one person off, not people, as I said, there are two people registered as BSD maintainers for drm code, oga and rnoland, neither of them cared. I'm not sure what value the codebase has if neither Free or OpenBSD are going to use it. You pissed a number of people off, but the difference with me is that I'm not letting either of you get away with it. There are more then two BSD maintainers, and your statement that neither of them cared is not correct. Don't get me wrong here, I don't like the current state of things, but given current drm development practices, this change was irrelevant. I was a bit frustrated at the build breakage for libdrm, but krh and I worked through that and it is now resolved. While you have provided me with patches in the past, (which are much appreciated) I have not seen consistent or relevant work lately, so it really isn't clear to me how this is a big deal. Given the nature of git, you could just branch your local repo before that commit, though patches based on the old repo are becoming increasingly difficult to merge into real code. robert. Suggest that you actually read the emails and IRC comments. Your lack of understanding on the value of the codebase is not in general my problem, except when you impact myself and others as you have done this time. Why bother adding code to a common tree that no operating system has any intention of shipping ever. This simply isn't true. Please don't make statements that are obviously false. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- Robert Noland rnol...@2hip.net 2Hip Networks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sat, Nov 28, 2009 at 1:41 PM, Robert Noland rnol...@2hip.net wrote: On Fri, 2009-11-27 at 17:23 -0800, vehemens wrote: ... I think we pissed one person off, not people, as I said, there are two people registered as BSD maintainers for drm code, oga and rnoland, neither of them cared. I'm not sure what value the codebase has if neither Free or OpenBSD are going to use it. You pissed a number of people off, but the difference with me is that I'm not letting either of you get away with it. There are more then two BSD maintainers, and your statement that neither of them cared is not correct. Don't get me wrong here, I don't like the current state of things, but given current drm development practices, this change was irrelevant. I was a bit frustrated at the build breakage for libdrm, but krh and I worked through that and it is now resolved. That was my understanding of things as well. I wouldn't have dropped the linux-core or bsd-core subdirectories if there was still work going on there. Again, apologies for the build breakage and thanks for having the patience to help work it out. cheers, Kristian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Saturday 28 November 2009 10:41:39 Robert Noland wrote: On Fri, 2009-11-27 at 17:23 -0800, vehemens wrote: On Sunday 22 November 2009 01:01:10 Dave Airlie wrote: On Sun, Nov 22, 2009 at 7:10 PM, vehemens vehem...@verizon.net wrote: On Saturday 21 November 2009 20:09:53 Dave Airlie wrote: I see that you deleted bsd-core dispite the requests of a number of people that you do not. Its git, nobody has touched any of it in ages, and none of the BSD maintainers used it, you can just get it back by branching from the commit before its removal, if you think revival is needed, don't bring back linux-core when you do please. I already told the both of you that I was planning to use it on IRC, I just haven't had time to put anything in. In addition, he's asking for a repro to libdrm. The way I see it, is there were two choices: 1) repro to libdrm, add the changes, not piss people off 2) add the changes, repro to libdrm, piss people off I think we pissed one person off, not people, as I said, there are two people registered as BSD maintainers for drm code, oga and rnoland, neither of them cared. I'm not sure what value the codebase has if neither Free or OpenBSD are going to use it. You pissed a number of people off, but the difference with me is that I'm not letting either of you get away with it. There are more then two BSD maintainers, and your statement that neither of them cared is not correct. Don't get me wrong here, I don't like the current state of things, but given current drm development practices, this change was irrelevant. I was a bit frustrated at the build breakage for libdrm, but krh and I worked through that and it is now resolved. While you have provided me with patches in the past, (which are much appreciated) I have not seen consistent or relevant work lately, so it really isn't clear to me how this is a big deal. Given the nature of git, you could just branch your local repo before that commit, though patches based on the old repo are becoming increasingly difficult to merge into real code. I haven't published any of my work recently, but that doesn't mean I haven't done anything that I would like to share. Not sure why you feel this is important however. I gave you a number of suggestions in private emails on how to fix problems such as the merging issue and you were unwilling to take them. The whole point of having a public repository for code is collaboration that it allows. You seem to of lost sight of this goal. If you are unwilling or unable to do the work your self, you shouldn't prevent others from doing so. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25230] Starred sky rendering broken in celestia 1.6.1 with mesa 7.7 branch
http://bugs.freedesktop.org/show_bug.cgi?id=25230 Maciej Cencora m.cenc...@gmail.com changed: What|Removed |Added AssignedTo|dri-|m.cenc...@gmail.com |de...@lists.sourceforge.net | Status|ASSIGNED|NEW --- Comment #1 from Maciej Cencora m.cenc...@gmail.com 2009-11-28 12:42:21 PST --- Can you check if commit radeon: need to flush cs when moving images between mipmap trees fixes the problem? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 20176] [Wine Application Issue]: X hangs after coming out of game
http://bugs.freedesktop.org/show_bug.cgi?id=20176 --- Comment #1 from Maciej Cencora m.cenc...@gmail.com 2009-11-28 12:48:36 PST --- Can you still reproduce the bug with newest mesa and radeon ddx? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22758] Glest falls back to software rendering on radeon (rs690)
http://bugs.freedesktop.org/show_bug.cgi?id=22758 --- Comment #4 from Maciej Cencora m.cenc...@gmail.com 2009-11-28 12:56:00 PST --- Is this still an issue with mesa from mesa_7_7_branch? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
I haven't published any of my work recently, but that doesn't mean I haven't done anything that I would like to share. Not sure why you feel this is important however. I gave you a number of suggestions in private emails on how to fix problems such as the merging issue and you were unwilling to take them. The whole point of having a public repository for code is collaboration that it allows. You seem to of lost sight of this goal. If you are unwilling or unable to do the work your self, you shouldn't prevent others from doing so. You don't feel sending patches and having integration/testing phases with the tree users use is a good process? shared repos are good, but they do seem to lead to a commit first, review later (if at all) mentality. Dave. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24611] KMS: Plugging in only S-video locks up machine
http://bugs.freedesktop.org/show_bug.cgi?id=24611 --- Comment #12 from Pierre Ossman pierre-bugzi...@ossman.eu 2009-11-28 13:50:12 PST --- Oddly enough, the _EN bit doesn't seem to release under any circumstance. I've tried with the VGA connected instead of S-video, as well as both UMS and KMS. No configuration is able to get _EN to 0. As for the bug at hand, I discovered that if you disable unused stuff before setting the mode (instead of after, as is done now), things work fine. IOW, reading the vblank counter of CRTC 2 works fine until KMS starts fiddling with the settings. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24611] KMS: Plugging in only S-video locks up machine
http://bugs.freedesktop.org/show_bug.cgi?id=24611 --- Comment #13 from Pierre Ossman pierre-bugzi...@ossman.eu 2009-11-28 13:54:34 PST --- Commit 9c2f909ea437a63a408d2398ecabe0b378dbb982 from the userspace driver might also be interesting: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=9c2f909ea437a63a408d2398ecabe0b378dbb982 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Saturday 28 November 2009 13:44:53 Dave Airlie wrote: I haven't published any of my work recently, but that doesn't mean I haven't done anything that I would like to share. Not sure why you feel this is important however. I gave you a number of suggestions in private emails on how to fix problems such as the merging issue and you were unwilling to take them. The whole point of having a public repository for code is collaboration that it allows. You seem to of lost sight of this goal. If you are unwilling or unable to do the work your self, you shouldn't prevent others from doing so. You don't feel sending patches and having integration/testing phases with the tree users use is a good process? shared repos are good, but they do seem to lead to a commit first, review later (if at all) mentality. I think ... that sending patches and having integration/testing phases with the tree users ... is a good process Have to agree that the .. commit first, review later (if at all) mentality. is a bit of problem sometimes. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22852] [r300 KMS] modesetting not accepted by monitor
http://bugs.freedesktop.org/show_bug.cgi?id=22852 --- Comment #7 from Arno Schuring aelschur...@hotmail.com 2009-11-28 14:54:51 PST --- (In reply to comment #6) [...] There is just one slight issue remaining, though: after booting the second screen occasionally blinks, like it does when it switches video modes. This happens a few times during the first ten minutes of uptime, but I haven't seen this happening for the past 30 minutes. This flickering is caused by xrandr queries (gnome-settings-daemon does these, as do several SDL apps I've run). I can reproduce by simply typing xrandr (without options) in a terminal. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 21501] Assertion `lvl-size 0' failed.
http://bugs.freedesktop.org/show_bug.cgi?id=21501 --- Comment #20 from Maciej Cencora m.cenc...@gmail.com 2009-11-28 15:27:47 PST --- Created an attachment (id=31544) -- (http://bugs.freedesktop.org/attachment.cgi?id=31544) proposed patch Ok, I've found the what's causing these assertions to fail. Unfortunately current solution is to disable failing assertions. Proper solution would be to fix the FBOs handling. More info in the attached patch. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sat, 2009-11-28 at 13:38 -0800, vehemens wrote: On Saturday 28 November 2009 10:41:39 Robert Noland wrote: On Fri, 2009-11-27 at 17:23 -0800, vehemens wrote: On Sunday 22 November 2009 01:01:10 Dave Airlie wrote: On Sun, Nov 22, 2009 at 7:10 PM, vehemens vehem...@verizon.net wrote: On Saturday 21 November 2009 20:09:53 Dave Airlie wrote: I see that you deleted bsd-core dispite the requests of a number of people that you do not. Its git, nobody has touched any of it in ages, and none of the BSD maintainers used it, you can just get it back by branching from the commit before its removal, if you think revival is needed, don't bring back linux-core when you do please. I already told the both of you that I was planning to use it on IRC, I just haven't had time to put anything in. In addition, he's asking for a repro to libdrm. The way I see it, is there were two choices: 1) repro to libdrm, add the changes, not piss people off 2) add the changes, repro to libdrm, piss people off I think we pissed one person off, not people, as I said, there are two people registered as BSD maintainers for drm code, oga and rnoland, neither of them cared. I'm not sure what value the codebase has if neither Free or OpenBSD are going to use it. You pissed a number of people off, but the difference with me is that I'm not letting either of you get away with it. There are more then two BSD maintainers, and your statement that neither of them cared is not correct. Don't get me wrong here, I don't like the current state of things, but given current drm development practices, this change was irrelevant. I was a bit frustrated at the build breakage for libdrm, but krh and I worked through that and it is now resolved. While you have provided me with patches in the past, (which are much appreciated) I have not seen consistent or relevant work lately, so it really isn't clear to me how this is a big deal. Given the nature of git, you could just branch your local repo before that commit, though patches based on the old repo are becoming increasingly difficult to merge into real code. I haven't published any of my work recently, but that doesn't mean I haven't done anything that I would like to share. Not sure why you feel this is important however. Because unpublished work doesn't exist That goes for the work that I've done that isn't yet published as well. Until it is in the hands of someone besides yourself it is irrelevant. I gave you a number of suggestions in private emails on how to fix problems such as the merging issue and you were unwilling to take them. I'm not sure which issue you are referring to right now. But if you mean trying to backport the work of Intel, ATI/AMD and nouveau into a repository that all of the above have now abandoned, none who currently have commit to the drm repo are willing or able to take on that task. Did you miss my plea's, rants and attempts to make valid arguments not to reorganize/abandon drm in the first place? Unfortunately, we lost that battle. It only served to increase the complexity and workload that I am faced with. However, since every major vendor has now pulled out and maintains a private linux repo for their code, the code that lived in drm git was stale, and not terribly useful for anything other than historical purposes. If you are referring to the patches/diffs that you have sent me, then I have always appreciated the work that you have done. The last batch of stuff that you sent me, however was quite a mess. While there was some nice cleanup in it, it also contained at least some reversions of code specifically changed for FreeBSD. Even more of a problem than that was that what you sent me at the time was one big jumble and in no way represented a coherent set of patches that I could apply and commit to any repo. You did state at the time, that it was WIP, so perhaps you have a more coherent patch set now. I should have provided you with direct feedback when you sent me that work and for that I do appologize. The whole point of having a public repository for code is collaboration that it allows. You seem to of lost sight of this goal. This is IMHO, the good and bad of git. There is nothing that prevents you from taking your existing drm git and branching it prior to the removal of the code and publishing that on some other server. I would truly hope that it isn't your intent to try to provide an alternate FreeBSD drm build, though there is nothing to prevent it. If you are unwilling or unable to do the work your self, you shouldn't prevent others from doing so. Who would be contributing to this repo besides yourself? And who would be the consumer? For good or bad, the responsibility for drm in FreeBSD lands entirely on my head. I'm happy to review and accept patches based on the
[Bug 22852] [r300 KMS] modesetting not accepted by monitor
http://bugs.freedesktop.org/show_bug.cgi?id=22852 --- Comment #8 from Alex Deucher ag...@yahoo.com 2009-11-28 16:52:29 PST --- (In reply to comment #7) This flickering is caused by xrandr queries (gnome-settings-daemon does these, as do several SDL apps I've run). I can reproduce by simply typing xrandr (without options) in a terminal. When apps query randr, it probes the outputs for monitors. If no monitors are connected, the analog ports use load detection to check for monitors which causes a flicker. IIRC, a new randr call was added that just gets the current config rather than re-probing the outputs. You can disable load detection using xrandr: xrandr --output output --set load detection 0 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Saturday 28 November 2009 16:21:58 Robert Noland wrote: On Sat, 2009-11-28 at 13:38 -0800, vehemens wrote: On Saturday 28 November 2009 10:41:39 Robert Noland wrote: On Fri, 2009-11-27 at 17:23 -0800, vehemens wrote: On Sunday 22 November 2009 01:01:10 Dave Airlie wrote: On Sun, Nov 22, 2009 at 7:10 PM, vehemens vehem...@verizon.net wrote: On Saturday 21 November 2009 20:09:53 Dave Airlie wrote: I see that you deleted bsd-core dispite the requests of a number of people that you do not. Its git, nobody has touched any of it in ages, and none of the BSD maintainers used it, you can just get it back by branching from the commit before its removal, if you think revival is needed, don't bring back linux-core when you do please. I already told the both of you that I was planning to use it on IRC, I just haven't had time to put anything in. In addition, he's asking for a repro to libdrm. The way I see it, is there were two choices: 1) repro to libdrm, add the changes, not piss people off 2) add the changes, repro to libdrm, piss people off I think we pissed one person off, not people, as I said, there are two people registered as BSD maintainers for drm code, oga and rnoland, neither of them cared. I'm not sure what value the codebase has if neither Free or OpenBSD are going to use it. You pissed a number of people off, but the difference with me is that I'm not letting either of you get away with it. There are more then two BSD maintainers, and your statement that neither of them cared is not correct. Don't get me wrong here, I don't like the current state of things, but given current drm development practices, this change was irrelevant. I was a bit frustrated at the build breakage for libdrm, but krh and I worked through that and it is now resolved. While you have provided me with patches in the past, (which are much appreciated) I have not seen consistent or relevant work lately, so it really isn't clear to me how this is a big deal. Given the nature of git, you could just branch your local repo before that commit, though patches based on the old repo are becoming increasingly difficult to merge into real code. I haven't published any of my work recently, but that doesn't mean I haven't done anything that I would like to share. Not sure why you feel this is important however. Because unpublished work doesn't exist That goes for the work that I've done that isn't yet published as well. Until it is in the hands of someone besides yourself it is irrelevant. Thats the whole point of having a public respository. How else can one publish? I gave you a number of suggestions in private emails on how to fix problems such as the merging issue and you were unwilling to take them. I'm not sure which issue you are referring to right now. But if you mean trying to backport the work of Intel, ATI/AMD and nouveau into a repository that all of the above have now abandoned, none who currently have commit to the drm repo are willing or able to take on that task. Did you miss my plea's, rants and attempts to make valid arguments not to reorganize/abandon drm in the first place? Unfortunately, we lost that battle. It only served to increase the complexity and workload that I am faced with. However, since every major vendor has now pulled out and maintains a private linux repo for their code, the code that lived in drm git was stale, and not terribly useful for anything other than historical purposes. First you say abandoning the respository increased your workload, then you say it wasn't useful. Which is it? If you are referring to the patches/diffs that you have sent me, then I have always appreciated the work that you have done. The last batch of stuff that you sent me, however was quite a mess. While there was some nice cleanup in it, it also contained at least some reversions of code specifically changed for FreeBSD. Even more of a problem than that was that what you sent me at the time was one big jumble and in no way represented a coherent set of patches that I could apply and commit to any repo. You did state at the time, that it was WIP, so perhaps you have a more coherent patch set now. I should have provided you with direct feedback when you sent me that work and for that I do appologize. The WIP was sent to you because you had stalled on DRM development and didn't seem to moving forward. I'm surprized that you didn't understand the changes as they were fairly stright forward. The whole point of having a public repository for code is collaboration that it allows. You seem to of lost sight of this goal. This is IMHO, the good and bad of git. There is nothing that prevents you from taking your existing drm git and branching it prior to the
[Bug 25337] New: compressed texture uploading
http://bugs.freedesktop.org/show_bug.cgi?id=25337 Summary: compressed texture uploading Product: DRI Version: XOrg CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: bioinfornat...@gmail.com Dear sir, i use the mesa experimental and r600 on my Fedora 12, good job work fine, except compressed texture uploading are not supported .. i think. how can i help you more on this subject? if you want any information say me __ Computer-- Processor 4x AMD Phenom(tm) II X4 955 Processor Memory 4058MB (675MB used) Operating SystemFedora release 12 (Constantine) Display-- Resolution 2960x1050 pixels OpenGL Renderer Mesa DRI R600 (RV730 9490) 20090101 TCL X11 Vendor The X.Org Foundation Version-- Kernel Linux 2.6.31.5-127.fc12.x86_64 (x86_64) Compiled#1 SMP Sat Nov 7 21:11:14 EST 2009 C Library Unknown Default C Compiler GNU C Compiler version 4.4.2 20091027 (Red Hat 4.4.2-7) (GCC) DistributionFedora release 12 (Constantine) Display[/COLOR] Resolution 2960x1050 pixels Vendor The X.Org Foundation Version 1.7.1 Monitors--- Monitor 0 1680x1050 pixels Monitor 1 1280x1024 pixels OpenGL--- Vendor Advanced Micro Devices, Inc. RendererMesa DRI R600 (RV730 9490) 20090101 TCL Version 1.4 Mesa 7.7-devel Direct RenderingYes __ kind regards -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24047] s3tc broken on r600
http://bugs.freedesktop.org/show_bug.cgi?id=24047 Alex Deucher ag...@yahoo.com changed: What|Removed |Added CC||bioinfornat...@gmail.com --- Comment #5 from Alex Deucher ag...@yahoo.com 2009-11-28 23:47:36 PST --- *** Bug 25337 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
