Re: [RFC PATCH v2] Utilize the PCI API in the TTM framework.
Hi, Konrad. This discussion has become a bit lenghty. I'll filter out the sorted-out stuff, which leaves me with two remaining issues: On 01/11/2011 04:55 PM, Konrad Rzeszutek Wilk wrote: So at the end we have 16GB taken from 8GB->24GB, and 320MB taken from 0->4GB. When you start allocating coherent memory from each guest (and yeah, say we use 2GB each), we end up with the first guest getting the 2GB, the second getting 1.7GB, and then the next two getting zil. You still have GFP_KERNEL memory in each guest - the first one has 2GB left , then second 2.3, the next two have each 4GB. > From the hyprevisor pool perspective, the 0-4GB zone is exhausted, so is the 8GB->24GB, but it still has 4GB->8GB free - so it can launch one more guest (but without PCI passthrough devices). On a 4GB machine or less, that would be the same as kernel memory. Now, if 4 guests think they can allocate 2GB of coherent memory each, you might run out of kernel memory on the host? So host in this case refers to the Hypervisor and it does not care about the DMA or what - it does not have any device drivers(*) or such. The first guest (dom0) is the one that deals with the device drivers. *: It has one: the serial port, but that is not really that important for this discussion. Let's assume we're at where the hypervisor (or host) has exhausted the 0-4GB zone, due to guests coherent memory allocations, and that the physical machine has 4GB of memory, all in the 0-4GB zone. Now if the hypervisor was running on a Linux kernel, there would be no more GFP_KERNEL memory available on the *host* (hypervisor), and the hypervisor would crash. Now I don't know much about Xen, but it might be that this is not a problem with Xen at all? Another thing that I was thinking of is what happens if you have a huge gart and allocate a lot of coherent memory. Could that potentially exhaust IOMMU resources? I need to be more specific. Let's assume we're on "bare metal", and we want to allocate 4GB of coherent memory. For most IOMMUs that would mean as you previously state, that we actually allocate GFP_DMA32 memory. But for some IOMMUs that would perhaps mean that we allocate *any* memory and set up a permanent DMA mapping in the IOMMU for the coherent pages. What if, in such a case, the IOMMU can only set up 2GB of coherent memory? Or in short, can there *ever* be "bare metal" cases where the amount of coherent memory available is less than DMA32 memory available? Thanks, Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 16265] Why is kslowd accumulating so much CPU time?
https://bugzilla.kernel.org/show_bug.cgi?id=16265 Florian Mickler changed: What|Removed |Added CC||edwinto...@gmail.com --- Comment #8 from Florian Mickler 2011-01-12 10:48:30 --- *** Bug 18802 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 16265] Why is kslowd accumulating so much CPU time?
https://bugzilla.kernel.org/show_bug.cgi?id=16265 --- Comment #9 from Florian Mickler 2011-01-12 11:19:26 --- Is this issue still visible on 2.6.37? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for rc1
Am 12.01.2011 00:28, schrieb Linus Torvalds: > On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger > wrote: >> >> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA >> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) >> During startup the framebuffer shows only stripes and a blank >> screen after suspend/resume. >> I also see lots of TRAP messages. (see below). >> X11 seems to work fine though... > > Can you try to bisect? dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit commit dfe63bb0ad9810db13aab0058caba97866e0a681 Author: James Simmons Date: Thu Dec 23 16:40:37 2010 + drm: Update fbdev fb_fix_screeninfo Reverting this on top of todays git also fixes my problem. Christian ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Mapping snooped user pages into the GTT
On Wed, 12 Jan 2011 15:40:33 +0800, april wrote: > Dear Chris: > > what do u mean " blit between snooped and unsnooped memory"? > It seems you want to map user-space pixmap to GTT space, and use 2d > copy to do upload/download? Yes, and sample from snooped memory for some operations. > TTM can map user space memory to GTT aperture by using > "ttm_bo_type_user", but no dirver use it yet.?? Different driver, but thanks for reminding me to check ttm. It seems we made slightly different choices over the lifetime of the gup, but otherwise the same. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 16265] Why is kslowd accumulating so much CPU time?
https://bugzilla.kernel.org/show_bug.cgi?id=16265 Florian Mickler changed: What|Removed |Added Status|NEW |RESOLVED Resolution||CODE_FIX --- Comment #10 from Florian Mickler 2011-01-12 11:37:46 --- I'm closing this for now, please reopen or shout if this issue is still unresolved for you. This should have been fixed for intel since 2.6.36-rc5: commit 930a9e283516a3a3595c0c515113f1b78d07f695 Author: Chris Wilson Date: Tue Sep 14 11:07:23 2010 +0100 drm: Use a nondestructive mode for output detect when polling (v2) for nouveau it's probably fixed since v2.6.37-rc3: commit 01db363979e96115a895f35c823303660f0f328d Author: Francisco Jerez Date: Thu Oct 21 17:43:08 2010 +0200 drm/nouveau: Use "force" to decide if analog load detection is ok or not. and for radeon since v2.6.37-rc1: commit c3cceeddf0b5f97b0d2352b98ef0f025e31a9ae3 Author: Dave Airlie Date: Tue Oct 26 12:55:52 2010 +1000 drm/radeon/kms: don't poll dac load detect. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 16265] Why is kslowd accumulating so much CPU time?
https://bugzilla.kernel.org/show_bug.cgi?id=16265 Florian Mickler changed: What|Removed |Added Status|RESOLVED|CLOSED -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [correction] load fbcon from drm_kms_helper
Hi David! Did you see this patch? I was wondering what you think about it... On Sun, 12 Dec 2010 12:39:22 -0600 David Fries wrote: > Kconfig says fbcon is required by drm_kms_helper. If radeon, fbcon, > and drm_kms_helper are all modules, radeon is auto loaded (by PCI id?), > drm_kms_helper is loaded because of the module dependency, but fbcon > isn't loaded leaving the console unusable. Since fbcon is required > and there isn't an explicit module dependency, request the module > to be loaded from drm_kms_helper. > > Signed-off-by: David Fries > Cc: David Airlie > Cc: dri-devel@lists.freedesktop.org Regards, Flo ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37
On Wed, 12 Jan 2011 01:35:49 +0100 (CET), "Indan Zupancic" wrote:
> Yeah, the second patch is a bit of a desperate attempt because Larry reported
> that
> it didn't fix his problem.
>
> About your patch, you still do:
>
> +void intel_panel_setup_backlight(struct drm_device *dev)
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
> +
> + dev_priv->backlight_level = intel_panel_get_max_backlight(dev);
> + dev_priv->backlight_enabled = dev_priv->backlight_level != 0;
> +}
>
> While my patch changes that to:
>
> + u32 level;
>
> - if (dev_priv->backlight_level == 0)
> - dev_priv->backlight_level = intel_panel_get_max_backlight(dev);
> + if (dev_priv->backlight_level == 0) {
> + level = intel_panel_get_backlight(dev);
> + if (level == 0)
> + level = intel_panel_get_max_backlight(dev);
> + dev_priv->backlight_level = level;
> + }
>
> Your patch uses intel_panel_get_max_backlight() to check if the backlight is
> enabled. Is this always correct, or may it cause bugs in the future?
That was a typo, cut'n'pasting the line from above.
> Anyway, my main concern with unconditionally setting the backlight level to
> the maximum is that any stored brightness level (by the BIOS or whatever) may
> be lost, and that the screen is set to maximum brightness at each boot. This
> is certainly the behaviour I've seen with an unpatched kernel. So I propose to
> do what my patch does and set it to intel_panel_get_backlight(dev) if that
> returns non-zero. Something like this:
Sure, s/intel_panel_get_max_backlight/intel_panel_get_backlight/ and we
get the behaviour we both want - preserving the current backlight unless
none is set.
> While I'm glad this problem is being fixed upstream, it would be nice to get
> some credit for finding the source of the problem.
Sorry. You found the bug but I felt your rationale was off. However, I was
amiss in not giving you the credit you fully deserved.
-Chris
commit 9c1c388a53e5df8819e898106a64e34d0994a5d4
Author: Indan Zupancic
Date: Wed Jan 12 11:59:19 2011 +
drm/i915/panel: The backlight is enabled if the current value is non-zero
... and not if the maximum is non-zero. This fixes the typo introduced
in 47356eb6728501452 and preserves the backlight value from boot.
[ickle: My thanks also to Indan Zupancic for diagnosing the original
regression and suggesting the appropriate fix.]
Signed-off-by: Chris Wilson
Cc: sta...@kernel.org # after 47356eb6728501452
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_pan
index e00d200..27c79c7 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -278,6 +278,6 @@ void intel_panel_setup_backlight(struct drm_device
*dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- dev_priv->backlight_level = intel_panel_get_max_backlight(dev);
+ dev_priv->backlight_level = intel_panel_max_backlight(dev);
dev_priv->backlight_enabled = dev_priv->backlight_level != 0;
}
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37
On Wed, 12 Jan 2011 12:07:23 +, Chris Wilson
wrote:
> diff --git a/drivers/gpu/drm/i915/intel_panel.c
> b/drivers/gpu/drm/i915/intel_pan
> index e00d200..27c79c7 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -278,6 +278,6 @@ void intel_panel_setup_backlight(struct drm_device
> *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
>
> - dev_priv->backlight_level = intel_panel_get_max_backlight(dev);
> + dev_priv->backlight_level = intel_panel_max_backlight(dev);
> dev_priv->backlight_enabled = dev_priv->backlight_level != 0;
dev_priv->backlight_level = intel_panel_get_backlight(dev);
-ETIRED
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for rc1
> Am 12.01.2011 00:28, schrieb Linus Torvalds: > > On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger > > wrote: > >> > >> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA > >> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) > >> During startup the framebuffer shows only stripes and a blank > >> screen after suspend/resume. > >> I also see lots of TRAP messages. (see below). > >> X11 seems to work fine though... > > > > Can you try to bisect? > > dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit > commit dfe63bb0ad9810db13aab0058caba97866e0a681 > Author: James Simmons > Date: Thu Dec 23 16:40:37 2010 + > > drm: Update fbdev fb_fix_screeninfo > > > Reverting this on top of todays git also fixes my problem. I see the problem. Nouveau for some hardware does a accelerated clearing of the screen before we register the framebuffer. The above patch does fix a real issue so please don't revert it. Can you try this patch. diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c index a26d047..4ef24d6 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c @@ -359,6 +359,8 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); info->screen_size = size; + info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : +FB_VISUAL_TRUECOLOR; drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, sizes->fb_height); /* Set aperture base/size for vesafb takeover */ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for rc1
Am 12.01.2011 13:49, schrieb James Simmons: > I see the problem. Nouveau for some hardware does a accelerated > clearing of the screen before we register the framebuffer. The above patch > does fix a real issue so please don't revert it. Can you try this patch. > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > index a26d047..4ef24d6 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > @@ -359,6 +359,8 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, > info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); > info->screen_size = size; > > + info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : > +FB_VISUAL_TRUECOLOR; > drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, > sizes->fb_height); > > /* Set aperture base/size for vesafb takeover */ Hmm, does not seem to work. Any more initialization missing? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26562] New: [bisected] blank screen with radeon.modeset=1
https://bugzilla.kernel.org/show_bug.cgi?id=26562 Summary: [bisected] blank screen with radeon.modeset=1 Product: Drivers Version: 2.5 Kernel Version: 2.6.37 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-...@kernel-bugs.osdl.org ReportedBy: slie...@cc.hut.fi CC: airl...@linux.ie, alexdeuc...@gmail.com Regression: Yes Hi, On 2.6.37, I get blank screen with my RV630 desktop radeon with KMS on (kernel parameter radeon.modeset=1). 2.6.36 works fine. The computer does not crash, the only symptom I can find is no signal to the screen. I have bisected the problem down to this commit: 48dfaaeb6637240af3089bf9b7a00a6cf24e0182 is the first bad commit commit 48dfaaeb6637240af3089bf9b7a00a6cf24e0182 Author: Alex Deucher Date: Wed Sep 29 11:37:41 2010 -0400 drm/radeon/kms: remove new pll algo The recent changes to the old algo (prefer high post div) coupled with the range and precision limitations of using fixed point with the new algo make the new algo less useful. So drop the new algo. This should work as well or better than the old new/old combinations and simplifies the code a lot. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=30218 among others. Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie lspci -v: 01:00.0 VGA compatible controller: ATI Technologies Inc RV630 [Radeon HD 2600 Series] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited Device e410 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at d000 (64-bit, prefetchable) [size=256M] Memory at fe62 (64-bit, non-prefetchable) [size=64K] I/O ports at e000 [size=256] Expansion ROM at fe60 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 01:00.1 Audio device: ATI Technologies Inc RV630/M76 audio device [Radeon HD 2600 Series] Subsystem: PC Partner Limited Device aa08 Flags: bus master, fast devsel, latency 0, IRQ 67 Memory at fe63 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 Kernel driver in use: HDA Intel I tried to diagnose this further with `radeontool regs', but there is no difference in the output between the last good commit (f28488c2) with screen in the working state and the first bad commit (48dfaaeb) with the screen blanked. Here's its output with a text console on the screen (no X): RADEON_DAC_CNTL RADEON_DAC_EXT_CNTL RADEON_DAC_MACRO_CNTL RADEON_DAC_CNTL2 RADEON_TV_DAC_CNTL RADEON_DISP_OUTPUT_CNTL RADEON_CONFIG_MEMSIZE RADEON_AUX_SC_CNTL2ba7a25e RADEON_CRTC_EXT_CNTL RADEON_CRTC_GEN_CNTL RADEON_CRTC2_GEN_CNTL RADEON_DEVICE_ID RADEON_DISP_MISC_CNTL RADEON_GPIO_MONID RADEON_GPIO_MONIDB RADEON_GPIO_CRT2_DDC RADEON_GPIO_DVI_DDC RADEON_GPIO_VGA_DDC RADEON_LVDS_GEN_CNTL RADEON_LVDS_PLL_CNTL RADEON_FP_GEN_CNTL RADEON_FP2_GEN_CNTL RADEON_PPLL_CNTL RADEON_PPLL_REF_DIV RADEON_PPLL_DIV_3 RADEON_PIXCLKS_CNTL RADEON_P2PLL_CNTL RADEON_P2PLL_REF_DIV RADEON_P2PLL_DIV_0 RADEON_VCLK_ECP_CNTL RADEON_MEM_TIMING_CNTL RADEON_TMDS_PLL_CNTL RADEON_TMDS_TRANSMITTER_CNTL RADEON_CRTC_MORE_CNTL RADEON_FP_H_SYNC_STRT_WID RADEON_FP_V_SYNC_STRT_WID RADEON_FP_CRTC_H_TOTAL_DISP RADEON_FP_CRTC_V_TOTAL_DISP RADEON_FP_HORZ_STRETCH RADEON_FP_VERT_STRETCH RADEON_FP_HORZ_VERT_ACTIVE RADEON_CRTC_H_TOTAL_DISP RADEON_CRTC_H_SYNC_STRT_WID RADEON_CRTC_V_TOTAL_DISP RADEON_CRTC_V_SYNC_STRT_WID RADEON_CRTC2_H_TOTAL_DISP020f RADEON_CRTC2_H_SYNC_STRT_WID
Re: [git pull] drm for rc1
> Am 12.01.2011 13:49, schrieb James Simmons: > > I see the problem. Nouveau for some hardware does a accelerated > > clearing of the screen before we register the framebuffer. The above patch > > does fix a real issue so please don't revert it. Can you try this patch. > > > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > > b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > > index a26d047..4ef24d6 100644 > > --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > > +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > > @@ -359,6 +359,8 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, > > info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); > > info->screen_size = size; > > > > + info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : > > +FB_VISUAL_TRUECOLOR; > > drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, > > sizes->fb_height); > > > > /* Set aperture base/size for vesafb takeover */ > > Hmm, does not seem to work. Any more initialization missing? Okay. The nouveau driver also uses the pitch as well. It really should be using the pitch field from drm_framebuffer instead of the line_length from fb_fix_screeninfo. This patch is just to make sure this is the issue. I will submit another patch later that uses drm_fb_framebuffer's pitch field. As for the visual unfortunely their is no real mapping between drm and fbdev. diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c index a26d047..de3b067 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c @@ -359,6 +359,9 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); info->screen_size = size; + info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : +FB_VISUAL_TRUECOLOR; + info->fix.line_length = fb->pitch; drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, sizes->fb_height); /* Set aperture base/size for vesafb takeover */ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for rc1
On Wed, Jan 12, 2011 at 1:21 PM, Christian Borntraeger wrote: > Am 12.01.2011 00:28, schrieb Linus Torvalds: >> On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger >> wrote: >>> >>> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA >>> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) >>> During startup the framebuffer shows only stripes and a blank >>> screen after suspend/resume. >>> I also see lots of TRAP messages. (see below). >>> X11 seems to work fine though... >> >> Can you try to bisect? > > dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit > commit dfe63bb0ad9810db13aab0058caba97866e0a681 > Author: James Simmons > Date: Thu Dec 23 16:40:37 2010 + > > drm: Update fbdev fb_fix_screeninfo > > > Reverting this on top of todays git also fixes my problem. > > Christian > -- > 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/ > I tested the revert: the boot screen did change the resolution (without it don't), but my PC still hangs. (using an nvidia 8800GT). ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26562] [bisected] blank screen with radeon.modeset=1
https://bugzilla.kernel.org/show_bug.cgi?id=26562 --- Comment #2 from Sami Liedes 2011-01-12 13:44:14 --- I believe bugzilla failed to send mail before I added comment #1 some 11 hours later. Reported this in #26592. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for rc1
> On Wed, Jan 12, 2011 at 1:21 PM, Christian Borntraeger > wrote: > > Am 12.01.2011 00:28, schrieb Linus Torvalds: > >> On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger > >> wrote: > >>> > >>> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA > >>> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) > >>> During startup the framebuffer shows only stripes and a blank > >>> screen after suspend/resume. > >>> I also see lots of TRAP messages. (see below). > >>> X11 seems to work fine though... > >> > >> Can you try to bisect? > > > > dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit > > commit dfe63bb0ad9810db13aab0058caba97866e0a681 > > Author: James Simmons > > Date: Thu Dec 23 16:40:37 2010 + > > > > drm: Update fbdev fb_fix_screeninfo > > > > > > Reverting this on top of todays git also fixes my problem. > > > > Christian > > -- > > 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/ > > > > I tested the revert: the boot screen did change the resolution > (without it don't), but my PC still hangs. (using an nvidia 8800GT). Try my most recent patch. Where does it hang at? Any logs? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for rc1
Am 12.01.2011 14:32, schrieb James Simmons: > Okay. The nouveau driver also uses the pitch as well. It > really should be using the pitch field from drm_framebuffer instead of the > line_length from fb_fix_screeninfo. This patch is just to make sure this > is the issue. I will submit another patch later that uses > drm_fb_framebuffer's pitch field. As for the visual unfortunely their is > no real mapping between drm and fbdev. > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > index a26d047..de3b067 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > @@ -359,6 +359,9 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, > info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); > info->screen_size = size; > > + info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : > +FB_VISUAL_TRUECOLOR; > + info->fix.line_length = fb->pitch; > drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, > sizes->fb_height); > > /* Set aperture base/size for vesafb takeover */ That fixes _my_ nouveau frame buffer regression. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for rc1
On Wed, Jan 12, 2011 at 3:45 PM, James Simmons wrote: > >> On Wed, Jan 12, 2011 at 1:21 PM, Christian Borntraeger >> wrote: >> > Am 12.01.2011 00:28, schrieb Linus Torvalds: >> >> On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger >> >> wrote: >> >>> >> >>> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA >> >>> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) >> >>> During startup the framebuffer shows only stripes and a blank >> >>> screen after suspend/resume. >> >>> I also see lots of TRAP messages. (see below). >> >>> X11 seems to work fine though... >> >> >> >> Can you try to bisect? >> > >> > dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit >> > commit dfe63bb0ad9810db13aab0058caba97866e0a681 >> > Author: James Simmons >> > Date: Thu Dec 23 16:40:37 2010 + >> > >> > drm: Update fbdev fb_fix_screeninfo >> > >> > >> > Reverting this on top of todays git also fixes my problem. >> > >> > Christian >> > -- >> > 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/ >> > >> >> I tested the revert: the boot screen did change the resolution >> (without it don't), but my PC still hangs. (using an nvidia 8800GT). > > Try my most recent patch. Where does it hang at? Any logs? > My keyboard is not working, I can not make an log. I see 'something' on the screen, I hear the boot song sometimes. I will test it your parch, but for me it will take over 1 hour. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33027] New: [Evergreen KMS] Crash with garbled screen on mode set
https://bugs.freedesktop.org/show_bug.cgi?id=33027 Summary: [Evergreen KMS] Crash with garbled screen on mode set Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: ser...@hosca.com Ever since Linus merged drm-next, laptop crashes with garbled screen on modeset during boot. I haven't tried to ssh to the laptop yet. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33027] [Evergreen KMS] Crash with garbled screen on mode set
https://bugs.freedesktop.org/show_bug.cgi?id=33027 --- Comment #1 from Serkan Hosca 2011-01-12 05:58:21 PST --- Created an attachment (id=41921) --> (https://bugs.freedesktop.org/attachment.cgi?id=41921) Picture of the screen -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33027] [Evergreen KMS] Crash with garbled screen on mode set
https://bugs.freedesktop.org/show_bug.cgi?id=33027 --- Comment #2 from Serkan Hosca 2011-01-12 06:03:35 PST --- Created an attachment (id=41922) --> (https://bugs.freedesktop.org/attachment.cgi?id=41922) dmesg from working 2.6.37-12-generic -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33027] [Evergreen KMS] Crash with garbled screen on mode set
https://bugs.freedesktop.org/show_bug.cgi?id=33027 --- Comment #3 from Serkan Hosca 2011-01-12 06:04:25 PST --- Created an attachment (id=41923) --> (https://bugs.freedesktop.org/attachment.cgi?id=41923) xorg log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for rc1
Am 12.01.2011 14:45, schrieb James Simmons: >> I tested the revert: the boot screen did change the resolution >> (without it don't), but my PC still hangs. (using an nvidia 8800GT). > > Try my most recent patch. Where does it hang at? Any logs? FYI, I just want to mention that with the latest git+the fix X11 sometimes consumes 100% cpu for a long time. Dont know if this is a related problem or not. Christian ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32556] screen flickers all the time with desktop image appearing only briefly
https://bugs.freedesktop.org/show_bug.cgi?id=32556 --- Comment #27 from Daniel 2011-01-12 07:14:30 PST --- I have a "flicker" problem, too. While option radeon.new_pll=0 fixes the problem at kernel 2.6.35 and 2.6.36, now with 2.6.37 this option is gone. But my computer NOT starts directly flickering after kernel modesetting is initialized. It starts after performing some cpu usage like compiling. First there are many white lines flickering at the screen, then the screen going black. Flickering Video: http://youtu.be/oKsQ4Ga1pKA I have IBM Thinkpad T60 / Gentoo Linux with ATI Technologies Inc Radeon Mobility X1400 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26552] Screen flickering with 2.6.37 [ATI X1600]
https://bugzilla.kernel.org/show_bug.cgi?id=26552 Daniel changed: What|Removed |Added CC||kernelbugzi...@hulapla.de --- Comment #2 from Daniel 2011-01-12 15:14:11 --- I have a "flicker" problem, too. While option radeon.new_pll=0 fixes the problem at kernel 2.6.35 and 2.6.36, now with 2.6.37 this option is gone. But my computer NOT starts directly flickering after kernel modesetting is initialized. It starts after performing some cpu usage like compiling. First there are many white lines flickering at the screen, then the screen going black. Flickering Video: http://youtu.be/oKsQ4Ga1pKA I have IBM Thinkpad T60 / Gentoo Linux with ATI Technologies Inc Radeon Mobility X1400 Same problem? https://bugs.freedesktop.org/show_bug.cgi?id=32556 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2] Utilize the PCI API in the TTM framework.
On Wed, Jan 12, 2011 at 10:12:14AM +0100, Thomas Hellstrom wrote: > Hi, Konrad. > > This discussion has become a bit lenghty. I'll filter out the > sorted-out stuff, which leaves me with two remaining issues: > > > On 01/11/2011 04:55 PM, Konrad Rzeszutek Wilk wrote: > > > >So at the end we have 16GB taken from 8GB->24GB, and 320MB taken from > >0->4GB. When you start allocating coherent memory from each guest > >(and yeah, say we use 2GB each), we end up with the first guest getting > >the 2GB, the second getting 1.7GB, and then the next two getting zil. > > > >You still have GFP_KERNEL memory in each guest - the first one has 2GB left > >, then second 2.3, the next two have each 4GB. > > > >> From the hyprevisor pool perspective, the 0-4GB zone is exhausted, so > >is the 8GB->24GB, but it still has 4GB->8GB free - so it can launch one more > >guest (but without PCI passthrough devices). > > > >>On a 4GB machine or less, that would be the same as kernel memory. > >>Now, if 4 guests think they can allocate 2GB of coherent memory > >>each, you might run out of kernel memory on the host? > >So host in this case refers to the Hypervisor and it does not care > >about the DMA or what - it does not have any device drivers(*) or such. > >The first guest (dom0) is the one that deals with the device drivers. > > > >*: It has one: the serial port, but that is not really that important > >for this discussion. > > Let's assume we're at where the hypervisor (or host) has exhausted > the 0-4GB zone, due to guests coherent memory allocations, and that > the physical machine has 4GB of memory, all in the 0-4GB zone. Now > if the hypervisor was running on a Linux kernel, there would be no > more GFP_KERNEL memory available on the *host* (hypervisor), and the > hypervisor would crash. Now I don't know much about Xen, but it > might be that this is not a problem with Xen at all? It will have no problem. It allocates at boot all the memory it needs and won't get bigger (or smaller) after that. > > > >> > >>Another thing that I was thinking of is what happens if you have a > >>huge gart and allocate a lot of coherent memory. Could that > >>potentially exhaust IOMMU resources? > > > > I need to be more specific. Let's assume we're on "bare metal", and > we want to allocate 4GB of coherent memory. For most IOMMUs that > would mean as you previously state, that we actually allocate > GFP_DMA32 memory. But for some IOMMUs that would perhaps mean that > we allocate *any* memory and set up a permanent DMA mapping in the > IOMMU for the coherent pages. What if, in such a case, the IOMMU can > only set up 2GB of coherent memory? > > Or in short, can there *ever* be "bare metal" cases where the amount > of coherent memory available is less than DMA32 memory available? There is no such case where the amount of coherent memory is less than DMA32 memory. [unless the IOMMU has some chipset problem where it can't map 2^31 -> 2^32 addresses, but that is not a something we should worry about] ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for rc1
On Wed, Jan 12, 2011 at 5:13 PM, Anca Emanuel wrote: > On Wed, Jan 12, 2011 at 3:45 PM, James Simmons wrote: >> >>> On Wed, Jan 12, 2011 at 1:21 PM, Christian Borntraeger >>> wrote: >>> > Am 12.01.2011 00:28, schrieb Linus Torvalds: >>> >> On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger >>> >> wrote: >>> >>> >>> >>> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA >>> >>> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev >>> >>> a1)) >>> >>> During startup the framebuffer shows only stripes and a blank >>> >>> screen after suspend/resume. >>> >>> I also see lots of TRAP messages. (see below). >>> >>> X11 seems to work fine though... >>> >> >>> >> Can you try to bisect? >>> > >>> > dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit >>> > commit dfe63bb0ad9810db13aab0058caba97866e0a681 >>> > Author: James Simmons >>> > Date: Thu Dec 23 16:40:37 2010 + >>> > >>> > drm: Update fbdev fb_fix_screeninfo >>> > >>> > >>> > Reverting this on top of todays git also fixes my problem. >>> > >>> > Christian >>> > -- >>> > 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/ >>> > >>> >>> I tested the revert: the boot screen did change the resolution >>> (without it don't), but my PC still hangs. (using an nvidia 8800GT). >> >> Try my most recent patch. Where does it hang at? Any logs? >> > > With your patch, I can boot the system. But nouveau is not loaded. > dmesg attached. > Forget to mention: the revert makes first steps of boot look the same (change the resolution of the text) but with your patch, I see a big ugly ununtu logo, (I think that is because nouveau is not loaded) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33031] New: r600 DPMS does not turn of backlight
https://bugs.freedesktop.org/show_bug.cgi?id=33031 Summary: r600 DPMS does not turn of backlight Product: DRI Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: cba...@jbandy.com When I issue `setterm -blank force` or `xset dpms force off` the laptop screen goes blank but the backlight does not turn off. # lspci -vns 01:00.0 01:00.0 0300: 1002:68c1 (prog-if 00 [VGA controller]) Subsystem: 103c:1449 Flags: bus master, fast devsel, latency 0, IRQ 49 Memory at c000 (64-bit, prefetchable) [size=256M] Memory at d400 (64-bit, non-prefetchable) [size=128K] I/O ports at 4000 [size=256] Expansion ROM at d404 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information Kernel driver in use: radeon Kernel modules: radeon In the attached logs, 1. Booted without X 2. Ran # setterm -blank force ; sleep 5 ; setterm -blank poke 3. Started X 4. Ran $ xset dpms force off ; sleep 5 ; xset dpms force on -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33031] r600 DPMS does not turn of backlight
https://bugs.freedesktop.org/show_bug.cgi?id=33031 --- Comment #1 from Chris Bandy 2011-01-12 07:27:58 PST --- Created an attachment (id=41925) --> (https://bugs.freedesktop.org/attachment.cgi?id=41925) dmesg.log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33031] r600 DPMS does not turn of backlight
https://bugs.freedesktop.org/show_bug.cgi?id=33031 --- Comment #2 from Chris Bandy 2011-01-12 07:28:25 PST --- Created an attachment (id=41926) --> (https://bugs.freedesktop.org/attachment.cgi?id=41926) Xorg.0.log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for rc1
> >>> I tested the revert: the boot screen did change the resolution > >>> (without it don't), but my PC still hangs. (using an nvidia 8800GT). > >> > >> Try my most recent patch. Where does it hang at? Any logs? > >> > > > > With your patch, I can boot the system. But nouveau is not loaded. > > dmesg attached. > > > > Forget to mention: the revert makes first steps of boot look the same > (change the resolution of the text) > but with your patch, I see a big ugly ununtu logo, (I think that is > because nouveau is not loaded) Is nouveau a module? Does X run? From my understanding is the xorg driver need KMS to run. I didn't see nouveau at all in your dmesg. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for rc1
On Wed, Jan 12, 2011 at 5:40 PM, James Simmons wrote: > >> >>> I tested the revert: the boot screen did change the resolution >> >>> (without it don't), but my PC still hangs. (using an nvidia 8800GT). >> >> >> >> Try my most recent patch. Where does it hang at? Any logs? >> >> >> > >> > With your patch, I can boot the system. But nouveau is not loaded. >> > dmesg attached. >> > >> >> Forget to mention: the revert makes first steps of boot look the same >> (change the resolution of the text) >> but with your patch, I see a big ugly ununtu logo, (I think that is >> because nouveau is not loaded) > > Is nouveau a module? Does X run? From my understanding is the xorg driver I didn't modified any option, from the standard Ubuntu 10.10 > need KMS to run. I didn't see nouveau at all in your dmesg. Exact. I mentioned this when I tested 'next' versions from last year. The answer is in dfe63bb0ad9810db13aab0058caba97866e0a681. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for rc1
On Wed, Jan 12, 2011 at 5:32 AM, James Simmons wrote: > > Okay. The nouveau driver also uses the pitch as well. It > really should be using the pitch field from drm_framebuffer instead of the > line_length from fb_fix_screeninfo. This patch is just to make sure this > is the issue. I will submit another patch later that uses > drm_fb_framebuffer's pitch field. As for the visual unfortunely their is > no real mapping between drm and fbdev. Why do you want to remove the drm_fb_helper_fill_fix() call? Quite frankly, you're then replacing it with open-coding the function partially: > + info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : > + FB_VISUAL_TRUECOLOR; > + info->fix.line_length = fb->pitch; > drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, > sizes->fb_height); Which seems to be just a regression. Why not just call "drm_fb_helper_fill_fix()" here like we used to? IOW, I'm inclined to just do the revert. The "fix" clearly breaks things, and now you're adding random parts of the function back rather than just calling the "fill_fix()" function like things used to. Why? The commit message in dfe63bb0ad98 doesn't support any of these hacks - it just seems to say that drm_fb_helper_fill_fix() should also have been called from setcolreg(). So why don't we just revert the commit and instead add that drm_fb_helper_fill_fix() to setcolreg()? Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for rc1
> IOW, I'm inclined to just do the revert. The "fix" clearly breaks > things, and now you're adding random parts of the function back rather > than just calling the "fill_fix()" function like things used to. Why? Its not the final patch. I'm trying to get feedback on what broke exactly. > The commit message in dfe63bb0ad98 doesn't support any of these hacks > - it just seems to say that drm_fb_helper_fill_fix() should also have > been called from setcolreg(). > > So why don't we just revert the commit and instead add that > drm_fb_helper_fill_fix() to setcolreg()? Fine by me. The real problem is the nouveau driver is using the framebuffer device (fb_fillrect) before set_par is ever called. Before calling set_par the framebuffer state is not defined. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33031] r600 DPMS does not turn of backlight
https://bugs.freedesktop.org/show_bug.cgi?id=33031 --- Comment #3 from Alex Deucher 2011-01-12 08:48:33 PST --- Please try 2.6.37, specifically this patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ba251bde9ab8bdce8fbd3f60dbb71b36cc4c9adf -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32556] screen flickers all the time with desktop image appearing only briefly
https://bugs.freedesktop.org/show_bug.cgi?id=32556 --- Comment #28 from Alex Deucher 2011-01-12 08:51:01 PST --- (In reply to comment #27) > I have a "flicker" problem, too. While option radeon.new_pll=0 fixes the > problem at kernel 2.6.35 and 2.6.36, now with 2.6.37 this option is gone. new_pll=0 became the default. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33027] [Evergreen KMS] Crash with garbled screen on mode set
https://bugs.freedesktop.org/show_bug.cgi?id=33027 --- Comment #4 from Alex Deucher 2011-01-12 08:52:57 PST --- Can you bisect? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for rc1
> Am 12.01.2011 14:45, schrieb James Simmons: > >> I tested the revert: the boot screen did change the resolution > >> (without it don't), but my PC still hangs. (using an nvidia 8800GT). > > > > Try my most recent patch. Where does it hang at? Any logs? > > FYI, I just want to mention that with the latest git+the fix > X11 sometimes consumes 100% cpu for a long time. Dont know if > this is a related problem or not. I doubt they are related. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26552] Screen flickering with 2.6.37 [ATI X1600]
https://bugzilla.kernel.org/show_bug.cgi?id=26552 Alex Deucher changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #3 from Alex Deucher 2011-01-12 17:18:43 --- I think this is probably a duplicate of bug 26562. new_pll=0 became the default in 2.6.37. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32556] screen flickers all the time with desktop image appearing only briefly
https://bugs.freedesktop.org/show_bug.cgi?id=32556 --- Comment #29 from Daniel 2011-01-12 10:22:38 PST --- Okay, but without new_pll=0 in 2.6.35/36 i had the completely identical error. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26552] Screen flickering with 2.6.37 [ATI X1600]
https://bugzilla.kernel.org/show_bug.cgi?id=26552 --- Comment #4 from Daniel 2011-01-12 18:28:41 --- Okay, but without new_pll=0 in 2.6.35/36 i had the completely identical error. Sombody else has this flickering white lines, before screen going black? (see video) -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33036] Null ptr deref in radeon_r300_winsys_buffer_from_handle()
https://bugs.freedesktop.org/show_bug.cgi?id=33036 Michel Dänzer changed: What|Removed |Added Product|xorg|Mesa Version|7.5 |7.9 Component|Driver/Radeon |Drivers/Gallium/r300 AssignedTo|xorg-driver-...@lists.x.org |dri-de...@lists.freedesktop ||.org QAContact|xorg-t...@lists.x.org | -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm intel only fixes
On Tue, Jan 11, 2011 at 10:03 PM, Dave Airlie wrote: > > I'm stuck at home with just my i5 laptop due to the office being shut due > to the ongoing floods. But I've booted and ran this for a few hours and it > seems to be better than the current tree. It contains a couple of patches > to fix DMAR interaction issues I see on this laptop on top of Chris's > pull. Hmm. I'm not seeing the screensaver issue any more, but there's something wrong with video. At least the TED ones (I'm not seeing it on a youtube video i tried). See for example http://www.ted.com/talks/lang/eng/david_gallo_shows_underwater_astonishments.html and when there is fast movement in the video (like when the octopus is spooked), I get these odd lines of noise. In fact, while I noticed the lines in the video itself, it's actually most repeatably noticeable in the buttons underneath while the video is playing: make your mouse go back-and-forth between the "rate" and "share" buttons, and they get corrupted (and it also corrupts the progress bar). It looks a bit like the noise you get with insufficient memory bandwidth, but I doubt that's the case here. Perhaps just some motion-comp problem? Any ideas? Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm intel only fixes
On Wed, 12 Jan 2011 11:22:58 -0800 Linus Torvalds wrote: > On Tue, Jan 11, 2011 at 10:03 PM, Dave Airlie wrote: > > > > I'm stuck at home with just my i5 laptop due to the office being shut due > > to the ongoing floods. But I've booted and ran this for a few hours and it > > seems to be better than the current tree. It contains a couple of patches > > to fix DMAR interaction issues I see on this laptop on top of Chris's > > pull. > > Hmm. I'm not seeing the screensaver issue any more, but there's > something wrong with video. At least the TED ones (I'm not seeing it > on a youtube video i tried). See for example > > > http://www.ted.com/talks/lang/eng/david_gallo_shows_underwater_astonishments.html > > and when there is fast movement in the video (like when the octopus is > spooked), I get these odd lines of noise. > > In fact, while I noticed the lines in the video itself, it's actually > most repeatably noticeable in the buttons underneath while the video > is playing: make your mouse go back-and-forth between the "rate" and > "share" buttons, and they get corrupted (and it also corrupts the > progress bar). > > It looks a bit like the noise you get with insufficient memory > bandwidth, but I doubt that's the case here. Perhaps just some > motion-comp problem? > > Any ideas? Since I doubt we're actually offloading to our video decode kernels for Flash video on your machine, it could very well be a memory bw issue. Can you try this small patch to see if one of the low power watermarks is giving you trouble (note: cut & pasted)? It could also be the normal power watermarks though too; you could just make plane-wm and cursor_wm higher to test that. -- Jesse Barnes, Intel Open Source Technology Center diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_d index 9ef5578..4e8af4d 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -3600,6 +3600,8 @@ static void ironlake_update_wm(struct drm_device *dev, if (enabled != 1) return; + return; + clock = planea_clock ? planea_clock : planeb_clock; /* WM1 */ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28905] missing scene triangle in scorched3d using KMS r600
https://bugs.freedesktop.org/show_bug.cgi?id=28905 --- Comment #4 from aceman 2011-01-12 12:25:07 PST --- Still a problem with Mesa 7.10, kernel 2.6.36.2, radeon driver 6.13.99 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm intel only fixes
On Wed, Jan 12, 2011 at 11:46 AM, Jesse Barnes wrote: > > Since I doubt we're actually offloading to our video decode kernels for > Flash video on your machine It's the latest 64-bit beta flash player, so maybe it does use hw acceleration. > it could very well be a memory bw issue. > Can you try this small patch to see if one of the low power watermarks > is giving you trouble (note: cut & pasted)? No difference. > It could also be the normal power watermarks though too; you could just > make plane-wm and cursor_wm higher to test that. I multiplied them by two, no difference. The patch I used attached. Does nobody else see this? Linus drivers/gpu/drm/i915/intel_display.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 25d9688..2ea1a51 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -3445,6 +3445,7 @@ static bool ironlake_compute_wm0(struct drm_device *dev, entries += tlb_miss; entries = DIV_ROUND_UP(entries, display->cacheline_size); *plane_wm = entries + display->guard_size; +*plane_wm *=2; if (*plane_wm > (int)display->max_wm) *plane_wm = display->max_wm; @@ -3457,6 +3458,7 @@ static bool ironlake_compute_wm0(struct drm_device *dev, entries += tlb_miss; entries = DIV_ROUND_UP(entries, cursor->cacheline_size); *cursor_wm = entries + cursor->guard_size; +*cursor_wm *= 2; if (*cursor_wm > (int)cursor->max_wm) *cursor_wm = (int)cursor->max_wm; @@ -3607,6 +3609,8 @@ static void ironlake_update_wm(struct drm_device *dev, if (enabled != 1) return; +return; + clock = planea_clock ? planea_clock : planeb_clock; /* WM1 */ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30503] atmosphere of planet in celestia gets blocky
https://bugs.freedesktop.org/show_bug.cgi?id=30503 aceman changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #3 from aceman 2011-01-12 12:27:53 PST --- After trying bisecting mesa 7.9 and finally returning to the official snapshot, the problem solved itself. Closing for now. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30502] atmospheres of planets get transparent when going away from planets in celestia
https://bugs.freedesktop.org/show_bug.cgi?id=30502 --- Comment #12 from aceman 2011-01-12 12:30:22 PST --- After trying bisecting mesa 7.9 and finally returning to the official snapshot, the problem vanished at the planet. It is still visible at some nebulas, but I am not sure it is the same problem. Both seem like a problem with some depth (distance from screen) determination. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30502] atmospheres of planets get transparent when going away from planets in celestia
https://bugs.freedesktop.org/show_bug.cgi?id=30502 aceman changed: What|Removed |Added Version|unspecified |7.9 --- Comment #13 from aceman 2011-01-12 12:36:22 PST --- The broken driver problem seems to be Bug 28284 according to the error message. I probably returned the tree into that time range. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32318] [r300g] Titan's atmosphere in celestia is blue with OpenGL 2.0 rendering path.
https://bugs.freedesktop.org/show_bug.cgi?id=32318 aceman changed: What|Removed |Added CC||aceli...@atlas.sk --- Comment #4 from aceman 2011-01-12 12:40:45 PST --- I also get this on Radeon HD 4350, driver 6.13.2, Xorg 1.7.7, Mesa 7.9 R600c, kernel 2.6.36. See Bug 30502. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33038] New: celestia crashes with error: "radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion `boi->space_accounted' failed"
https://bugs.freedesktop.org/show_bug.cgi?id=33038 Summary: celestia crashes with error: "radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion `boi->space_accounted' failed" Product: Mesa Version: 7.10 Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: aceli...@atlas.sk Celestia program starts, draws the universe for a few seconds, then crashes with the error message: "radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion `boi->space_accounted' failed". Using kernel 2.6.36.2 (2.6.37 already out, but hangs the X server at start), Mesa 7.10 r600c, radeon 6.13.99-af2e6d7d2f1b3d8f8f6b0acfb2b7b0cfaff7bcdb. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 27708] [KMS] Repeated EDID errors despite everything working
https://bugs.freedesktop.org/show_bug.cgi?id=27708 aceman changed: What|Removed |Added CC||aceli...@atlas.sk --- Comment #9 from aceman 2011-01-12 12:57:13 PST --- I also see this with Radeon HD 4350, kernel 2.6.36, driver 6.13.2 (and also 99), KMS. Monitor is a HP ZR24w, using DVI. Jan 12 21:00:40 coolbox kernel: [drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Trim the GEM mmap offset hashtab
Using an order 19 drm_ht for the mmap offsets is a little obscene. That
means that will a fully populated GTT with every single object mmaped at
least once in its lifetime, there will be exactly one object in each
bucket.
Typically systems only have at most a few thousand objects, though you
may see a KDE desktop hit 5. And most of those should never be
mapped... On my systems, just using an order 10 ht would still have an
average occupancy less than 1, so apply a small safety factor and
use an order 12 ht, like the other mmap offset ht.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_gem.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index ea1c4b0..31ece38 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -101,7 +101,7 @@ drm_gem_init(struct drm_device *dev)
dev->mm_private = mm;
- if (drm_ht_create(&mm->offset_hash, 19)) {
+ if (drm_ht_create(&mm->offset_hash, 12)) {
kfree(mm);
return -ENOMEM;
}
--
1.7.2.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] vmwgfx: Remove unnecessary memset(,0,)
kzalloc'd memory doesn't need a memset to 0.
Signed-off-by: Joe Perches
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 10ca97e..ed18932 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -248,7 +248,6 @@ static int vmw_driver_load(struct drm_device *dev, unsigned
long chipset)
DRM_ERROR("Failed allocating a device private struct.\n");
return -ENOMEM;
}
- memset(dev_priv, 0, sizeof(*dev_priv));
dev_priv->dev = dev;
dev_priv->vmw_chipset = chipset;
--
1.7.3.3.398.g0b0cd.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm intel only fixes
On Wed, Jan 12, 2011 at 12:27 PM, Linus Torvalds wrote: > On Wed, Jan 12, 2011 at 11:46 AM, Jesse Barnes > wrote: >> >> Since I doubt we're actually offloading to our video decode kernels for >> Flash video on your machine > > It's the latest 64-bit beta flash player, so maybe it does use hw > acceleration. > > >> it could very well be a memory bw issue. >> Can you try this small patch to see if one of the low power watermarks >> is giving you trouble (note: cut & pasted)? > > No difference. Oh, and I'm also seeing corruption on my sandybridge machine. No video involved, the gdm login screen is already corrupted this way. Similar odd shifted lines etc, so I'd assume it's related. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33027] [Evergreen KMS] Crash with garbled screen on mode set
https://bugs.freedesktop.org/show_bug.cgi?id=33027 --- Comment #5 from Serkan Hosca 2011-01-12 13:45:01 PST --- After countless reboots: 9e46a48df24f9698b34d28385b320c529851e5f7 is the first bad commit commit 9e46a48df24f9698b34d28385b320c529851e5f7 Author: Alex Deucher Date: Thu Jan 6 18:49:35 2011 -0500 drm/radeon/kms: add support for gen2 pcie link speeds Supported on rv6xx/r7xx/evergreen. Cards come up in gen1 mode. Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie :04 04 55843e87128e6be0103a644d565aa42cadfaa331 7c9afe069f4bc71eb2f815cf3e8fe0a9c96d7be8 Mdrivers -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26552] Screen flickering with 2.6.37 [ATI X1600]
https://bugzilla.kernel.org/show_bug.cgi?id=26552 --- Comment #5 from Andrea Iob 2011-01-12 22:03:07 --- (In reply to comment #2) > > Same problem? https://bugs.freedesktop.org/show_bug.cgi?id=32556 I've tried the patches proposed in that bugreport (comment #24) without any luck: the flickering is still there. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26552] Screen flickering with 2.6.37 [ATI X1600]
https://bugzilla.kernel.org/show_bug.cgi?id=26552 --- Comment #6 from Andrea Iob 2011-01-12 22:04:23 --- Created an attachment (id=43332) --> (https://bugzilla.kernel.org/attachment.cgi?id=43332) lspci -v -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26552] Screen flickering with 2.6.37 [ATI X1600]
https://bugzilla.kernel.org/show_bug.cgi?id=26552 --- Comment #7 from Andrea Iob 2011-01-12 22:08:27 --- Created an attachment (id=43342) --> (https://bugzilla.kernel.org/attachment.cgi?id=43342) vbios -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm intel only fixes
On Wed, 12 Jan 2011 13:28:53 -0800
Linus Torvalds wrote:
> On Wed, Jan 12, 2011 at 12:27 PM, Linus Torvalds
> wrote:
> > On Wed, Jan 12, 2011 at 11:46 AM, Jesse Barnes
> > wrote:
> >>
> >> Since I doubt we're actually offloading to our video decode kernels for
> >> Flash video on your machine
> >
> > It's the latest 64-bit beta flash player, so maybe it does use hw
> > acceleration.
> >
> >
> >> it could very well be a memory bw issue.
> >> Can you try this small patch to see if one of the low power watermarks
> >> is giving you trouble (note: cut & pasted)?
> >
> > No difference.
>
> Oh, and I'm also seeing corruption on my sandybridge machine. No video
> involved, the gdm login screen is already corrupted this way. Similar
> odd shifted lines etc, so I'd assume it's related.
Ah, ok. So it could be our internal FDI link is underrunning; it goes
between the CPU and PCH and carries display bits.
Are these both desktop type machines with DVI attached monitors?
If it's an FDI or transcoder problem, something like the below may give
us more info.
Can you take a picture of the corruption? If I see it I can try to
reproduce it here by messing with FDI, transcoder, and DP link settings
to see if they're the problem.
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index e418e8b..4c6c465 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -428,6 +428,15 @@ static void pch_irq_handler(struct drm_device *dev)
fdia = I915_READ(FDI_RXA_IIR);
fdib = I915_READ(FDI_RXB_IIR);
DRM_DEBUG_DRIVER("PCH FDI RX interrupt; FDI RXA IIR: 0x%08x,
FDI RXB IIR: 0x%08x\n", fdia, fdib);
+
+ if (fdia & FDI_RX_ERR_MASK) {
+ DRM_ERROR("FDI A RX error: 0x%08x\n", fdia);
+ I915_WRITE(FDI_RXA_IIR, FDI_RX_ERR_MASK);
+ }
+ if (fdib & FDI_RX_ERR_MASK) {
+ DRM_ERROR("FDI B RX error: 0x%08x\n", fdib);
+ I915_WRITE(FDI_RXB_IIR, FDI_RX_ERR_MASK);
+ }
}
if (pch_iir & (SDE_TRANSB_CRC_DONE | SDE_TRANSA_CRC_DONE))
@@ -437,9 +446,9 @@ static void pch_irq_handler(struct drm_device *dev)
DRM_DEBUG_DRIVER("PCH transcoder CRC error interrupt\n");
if (pch_iir & SDE_TRANSB_FIFO_UNDER)
- DRM_DEBUG_DRIVER("PCH transcoder B underrun interrupt\n");
+ DRM_ERROR("PCH transcoder B underrun interrupt\n");
if (pch_iir & SDE_TRANSA_FIFO_UNDER)
- DRM_DEBUG_DRIVER("PCH transcoder A underrun interrupt\n");
+ DRM_ERROR("PCH transcoder A underrun interrupt\n");
}
static irqreturn_t ironlake_irq_handler(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 40a407f..6e81d97 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3101,6 +3101,11 @@
#define FDI_RX_PIXEL_FIFO_OVERFLOW (1<<2)
#define FDI_RX_CROSS_CLOCK_OVERFLOW (1<<1)
#define FDI_RX_SYMBOL_QUEUE_OVERFLOW(1<<0)
+#define FDI_RX_ERR_MASK (FDI_RX_FS_CODE_ERR | FDI_RX_FE_CODE_ERR | \
+FDI_RX_SYMBOL_ERR_RATE_ABOVE | \
+FDI_RX_PIXEL_FIFO_OVERFLOW | \
+FDI_RX_CROSS_CLOCK_OVERFLOW | \
+FDI_RX_SYMBOL_QUEUE_OVERFLOW)
#define FDI_RXA_IIR 0xf0014
#define FDI_RXA_IMR 0xf0018
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm intel only fixes
On Wed, Jan 12, 2011 at 1:28 PM, Linus Torvalds wrote: > > Oh, and I'm also seeing corruption on my sandybridge machine. No video > involved, the gdm login screen is already corrupted this way. Similar > odd shifted lines etc, so I'd assume it's related. Hmm. I bisected it down to commit 6fe4f14044f181e146cdc15485428f95fa541ce8 Author: Chris Wilson Date: Mon Jan 10 17:35:37 2011 + drm/i915/execbuffer: Reorder binding of objects to favour restrictions on my sandybridge machine. Chris? Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm intel only fixes
On Wed, Jan 12, 2011 at 2:22 PM, Jesse Barnes wrote: > > Ah, ok. So it could be our internal FDI link is underrunning; it goes > between the CPU and PCH and carries display bits. I'm not sure it's an underrun or anything like that: the corruption is long-term in the non-video case. So I take back the "looks like memory bandwidth problems", because it really looks more like a corrupted blit operation there. > Are these both desktop type machines with DVI attached monitors? DVI on the Core i5, plain analog VGA on the sandybridge one (I can hear you asking "Why?". Because the silly intel motherboard doesn't _have_ DVI out, and I didn't have a hdmi cable) > If it's an FDI or transcoder problem, something like the below may give > us more info. See above. It's long-term, it was just the video behavior that made me originally think it was temporary. > Can you take a picture of the corruption? Will do. I'll have to reboot to the broken kernel (my bisection ended in a non-broken case) Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm intel only fixes
On Wed, 12 Jan 2011 14:24:17 -0800, Linus Torvalds wrote: > On Wed, Jan 12, 2011 at 1:28 PM, Linus Torvalds > wrote: > > > > Oh, and I'm also seeing corruption on my sandybridge machine. No video > > involved, the gdm login screen is already corrupted this way. Similar > > odd shifted lines etc, so I'd assume it's related. > > Hmm. I bisected it down to > > commit 6fe4f14044f181e146cdc15485428f95fa541ce8 > Author: Chris Wilson > Date: Mon Jan 10 17:35:37 2011 + > > drm/i915/execbuffer: Reorder binding of objects to favour restrictions > > on my sandybridge machine. Chris? Wow. That should have had zero visible impact upon the rendering. All it should have done is reorder the sequence in which we pin the buffers into the GTT before applying the relocations, just to allow some pathological execbuffers. Just the SNB machine? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33027] [Evergreen KMS] Crash with garbled screen on mode set
https://bugs.freedesktop.org/show_bug.cgi?id=33027 --- Comment #6 from Alex Deucher 2011-01-12 15:01:15 PST --- Created an attachment (id=41939) View: https://bugs.freedesktop.org/attachment.cgi?id=41939 Review: https://bugs.freedesktop.org/review?bug=33027&attachment=41939 add gen2 module option Seems there may be gen2 compat issues with some motherboards. What chipset is your system? Can you attach the lspci -vnn output? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33027] [Evergreen KMS] Crash with garbled screen on mode set
https://bugs.freedesktop.org/show_bug.cgi?id=33027 --- Comment #7 from Serkan Hosca 2011-01-12 15:03:38 PST --- Created an attachment (id=41940) --> (https://bugs.freedesktop.org/attachment.cgi?id=41940) lspci -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm intel only fixes
On Wed, 12 Jan 2011 14:31:33 -0800 Linus Torvalds wrote: > On Wed, Jan 12, 2011 at 2:22 PM, Jesse Barnes > wrote: > > > > Ah, ok. So it could be our internal FDI link is underrunning; it goes > > between the CPU and PCH and carries display bits. > > I'm not sure it's an underrun or anything like that: the corruption is > long-term in the non-video case. So I take back the "looks like memory > bandwidth problems", because it really looks more like a corrupted > blit operation there. Ah ok if it's long running then yeah it's more likely to be a rendering issue. It could also be the FDI link getting its timings messed up though, and consistently delivering the wrong bits; that could show up in the same place on the screen each time, or it might move in a pattern across the screen (usually from top to bottom). > Will do. I'll have to reboot to the broken kernel (my bisection ended > in a non-broken case) Great, thanks. -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm intel only fixes
On Wed, 12 Jan 2011 15:05:36 -0800, Linus Torvalds wrote: > On Wed, Jan 12, 2011 at 2:40 PM, Chris Wilson > wrote: > > Just the SNB machine? > > No. I just checked. Reverting that commit on my other machine makes > that TED video on my Core i5 machine look fine too. > > So it's definitely the same bug on both Sandybridge and Core-i5 (I > guess that's "Ironlake" in the crazy intel codename naming), just two > slightly different symptoms. And I worried a bit that my bisect was > bogus, but with the revert clearing it up on the other machine, I'm > confident the bisect was good too. > > On my sandybridge machine, the corruption happens already at the gdm > login screen, which is why I used that one to bisect things. I'm > including a (bad) photo taken with my cellphone of what the corruption > looks like - see how the "sandybridge.linux-foundation.org" machine > name text has been corrupted, and obviously my name (and the "e" in > Other). And that blue rounded rectangle should contain "Log in as > torvalds" or something like that, but instead it's clear. Yes, that looks consistent with using the wrong relocation entry or GTT offset within the batch. Thanks, -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33027] [Evergreen KMS] Crash with garbled screen on mode set
https://bugs.freedesktop.org/show_bug.cgi?id=33027 --- Comment #8 from Serkan Hosca 2011-01-12 15:18:47 PST --- Its a second generation HP envy 15. According to google the chipset is PM55. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33027] [Evergreen KMS] Crash with garbled screen on mode set
https://bugs.freedesktop.org/show_bug.cgi?id=33027 --- Comment #9 from Serkan Hosca 2011-01-12 15:44:08 PST --- gen2 patch fixed the problem. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26562] [bisected] blank screen with radeon.modeset=1
https://bugzilla.kernel.org/show_bug.cgi?id=26562 --- Comment #3 from Sami Liedes 2011-01-12 23:49:00 --- Created an attachment (id=43352) --> (https://bugzilla.kernel.org/attachment.cgi?id=43352) Revert "drm/radeon/kms: remove new pll algo" I can now confirm that reverting 48dfaaeb6637240af3089bf9b7a00a6cf24e0182 on 2.6.37 fixes this problem for me. Patch attached. Of course I'll still be happy to test better fixes. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37
On Wed, January 12, 2011 13:07, Chris Wilson wrote: > > Sure, s/intel_panel_get_max_backlight/intel_panel_get_backlight/ and we > get the behaviour we both want - preserving the current backlight unless > none is set. Indeed, I hadn't noticed that shortcut. That's a lot nicer than my ifdefery. > >> While I'm glad this problem is being fixed upstream, it would be nice to get >> some credit for finding the source of the problem. > > Sorry. You found the bug but I felt your rationale was off. However, I was > amiss in not giving you the credit you fully deserved. Thank you very much! The rationale was that intel_panel_set_backlight(0) was somehow called twice, and that the current code unconditionally stored the old backlight, and thus losing the original brightness level. This is exactly what happened. My fix was to prevent backlight_level from being overwritten by zero. Your fix was more structural and properly fixed backlight enabled/disabled state. In the end both have the same effect and solve the bug. Perhaps I was unclear in the bug description. Anyhow, it's a pleasure working with you. I'll try to not bother you too much, you got enough on your plate as it is. I'll leave you alone for a while after you looked into my fix for bug 23472, after that all my Intel graphics are pretty much solved. :-) Take care, Indan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32556] screen flickers all the time with desktop image appearing only briefly
https://bugs.freedesktop.org/show_bug.cgi?id=32556 --- Comment #30 from Alex Deucher 2011-01-12 17:01:16 PST --- Created an attachment (id=41943) View: https://bugs.freedesktop.org/attachment.cgi?id=41943 Review: https://bugs.freedesktop.org/review?bug=32556&attachment=41943 possible fix Does this patch fix the issues? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26552] Screen flickering with 2.6.37 [ATI X1600]
https://bugzilla.kernel.org/show_bug.cgi?id=26552 --- Comment #8 from Alex Deucher 2011-01-13 01:01:54 --- Created an attachment (id=43362) --> (https://bugzilla.kernel.org/attachment.cgi?id=43362) possible fix Does this patch fix the issues? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26562] [bisected] blank screen with radeon.modeset=1
https://bugzilla.kernel.org/show_bug.cgi?id=26562 --- Comment #4 from Alex Deucher 2011-01-13 01:02:48 --- Created an attachment (id=43372) --> (https://bugzilla.kernel.org/attachment.cgi?id=43372) possible fix Does this patch fix the issues? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: add module option for pcie gen2
Switching to pcie gen2 causes problems on some
boards. Add a module option to turn it on/off.
There are gen2 compatability issues with some
motherboards it seems.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=33027
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c |3 +++
drivers/gpu/drm/radeon/r600.c |3 +++
drivers/gpu/drm/radeon/radeon.h |1 +
drivers/gpu/drm/radeon/radeon_drv.c |4
drivers/gpu/drm/radeon/rv770.c |3 +++
5 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 1db2684..7ebc341 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3133,6 +3133,9 @@ static void evergreen_pcie_gen2_enable(struct
radeon_device *rdev)
{
u32 link_width_cntl, speed_cntl;
+ if (radeon_pcie_gen2 == 0)
+ return;
+
if (rdev->flags & RADEON_IS_IGP)
return;
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 203f6a4..becc0a9 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -3648,6 +3648,9 @@ static void r600_pcie_gen2_enable(struct radeon_device
*rdev)
u32 link_width_cntl, lanes, speed_cntl, training_cntl, tmp;
u16 link_cntl2;
+ if (radeon_pcie_gen2 == 0)
+ return;
+
if (rdev->flags & RADEON_IS_IGP)
return;
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index d3b3adc..854ddc6 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -92,6 +92,7 @@ extern int radeon_tv;
extern int radeon_audio;
extern int radeon_disp_priority;
extern int radeon_hw_i2c;
+extern int radeon_pcie_gen2;
/*
* Copy from radeon_drv.h so we don't have to include both and have conflicting
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index be5cb4f..d5680a0 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -104,6 +104,7 @@ int radeon_tv = 1;
int radeon_audio = 1;
int radeon_disp_priority = 0;
int radeon_hw_i2c = 0;
+int radeon_pcie_gen2 = 0;
MODULE_PARM_DESC(no_wb, "Disable AGP writeback for scratch registers");
module_param_named(no_wb, radeon_no_wb, int, 0444);
@@ -147,6 +148,9 @@ module_param_named(disp_priority, radeon_disp_priority,
int, 0444);
MODULE_PARM_DESC(hw_i2c, "hw i2c engine enable (0 = disable)");
module_param_named(hw_i2c, radeon_hw_i2c, int, 0444);
+MODULE_PARM_DESC(pcie_gen2, "PCIE Gen2 mode (1 = enable)");
+module_param_named(pcie_gen2, radeon_pcie_gen2, int, 0444);
+
static int radeon_suspend(struct drm_device *dev, pm_message_t state)
{
drm_radeon_private_t *dev_priv = dev->dev_private;
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index 3bf7828..491dc90 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -1372,6 +1372,9 @@ static void rv770_pcie_gen2_enable(struct radeon_device
*rdev)
u32 link_width_cntl, lanes, speed_cntl, tmp;
u16 link_cntl2;
+ if (radeon_pcie_gen2 == 0)
+ return;
+
if (rdev->flags & RADEON_IS_IGP)
return;
--
1.7.1.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 27314] DP link training fails on 2560x1440 panels
https://bugs.freedesktop.org/show_bug.cgi?id=27314 --- Comment #26 from Alex Deucher 2011-01-12 17:10:50 PST --- Created an attachment (id=41944) View: https://bugs.freedesktop.org/attachment.cgi?id=41944 Review: https://bugs.freedesktop.org/review?bug=27314&attachment=41944 possible fix Maybe the monitor doesn't like the clock... Does this patch help? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33042] New: RV770: Broken Mipmap creation/display
https://bugs.freedesktop.org/show_bug.cgi?id=33042 Summary: RV770: Broken Mipmap creation/display Product: DRI Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: andreas.bo...@mytum.de Created an attachment (id=41946) --> (https://bugs.freedesktop.org/attachment.cgi?id=41946) Celestia screenshot I'm using mainline Linux kernels, and this bug is a regression from 2.6.36. It got broken already in 37-rc series but I haven't noticed it (compiz desktop works fine) and didn't get around to report it in time. The latest kernel I've tested is 2.6.37-05292-g7bc4a4c running Debian sid. It appears that the vertical size assumed during display of the mipmap is twice the mipmap's height. See attached screenshot from Celestia which shows the first level mipmap on the central star. Horizontal size seems to be correct. Zooming outward reveals further mipmap levels with unrelated data as can be seen on the other two stars in the image. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33042] RV770: Broken Mipmap creation/display
https://bugs.freedesktop.org/show_bug.cgi?id=33042 --- Comment #1 from Andreas Bombe 2011-01-12 17:25:52 PST --- Created an attachment (id=41947) --> (https://bugs.freedesktop.org/attachment.cgi?id=41947) Xorg log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33042] RV770: Broken Mipmap creation/display
https://bugs.freedesktop.org/show_bug.cgi?id=33042 --- Comment #2 from Andreas Bombe 2011-01-12 17:29:44 PST --- Created an attachment (id=41948) --> (https://bugs.freedesktop.org/attachment.cgi?id=41948) DRM specific lines from kernel log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33042] RV770: Broken Mipmap creation/display
https://bugs.freedesktop.org/show_bug.cgi?id=33042 --- Comment #3 from Alex Deucher 2011-01-12 18:59:27 PST --- What version of mesa are you using? Does mesa 7.10 or 7.9.1 work any better? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32733] arbocclude2 from mesa-demos segfaults
https://bugs.freedesktop.org/show_bug.cgi?id=32733 --- Comment #4 from Brian Paterni 2011-01-12 19:23:50 PST --- 30616fdacfd3e2d8d3df64e4aa6b4cac405f3cf0 fixes arbocclude2 for me. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26562] [bisected] blank screen with radeon.modeset=1
https://bugzilla.kernel.org/show_bug.cgi?id=26562 --- Comment #5 from Sami Liedes 2011-01-13 04:48:58 --- Yes, 2.6.37 + that patch works for me. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33031] r600 DPMS does not turn of backlight
https://bugs.freedesktop.org/show_bug.cgi?id=33031 Chris Bandy changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #4 from Chris Bandy 2011-01-12 21:32:29 PST --- Yes, this is fixed in gentoo-sources-2.6.37 for me. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm for rc1
Am 10.01.2011 23:59, schrieb Dave Airlie: > > Hi Linus, > > non-drm changes: > one kref change we needed that went on list with no comments > > New hardware: > radeon: add support for Fusion APUs and Radeon HD6xxx chipsets > nouveau: Fermi acceleration support (requires external fw for now) > > Highlights: > core/drivers: add support for high precision vblank timestamps > radeon: pageflipping support, Gen2 PCIE support > nouveau: reworked VRAM and VM support > intel: better ILK/SNB powersaving support, Full GTT support > > There are also some switcheroo patches to further improve it, though I > have a later patch blocking on an x86 platform driver for the nvidia/intel > switcher. > > Dave. Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) During startup the framebuffer shows only stripes and a blank screen after suspend/resume. I also see lots of TRAP messages. (see below). X11 seems to work fine though... $ dmesg | grep drm [0.520906] [drm] Initialized drm 1.1.0 20060810 [0.521200] [drm] radeon defaulting to kernel modesetting. [0.521416] [drm] radeon kernel modesetting enabled. [0.522179] [drm:i915_init] *ERROR* drm/i915 can't work without intel_agp module! [0.536664] [drm] nouveau :01:00.0: Detected an NV50 generation card (0x084c00a2) [0.556998] [drm] nouveau :01:00.0: Attempting to load BIOS image from PRAMIN [0.641884] [drm] nouveau :01:00.0: ... appears to be valid [0.642058] [drm] nouveau :01:00.0: BIT BIOS found [0.642227] [drm] nouveau :01:00.0: Bios version 60.84.51.00 [0.642400] [drm] nouveau :01:00.0: TMDS table version 2.0 [0.642567] [drm] nouveau :01:00.0: BIT table 'd' not found [0.642736] [drm] nouveau :01:00.0: Found Display Configuration Block version 4.0 [0.642969] [drm] nouveau :01:00.0: Raw DCB entry 0: 01000323 00010034 [0.643141] [drm] nouveau :01:00.0: Raw DCB entry 1: 02811300 0028 [0.643315] [drm] nouveau :01:00.0: Raw DCB entry 2: 02822312 00010030 [0.643490] [drm] nouveau :01:00.0: Raw DCB entry 3: 000e [0.643662] [drm] nouveau :01:00.0: DCB connector table: VHER 0x40 5 14 2 [0.643836] [drm] nouveau :01:00.0: 0: 0x0040: type 0x40 idx 0 tag 0xff [0.644089] [drm] nouveau :01:00.0: 1: 0x0100: type 0x00 idx 1 tag 0xff [0.644317] [drm] nouveau :01:00.0: 2: 0x1231: type 0x31 idx 2 tag 0x07 [0.644543] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 0xDEBB [0.688140] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 0xE208 [0.724028] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at offset 0xEC55 [0.724264] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at offset 0xED47 [0.732117] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 0xEF7A [0.732345] [drm] nouveau :01:00.0: Parsing VBIOS init table at offset 0xEFDF [0.756029] [drm] nouveau :01:00.0: 0xEFDF: Condition still not met after 20ms, skipping following opcodes [0.775483] [drm] nouveau :01:00.0: 3 available performance level(s) [0.775663] [drm] nouveau :01:00.0: 0: memory 100MHz core 169MHz shader 338MHz voltage 1150mV fanspeed 100% [0.775900] [drm] nouveau :01:00.0: 1: memory 301MHz core 275MHz shader 550MHz voltage 1150mV fanspeed 100% [0.776165] [drm] nouveau :01:00.0: 2: memory 702MHz core 475MHz shader 950MHz voltage 1200mV fanspeed 100% [0.776419] [drm] nouveau :01:00.0: c: memory 302MHz core 275MHz shader 550MHz voltage 1150mV [0.777232] [drm] nouveau :01:00.0: Detected 256MiB VRAM [0.817893] [drm] nouveau :01:00.0: 512 MiB GART (aperture) [0.889393] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [0.889565] [drm] No driver support for vblank timestamp query. [0.904293] [drm] nouveau :01:00.0: ACPI backlight interface available, not registering our own [1.071762] [drm] nouveau :01:00.0: allocated 1920x1200 fb: 0x6000, bo 88013af63400 [1.071842] [drm] nouveau
Linux 2.6.37
Hello,
On Tue, January 11, 2011 18:39, Chris Wilson wrote:
> On Tue, 11 Jan 2011 18:19:17 +0100, Michal Hocko wrote:
>> [Let's CC Indan - author of the bugzilla patches]
>>
>> On Thu 06-01-11 11:48:16, Michal Hocko wrote:
>> > Hi,
>> >
>> > On Tue 04-01-11 17:15:45, Linus Torvalds wrote:
>> > [...]
>> > > We did have another revert to fix hopefullythe last "blank screen"
>> > > regression on intel graphics.
>> >
>> > It seems that there is still a regression for intel graphic cards
>> > backlight. One report is https://bugzilla.kernel.org/show_bug.cgi?id=22672.
>> > I can reproduce the problem easily by:
>> > xset dpms force standby; sleep 3s; xset dpms force on
>> >
>> > backlight doesn't get up (there is really dark picture though which
>> > doesn't get brighter by function keys which work normally) after dpms on
>> > until I close and open lid.
>> >
>> > The problem wasn't present in 2.6.36
>>
>> I can confirm that this problem is not present if both patches from
>> bko#22672 are applied on top of 2.6.37 kernel.
>> I haven't tried both patches separately, but I can surely try it if it
>> makes any sense.
>
> The second patch is wrong in that it will prevent changing resolutions
> using the panel fitter.
I can confirm that with the second patch changing resolutions doesn't always go
right.
$ xrandr
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 2048 x 2048
LVDS1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x
0mm
1024x768 50.0*+ 85.0 75.0 70.1 60.0
832x62474.6
800x60085.1 72.2 75.0 60.3 56.2
640x48085.0 72.8 75.0 59.9
720x40085.0
640x40085.1
640x35085.1
VGA1 disconnected (normal left inverted right x axis y axis)
Going from xrandr -s 1, 2 or 3 back to 0 works, but not from 4, 5 or 6 to 0.
The second patch was really a stab in the dark, I'm happy it was in the right
direction at least.
> The first patch looks along the right lines, just
> misses the possibility that the backlight can be modified by other means.
I'm not sure about that. All it does is avoiding setting backlight_level to
0. If it's modified some other way and intel_panel_get_backlight() returns 0,
backlight_level is just never set and will stay zero. If there is a way to
switch between ways to modify the backlight then I can see how this may not
always work, because then backlight_level is stuck on the last non-zero value
before it was switched to intel_panel_set_backlight(0) and the different method.
Alex reported a slightly dimmer display after resume, so I wonder what I missed
in my patch. Larry's problem was probably fixed with just the first patch, but
then I wonder why he reported that it didn't work first. Maybe he meant the
setpci thing, or made a mistake.
> So hopefully, you just need the first patch.
> -Chris
Yeah, the second patch is a bit of a desperate attempt because Larry reported
that
it didn't fix his problem.
About your patch, you still do:
+void intel_panel_setup_backlight(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ dev_priv->backlight_level = intel_panel_get_max_backlight(dev);
+ dev_priv->backlight_enabled = dev_priv->backlight_level != 0;
+}
While my patch changes that to:
+ u32 level;
- if (dev_priv->backlight_level == 0)
- dev_priv->backlight_level = intel_panel_get_max_backlight(dev);
+ if (dev_priv->backlight_level == 0) {
+ level = intel_panel_get_backlight(dev);
+ if (level == 0)
+ level = intel_panel_get_max_backlight(dev);
+ dev_priv->backlight_level = level;
+ }
Your patch uses intel_panel_get_max_backlight() to check if the backlight is
enabled. Is this always correct, or may it cause bugs in the future?
Anyway, my main concern with unconditionally setting the backlight level to
the maximum is that any stored brightness level (by the BIOS or whatever) may
be lost, and that the screen is set to maximum brightness at each boot. This
is certainly the behaviour I've seen with an unpatched kernel. So I propose to
do what my patch does and set it to intel_panel_get_backlight(dev) if that
returns non-zero. Something like this:
+void intel_panel_setup_backlight(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ u32 max, level;
+
+ max = intel_panel_get_max_backlight(dev);
+ if (max) {
+ dev_priv->backlight_enabled = 1;
+ level = intel_panel_get_backlight(dev);
+ if (!level)
+ level = max;
+ dev_priv->backlight_level = level;
+ }
+}
While I'm glad this problem is being fixed upstream, it would be nice to get
some credit for finding the source of the problem.
Greetings,
Indan
[git pull] drm for rc1
On Wed, Jan 12, 2011 at 11:36 AM, Linus Torvalds wrote: > On Tue, Jan 11, 2011 at 3:01 PM, Linus Torvalds > wrote: >> >> ?... I'll test that drm-intel-staging commit. > > Initial testing _seems_ to confirm that merging drm-intel-staging gets > rid of the problem. But I haven't spent a whole lot of time in the > screen saver. Will start driving kids around now, so more intense > screen saver testing is coming up.. Its looking good here, I've pushed a drm-fixes branch with what Chris sent me + a couple of i915/iommu fixes to my repo, I'm going to run it on my laptop for a few more hours then I'll send you a pull req, but none of the triggers I had yesterday seem to take it down. Dave. > > ? ? ? ? ? ? ? ? ? Linus >
[git pull] drm intel only fixes
I'm stuck at home with just my i5 laptop due to the office being shut due to the ongoing floods. But I've booted and ran this for a few hours and it seems to be better than the current tree. It contains a couple of patches to fix DMAR interaction issues I see on this laptop on top of Chris's pull. Dave. The following changes since commit 4162cf64973df51fc885825bc9ca4d055891c49f: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6 (2011-01-11 16:32:41 -0800) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes Chris Wilson (25): drm/i915/sdvo: Defer detection of output capabilities until probing drm/i915/panel: Only record the backlight level when it is enabled drm/i915/lvds: Always use 0 to disable the pfit controller drm/i915: Use the mappable sizes determined by GTT for consistency. drm/i915: Workaround erratum on i830 for TAIL pointer within last 2 cachelines agp/intel: Flush the chipset write buffers when changing GTT base drm/i915: add 'reset' parameter drm/i915: Remove impossible test drm/i915: Enforce write ordering through the GTT drm/i915: Handle ringbuffer stalls when flushing drm/i915: Mask USER interrupts on gen6 (until required) drm/i915/debugfs: Show the per-ring IMR drm/i915/ringbuffer: Simplify the ring irq refcounting drm/i915: Make the ring IMR handling private drm/i915: Propagate error from flushing the ring drm/i915: Include TLB miss overhead for computing WM drm/i915: Record the error batchbuffer on each ring drm/i915/gtt: Unmap the PCI pages after unbinding them from the GTT drm/i915: Periodically flush the active lists and requests drm/i915: Record AGP memory type upon error drm/i915/debugfs: Show all objects in the gtt drm/i915/execbuffer: Correctly clear the current object list upon EFAULT drm/i915/evict: Ensure we completely cleanup on failure drm/i915: If we hit OOM when allocating GTT pages, clear the aperture drm/i915/execbuffer: Reorder binding of objects to favour restrictions Dave Airlie (3): Merge branch 'drm-intel-fixes' of ssh://master.kernel.org/.../ickle/drm-intel i915/gtt: fix ordering issues with status setup and DMAR i915/gtt: fix ordering causing DMAR errors on object teardown. David M?ller (1): drm/i915/crt: Check for a analog monitor in case of DVI-I Jesse Barnes (9): drm/i915: check eDP encoder correctly when setting modes drm/i915: make DP training try a little harder drm/i915: support overclocking on Sandy Bridge drm/i915: support low power watermarks on Ironlake drm/i915: avoid reading non-existent PLL reg on Ironlake+ drm/i915: re-enable rc6 support for Ironlake+ drm/i915: fix rc6 enabling around suspend/resume drm/i915: cleanup rc6 code drm/i915: detect & report PCH display error interrupts Yuanhan Liu (2): drm/i915: fix calculation of eDP signal levels on Sandybridge drm/i915: fix the wrong latency value while computing wm0 drivers/char/agp/intel-agp.h |2 + drivers/char/agp/intel-gtt.c | 17 +- drivers/gpu/drm/i915/i915_debugfs.c| 87 +- drivers/gpu/drm/i915/i915_dma.c|8 - drivers/gpu/drm/i915/i915_drv.c|9 + drivers/gpu/drm/i915/i915_drv.h| 24 +- drivers/gpu/drm/i915/i915_gem.c| 156 +++--- drivers/gpu/drm/i915/i915_gem_evict.c |9 +- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 119 +--- drivers/gpu/drm/i915/i915_gem_gtt.c| 10 +- drivers/gpu/drm/i915/i915_irq.c| 269 +++--- drivers/gpu/drm/i915/i915_reg.h| 95 ++- drivers/gpu/drm/i915/i915_suspend.c|8 +- drivers/gpu/drm/i915/intel_crt.c | 30 ++- drivers/gpu/drm/i915/intel_display.c | 434 drivers/gpu/drm/i915/intel_dp.c| 50 +++- drivers/gpu/drm/i915/intel_drv.h |3 + drivers/gpu/drm/i915/intel_fb.c| 20 +- drivers/gpu/drm/i915/intel_lvds.c | 14 +- drivers/gpu/drm/i915/intel_panel.c | 31 ++ drivers/gpu/drm/i915/intel_ringbuffer.c| 255 - drivers/gpu/drm/i915/intel_ringbuffer.h| 36 ++- drivers/gpu/drm/i915/intel_sdvo.c | 33 +-- 23 files changed, 1082 insertions(+), 637 deletions(-)
[PATCH] Mapping snooped user pages into the GTT
Dear Chris:
what do u mean " blit between snooped and unsnooped memory"?
It seems you want to map user-space pixmap to GTT space, and use 2d
copy to do upload/download?
TTM can map user space memory to GTT aperture by using
"ttm_bo_type_user", but no dirver use it yet.??
Thanks
2011/1/8 Chris Wilson :
> I've been looking at how we can improve upload/download performance on our
> UMA gfx. One under-used aspect of the IGP is its ability to blit between
> snooped-and-unsnooped memory i.e. from normal ram into the GTT. Only the
> BLT has this ability, almost all other functions of the GPU most be from
> unsnooped memory. SNB introduces its own cache handling that we need to
> exploit further, however the BLT remains and is orders of magnitude faster
> for read back than an UC read by the CPU...
>
> It is surprisingly simple to replace the shmem_getpage with
> get_user_pages and insert a user-bo into the GTT. The downside is that
> this pins user-memory until it becomes inactive and so care needs to be
> taken by the client to synchronize appropriately. Another issue that I've
> not dealt with successfully is tracking memory protection on user pages.
> Different processes will need different protection on potentially the same
> PTEs. (I've also looked at implementing 2D pwrite/pread using the BLT but
> I'm dissatisfied with the per-request overhead; though that too is still
> many times faster for pread.)
>
> I'm slightly concerned about pinning user-memory for undeterminable
> lengths of time. However, this is no worse than any other bo, and the
> pages will be reaped under memory pressure by eviction.
>
> Any other comments or suggestions?
> -Chris
>
> ---
> ?drivers/gpu/drm/drm_gem.c ? ? ? ? ? ? ?| ? ?3 +-
> ?drivers/gpu/drm/i915/Makefile ? ? ? ? ?| ? ?1 +
> ?drivers/gpu/drm/i915/i915_dma.c ? ? ? ?| ? ?3 +-
> ?drivers/gpu/drm/i915/i915_drv.h ? ? ? ?| ? 12 +++
> ?drivers/gpu/drm/i915/i915_gem.c ? ? ? ?| ? 93 ++--
> ?drivers/gpu/drm/i915/i915_gem_gtt.c ? ?| ? ?4 +-
> ?drivers/gpu/drm/i915/i915_gem_io.c ? ? | ? 10 ++
> ?drivers/gpu/drm/i915/i915_gem_tiling.c | ? ?5 +
> ?drivers/gpu/drm/i915/i915_gem_vmap.c ? | ?145
>
> ?include/drm/i915_drm.h ? ? ? ? ? ? ? ? | ? 16
> ?10 files changed, 260 insertions(+), 32 deletions(-)
> ?create mode 100644 drivers/gpu/drm/i915/i915_gem_vmap.c
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index ea1c4b0..adb886a 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -425,7 +425,8 @@ drm_gem_release(struct drm_device *dev, struct drm_file
> *file_private)
> ?void
> ?drm_gem_object_release(struct drm_gem_object *obj)
> ?{
> - ? ? ? fput(obj->filp);
> + ? ? ? if (obj->filp)
> + ? ? ? ? ? ? ? fput(obj->filp);
> ?}
> ?EXPORT_SYMBOL(drm_gem_object_release);
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 07a351f..4b901c5 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -13,6 +13,7 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o i915_mem.o \
> ? ? ? ? ?i915_gem_gtt.o \
> ? ? ? ? ?i915_gem_io.o \
> ? ? ? ? ?i915_gem_tiling.o \
> + ? ? ? ? i915_gem_vmap.o \
> ? ? ? ? ?i915_trace_points.o \
> ? ? ? ? ?intel_display.o \
> ? ? ? ? ?intel_crt.o \
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 8def614..52efa11 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -783,7 +783,7 @@ static int i915_getparam(struct drm_device *dev, void
> *data,
> ? ? ? ? ? ? ? ?value = INTEL_INFO(dev)->gen >= 4;
> ? ? ? ? ? ? ? ?break;
> ? ? ? ?case I915_PARAM_HAS_2D_IO:
> - ? ? ? ? ? ? ? /* depends on GEM */
> + ? ? ? case I915_PARAM_HAS_VMAP:
> ? ? ? ? ? ? ? ?value = dev_priv->has_gem;
> ? ? ? ? ? ? ? ?break;
> ? ? ? ?default:
> @@ -2256,6 +2256,7 @@ struct drm_ioctl_desc i915_ioctls[] = {
> ? ? ? ?DRM_IOCTL_DEF_DRV(I915_OVERLAY_ATTRS, intel_overlay_attrs,
> DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
> ? ? ? ?DRM_IOCTL_DEF_DRV(I915_GEM_PREAD_2D, i915_gem_pread_2d_ioctl,
> DRM_UNLOCKED),
> ? ? ? ?DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE_2D, i915_gem_pwrite_2d_ioctl,
> DRM_UNLOCKED),
> + ? ? ? DRM_IOCTL_DEF_DRV(I915_GEM_VMAP, i915_gem_vmap_ioctl, DRM_UNLOCKED),
> ?};
>
> ?int i915_max_ioctl = DRM_ARRAY_SIZE(i915_ioctls);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 64033cc..6899bde 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -695,6 +695,11 @@ typedef struct drm_i915_private {
> ? ? ? ?struct intel_fbdev *fbdev;
> ?} drm_i915_private_t;
>
> +struct drm_i915_gem_object_ops {
> + ? ? ? int (*get_pages)(struct drm_i915_gem_object *, gfp_t, u32 *offset);
> + ? ? ? void (*put_pages)(struct drm_i915_gem_object *);
> +};
> +
> ?struct drm_i915_gem_object {
> ? ? ? ?struct drm_gem_object base;
>
> @@ -782,6 +787,7 @@ struct drm_i915_gem_object {
> ? ? ? ?unsigned int
[RFC PATCH v2] Utilize the PCI API in the TTM framework.
Hi, Konrad. This discussion has become a bit lenghty. I'll filter out the sorted-out stuff, which leaves me with two remaining issues: On 01/11/2011 04:55 PM, Konrad Rzeszutek Wilk wrote: > > So at the end we have 16GB taken from 8GB->24GB, and 320MB taken from > 0->4GB. When you start allocating coherent memory from each guest > (and yeah, say we use 2GB each), we end up with the first guest getting > the 2GB, the second getting 1.7GB, and then the next two getting zil. > > You still have GFP_KERNEL memory in each guest - the first one has 2GB left > , then second 2.3, the next two have each 4GB. > > > From the hyprevisor pool perspective, the 0-4GB zone is exhausted, so > is the 8GB->24GB, but it still has 4GB->8GB free - so it can launch one more > guest (but without PCI passthrough devices). > > >> On a 4GB machine or less, that would be the same as kernel memory. >> Now, if 4 guests think they can allocate 2GB of coherent memory >> each, you might run out of kernel memory on the host? >> > So host in this case refers to the Hypervisor and it does not care > about the DMA or what - it does not have any device drivers(*) or such. > The first guest (dom0) is the one that deals with the device drivers. > > *: It has one: the serial port, but that is not really that important > for this discussion. > Let's assume we're at where the hypervisor (or host) has exhausted the 0-4GB zone, due to guests coherent memory allocations, and that the physical machine has 4GB of memory, all in the 0-4GB zone. Now if the hypervisor was running on a Linux kernel, there would be no more GFP_KERNEL memory available on the *host* (hypervisor), and the hypervisor would crash. Now I don't know much about Xen, but it might be that this is not a problem with Xen at all? >> >> Another thing that I was thinking of is what happens if you have a >> huge gart and allocate a lot of coherent memory. Could that >> potentially exhaust IOMMU resources? >> > > I need to be more specific. Let's assume we're on "bare metal", and we want to allocate 4GB of coherent memory. For most IOMMUs that would mean as you previously state, that we actually allocate GFP_DMA32 memory. But for some IOMMUs that would perhaps mean that we allocate *any* memory and set up a permanent DMA mapping in the IOMMU for the coherent pages. What if, in such a case, the IOMMU can only set up 2GB of coherent memory? Or in short, can there *ever* be "bare metal" cases where the amount of coherent memory available is less than DMA32 memory available? Thanks, Thomas
[Bug 16265] Why is kslowd accumulating so much CPU time?
https://bugzilla.kernel.org/show_bug.cgi?id=16265 Florian Mickler changed: What|Removed |Added CC||edwintorok at gmail.com --- Comment #8 from Florian Mickler 2011-01-12 10:48:30 --- *** Bug 18802 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 16265] Why is kslowd accumulating so much CPU time?
https://bugzilla.kernel.org/show_bug.cgi?id=16265 --- Comment #9 from Florian Mickler 2011-01-12 11:19:26 --- Is this issue still visible on 2.6.37? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[git pull] drm for rc1
Am 12.01.2011 00:28, schrieb Linus Torvalds: > On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger > wrote: >> >> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA >> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) >> During startup the framebuffer shows only stripes and a blank >> screen after suspend/resume. >> I also see lots of TRAP messages. (see below). >> X11 seems to work fine though... > > Can you try to bisect? dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit commit dfe63bb0ad9810db13aab0058caba97866e0a681 Author: James Simmons Date: Thu Dec 23 16:40:37 2010 + drm: Update fbdev fb_fix_screeninfo Reverting this on top of todays git also fixes my problem. Christian
[PATCH] Mapping snooped user pages into the GTT
On Wed, 12 Jan 2011 15:40:33 +0800, april wrote: > Dear Chris: > > what do u mean " blit between snooped and unsnooped memory"? > It seems you want to map user-space pixmap to GTT space, and use 2d > copy to do upload/download? Yes, and sample from snooped memory for some operations. > TTM can map user space memory to GTT aperture by using > "ttm_bo_type_user", but no dirver use it yet.?? Different driver, but thanks for reminding me to check ttm. It seems we made slightly different choices over the lifetime of the gup, but otherwise the same. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Bug 16265] Why is kslowd accumulating so much CPU time?
https://bugzilla.kernel.org/show_bug.cgi?id=16265 Florian Mickler changed: What|Removed |Added Status|NEW |RESOLVED Resolution||CODE_FIX --- Comment #10 from Florian Mickler 2011-01-12 11:37:46 --- I'm closing this for now, please reopen or shout if this issue is still unresolved for you. This should have been fixed for intel since 2.6.36-rc5: commit 930a9e283516a3a3595c0c515113f1b78d07f695 Author: Chris Wilson Date: Tue Sep 14 11:07:23 2010 +0100 drm: Use a nondestructive mode for output detect when polling (v2) for nouveau it's probably fixed since v2.6.37-rc3: commit 01db363979e96115a895f35c823303660f0f328d Author: Francisco Jerez Date: Thu Oct 21 17:43:08 2010 +0200 drm/nouveau: Use "force" to decide if analog load detection is ok or not. and for radeon since v2.6.37-rc1: commit c3cceeddf0b5f97b0d2352b98ef0f025e31a9ae3 Author: Dave Airlie Date: Tue Oct 26 12:55:52 2010 +1000 drm/radeon/kms: don't poll dac load detect. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 16265] Why is kslowd accumulating so much CPU time?
https://bugzilla.kernel.org/show_bug.cgi?id=16265 Florian Mickler changed: What|Removed |Added Status|RESOLVED|CLOSED -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] [correction] load fbcon from drm_kms_helper
Hi David! Did you see this patch? I was wondering what you think about it... On Sun, 12 Dec 2010 12:39:22 -0600 David Fries wrote: > Kconfig says fbcon is required by drm_kms_helper. If radeon, fbcon, > and drm_kms_helper are all modules, radeon is auto loaded (by PCI id?), > drm_kms_helper is loaded because of the module dependency, but fbcon > isn't loaded leaving the console unusable. Since fbcon is required > and there isn't an explicit module dependency, request the module > to be loaded from drm_kms_helper. > > Signed-off-by: David Fries > Cc: David Airlie > Cc: dri-devel at lists.freedesktop.org Regards, Flo
Linux 2.6.37
On Wed, 12 Jan 2011 01:35:49 +0100 (CET), "Indan Zupancic"
wrote:
> Yeah, the second patch is a bit of a desperate attempt because Larry reported
> that
> it didn't fix his problem.
>
> About your patch, you still do:
>
> +void intel_panel_setup_backlight(struct drm_device *dev)
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
> +
> + dev_priv->backlight_level = intel_panel_get_max_backlight(dev);
> + dev_priv->backlight_enabled = dev_priv->backlight_level != 0;
> +}
>
> While my patch changes that to:
>
> + u32 level;
>
> - if (dev_priv->backlight_level == 0)
> - dev_priv->backlight_level = intel_panel_get_max_backlight(dev);
> + if (dev_priv->backlight_level == 0) {
> + level = intel_panel_get_backlight(dev);
> + if (level == 0)
> + level = intel_panel_get_max_backlight(dev);
> + dev_priv->backlight_level = level;
> + }
>
> Your patch uses intel_panel_get_max_backlight() to check if the backlight is
> enabled. Is this always correct, or may it cause bugs in the future?
That was a typo, cut'n'pasting the line from above.
> Anyway, my main concern with unconditionally setting the backlight level to
> the maximum is that any stored brightness level (by the BIOS or whatever) may
> be lost, and that the screen is set to maximum brightness at each boot. This
> is certainly the behaviour I've seen with an unpatched kernel. So I propose to
> do what my patch does and set it to intel_panel_get_backlight(dev) if that
> returns non-zero. Something like this:
Sure, s/intel_panel_get_max_backlight/intel_panel_get_backlight/ and we
get the behaviour we both want - preserving the current backlight unless
none is set.
> While I'm glad this problem is being fixed upstream, it would be nice to get
> some credit for finding the source of the problem.
Sorry. You found the bug but I felt your rationale was off. However, I was
amiss in not giving you the credit you fully deserved.
-Chris
commit 9c1c388a53e5df8819e898106a64e34d0994a5d4
Author: Indan Zupancic
Date: Wed Jan 12 11:59:19 2011 +
drm/i915/panel: The backlight is enabled if the current value is non-zero
... and not if the maximum is non-zero. This fixes the typo introduced
in 47356eb6728501452 and preserves the backlight value from boot.
[ickle: My thanks also to Indan Zupancic for diagnosing the original
regression and suggesting the appropriate fix.]
Signed-off-by: Chris Wilson
Cc: stable at kernel.org # after 47356eb6728501452
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_pan
index e00d200..27c79c7 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -278,6 +278,6 @@ void intel_panel_setup_backlight(struct drm_device
*dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- dev_priv->backlight_level = intel_panel_get_max_backlight(dev);
+ dev_priv->backlight_level = intel_panel_max_backlight(dev);
dev_priv->backlight_enabled = dev_priv->backlight_level != 0;
}
--
Chris Wilson, Intel Open Source Technology Centre
Linux 2.6.37
On Wed, 12 Jan 2011 12:07:23 +, Chris Wilson
wrote:
> diff --git a/drivers/gpu/drm/i915/intel_panel.c
> b/drivers/gpu/drm/i915/intel_pan
> index e00d200..27c79c7 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -278,6 +278,6 @@ void intel_panel_setup_backlight(struct drm_device
> *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
>
> - dev_priv->backlight_level = intel_panel_get_max_backlight(dev);
> + dev_priv->backlight_level = intel_panel_max_backlight(dev);
> dev_priv->backlight_enabled = dev_priv->backlight_level != 0;
dev_priv->backlight_level = intel_panel_get_backlight(dev);
-ETIRED
--
Chris Wilson, Intel Open Source Technology Centre
[git pull] drm for rc1
> Am 12.01.2011 00:28, schrieb Linus Torvalds: > > On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger > > wrote: > >> > >> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA > >> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) > >> During startup the framebuffer shows only stripes and a blank > >> screen after suspend/resume. > >> I also see lots of TRAP messages. (see below). > >> X11 seems to work fine though... > > > > Can you try to bisect? > > dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit > commit dfe63bb0ad9810db13aab0058caba97866e0a681 > Author: James Simmons > Date: Thu Dec 23 16:40:37 2010 + > > drm: Update fbdev fb_fix_screeninfo > > > Reverting this on top of todays git also fixes my problem. I see the problem. Nouveau for some hardware does a accelerated clearing of the screen before we register the framebuffer. The above patch does fix a real issue so please don't revert it. Can you try this patch. diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c index a26d047..4ef24d6 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c @@ -359,6 +359,8 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); info->screen_size = size; + info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : +FB_VISUAL_TRUECOLOR; drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, sizes->fb_height); /* Set aperture base/size for vesafb takeover */
