[Bug 25580] New: [REGRESSION] drm/radeon/kms: [drm:radeon_fence_wait] *ERROR* fence(f6608d80:0x00000007) 510ms timeout
http://bugs.freedesktop.org/show_bug.cgi?id=25580 Summary: [REGRESSION] drm/radeon/kms: [drm:radeon_fence_wait] *ERROR* fence(f6608d80:0x0007) 510ms timeout Product: DRI Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: zaj...@gmail.com Day after splitting branches by Dave I switched to drm-radeon-testing and was using it successfully. Yesterday I did pull last changes and now my machine locks up in 70% tries of starting X. Unfortunately I did dmegs dmesg.log so I didn't catch messages before netconsole loading... Are attached messages enough? Sony VAIO FW11S M82 == RV620 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25580] [REGRESSION] drm/radeon/kms: [drm:radeon_fence_wait] *ERROR* fence(f6608d80:0x00000007) 510ms timeout
http://bugs.freedesktop.org/show_bug.cgi?id=25580 --- Comment #1 from Rafał Miłecki zaj...@gmail.com 2009-12-11 00:34:49 PST --- Created an attachment (id=31970) -- (http://bugs.freedesktop.org/attachment.cgi?id=31970) dmesg from starting X [ 44.039173] [drm:radeon_fence_wait] *ERROR* fence(f6608d80:0x0007) 510ms timeout going to reset GPU [ 44.039200] radeon :01:00.0: GPU softreset [ 44.039220] radeon :01:00.0: R_008010_GRBM_STATUS=0xA0003030 [ 44.039242] radeon :01:00.0: R_008014_GRBM_STATUS2=0x0003 [ 44.039263] radeon :01:00.0: R_000E50_SRBM_STATUS=0x20C0 [ 44.039289] radeon :01:00.0: R_008020_GRBM_SOFT_RESET=0x7FEE [ 44.039360] radeon :01:00.0: R_008020_GRBM_SOFT_RESET=0x0001 [ 44.039446] radeon :01:00.0: R_000E60_SRBM_SOFT_RESET=0x0402 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] TTM change buffer_object_init to use ttm_placement rather than flag
On Thu, Dec 10, 2009 at 08:51:07PM +0100, Thomas Hellstrom wrote: Jerome Glisse wrote: Hi, So here is a patch which convert bo_init to use struct ttm_placement rather than flag. It allow the driver to give placement preference on where to create a bo. Also allow to create a bo at specific range which is i believe somethings nouveau would like to see :) Aside from the change i renamed ttm_buffer_object_init|validate to ttm_bo_init|validate this is shorter but also more consistent with others functions naming. For consistency i would like to rename struct ttm_buffer_object to struct ttm_bo but this lead to massive regular expression abuse for everyone using ttm so before proposing a patch let me know if you like or not this. I haven't strong feeling on that except that this would allow to stay in the 80 line lenght in some place. Cheers, Jerome Jerome, this looks good and consistent with previous changes. In order to get the vmwgfx driver ready for upstream in the not too distant future we need a (temporarily) stable API. Is this patch targeted for 2.6.33? /Thomas I think i will do the massive rename for 2.6.34 so i am will be in charge of converting other driver, rather than putting any more burden on others driver. It's not very important it's just cleanup. Cheers. Jerome -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
I realize that you have some emotional attachments to Red Hat, but ask yourself (and answer honestly): what would you think if some random other distro was packaging tens of thousands of lines of kernel code and not apparently working at trying to get them upstream? Like Ubuntu does for a load of stuff and did for years ? I'd like to see stuff get upstream yes. The point you seem to be missing is you are ranting at the wrong people. I want to see it upstream too, but if you must shout at people do it productively at the right target. I would be cross if they were controlling and hiding it, but its sitting in a public repository, its maintained by a collection of people one of whom happens to work for Red Hat and anyone can grab it. It's vastly easier to get hold of than the userspace for some of the stuff in kernel. However the fundamental point stands. The only people who can sign it off are the people who wrote it. Those are the rules. Red Hat didn't write the code, Red Hat cannot sign it off however much you rant at them. You also previously said you don't want to merge stuff when the authors don't want it merged. If you like I can also dig out some Torvalds quotes about not wanting to dictate to distros. If you want to progress this then - Starting talking to the project *authors* - Help them decide what to do about the firmware stuff - If need be get the Linux Foundation, Red Hat and other relevant lawyers and people on a phone call with you so that legal issues can get discussed and you can shout at them as necessary too. I am not privy to what the lawyers think on this one. But I'd bet that the only way you'll get a full answer is in conjunction with lawyers speaking to lawyers, and the only way you'll get a sign off is when the lawyers say yes. Anything else would be rather irresponsible. And it's possible that other distros are doing the same thing. I happen to know that Fedora does it (and has been doing it for at least a year), because I happen to have an Intel development machine that runs Fedora and F11 certainly shipped some bits of it for 2D support. I am not sure if F10 shipped a purely userspace set up. Neither had it enabled as the default driver - they used nv or vesa depending upon the card. was shipped by Intel with an nVidia card (and has a power supply that craps out if you don't use several hundred watts of power, so I can't change it to something more power-efficient - seriously). Alan -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
From: Alan Cox a...@lxorguk.ukuu.org.uk Date: Fri, 11 Dec 2009 09:18:43 + However the fundamental point stands. The only people who can sign it off are the people who wrote it. Those are the rules. Red Hat didn't write the code, Red Hat cannot sign it off however much you rant at them. You also previously said you don't want to merge stuff when the authors don't want it merged. I agree with a lot of what you say. However, one point remains is that we were told, by Dave Airlie, that they didn't want this code merged because the one person being paid to work on it would be overwhelmed if the code went upstream. I distinctly remember this being mentioned at the kernel summit. And you know what? That kind of excuse pisses me off too :-) -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
On Fri, Dec 11, 2009 at 00:58, Alan Cox a...@lxorguk.ukuu.org.uk wrote: But not only is Fedora not following the rules, You changed the rules. You require a Signed-off-by:. Fedora can no more add a signed off by than you can. It's not their code nor Red Hat's code any more than they own the kernel because they pay someone to work on it. See above. It's not you. It's Fedora. If Fedora hadn't merged Nouveau and shipped it, I wouldn't care. And zillions of Nvidia users would have been worse off. It's really simple: if you want to merge it *you* pull it and sign it off. If you aren't prepared to do that then ask why Fedora should, its not their code either. So what, if someone outside RedHat is ok to sign it off, it can go into staging? If it's that simple I don't mind signing it off (including the dubious bits), I can take the blame if that helps things move forward. Stephane -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
On Fri, Dec 11, 2009 at 7:34 PM, David Miller da...@davemloft.net wrote: From: Alan Cox a...@lxorguk.ukuu.org.uk Date: Fri, 11 Dec 2009 09:18:43 + However the fundamental point stands. The only people who can sign it off are the people who wrote it. Those are the rules. Red Hat didn't write the code, Red Hat cannot sign it off however much you rant at them. You also previously said you don't want to merge stuff when the authors don't want it merged. I agree with a lot of what you say. However, one point remains is that we were told, by Dave Airlie, that they didn't want this code merged because the one person being paid to work on it would be overwhelmed if the code went upstream. I distinctly remember this being mentioned at the kernel summit. And you know what? That kind of excuse pisses me off too :-) Well the main thing was I wasn't mean to discuss possible legal issues and still don't have permission, you know as well as I do once lawyers are involved you have to keep out of things until they deal with them. but yes it is a side effect of upstreaming this code that other distros will start to place time demands on people who Red Hat employ but we were starting to see that anyways without upstreaming. It would be have been really nice if some of the distros would start to put their money behind what they want to ship instead of rhetoric[1]. Dave. [1] http://www.markshuttleworth.com/archives/95 -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
On 12/11/2009 04:18 AM, Alan Cox wrote: F11 certainly shipped some bits of it for 2D support. I am not sure if F10 shipped a purely userspace set up. Neither had it enabled as the default driver - they used nv or vesa depending upon the card. F11 uses nouveau here. It is actually a pain to get 'nv' going as an alternate -- bugs have been filed. Makes kernel dev more difficult for me. I was actually told, by Fedora people, that I should be hacking on the Fedora (rpm-based) kernel, rather than a 100% upstream kernel like I have been hacking/booting for the past decade, as a result of this setup (needing nouveau kernel support, thus needing Fedora rather than upstream kernel). Jeff -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
On Fri, Dec 11, 2009 at 8:28 PM, Jeff Garzik j...@garzik.org wrote: On 12/11/2009 04:18 AM, Alan Cox wrote: F11 certainly shipped some bits of it for 2D support. I am not sure if F10 shipped a purely userspace set up. Neither had it enabled as the default driver - they used nv or vesa depending upon the card. F11 uses nouveau here. It is actually a pain to get 'nv' going as an alternate -- bugs have been filed. Makes kernel dev more difficult for me. I was actually told, by Fedora people, that I should be hacking on the Fedora (rpm-based) kernel, rather than a 100% upstream kernel like I have been hacking/booting for the past decade, as a result of this setup (needing nouveau kernel support, thus needing Fedora rather than upstream kernel). It wouldn't have helped the ABI was broken between F11 and now, so you'd be in the same boat putting this code upstream via staging in no way means you can run it with the F11 userspace or ongoing even with the F12 one. Dave. Jeff -- 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/ -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
On Fri, 2009-12-11 at 01:34 -0800, David Miller wrote: From: Alan Cox a...@lxorguk.ukuu.org.uk Date: Fri, 11 Dec 2009 09:18:43 + You also previously said you don't want to merge stuff when the authors don't want it merged. However, one point remains is that we were told, by Dave Airlie, that they didn't want this code merged because the one person being paid to work on it would be overwhelmed if the code went upstream. I distinctly remember this being mentioned at the kernel summit. That reason for not merging seems to fall squarely in the authors don't want it merged category. Your point does highlight, though, that it is worth talking to the author directly to understand the obstacles, as Alan mentioned. Regards, Andy -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
On Fri, 2009-12-11 at 11:02 +0100, Stephane Marchesin wrote: On Fri, Dec 11, 2009 at 00:58, Alan Cox a...@lxorguk.ukuu.org.uk wrote: It's really simple: if you want to merge it *you* pull it and sign it off. If you aren't prepared to do that then ask why Fedora should, its not their code either. So what, if someone outside RedHat is ok to sign it off, it can go into staging? If it's that simple I don't mind signing it off (including the dubious bits), I can take the blame if that helps things move forward. Could not a NAK by the author stop that? Regards, Andy -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[git pull] drm pull - drm core prep for nouveau
Hi Linus, Please pull the 'drm-linus' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus These are some fixups to the TTM API required to pull the nouveau and vmware drivers into staging, along with a typo in radeon code. Dave. drivers/gpu/drm/radeon/radeon_drv.c|2 +- drivers/gpu/drm/radeon/radeon_object.c | 39 ++--- drivers/gpu/drm/ttm/ttm_bo.c | 134 ++- include/drm/ttm/ttm_bo_api.h | 63 +++ 4 files changed, 101 insertions(+), 137 deletions(-) commit d1ede145cea25c5b6d2ebb19b167af14e374bb45 Author: Ben Skeggs bske...@redhat.com Date: Fri Dec 11 15:13:00 2009 +1000 drm/ttm: export some functions useful to drivers using ttm These are functions required by nouveau which will be merged later. Signed-off-by: Ben Skeggs bske...@redhat.com Signed-off-by: Dave Airlie airl...@redhat.com commit 9062fa6612958f35f41379425bcae9c9b4ccd68e Author: Alex Deucher alexdeuc...@gmail.com Date: Wed Dec 9 19:38:58 2009 -0500 drm/radeon/kms/avivo: fix typo in new_pll module description Signed-off-by: Alex Deucher alexdeuc...@gmail.com Signed-off-by: Dave Airlie airl...@redhat.com commit 1fb107fc46692a000533da3d6904ac28b6b3148d Author: Jerome Glisse jgli...@redhat.com Date: Thu Dec 10 17:16:28 2009 +0100 drm/radeon/kms: Convert radeon to new ttm_bo_init Now bo init use placement structure like bo validation does. Signed-off-by: Jerome Glisse jgli...@redhat.com Signed-off-by: Dave Airlie airl...@redhat.com commit 09855acb1c2e3779f25317ec9a8ffe1b1784a4a8 Author: Jerome Glisse jgli...@redhat.com Date: Thu Dec 10 17:16:27 2009 +0100 drm/ttm: Convert ttm_buffer_object_init to use ttm_placement Convert ttm_buffer_object_init to use struct ttm_placement and rename to ttm_bo_init for consistency with function naming. This allow to give more complex placement at buffer creation. For instance you ask to allocate bo into vram first but if there is not enough vram you can give system as a second possible placement. It also allow to create buffer in a specific range. Also rename ttm_buffer_object_validate to ttm_bo_validate. Signed-off-by: Jerome Glisse jgli...@redhat.com Signed-off-by: Dave Airlie airl...@redhat.com -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[git pull] drm nouveau pony for Xmas.
Hi Linus, Please pull the 'drm-nouveau-pony' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-nouveau-pony This contains the nouveau driver with Kconfig under staging for now, the code is going under drm because the upstream tree has it there, and it makes passing patches a lot easier at least initially. Thanks to Ben Skeggs for doing overtime on his Friday evening to get the ctxprogs ripped out and firmware loader support added. The firmware is available elsewhere via the nouveau project linux git tree, and comes with all the warnings mentioned about possible copyright issues. After this I also hope to merge the VMware virtual GPU kms driver early next week which is also TTM based and going into staging. The driver alone is ~36,000 lines of code, which is bigger than most subsystems we carry, so hopefully ppl realise the monumental scale of writing a driver for these things. Dave. drivers/gpu/drm/Makefile|2 + drivers/gpu/drm/i2c/Makefile|4 + drivers/gpu/drm/i2c/ch7006_drv.c| 531 +++ drivers/gpu/drm/i2c/ch7006_mode.c | 473 +++ drivers/gpu/drm/i2c/ch7006_priv.h | 344 ++ drivers/gpu/drm/nouveau/Kconfig | 44 + drivers/gpu/drm/nouveau/Makefile| 31 + drivers/gpu/drm/nouveau/nouveau_acpi.c | 125 + drivers/gpu/drm/nouveau/nouveau_backlight.c | 155 + drivers/gpu/drm/nouveau/nouveau_bios.c | 6095 +++ drivers/gpu/drm/nouveau/nouveau_bios.h | 289 ++ drivers/gpu/drm/nouveau/nouveau_bo.c| 671 +++ drivers/gpu/drm/nouveau/nouveau_calc.c | 478 +++ drivers/gpu/drm/nouveau/nouveau_channel.c | 468 ++ drivers/gpu/drm/nouveau/nouveau_connector.c | 824 drivers/gpu/drm/nouveau/nouveau_connector.h | 54 + drivers/gpu/drm/nouveau/nouveau_crtc.h | 95 + drivers/gpu/drm/nouveau/nouveau_debugfs.c | 155 + drivers/gpu/drm/nouveau/nouveau_display.c | 115 + drivers/gpu/drm/nouveau/nouveau_dma.c | 206 + drivers/gpu/drm/nouveau/nouveau_dma.h | 157 + drivers/gpu/drm/nouveau/nouveau_dp.c| 569 +++ drivers/gpu/drm/nouveau/nouveau_drv.c | 405 ++ drivers/gpu/drm/nouveau/nouveau_drv.h | 1286 ++ drivers/gpu/drm/nouveau/nouveau_encoder.h | 91 + drivers/gpu/drm/nouveau/nouveau_fb.h| 47 + drivers/gpu/drm/nouveau/nouveau_fbcon.c | 380 ++ drivers/gpu/drm/nouveau/nouveau_fbcon.h | 47 + drivers/gpu/drm/nouveau/nouveau_fence.c | 262 ++ drivers/gpu/drm/nouveau/nouveau_gem.c | 992 + drivers/gpu/drm/nouveau/nouveau_hw.c| 1080 + drivers/gpu/drm/nouveau/nouveau_hw.h| 455 ++ drivers/gpu/drm/nouveau/nouveau_i2c.c | 269 ++ drivers/gpu/drm/nouveau/nouveau_i2c.h | 52 + drivers/gpu/drm/nouveau/nouveau_ioc32.c | 72 + drivers/gpu/drm/nouveau/nouveau_irq.c | 702 +++ drivers/gpu/drm/nouveau/nouveau_mem.c | 568 +++ drivers/gpu/drm/nouveau/nouveau_notifier.c | 196 + drivers/gpu/drm/nouveau/nouveau_object.c| 1294 ++ drivers/gpu/drm/nouveau/nouveau_reg.h | 836 drivers/gpu/drm/nouveau/nouveau_sgdma.c | 321 ++ drivers/gpu/drm/nouveau/nouveau_state.c | 811 drivers/gpu/drm/nouveau/nouveau_ttm.c | 131 + drivers/gpu/drm/nouveau/nv04_crtc.c | 1002 + drivers/gpu/drm/nouveau/nv04_cursor.c | 70 + drivers/gpu/drm/nouveau/nv04_dac.c | 528 +++ drivers/gpu/drm/nouveau/nv04_dfp.c | 621 +++ drivers/gpu/drm/nouveau/nv04_display.c | 288 ++ drivers/gpu/drm/nouveau/nv04_fb.c | 21 + drivers/gpu/drm/nouveau/nv04_fbcon.c| 316 ++ drivers/gpu/drm/nouveau/nv04_fifo.c | 271 ++ drivers/gpu/drm/nouveau/nv04_graph.c| 579 +++ drivers/gpu/drm/nouveau/nv04_instmem.c | 208 + drivers/gpu/drm/nouveau/nv04_mc.c | 20 + drivers/gpu/drm/nouveau/nv04_timer.c| 51 + drivers/gpu/drm/nouveau/nv04_tv.c | 305 ++ drivers/gpu/drm/nouveau/nv10_fb.c | 24 + drivers/gpu/drm/nouveau/nv10_fifo.c | 260 ++ drivers/gpu/drm/nouveau/nv10_graph.c| 892 drivers/gpu/drm/nouveau/nv17_gpio.c | 92 + drivers/gpu/drm/nouveau/nv17_tv.c | 681 +++ drivers/gpu/drm/nouveau/nv17_tv.h | 156 + drivers/gpu/drm/nouveau/nv17_tv_modes.c | 583 +++ drivers/gpu/drm/nouveau/nv20_graph.c| 780 drivers/gpu/drm/nouveau/nv40_fb.c | 62 + drivers/gpu/drm/nouveau/nv40_fifo.c | 314 ++ drivers/gpu/drm/nouveau/nv40_graph.c| 560 +++ drivers/gpu/drm/nouveau/nv40_mc.c | 38 + drivers/gpu/drm/nouveau/nv50_crtc.c | 769 drivers/gpu/drm/nouveau/nv50_cursor.c | 156 + drivers/gpu/drm/nouveau/nv50_dac.c | 304 ++ drivers/gpu/drm/nouveau/nv50_display.c | 1015 + drivers/gpu/drm/nouveau/nv50_display.h | 46
Re: [git pull] drm nouveau pony for Xmas.
On Fri, 2009-12-11 at 11:57 +, Dave Airlie wrote: This driver is reverse engineered, and is in no way supported by nVidia. Support for nearly the complete range of nvidia hw from nv04-g80 (nv50) is available, and the kms driver should support driving nearly all output types (displayport is under development still) along with supporting suspend/resume. This work is all from the upstream nouveau project found at nouveau.freedesktop.org. The original authors list from nouveau git tree is: Anssi Hannula anssi.hann...@iki.fi Ben Skeggs bske...@redhat.com Francisco Jerez curroje...@riseup.net Maarten Maathuis madman2...@gmail.com Marcin Kościelnicki koria...@0x04.net Matthew Garrett m...@redhat.com Matt Parnell mparn...@gmail.com Patrice Mandin patman...@gmail.com Pekka Paalanen p...@iki.fi Xavier Chantry shinin...@gmail.com along with project founder Stephane Marchesin marche...@icps.u-strasbg.fr Signed-off-by: Ben Skeggs bske...@redhat.com Signed-off-by: Dave Airlie airl...@redhat.com Oh, so _that's_ what a noveau is. Cool. I've got a darn nvidia card, and look forward to someday having eye-candy.. and being able to not only suspend, but _resume_ too :) -Mike -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ 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
Hi Alex, no change. Does not matter if radeon.new_pll=1 or radeon.new_pll=0. Delay is still there. Best, Viktor On Thursday 10 December 2009 09:44:40 am Alex Deucher wrote: On Tue, Dec 8, 2009 at 11:17 PM, Viktor Malyarchuk mal...@gmail.com wrote: Hi Alex, patch did not change anything for me. Problem still there. Can you try Dave's drm-radeon-testing or drm-radeon-next tree? Specifically this patch: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff; h=b27b63750d912e80d61d2120c4a1664062d0f808 Alex Best, Viktor On Tuesday 08 December 2009 04:54:35 pm Alex Deucher wrote: On Wed, Dec 2, 2009 at 7:51 AM, Viktor Malyarchuk mal...@gmail.com wrote: Hi Alex, I bisected drm-next branch from Dave's git tree git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git . The result is: ebbe1cb936dfc96d809ccf4d64a9755f8ba0c0ff is the first bad commit commit ebbe1cb936dfc96d809ccf4d64a9755f8ba0c0ff Author: Alex Deucher alexdeuc...@gmail.com Date: Fri Oct 16 11:15:25 2009 -0400 drm/radeon/kms/atom: add support for spread spectrum (v2) Spread spectrum is a periodic disturbance added to the feedback divider to change the pixel clock periodically to reduce interference. Only enabled on LVDS. v2: add support for r4xx and fix DCE 3 Signed-off-by: Alex Deucher alexdeuc...@gmail.com Signed-off-by: Dave Airlie airl...@redhat.com :04 04 4cd7bdabeac245accf789e26e944aeb678fe1f16 077d0d318aed2f25464f9eeaffa39f33fa652909 M drivers Can you try the patch I attached to bug 25506: http://bugs.freedesktop.org/show_bug.cgi?id=25506 Alex Best, Viktor -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm nouveau pony for Xmas.
On Fri, 2009-12-11 at 11:57 +, Dave Airlie wrote: Hi Linus, Please pull the 'drm-nouveau-pony' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-nouveau-pony This contains the nouveau driver with Kconfig under staging for now, the code is going under drm because the upstream tree has it there, and it makes passing patches a lot easier at least initially. Thanks to Ben Skeggs for doing overtime on his Friday evening to get the ctxprogs ripped out and firmware loader support added. The firmware is available elsewhere via the nouveau project linux git tree, and comes with all the warnings mentioned about possible copyright issues. After this I also hope to merge the VMware virtual GPU kms driver early next week which is also TTM based and going into staging. The driver alone is ~36,000 lines of code, which is bigger than most subsystems we carry, so hopefully ppl realise the monumental scale of writing a driver for these things. Dave. drivers/gpu/drm/Makefile|2 + drivers/gpu/drm/i2c/Makefile|4 + drivers/gpu/drm/i2c/ch7006_drv.c| 531 +++ drivers/gpu/drm/i2c/ch7006_mode.c | 473 +++ drivers/gpu/drm/i2c/ch7006_priv.h | 344 ++ drivers/gpu/drm/nouveau/Kconfig | 44 + drivers/gpu/drm/nouveau/Makefile| 31 + drivers/gpu/drm/nouveau/nouveau_acpi.c | 125 + drivers/gpu/drm/nouveau/nouveau_backlight.c | 155 + drivers/gpu/drm/nouveau/nouveau_bios.c | 6095 +++ drivers/gpu/drm/nouveau/nouveau_bios.h | 289 ++ drivers/gpu/drm/nouveau/nouveau_bo.c| 671 +++ drivers/gpu/drm/nouveau/nouveau_calc.c | 478 +++ drivers/gpu/drm/nouveau/nouveau_channel.c | 468 ++ drivers/gpu/drm/nouveau/nouveau_connector.c | 824 drivers/gpu/drm/nouveau/nouveau_connector.h | 54 + drivers/gpu/drm/nouveau/nouveau_crtc.h | 95 + drivers/gpu/drm/nouveau/nouveau_debugfs.c | 155 + drivers/gpu/drm/nouveau/nouveau_display.c | 115 + drivers/gpu/drm/nouveau/nouveau_dma.c | 206 + drivers/gpu/drm/nouveau/nouveau_dma.h | 157 + drivers/gpu/drm/nouveau/nouveau_dp.c| 569 +++ drivers/gpu/drm/nouveau/nouveau_drv.c | 405 ++ drivers/gpu/drm/nouveau/nouveau_drv.h | 1286 ++ drivers/gpu/drm/nouveau/nouveau_encoder.h | 91 + drivers/gpu/drm/nouveau/nouveau_fb.h| 47 + drivers/gpu/drm/nouveau/nouveau_fbcon.c | 380 ++ drivers/gpu/drm/nouveau/nouveau_fbcon.h | 47 + drivers/gpu/drm/nouveau/nouveau_fence.c | 262 ++ drivers/gpu/drm/nouveau/nouveau_gem.c | 992 + drivers/gpu/drm/nouveau/nouveau_hw.c| 1080 + drivers/gpu/drm/nouveau/nouveau_hw.h| 455 ++ drivers/gpu/drm/nouveau/nouveau_i2c.c | 269 ++ drivers/gpu/drm/nouveau/nouveau_i2c.h | 52 + drivers/gpu/drm/nouveau/nouveau_ioc32.c | 72 + drivers/gpu/drm/nouveau/nouveau_irq.c | 702 +++ drivers/gpu/drm/nouveau/nouveau_mem.c | 568 +++ drivers/gpu/drm/nouveau/nouveau_notifier.c | 196 + drivers/gpu/drm/nouveau/nouveau_object.c| 1294 ++ drivers/gpu/drm/nouveau/nouveau_reg.h | 836 drivers/gpu/drm/nouveau/nouveau_sgdma.c | 321 ++ drivers/gpu/drm/nouveau/nouveau_state.c | 811 drivers/gpu/drm/nouveau/nouveau_ttm.c | 131 + drivers/gpu/drm/nouveau/nv04_crtc.c | 1002 + drivers/gpu/drm/nouveau/nv04_cursor.c | 70 + drivers/gpu/drm/nouveau/nv04_dac.c | 528 +++ drivers/gpu/drm/nouveau/nv04_dfp.c | 621 +++ drivers/gpu/drm/nouveau/nv04_display.c | 288 ++ drivers/gpu/drm/nouveau/nv04_fb.c | 21 + drivers/gpu/drm/nouveau/nv04_fbcon.c| 316 ++ drivers/gpu/drm/nouveau/nv04_fifo.c | 271 ++ drivers/gpu/drm/nouveau/nv04_graph.c| 579 +++ drivers/gpu/drm/nouveau/nv04_instmem.c | 208 + drivers/gpu/drm/nouveau/nv04_mc.c | 20 + drivers/gpu/drm/nouveau/nv04_timer.c| 51 + drivers/gpu/drm/nouveau/nv04_tv.c | 305 ++ drivers/gpu/drm/nouveau/nv10_fb.c | 24 + drivers/gpu/drm/nouveau/nv10_fifo.c | 260 ++ drivers/gpu/drm/nouveau/nv10_graph.c| 892 drivers/gpu/drm/nouveau/nv17_gpio.c | 92 + drivers/gpu/drm/nouveau/nv17_tv.c | 681 +++ drivers/gpu/drm/nouveau/nv17_tv.h | 156 + drivers/gpu/drm/nouveau/nv17_tv_modes.c | 583 +++ drivers/gpu/drm/nouveau/nv20_graph.c| 780 drivers/gpu/drm/nouveau/nv40_fb.c | 62 + drivers/gpu/drm/nouveau/nv40_fifo.c | 314 ++ drivers/gpu/drm/nouveau/nv40_graph.c| 560 +++ drivers/gpu/drm/nouveau/nv40_mc.c | 38 + drivers/gpu/drm/nouveau/nv50_crtc.c | 769 drivers/gpu/drm/nouveau/nv50_cursor.c | 156 +
Re: [git pull] drm
On Fri, Dec 11, 2009 at 08:20:57PM +1000, Dave Airlie wrote: Well the main thing was I wasn't mean to discuss possible legal issues and still don't have permission, you know as well as I do once lawyers are involved you have to keep out of things until they deal with them. The thing which really surprises me is that if there are legally dubious issues, why on *earth* did Red Hat allow Fedora to ship said code? - Ted -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
Is the kernel really interested in code that could result in FUD? Think of the whole SCO case, where Microsoft unquestionable funded the law suites by buying Unix licenses at outrageous prices to harm Linux. Microsoft would use the FUD as a weapon against Linux, if such code got merged. If questionable code is merged, uncertainty will not pay to the kernels benefit as a whole. There would be very good legal reasons for NOT using Linux, if such code is merged. Maybe it would be worth contacting nVidia. They might not even give a damn about the microcode. When open sourcing have come up, nVidia had this to say[0]: - - For competitive reasons on other platforms, I don't think we would ever open source any of our cross-platform driver source code (which is 90%+ of the Linux driver... see my earlier description of code sharing). The Linux-specific pieces of the driver code base don't really stand on their own, and generally need to change in sync with the cross-platform code, so I don't believe it would be practical to just open source the Linux-specific pieces. - We have developed substantial IP in our graphics driver that we do not want to expose. - Unfortunately the vast majority of our documentation is created solely for internal distribution. While at some point it may be possible to release some of this information in pubic form it would be quite a monumental effort to go through the vast amounts of internal documents and repurpose them for external consumption. - So if someone could get in touch with Andy Ritger of nVidia and ask him if this also holds for the microcode. if: seek legal advice else: merge [0] http://www.phoronix.com/scan.php?page=articleitem=nvidia_qa_linuxnum=3 -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25483] Neverwinter nights lacks ram when using the radeon driver
http://bugs.freedesktop.org/show_bug.cgi?id=25483 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added AssignedTo|xorg-driver-...@lists.x.org |dri- ||de...@lists.sourceforge.net Component|Driver/Radeon |Drivers/DRI/R600 Product|xorg|Mesa QAContact|xorg-t...@lists.x.org | Version|7.4 |git --- Comment #8 from Michel Dänzer mic...@daenzer.net 2009-12-11 06:13:40 PST --- AFAICT the messages are from the Mesa r600 driver. However, it's not clear how they would result in growing memory usage of the X server - is NWN using direct rendering? Presumably it's only available as a 32 bit binary, do you have a 32 bit r600 driver installed? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: If no placement is supplied fallback to system
Do as we did before rework, if no placement is supplied at bo creation time, fallback to allocating bo from system ram. This will fix most of the creation failed issue report we got since the rework get merged. Signed-off-by: Jerome Glisse jgli...@redhat.com --- drivers/gpu/drm/radeon/radeon_object.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c index 544e18f..132130f 100644 --- a/drivers/gpu/drm/radeon/radeon_object.c +++ b/drivers/gpu/drm/radeon/radeon_object.c @@ -71,6 +71,8 @@ void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32 domain) rbo-placements[c++] = TTM_PL_MASK_CACHING | TTM_PL_FLAG_TT; if (domain RADEON_GEM_DOMAIN_CPU) rbo-placements[c++] = TTM_PL_MASK_CACHING | TTM_PL_FLAG_SYSTEM; + if (!c) + rbo-placements[c++] = TTM_PL_MASK_CACHING | TTM_PL_FLAG_SYSTEM; rbo-placement.num_placement = c; rbo-placement.num_busy_placement = c; } -- 1.6.5.2 -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25483] Neverwinter nights lacks ram when using the radeon driver
http://bugs.freedesktop.org/show_bug.cgi?id=25483 --- Comment #9 from Jesús Guerrero i92gu...@terra.es 2009-12-11 06:48:46 PST --- The game is a 32 bit x86 binary blob, yes. There's absolutely no way to get it in another format and I completely forgot about that while testing this. I simply assumed that if it was working and I could see the 3d scenes then everything should be on its place (specially, since this is a single k8 cpu, not a multicore monster). My OS is Gentoo x86_64, and the only dri file from mesa for r600 is this one: $ equery f mesa|grep 600 /usr/lib64/dri/r600_dri.so So I guess I might really be missing the 32 bits piece here. However, is that really the only thing or do I need something else? I don't understand either why is the game running at all without the mesa driver that matches its bitness, but surely there's an easy explanation for that. So, do you think that the missing 32 bits r600_dri.so could be the root of this problem? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ 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
On Fri, Dec 11, 2009 at 7:58 AM, Viktor Malyarchuk mal...@gmail.com wrote: Hi Alex, no change. Does not matter if radeon.new_pll=1 or radeon.new_pll=0. Delay is still there. new_pll=1 is the default and the new code. Can you send me your vbios? (as root): cd /sys/bus/pci/devices/pci bus id echo 1 rom cat rom /tmp/vbios.rom echo 0 rom Alex Best, Viktor On Thursday 10 December 2009 09:44:40 am Alex Deucher wrote: On Tue, Dec 8, 2009 at 11:17 PM, Viktor Malyarchuk mal...@gmail.com wrote: Hi Alex, patch did not change anything for me. Problem still there. Can you try Dave's drm-radeon-testing or drm-radeon-next tree? Specifically this patch: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff; h=b27b63750d912e80d61d2120c4a1664062d0f808 Alex Best, Viktor On Tuesday 08 December 2009 04:54:35 pm Alex Deucher wrote: On Wed, Dec 2, 2009 at 7:51 AM, Viktor Malyarchuk mal...@gmail.com wrote: Hi Alex, I bisected drm-next branch from Dave's git tree git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git . The result is: ebbe1cb936dfc96d809ccf4d64a9755f8ba0c0ff is the first bad commit commit ebbe1cb936dfc96d809ccf4d64a9755f8ba0c0ff Author: Alex Deucher alexdeuc...@gmail.com Date: Fri Oct 16 11:15:25 2009 -0400 drm/radeon/kms/atom: add support for spread spectrum (v2) Spread spectrum is a periodic disturbance added to the feedback divider to change the pixel clock periodically to reduce interference. Only enabled on LVDS. v2: add support for r4xx and fix DCE 3 Signed-off-by: Alex Deucher alexdeuc...@gmail.com Signed-off-by: Dave Airlie airl...@redhat.com :04 04 4cd7bdabeac245accf789e26e944aeb678fe1f16 077d0d318aed2f25464f9eeaffa39f33fa652909 M drivers Can you try the patch I attached to bug 25506: http://bugs.freedesktop.org/show_bug.cgi?id=25506 Alex Best, Viktor -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25483] Neverwinter nights lacks ram when using the radeon driver
http://bugs.freedesktop.org/show_bug.cgi?id=25483 --- Comment #10 from Michel Dänzer mic...@daenzer.net 2009-12-11 07:20:53 PST --- (In reply to comment #9) I don't understand either why is the game running at all without the mesa driver that matches its bitness, but surely there's an easy explanation for that. It's indirect rendering, libGL sends GLX protocol to the X server which uses the 64 bit driver for hardware acceleration. So, do you think that the missing 32 bits r600_dri.so could be the root of this problem? If nothing else, with direct rendering you should get better performance, and if the leak is still there it should be in the NWN process as opposed to the X server, which should make it easier to track it down. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25580] [REGRESSION] drm/radeon/kms: [drm:radeon_fence_wait] *ERROR* fence(f6608d80:0x00000007) 510ms timeout
http://bugs.freedesktop.org/show_bug.cgi?id=25580 --- Comment #2 from Alex Deucher ag...@yahoo.com 2009-12-11 07:29:08 PST --- Can you bisect the problematic commit? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
On Fri, 11 Dec 2009, Jeff Garzik wrote: F11 uses nouveau here. It is actually a pain to get 'nv' going as an alternate -- bugs have been filed. Makes kernel dev more difficult for me. I was actually told, by Fedora people, that I should be hacking on the Fedora (rpm-based) kernel, rather than a 100% upstream kernel like I have been hacking/booting for the past decade, as a result of this setup (needing nouveau kernel support, thus needing Fedora rather than upstream kernel). Btw, for all my ranting (and maybe Alan is right, and I'm ranting at the wrong people - it's just that the actual driver authors aren't the ones that violated any rules), I do have to give kudos for the fact that the F12 situation seems to be much better. These days, what you can do is basically do all development (assuming it's not nouveau development) in the upstream kernel, and then you just have a separate 'nouveau' git tree (or branch) that you pull in the nouvea stuff into. That tree/branch will be a mess of random merges-of-the-day, but you'll never push it out to anybody anyway, so nobody cares. And building that messy merge tree will get you a working setup without any extra steps - a simple make modules_install ; make install will JustWork(tm). So it's much more straightforward than it used to be (you had that separate tree that you could build modules in), you can basically build things exactly the same way you are supposed to do things _anyway_ if you have experimental branches etc and want to build in a temporary merged tree (even if you're not actually ready to merge it all and still want to keep the branches separate). Of course, it's a good thing that it's easier in F12, because in F11 if you forgot to build the nouveau stuff, it would just fall back on the VESA FB setup - you had a working system, it was just very slow X. You could then build the nouveau modules you forgot about, and re-start X. That oops, I forgot case seems to no longer work at all in F12 - if I build without Nouveau on my nvidia machine, the kernel will boot, but I will have neither working X _nor_ a working text login. So there's no way to even build the modules and fix it up - you have just to re-boot back into an old kernel. Very annoying for bisection. Linus -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25483] Neverwinter nights lacks ram when using the radeon driver
http://bugs.freedesktop.org/show_bug.cgi?id=25483 --- Comment #11 from Jesús Guerrero i92gu...@terra.es 2009-12-11 08:23:00 PST --- Well, I will try that way then. Suggestions on a sane way to compile a 32 bit mesa without hosing my 64 bit system are welcome, I'll check on the Gentoo forum about that anyway. Thanks. I'll report back. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25590] New: commit drm: disable all the possible outputs/crtcs before entering KMS mode introduces EDID errors
http://bugs.freedesktop.org/show_bug.cgi?id=25590 Summary: commit drm: disable all the possible outputs/crtcs before entering KMS mode introduces EDID errors Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: f...@chilicode.com Created an attachment (id=31988) -- (http://bugs.freedesktop.org/attachment.cgi?id=31988) dmesg with EDID errors as a result of this screen resolution at boot time is messed up. reverting the commit 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. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25590] commit drm: disable all the possible outputs/crtcs before entering KMS mode introduces EDID errors
http://bugs.freedesktop.org/show_bug.cgi?id=25590 --- Comment #1 from Florian Scandella f...@chilicode.com 2009-12-11 08:34:16 PST --- Created an attachment (id=31989) -- (http://bugs.freedesktop.org/attachment.cgi?id=31989) dmesg without EDID errors (commit reverted) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25580] [REGRESSION] drm/radeon/kms: [drm:radeon_fence_wait] *ERROR* fence(f6608d80:0x00000007) 510ms timeout
http://bugs.freedesktop.org/show_bug.cgi?id=25580 --- Comment #3 from Rafał Miłecki zaj...@gmail.com 2009-12-11 09:49:00 PST --- Created an attachment (id=31990) -- (http://bugs.freedesktop.org/attachment.cgi?id=31990) git bisect log ec42a6e7dcfc2e9a92fad1c132bc9e110fafeb3f is the first bad commit commit ec42a6e7dcfc2e9a92fad1c132bc9e110fafeb3f Author: Dave Airlie airl...@redhat.com Date: Tue Dec 8 15:58:08 2009 +1000 drm/ttm: fix memory leak noticed by kmemleak. If we don't need the zone we need to free it. Acked-By: Thomas Hellstrom thellst...@vmware.com Signed-off-by: Dave Airlie airl...@redhat.com :04 04 c65430b9f69957be4d0bc67be14c8deacfac58a9 f84a05852ae0b05680ca69bae650a389ce36e598 M drivers -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
On 12/11/2009 10:28 AM, Linus Torvalds wrote: On Fri, 11 Dec 2009, Jeff Garzik wrote: F11 uses nouveau here. It is actually a pain to get 'nv' going as an alternate -- bugs have been filed. Makes kernel dev more difficult for me. I was actually told, by Fedora people, that I should be hacking on the Fedora (rpm-based) kernel, rather than a 100% upstream kernel like I have been hacking/booting for the past decade, as a result of this setup (needing nouveau kernel support, thus needing Fedora rather than upstream kernel). Btw, for all my ranting (and maybe Alan is right, and I'm ranting at the wrong people - it's just that the actual driver authors aren't the ones that violated any rules), I do have to give kudos for the fact that the F12 situation seems to be much better. These days, what you can do is basically do all development (assuming it's not nouveau development) in the upstream kernel, and then you just have a separate 'nouveau' git tree (or branch) that you pull in the nouvea stuff into. That tree/branch will be a mess of random merges-of-the-day, but you'll never push it out to anybody anyway, so nobody cares. And building that messy merge tree will get you a working setup without any extra steps - a simple make modules_install ; make install will JustWork(tm). At the outset, I was hoping for an even more straightforward solution: if nouveau kernel mod not present, fall back to nv That would work without any kernel modifications at all. But the answer came back as if you run Fedora, run a Fedora kernel, otherwise don't expect anything to work My experience directly contradicts claims of upstream first policy, both in code and attitude. I am looking into doing the git tree merge you suggest right now I didn't know that was an option, given ongoing API changes. That would make my life quite a bit easier. As you note, anything graphics is _glacially_ slow due to vesa fallback, when using a 100% upstream kernel. Jeff -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25580] [REGRESSION] drm/radeon/kms: [drm:radeon_fence_wait] *ERROR* fence(f6608d80:0x00000007) 510ms timeout
http://bugs.freedesktop.org/show_bug.cgi?id=25580 --- Comment #4 from Thomas Hellström thellst...@vmware.com 2009-12-11 10:44:45 PST --- What you're seeing is a probable GPU lockup. It can't possibly have anything to do with the commit stated. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: Avoid crash when trying to cleanup uninitialized structure
Add boolean to record if some part of the driver are initialized or
not this allow to avoid a crash when trying to cleanup uninitialized
structure members.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/radeon.h |4 +++-
drivers/gpu/drm/radeon/radeon_fence.c |9 ++---
drivers/gpu/drm/radeon/radeon_ttm.c |4
3 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 1fd562f..d4c786f 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -162,6 +162,7 @@ struct radeon_fence_driver {
struct list_headcreated;
struct list_heademited;
struct list_headsignaled;
+ boolinitialized;
};
struct radeon_fence {
@@ -202,8 +203,9 @@ struct radeon_surface_reg {
struct radeon_mman {
struct ttm_bo_global_refbo_global_ref;
struct ttm_global_reference mem_global_ref;
- boolmem_global_referenced;
struct ttm_bo_devicebdev;
+ boolmem_global_referenced;
+ boolinitialized;
};
struct radeon_bo {
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index cb4cd97..4cdd8b4 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -324,7 +324,7 @@ int radeon_fence_driver_init(struct radeon_device *rdev)
write_lock_irqsave(rdev-fence_drv.lock, irq_flags);
r = radeon_scratch_get(rdev, rdev-fence_drv.scratch_reg);
if (r) {
- DRM_ERROR(Fence failed to get a scratch register.);
+ dev_err(rdev-dev, fence failed to get scratch register\n);
write_unlock_irqrestore(rdev-fence_drv.lock, irq_flags);
return r;
}
@@ -335,9 +335,10 @@ int radeon_fence_driver_init(struct radeon_device *rdev)
INIT_LIST_HEAD(rdev-fence_drv.signaled);
rdev-fence_drv.count_timeout = 0;
init_waitqueue_head(rdev-fence_drv.queue);
+ rdev-fence_drv.initialized = true;
write_unlock_irqrestore(rdev-fence_drv.lock, irq_flags);
if (radeon_debugfs_fence_init(rdev)) {
- DRM_ERROR(Failed to register debugfs file for fence !\n);
+ dev_err(rdev-dev, fence debugfs file creation failed\n);
}
return 0;
}
@@ -346,11 +347,13 @@ void radeon_fence_driver_fini(struct radeon_device *rdev)
{
unsigned long irq_flags;
+ if (!rdev-fence_drv.initialized)
+ return;
wake_up_all(rdev-fence_drv.queue);
write_lock_irqsave(rdev-fence_drv.lock, irq_flags);
radeon_scratch_free(rdev, rdev-fence_drv.scratch_reg);
write_unlock_irqrestore(rdev-fence_drv.lock, irq_flags);
- DRM_INFO(radeon: fence finalized\n);
+ rdev-fence_drv.initialized = false;
}
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index cc310cc..74a6a9f 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -482,6 +482,7 @@ int radeon_ttm_init(struct radeon_device *rdev)
DRM_ERROR(failed initializing buffer object driver(%d).\n, r);
return r;
}
+ rdev-mman.initialized = true;
r = ttm_bo_init_mm(rdev-mman.bdev, TTM_PL_VRAM,
rdev-mc.vram_size PAGE_SHIFT);
if (r) {
@@ -524,6 +525,8 @@ void radeon_ttm_fini(struct radeon_device *rdev)
{
int r;
+ if (!rdev-mman.initialized)
+ return;
if (rdev-stollen_vga_memory) {
r = radeon_bo_reserve(rdev-stollen_vga_memory, false);
if (r == 0) {
@@ -537,6 +540,7 @@ void radeon_ttm_fini(struct radeon_device *rdev)
ttm_bo_device_release(rdev-mman.bdev);
radeon_gart_fini(rdev);
radeon_ttm_global_fini(rdev);
+ rdev-mman.initialized = false;
DRM_INFO(radeon: ttm finalized\n);
}
--
1.6.5.2
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25597] New: SIGSEGV in _radeon_bo_unref
http://bugs.freedesktop.org/show_bug.cgi?id=25597 Summary: SIGSEGV in _radeon_bo_unref Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/DRI/r200 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: david.ro...@mcgill.ca I occasionally crash in the sauerbrauten game (even after the fix in bug #25355); the problem seems to be game-map related. I'm following the git/master. I see the following on the console: *WARN_ONCE* File radeon_dma.c function radeonReleaseDmaRegions line 340 Leaking dma buffer object! *** From the backtrace it's clear that radeon_bo_unref is being passed a NULL pointer. My bet is that the culprit is radeonReleaseDmaRegions' calculation of bo (like in bug 25355). Here's the backtrace: Program terminated with signal 11, Segmentation fault. [New process 12045] #0 0xb641a054 in _radeon_bo_unref (bo=0x0, file=0xb664c012 radeon_dma.c, func=0xb664c353 radeonReleaseDmaRegions, line=341) at /usr/include/drm/radeon_bo.h:137 137 bo-cref--; Thread 1 (process 12045): #0 0xb641a054 in _radeon_bo_unref (bo=0x0, file=0xb664c012 radeon_dma.c, func=0xb664c353 radeonReleaseDmaRegions, line=341) at /usr/include/drm/radeon_bo.h:137 No locals. #1 0xb641b1d0 in radeonReleaseDmaRegions (rmesa=0x843b978) at radeon_dma.c:341 dma_bo = (struct radeon_dma_bo *) 0x843b994 temp = (struct radeon_dma_bo *) 0xcdacfd0 expire_at = 371036 time = 370936 __FUNCTION__ = radeonReleaseDmaRegions #2 0xb6418b37 in rcommonFlushCmdBuf (rmesa=0x843b978, caller=0xb664bd88 radeonFlush) at radeon_common.c:1201 ret = 138935784 #3 0xb641879f in radeonFlush (ctx=0x8440eb0) at radeon_common.c:1104 radeon = (radeonContextPtr) 0x843b978 __FUNCTION__ = radeonFlush #4 0xb6414146 in radeon_firevertices (radeon=0x843b978) at radeon_cmdbuf.h:118 No locals. #5 0xb6414984 in radeonDestroyContext (driContextPriv=0x84395b0) at radeon_common_context.c:308 ctx = (GLcontext *) 0x8440eb0 radeon = (radeonContextPtr) 0x843b978 current = (radeonContextPtr) 0x843b978 __PRETTY_FUNCTION__ = radeonDestroyContext __FUNCTION__ = radeonDestroyContext #6 0xb63e259e in r200DestroyContext (driContextPriv=0x84395b0) at r200_context.c:509 i = 6 rmesa = (r200ContextPtr) 0x843b978 #7 0xb63d9d2d in driDestroyContext (pcp=0x84395b0) at ../common/dri_util.c:546 No locals. #8 0xb753e09e in driDestroyContext (context=0x8439880, psc=0x8438e18, dpy=0x83f59d0) at dri_glx.c:495 pcp = (__GLXDRIcontextPrivate *) 0x8439880 #9 0xb7506523 in DestroyContext (dpy=0x83f59d0, gc=0x8410ef8) at glxcmds.c:556 req = (xGLXDestroyContextReq *) 0xb73afff4 xid = 65011714 opcode = 151 '\227' imported = 0 '\0' #10 0xb7506687 in glXDestroyContext (dpy=0x83f59d0, gc=0x8410ef8) at glxcmds.c:592 No locals. #11 0xb76c01b4 in X11_GL_Shutdown () from /usr/lib/libSDL-1.2.so.0 No locals. #12 0x08410ef8 in ?? () No symbol table info available. #13 0x in ?? () No symbol table info available. Current language: auto; currently c -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25597] SIGSEGV in _radeon_bo_unref
http://bugs.freedesktop.org/show_bug.cgi?id=25597 David Ronis david.ro...@mcgill.ca changed: What|Removed |Added Component|Drivers/DRI/r200|Drivers/DRI/Radeon -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23545] flashing textures in some maps of sauerbraten game
http://bugs.freedesktop.org/show_bug.cgi?id=23545 --- Comment #10 from Maciej Cencora m.cenc...@gmail.com 2009-12-11 12:01:54 PST --- If you're experiencing the same problem on intel hw then it could be a problem in core Mesa. Unfortunately without some simple testcase I don't think we will be able to track down and fix the bug. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/3] drm/radeon/kms: Avoid crash when trying to cleanup uninitialized structure
Add boolean to record if some part of the driver are initialized or
not this allow to avoid a crash when trying to cleanup uninitialized
structure members.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/radeon.h |4 +++-
drivers/gpu/drm/radeon/radeon_fence.c |9 ++---
drivers/gpu/drm/radeon/radeon_ttm.c |4
3 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 49bea93..baec009 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -162,6 +162,7 @@ struct radeon_fence_driver {
struct list_headcreated;
struct list_heademited;
struct list_headsignaled;
+ boolinitialized;
};
struct radeon_fence {
@@ -202,8 +203,9 @@ struct radeon_surface_reg {
struct radeon_mman {
struct ttm_bo_global_refbo_global_ref;
struct ttm_global_reference mem_global_ref;
- boolmem_global_referenced;
struct ttm_bo_devicebdev;
+ boolmem_global_referenced;
+ boolinitialized;
};
struct radeon_bo {
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index cb4cd97..4cdd8b4 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -324,7 +324,7 @@ int radeon_fence_driver_init(struct radeon_device *rdev)
write_lock_irqsave(rdev-fence_drv.lock, irq_flags);
r = radeon_scratch_get(rdev, rdev-fence_drv.scratch_reg);
if (r) {
- DRM_ERROR(Fence failed to get a scratch register.);
+ dev_err(rdev-dev, fence failed to get scratch register\n);
write_unlock_irqrestore(rdev-fence_drv.lock, irq_flags);
return r;
}
@@ -335,9 +335,10 @@ int radeon_fence_driver_init(struct radeon_device *rdev)
INIT_LIST_HEAD(rdev-fence_drv.signaled);
rdev-fence_drv.count_timeout = 0;
init_waitqueue_head(rdev-fence_drv.queue);
+ rdev-fence_drv.initialized = true;
write_unlock_irqrestore(rdev-fence_drv.lock, irq_flags);
if (radeon_debugfs_fence_init(rdev)) {
- DRM_ERROR(Failed to register debugfs file for fence !\n);
+ dev_err(rdev-dev, fence debugfs file creation failed\n);
}
return 0;
}
@@ -346,11 +347,13 @@ void radeon_fence_driver_fini(struct radeon_device *rdev)
{
unsigned long irq_flags;
+ if (!rdev-fence_drv.initialized)
+ return;
wake_up_all(rdev-fence_drv.queue);
write_lock_irqsave(rdev-fence_drv.lock, irq_flags);
radeon_scratch_free(rdev, rdev-fence_drv.scratch_reg);
write_unlock_irqrestore(rdev-fence_drv.lock, irq_flags);
- DRM_INFO(radeon: fence finalized\n);
+ rdev-fence_drv.initialized = false;
}
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index d2ed896..310562a 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -482,6 +482,7 @@ int radeon_ttm_init(struct radeon_device *rdev)
DRM_ERROR(failed initializing buffer object driver(%d).\n, r);
return r;
}
+ rdev-mman.initialized = true;
r = ttm_bo_init_mm(rdev-mman.bdev, TTM_PL_VRAM,
rdev-mc.real_vram_size PAGE_SHIFT);
if (r) {
@@ -529,6 +530,8 @@ void radeon_ttm_fini(struct radeon_device *rdev)
{
int r;
+ if (!rdev-mman.initialized)
+ return;
if (rdev-stollen_vga_memory) {
r = radeon_bo_reserve(rdev-stollen_vga_memory, false);
if (r == 0) {
@@ -542,6 +545,7 @@ void radeon_ttm_fini(struct radeon_device *rdev)
ttm_bo_device_release(rdev-mman.bdev);
radeon_gart_fini(rdev);
radeon_ttm_global_fini(rdev);
+ rdev-mman.initialized = false;
DRM_INFO(radeon: ttm finalized\n);
}
--
1.6.5.2
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 3/3] drm/radeon/kms: Simplify GPU address space initialization V2
This patch simplify the GPU address space initialization,
it always try to put VRAM at same address as the VRAM PCI BAR
Sadly it seems that the memory controller of radeon got too
many bugs to safely put it at others place (especialy on IGP).
This patch also kill some duplicated value and split vram size
into 2 different value the mc_vram_size which will always be the
true VRAM size of the GPU (unless we hit the AGP corner case).
While vram_size is the amount of VRAM we will use (it can be less
than mc_vram_size if we limit the VRAM size or for matching the
aperture size).
This cleanup is done as first pass before adding support for
unmapped VRAM.
V2: Simplify things somemore, now all hw AGP should work.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/r100.c | 71 -
drivers/gpu/drm/radeon/r300.c |8 +-
drivers/gpu/drm/radeon/r420.c | 26 +-
drivers/gpu/drm/radeon/r520.c |4 +-
drivers/gpu/drm/radeon/r600.c | 65 ++--
drivers/gpu/drm/radeon/radeon.h | 27 --
drivers/gpu/drm/radeon/radeon_agp.c |2 +
drivers/gpu/drm/radeon/radeon_device.c | 154 ---
drivers/gpu/drm/radeon/radeon_fb.c |6 +-
drivers/gpu/drm/radeon/radeon_gem.c |4 +-
drivers/gpu/drm/radeon/radeon_legacy_crtc.c |2 +-
drivers/gpu/drm/radeon/radeon_test.c|2 +-
drivers/gpu/drm/radeon/radeon_ttm.c | 19 ++--
drivers/gpu/drm/radeon/rs400.c | 16 +--
drivers/gpu/drm/radeon/rs600.c | 27 ++---
drivers/gpu/drm/radeon/rs690.c | 26 ++---
drivers/gpu/drm/radeon/rv515.c |4 +-
drivers/gpu/drm/radeon/rv770.c | 45 ++---
18 files changed, 196 insertions(+), 312 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 824cc64..9676a7c 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -200,9 +200,8 @@ int r100_pci_gart_enable(struct radeon_device *rdev)
tmp = RREG32(RADEON_AIC_CNTL) | RADEON_DIS_OUT_OF_PCI_GART_ACCESS;
WREG32(RADEON_AIC_CNTL, tmp);
/* set address range for PCI address translate */
- WREG32(RADEON_AIC_LO_ADDR, rdev-mc.gtt_location);
- tmp = rdev-mc.gtt_location + rdev-mc.gtt_size - 1;
- WREG32(RADEON_AIC_HI_ADDR, tmp);
+ WREG32(RADEON_AIC_LO_ADDR, rdev-mc.gtt_start);
+ WREG32(RADEON_AIC_HI_ADDR, rdev-mc.gtt_end);
/* set PCI GART page-table base address */
WREG32(RADEON_AIC_PT_BASE, rdev-gart.table_addr);
tmp = RREG32(RADEON_AIC_CNTL) | RADEON_PCIGART_TRANSLATE_EN;
@@ -1881,44 +1880,25 @@ void r100_vram_init_sizes(struct radeon_device *rdev)
uint32_t tom;
/* read NB_TOM to get the amount of ram stolen for the GPU */
tom = RREG32(RADEON_NB_TOM);
- rdev-mc.real_vram_size = (((tom 16) - (tom 0x) + 1)
16);
+ rdev-mc.mc_vram_size = (((tom 16) - (tom 0x) + 1)
16);
/* for IGPs we need to keep VRAM where it was put by the BIOS */
- rdev-mc.vram_location = (tom 0x) 16;
- WREG32(RADEON_CONFIG_MEMSIZE, rdev-mc.real_vram_size);
- rdev-mc.mc_vram_size = rdev-mc.real_vram_size;
+ rdev-mc.vram_start = (tom 0x) 16;
+ WREG32(RADEON_CONFIG_MEMSIZE, rdev-mc.mc_vram_size);
} else {
- rdev-mc.real_vram_size = RREG32(RADEON_CONFIG_MEMSIZE);
+ rdev-mc.mc_vram_size = RREG32(RADEON_CONFIG_MEMSIZE);
/* Some production boards of m6 will report 0
* if it's 8 MB
*/
- if (rdev-mc.real_vram_size == 0) {
- rdev-mc.real_vram_size = 8192 * 1024;
- WREG32(RADEON_CONFIG_MEMSIZE, rdev-mc.real_vram_size);
- }
- /* let driver place VRAM */
- rdev-mc.vram_location = 0xUL;
-/* Fix for RN50, M6, M7 with 8/16/32(??) MBs of VRAM -
- * Novell bug 204882 + along with lots of ubuntu ones */
- if (config_aper_size rdev-mc.real_vram_size)
- rdev-mc.mc_vram_size = config_aper_size;
- else
- rdev-mc.mc_vram_size = rdev-mc.real_vram_size;
+ if (rdev-mc.mc_vram_size == 0) {
+ rdev-mc.mc_vram_size = 8192 * 1024;
+ WREG32(RADEON_CONFIG_MEMSIZE, rdev-mc.mc_vram_size);
+ }
}
-
/* work out accessible VRAM */
+ /* FIXME: take advantage of second aperture when it works */
accessible = r100_get_accessible_vram(rdev);
-
rdev-mc.aper_base = drm_get_resource_start(rdev-ddev, 0);
rdev-mc.aper_size = drm_get_resource_len(rdev-ddev, 0);
-
[RFC] Simplify GPU address space initialization
Patch 1 is a fixed version of previous patch, lastest patch depends on it Patch 2 is fixing up issue when we shutdown radeon modeule while not everythings were initialized Patch 3 does the address space code simplification, it should only change r1xx-r5xx hw where it will put vram at pci bar address space. It will also change behavior in front of tight pci address space. (comment in patch describe the policy) i haven't yet done full testing on all GPU (so far R3XX/R7XX AGP, RV515 PCIE). I post it here so others can test too. Once i am done with more testing i will report. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/3] drm/radeon/kms: Check module arguments to be valid V2
This patch add a function which check module argument to be
valid. On invalid argument it prints a warning and setback
the default value.
V2: Allow 0 for vram limit agp mode which are the default
value
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/radeon_device.c | 73 +--
1 files changed, 68 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 02bcdb1..ff5a955 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -539,9 +539,72 @@ void radeon_agp_disable(struct radeon_device *rdev)
}
}
-/*
- * Radeon device.
- */
+void radeon_check_arguments(struct radeon_device *rdev)
+{
+ /* vramlimit must be a power of two */
+ switch (radeon_vram_limit) {
+ case 0:
+ case 4:
+ case 8:
+ case 16:
+ case 32:
+ case 64:
+ case 128:
+ case 256:
+ case 512:
+ case 1024:
+ case 2048:
+ case 4096:
+ break;
+ default:
+ dev_warn(rdev-dev, vram limit (%d) must be a power of 2\n,
+ radeon_vram_limit);
+ radeon_vram_limit = 0;
+ break;
+ }
+ radeon_vram_limit = radeon_vram_limit 20;
+ /* gtt size must be power of two and greater or equal to 32M */
+ switch (radeon_gart_size) {
+ case 4:
+ case 8:
+ case 16:
+ dev_warn(rdev-dev, gart size (%d) too small forcing to
512M\n,
+ radeon_gart_size);
+ radeon_gart_size = 512;
+ break;
+ case 32:
+ case 64:
+ case 128:
+ case 256:
+ case 512:
+ case 1024:
+ case 2048:
+ case 4096:
+ break;
+ default:
+ dev_warn(rdev-dev, gart size (%d) must be a power of 2\n,
+ radeon_gart_size);
+ radeon_gart_size = 512;
+ break;
+ }
+ rdev-mc.gtt_size = radeon_gart_size * 1024 * 1024;
+ /* AGP mode can only be -1, 1, 2, 4, 8 */
+ switch (radeon_agpmode) {
+ case -1:
+ case 0:
+ case 1:
+ case 2:
+ case 4:
+ case 8:
+ break;
+ default:
+ dev_warn(rdev-dev, invalid AGP mode %d (valid mode:
+ -1, 0, 1, 2, 4, 8)\n, radeon_agpmode);
+ radeon_agpmode = 0;
+ break;
+ }
+}
+
int radeon_device_init(struct radeon_device *rdev,
struct drm_device *ddev,
struct pci_dev *pdev,
@@ -580,9 +643,9 @@ int radeon_device_init(struct radeon_device *rdev,
/* Set asic functions */
r = radeon_asic_init(rdev);
- if (r) {
+ if (r)
return r;
- }
+ radeon_check_arguments(rdev);
if (rdev-flags RADEON_IS_AGP radeon_agpmode == -1) {
radeon_agp_disable(rdev);
--
1.6.5.2
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm nouveau pony for Xmas.
On Fri, 11 Dec 2009, Dave Airlie wrote: Please pull the 'drm-nouveau-pony' branch from PONIES! Yay! I lurve ponies! And it works for me too. Needed to get the firmware from the fedora project, and make sure that it loads as a module rather than built in (so that it can find the firmware!), but other than those two gotchas (that are obvious, but I needed to fail a couple of boots to hammer the point home) it all seems to work. Thank you. The squeaky wheel _does_ get greased. Linus -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm nouveau pony for Xmas.
2009/12/12 Stephane Marchesin stephane.marche...@gmail.com: 2009/12/11 Dave Airlie airl...@linux.ie: Hi Linus, Please pull the 'drm-nouveau-pony' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-nouveau-pony This contains the nouveau driver with Kconfig under staging for now, the code is going under drm because the upstream tree has it there, and it makes passing patches a lot easier at least initially. Thanks to Ben Skeggs for doing overtime on his Friday evening to get the ctxprogs ripped out and firmware loader support added. The firmware is available elsewhere via the nouveau project linux git tree, and comes with all the warnings mentioned about possible copyright issues. After this I also hope to merge the VMware virtual GPU kms driver early next week which is also TTM based and going into staging. The driver alone is ~36,000 lines of code, which is bigger than most subsystems we carry, so hopefully ppl realise the monumental scale of writing a driver for these things. Dave. drivers/gpu/drm/Makefile | 2 + drivers/gpu/drm/i2c/Makefile | 4 + drivers/gpu/drm/i2c/ch7006_drv.c | 531 +++ drivers/gpu/drm/i2c/ch7006_mode.c | 473 +++ drivers/gpu/drm/i2c/ch7006_priv.h | 344 ++ drivers/gpu/drm/nouveau/Kconfig | 44 + drivers/gpu/drm/nouveau/Makefile | 31 + drivers/gpu/drm/nouveau/nouveau_acpi.c | 125 + drivers/gpu/drm/nouveau/nouveau_backlight.c | 155 + drivers/gpu/drm/nouveau/nouveau_bios.c | 6095 +++ drivers/gpu/drm/nouveau/nouveau_bios.h | 289 ++ drivers/gpu/drm/nouveau/nouveau_bo.c | 671 +++ drivers/gpu/drm/nouveau/nouveau_calc.c | 478 +++ drivers/gpu/drm/nouveau/nouveau_channel.c | 468 ++ drivers/gpu/drm/nouveau/nouveau_connector.c | 824 drivers/gpu/drm/nouveau/nouveau_connector.h | 54 + drivers/gpu/drm/nouveau/nouveau_crtc.h | 95 + drivers/gpu/drm/nouveau/nouveau_debugfs.c | 155 + drivers/gpu/drm/nouveau/nouveau_display.c | 115 + drivers/gpu/drm/nouveau/nouveau_dma.c | 206 + drivers/gpu/drm/nouveau/nouveau_dma.h | 157 + drivers/gpu/drm/nouveau/nouveau_dp.c | 569 +++ drivers/gpu/drm/nouveau/nouveau_drv.c | 405 ++ drivers/gpu/drm/nouveau/nouveau_drv.h | 1286 ++ drivers/gpu/drm/nouveau/nouveau_encoder.h | 91 + drivers/gpu/drm/nouveau/nouveau_fb.h | 47 + drivers/gpu/drm/nouveau/nouveau_fbcon.c | 380 ++ drivers/gpu/drm/nouveau/nouveau_fbcon.h | 47 + drivers/gpu/drm/nouveau/nouveau_fence.c | 262 ++ drivers/gpu/drm/nouveau/nouveau_gem.c | 992 + drivers/gpu/drm/nouveau/nouveau_hw.c | 1080 + drivers/gpu/drm/nouveau/nouveau_hw.h | 455 ++ drivers/gpu/drm/nouveau/nouveau_i2c.c | 269 ++ drivers/gpu/drm/nouveau/nouveau_i2c.h | 52 + drivers/gpu/drm/nouveau/nouveau_ioc32.c | 72 + drivers/gpu/drm/nouveau/nouveau_irq.c | 702 +++ drivers/gpu/drm/nouveau/nouveau_mem.c | 568 +++ drivers/gpu/drm/nouveau/nouveau_notifier.c | 196 + drivers/gpu/drm/nouveau/nouveau_object.c | 1294 ++ drivers/gpu/drm/nouveau/nouveau_reg.h | 836 drivers/gpu/drm/nouveau/nouveau_sgdma.c | 321 ++ drivers/gpu/drm/nouveau/nouveau_state.c | 811 drivers/gpu/drm/nouveau/nouveau_ttm.c | 131 + drivers/gpu/drm/nouveau/nv04_crtc.c | 1002 + drivers/gpu/drm/nouveau/nv04_cursor.c | 70 + drivers/gpu/drm/nouveau/nv04_dac.c | 528 +++ drivers/gpu/drm/nouveau/nv04_dfp.c | 621 +++ drivers/gpu/drm/nouveau/nv04_display.c | 288 ++ drivers/gpu/drm/nouveau/nv04_fb.c | 21 + drivers/gpu/drm/nouveau/nv04_fbcon.c | 316 ++ drivers/gpu/drm/nouveau/nv04_fifo.c | 271 ++ drivers/gpu/drm/nouveau/nv04_graph.c | 579 +++ drivers/gpu/drm/nouveau/nv04_instmem.c | 208 + drivers/gpu/drm/nouveau/nv04_mc.c | 20 + drivers/gpu/drm/nouveau/nv04_timer.c | 51 + drivers/gpu/drm/nouveau/nv04_tv.c | 305 ++ drivers/gpu/drm/nouveau/nv10_fb.c | 24 + drivers/gpu/drm/nouveau/nv10_fifo.c | 260 ++ drivers/gpu/drm/nouveau/nv10_graph.c | 892 drivers/gpu/drm/nouveau/nv17_gpio.c | 92 + drivers/gpu/drm/nouveau/nv17_tv.c | 681 +++ drivers/gpu/drm/nouveau/nv17_tv.h | 156 + drivers/gpu/drm/nouveau/nv17_tv_modes.c | 583 +++ drivers/gpu/drm/nouveau/nv20_graph.c | 780 drivers/gpu/drm/nouveau/nv40_fb.c | 62 + drivers/gpu/drm/nouveau/nv40_fifo.c | 314 ++ drivers/gpu/drm/nouveau/nv40_graph.c | 560 +++ drivers/gpu/drm/nouveau/nv40_mc.c | 38 + drivers/gpu/drm/nouveau/nv50_crtc.c | 769
Re: [git pull] drm nouveau pony for Xmas.
2009/12/12 Dave Airlie airl...@gmail.com: 2009/12/12 Stephane Marchesin stephane.marche...@gmail.com: I did git log on the nouveau kernel tree nouveau dir with sort and uniq, I'm not sure where else I needed to trawl to get anymore ppl who have contributed to the KMS driver. I'm sure ppl contributed to X.org/Mesa drivers but this isn't the place for them. Also all copyright should be intact. The problem is that when you moved from the drm to the linux tree, you killed the whole history and the authors along. But we can add an author lists to the code subdir if you like, if someone compiles the complete list of ppl who have added code to the kernel driver. That would indeed be the proper thing to do. Stephane -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm nouveau pony for Xmas.
On Sat, Dec 12, 2009 at 00:27, Stephane Marchesin stephane.marche...@gmail.com wrote: 2009/12/12 Dave Airlie airl...@gmail.com: 2009/12/12 Stephane Marchesin stephane.marche...@gmail.com: I did git log on the nouveau kernel tree nouveau dir with sort and uniq, I'm not sure where else I needed to trawl to get anymore ppl who have contributed to the KMS driver. I'm sure ppl contributed to X.org/Mesa drivers but this isn't the place for them. Also all copyright should be intact. The problem is that when you moved from the drm to the linux tree, you killed the whole history and the authors along. But we can add an author lists to the code subdir if you like, if someone compiles the complete list of ppl who have added code to the kernel driver. That would indeed be the proper thing to do. Ok, as you requested here is a proper list of actual authors: Arthur Huillet arthur.huil...@free.fr Anssi Hannula anssi.hann...@iki.fi Ben Skeggs bske...@redhat.com B. Rathmann koala...@users.sourceforge.net Danny Tholen moondr...@gmail.com Dave Airlie airl...@redhat.com Francisco Jerez curroje...@riseup.net Jeremy Kolb jk...@brandeis.edu Maarten Maathuis madman2...@gmail.com Marcin Kościelnicki koria...@0x04.net Matthew Garrett m...@redhat.com Matthieu Castet castet.matth...@free.fr Matt Parnell mparn...@gmail.com Maurice van der Pot griffo...@kfk4ever.com Patrice Mandin patman...@gmail.com Pekka Paalanen p...@iki.fi Stephane Marchesin marche...@icps.u-strasbg.fr Stuart Bennett stu...@freedesktop.org Xavier Chantry shinin...@gmail.com As far as I can recall, this list is complete. Stephane -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm nouveau pony for Xmas.
2009/12/11 Dave Airlie airl...@linux.ie: Hi Linus, Please pull the 'drm-nouveau-pony' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-nouveau-pony This contains the nouveau driver with Kconfig under staging for now, the code is going under drm because the upstream tree has it there, and it makes passing patches a lot easier at least initially. Thanks to Ben Skeggs for doing overtime on his Friday evening to get the ctxprogs ripped out and firmware loader support added. The firmware is available elsewhere via the nouveau project linux git tree, and comes with all the warnings mentioned about possible copyright issues. After this I also hope to merge the VMware virtual GPU kms driver early next week which is also TTM based and going into staging. The driver alone is ~36,000 lines of code, which is bigger than most subsystems we carry, so hopefully ppl realise the monumental scale of writing a driver for these things. Dave. drivers/gpu/drm/Makefile | 2 + drivers/gpu/drm/i2c/Makefile | 4 + drivers/gpu/drm/i2c/ch7006_drv.c | 531 +++ drivers/gpu/drm/i2c/ch7006_mode.c | 473 +++ drivers/gpu/drm/i2c/ch7006_priv.h | 344 ++ drivers/gpu/drm/nouveau/Kconfig | 44 + drivers/gpu/drm/nouveau/Makefile | 31 + drivers/gpu/drm/nouveau/nouveau_acpi.c | 125 + drivers/gpu/drm/nouveau/nouveau_backlight.c | 155 + drivers/gpu/drm/nouveau/nouveau_bios.c | 6095 +++ drivers/gpu/drm/nouveau/nouveau_bios.h | 289 ++ drivers/gpu/drm/nouveau/nouveau_bo.c | 671 +++ drivers/gpu/drm/nouveau/nouveau_calc.c | 478 +++ drivers/gpu/drm/nouveau/nouveau_channel.c | 468 ++ drivers/gpu/drm/nouveau/nouveau_connector.c | 824 drivers/gpu/drm/nouveau/nouveau_connector.h | 54 + drivers/gpu/drm/nouveau/nouveau_crtc.h | 95 + drivers/gpu/drm/nouveau/nouveau_debugfs.c | 155 + drivers/gpu/drm/nouveau/nouveau_display.c | 115 + drivers/gpu/drm/nouveau/nouveau_dma.c | 206 + drivers/gpu/drm/nouveau/nouveau_dma.h | 157 + drivers/gpu/drm/nouveau/nouveau_dp.c | 569 +++ drivers/gpu/drm/nouveau/nouveau_drv.c | 405 ++ drivers/gpu/drm/nouveau/nouveau_drv.h | 1286 ++ drivers/gpu/drm/nouveau/nouveau_encoder.h | 91 + drivers/gpu/drm/nouveau/nouveau_fb.h | 47 + drivers/gpu/drm/nouveau/nouveau_fbcon.c | 380 ++ drivers/gpu/drm/nouveau/nouveau_fbcon.h | 47 + drivers/gpu/drm/nouveau/nouveau_fence.c | 262 ++ drivers/gpu/drm/nouveau/nouveau_gem.c | 992 + drivers/gpu/drm/nouveau/nouveau_hw.c | 1080 + drivers/gpu/drm/nouveau/nouveau_hw.h | 455 ++ drivers/gpu/drm/nouveau/nouveau_i2c.c | 269 ++ drivers/gpu/drm/nouveau/nouveau_i2c.h | 52 + drivers/gpu/drm/nouveau/nouveau_ioc32.c | 72 + drivers/gpu/drm/nouveau/nouveau_irq.c | 702 +++ drivers/gpu/drm/nouveau/nouveau_mem.c | 568 +++ drivers/gpu/drm/nouveau/nouveau_notifier.c | 196 + drivers/gpu/drm/nouveau/nouveau_object.c | 1294 ++ drivers/gpu/drm/nouveau/nouveau_reg.h | 836 drivers/gpu/drm/nouveau/nouveau_sgdma.c | 321 ++ drivers/gpu/drm/nouveau/nouveau_state.c | 811 drivers/gpu/drm/nouveau/nouveau_ttm.c | 131 + drivers/gpu/drm/nouveau/nv04_crtc.c | 1002 + drivers/gpu/drm/nouveau/nv04_cursor.c | 70 + drivers/gpu/drm/nouveau/nv04_dac.c | 528 +++ drivers/gpu/drm/nouveau/nv04_dfp.c | 621 +++ drivers/gpu/drm/nouveau/nv04_display.c | 288 ++ drivers/gpu/drm/nouveau/nv04_fb.c | 21 + drivers/gpu/drm/nouveau/nv04_fbcon.c | 316 ++ drivers/gpu/drm/nouveau/nv04_fifo.c | 271 ++ drivers/gpu/drm/nouveau/nv04_graph.c | 579 +++ drivers/gpu/drm/nouveau/nv04_instmem.c | 208 + drivers/gpu/drm/nouveau/nv04_mc.c | 20 + drivers/gpu/drm/nouveau/nv04_timer.c | 51 + drivers/gpu/drm/nouveau/nv04_tv.c | 305 ++ drivers/gpu/drm/nouveau/nv10_fb.c | 24 + drivers/gpu/drm/nouveau/nv10_fifo.c | 260 ++ drivers/gpu/drm/nouveau/nv10_graph.c | 892 drivers/gpu/drm/nouveau/nv17_gpio.c | 92 + drivers/gpu/drm/nouveau/nv17_tv.c | 681 +++ drivers/gpu/drm/nouveau/nv17_tv.h | 156 + drivers/gpu/drm/nouveau/nv17_tv_modes.c | 583 +++ drivers/gpu/drm/nouveau/nv20_graph.c | 780 drivers/gpu/drm/nouveau/nv40_fb.c | 62 + drivers/gpu/drm/nouveau/nv40_fifo.c | 314 ++ drivers/gpu/drm/nouveau/nv40_graph.c | 560 +++ drivers/gpu/drm/nouveau/nv40_mc.c | 38 + drivers/gpu/drm/nouveau/nv50_crtc.c | 769 drivers/gpu/drm/nouveau/nv50_cursor.c | 156 + drivers/gpu/drm/nouveau/nv50_dac.c
Re: [OOPS] Radeon KMS with 2.6.32 and agp not compiled in
This looks like an issue I've had related to the backdoor entry hack for GART_IOMMU – Basically, amd64_agp doesn't utilise module_init or module_exit when CONFIG_GART_IOMMU is enabled, instead stating: drivers/char/agp/amd64-ag...@774-775: /* On AMD64 the PCI driver needs to initialize this driver early http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/char/agp/amd64-agp.c;h=2fb2e6cc322aab1a36164de3fc99674559dea9ed;hb=HEAD#l775 for the IOMMU, so it has to be called via a backdoor. */ This resulted, on my system, of the agpgart not being initialised despite the module being loaded, and ultimately leads to the crash you describe below. My fix was to remove the #ifndef surrounding the module_init and module_exit calls, however I'm not sure if this is the best way to approach the issue (I have no idea what this backdoor mentioned *is*, and AFAIK it all works for other drivers). Regards, Francis 2009/12/11 Johannes Hirte johannes.hi...@fem.tu-ilmenau.de When the agp driver is not compiled in but is build as module, the kernel oopes on modprobing radeon with modeset=1. Dec 7 22:08:53 datengrab kernel: BUG: unable to handle kernel NULL pointer dereference at 0074 Dec 7 22:08:53 datengrab kernel: IP: [a01f693c] radeon_agp_init+0x18/0x23c [radeon] Dec 7 22:08:53 datengrab kernel: PGD 0 Dec 7 22:08:53 datengrab kernel: Oops: [#1] SMP Dec 7 22:08:53 datengrab kernel: last sysfs file: /sys/module/agpgart/initstate Dec 7 22:08:53 datengrab kernel: CPU 0 Dec 7 22:08:53 datengrab kernel: Modules linked in: radeon(+) ttm drm_kms_helper drm i2c_algo_bit snd_seq_midi snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss aes_x86_64 aes_generic xts gf128mul dm_crypt snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus snd_pcm snd_seq_device snd_timer snd_page_alloc snd_util_mem snd_hwdep ohci_hcd i2c_amd8111 uhci_hcd sg snd amd64_agp sata_sil k8temp agpgart i2c_amd756 sr_mod hwmon Dec 7 22:08:53 datengrab kernel: Pid: 2531, comm: work_for_cpu Not tainted 2.6.32 #2 To Be Filled By O.E.M. Dec 7 22:08:53 datengrab kernel: RIP: 0010:[a01f693c] [a01f693c] radeon_agp_init+0x18/0x23c [radeon] Dec 7 22:08:53 datengrab kernel: RSP: 0018:8801172c3d80 EFLAGS: 00010282 Dec 7 22:08:53 datengrab kernel: RAX: RBX: 88011841 RCX: 88011fb97800 Dec 7 22:08:53 datengrab kernel: RDX: c000 RSI: RDI: 88011e43d800 Dec 7 22:08:53 datengrab kernel: RBP: R08: a0238201 R09: 8801172c3d90 Dec 7 22:08:53 datengrab kernel: R10: 81589940 R11: 0400 R12: 88011fb97800 Dec 7 22:08:53 datengrab kernel: R13: 0020 R14: a0243240 R15: 88011e43dbc0 Dec 7 22:08:53 datengrab kernel: FS: 7f0e85a7f700() GS:88002820() knlGS: Dec 7 22:08:53 datengrab kernel: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b Dec 7 22:08:53 datengrab kernel: CR2: 0074 CR3: 01001000 CR4: 06f0 Dec 7 22:08:53 datengrab kernel: DR0: DR1: DR2: Dec 7 22:08:53 datengrab kernel: DR3: DR6: 0ff0 DR7: 0400 Dec 7 22:08:53 datengrab kernel: Process work_for_cpu (pid: 2531, threadinfo 8801172c2000, task 8801188d2280) Dec 7 22:08:53 datengrab kernel: Stack: Dec 7 22:08:53 datengrab kernel: 88011e43dbc0 813436f0 88010008 8801172c3df0 Dec 7 22:08:53 datengrab kernel: 0 8801172c3db0 0246 88011841 880118410144 Dec 7 22:08:53 datengrab kernel: 0 0282 88011841 88011fb97800 Dec 7 22:08:53 datengrab kernel: Call Trace: Dec 7 22:08:53 datengrab kernel: [813436f0] ? printk+0x40/0x48 Dec 7 22:08:53 datengrab kernel: [a021f0b0] ? r600_mc_init+0xf0/0x251 [radeon] Dec 7 22:08:53 datengrab kernel: [a021fb91] ? r600_init+0x154/0x2b7 [radeon] Dec 7 22:08:53 datengrab kernel: [a01f4369] ? radeon_device_init+0x1fe/0x276 [radeon] Dec 7 22:08:53 datengrab kernel: [a01f4bda] ? radeon_driver_load_kms+0xb2/0xec [radeon] Dec 7 22:08:53 datengrab kernel: [a019ba34] ? drm_get_dev+0x322/0x42e [drm] Dec 7 22:08:53 datengrab kernel: [810452d2] ? do_work_for_cpu+0x0/0x1b Dec 7 22:08:53 datengrab kernel: [811b9ae1] ? local_pci_probe+0x12/0x16 Dec 7 22:08:53 datengrab kernel: [810452dd] ? do_work_for_cpu+0xb/0x1b Dec 7 22:08:53 datengrab kernel: [8104827c] ? kthread+0x75/0x7d Dec 7 22:08:53 datengrab kernel: [8100bc7a] ? child_rip+0xa/0x20 Dec 7 22:08:53 datengrab kernel: [81048207] ? kthread+0x0/0x7d Dec 7 22:08:53 datengrab kernel: [8100bc70] ? child_rip+0x0/0x20 Dec 7
[Bug 25463] crash with progs/perf/copytex
http://bugs.freedesktop.org/show_bug.cgi?id=25463 --- Comment #2 from Maciej Cencora m.cenc...@gmail.com 2009-12-11 17:23:59 PST --- Workaround pushed to mesa_7_7_branch (commit id 8413a3aefaf4968f8b17263826b34baa99c2a907). -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
