Re: [PATCH] drm: ignore LVDS on intel graphics systems that lie about having it
On Monday 06 April 2009 12:52:16 Jesse Barnes wrote: On Mon, 6 Apr 2009 10:11:25 -0400 Jarod Wilson ja...@redhat.com wrote: There are a number of small form factor desktop systems with Intel mobile graphics chips that lie and say they have an LVDS. With kernel mode-setting, this becomes a problem, and makes native resolution boot go haywire -- for example, my Dell Studio Hybrid, hooked to a 1920x1080 display claims to have a 1024x768 LVDS, and the resulting graphical boot on the 1920x1080 display uses only the top left 1024x768, and auto-configured X will end up only 1024x768 as well. With this change, graphical boot and X both do 1920x1080 as expected. Note that we're simply embracing and extending the early bail-out code in place for the Mac Mini here. The xorg intel driver uses pci subsystem device and vendor id for matching, while we're using dmi lookups here. The MSI addition is courtesy of and tested by Bill Nottingham. One minor issue... Current Fedora rawhide, video playback using Xv makes X go off into the weeds with this patch added, but that's a bug elsewhere, still confident this patch DTRT. Signed-off-by: Jarod Wilson ja...@redhat.com Tested-by: Bill Nottingham nott...@redhat.com The 2D driver has a similar set of quirks, but since we started that list we've found that the VBIOS should contain a pretty reliable table indicating which outputs are available, including LVDS. I think if we can figure out how to parse it reliably (accounting for VBIOS versioning and structure size changes) we shouldn't need this patch. If we can't get that done in time for 2.6.30 though I'm all for including this. Sounds like a plan to me. Either way, would this patch still make sense for submission to the 2.6.29.x stable series? I've already tacked it onto the Fedora 2.6.29 kernel builds, fwiw. -- Jarod Wilson ja...@redhat.com -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Intel-gfx] [Patch 2/2_v2][DRM/I915]: Sync the panel fitting property with 2D driver
sorry, please ignore this email
Thanks
Ma Ling
-Original Message-
From: Ma, Ling
Sent: Monday, April 06, 2009 9:56 PM
To: Zhao, Yakui; e...@anholt.net
Cc: intel-...@lists.freedesktop.org; dri-devel@lists.sourceforge.net
Subject: RE: [Intel-gfx] [Patch 2/2_v2][DRM/I915]: Sync the panel fitting
property with 2D driver
Any comments ?
Thanks
Ma Ling
-Original Message-
From: intel-gfx-boun...@lists.freedesktop.org
[mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of yakui_zhao
Sent: Thursday, April 02, 2009 12:00 PM
To: e...@anholt.net
Cc: intel-...@lists.freedesktop.org; dri-devel@lists.sourceforge.net
Subject: [Intel-gfx] [Patch 2/2_v2][DRM/I915]: Sync the panel fitting property
with 2D driver
This covers:
a. create the scaling mode property and attach it to LVDS
b. add the support of panel fitting property for LVDS
c. update the display mode according to the panel fitting mode
v2: the drm_calloc/drm_free is replaced by kzalloc/kfree based
on Eric's suggestion.
Signed-off-by: Zhao Yakui yakui.z...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 16 ++
drivers/gpu/drm/i915/intel_lvds.c | 282 +++---
2 files changed, 277 insertions(+), 21 deletions(-)
Index: linux-2.6/drivers/gpu/drm/i915/i915_reg.h
===
--- linux-2.6.orig/drivers/gpu/drm/i915/i915_reg.h 2009-04-02
11:05:28.0 +0800
+++ linux-2.6/drivers/gpu/drm/i915/i915_reg.h 2009-04-02 11:11:36.0
+0800
@@ -819,9 +819,25 @@
#define HORIZ_INTERP_MASK(3 6)
#define HORIZ_AUTO_SCALE (1 5)
#define PANEL_8TO6_DITHER_ENABLE (1 3)
+#define PFIT_FILTER_FUZZY(0 24)
+#define PFIT_SCALING_AUTO(0 26)
+#define PFIT_SCALING_PROGRAMMED (1 26)
+#define PFIT_SCALING_PILLAR (2 26)
+#define PFIT_SCALING_LETTER (3 26)
#define PFIT_PGM_RATIOS0x61234
#define PFIT_VERT_SCALE_MASK 0xfff0
#define PFIT_HORIZ_SCALE_MASK0xfff0
+/* Pre-965 */
+#definePFIT_VERT_SCALE_SHIFT 20
+#definePFIT_VERT_SCALE_MASK0xfff0
+#definePFIT_HORIZ_SCALE_SHIFT 4
+#definePFIT_HORIZ_SCALE_MASK 0xfff0
+/* 965+ */
+#definePFIT_VERT_SCALE_SHIFT_965 16
+#definePFIT_VERT_SCALE_MASK_9650x1fff
+#definePFIT_HORIZ_SCALE_SHIFT_965 0
+#definePFIT_HORIZ_SCALE_MASK_965 0x1fff
+
#define PFIT_AUTO_RATIOS 0x61238
/* Backlight control */
Index: linux-2.6/drivers/gpu/drm/i915/intel_lvds.c
===
--- linux-2.6.orig/drivers/gpu/drm/i915/intel_lvds.c2009-03-30
10:08:58.0 +0800
+++ linux-2.6/drivers/gpu/drm/i915/intel_lvds.c 2009-04-02 11:40:13.0
+0800
@@ -37,6 +37,21 @@
#include i915_drm.h
#include i915_drv.h
+/*
+ * the following four scaling options are defined.
+ * #define DRM_MODE_SCALE_NON_GPU 0
+ * #define DRM_MODE_SCALE_FULLSCREEN 1
+ * #define DRM_MODE_SCALE_NO_SCALE 2
+ * #define DRM_MODE_SCALE_ASPECT 3
+ */
+
+/* Private structure for the integrated LVDS support */
+struct intel_lvds_priv {
+ int fitting_mode;
+ u32 pfit_control;
+ u32 pfit_pgm_ratios;
+};
+
/**
* Sets the backlight level.
*
@@ -160,10 +175,24 @@
struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
{
+ /*
+* float point operation is not supported . So the PANEL_RATIO_FACTOR
+* is defined, which can avoid the float point computation when
+* calculating the panel ratio.
+*/
+#define PANEL_RATIO_FACTOR 8192
struct drm_device *dev = encoder-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(encoder-crtc);
struct drm_encoder *tmp_encoder;
+ struct intel_output *intel_output = enc_to_intel_output(encoder);
+ struct intel_lvds_priv *lvds_priv = intel_output-dev_priv;
+ u32 pfit_control = 0, pfit_pgm_ratios = 0;
+ int left_border = 0, right_border = 0, top_border = 0;
+ int bottom_border = 0;
+ bool border = 0;
+ int panel_ratio, desired_ratio, vert_scale, horiz_scale;
+ int horiz_ratio, vert_ratio;
/* Should never happen!! */
if (!IS_I965G(dev) intel_crtc-pipe == 0) {
@@ -179,7 +208,9 @@
return false;
}
}
-
+ /* If we don't have a panel mode, there is nothing we can do */
+ if (dev_priv-panel_fixed_mode == NULL)
+ return true;
/*
* If we have timings from the BIOS for the panel, put them in
* to the adjusted mode. The CRTC will be set up for this mode,
@@
RE: workaround for bogus EDID data
-Original Message- From: Jesse Barnes [mailto:jbar...@virtuousgeek.org] Sent: Saturday, April 04, 2009 12:42 AM To: Guo, Chaohong Cc: dri-devel@lists.sourceforge.net Subject: Re: workaround for bogus EDID data On Fri, 3 Apr 2009 15:40:44 +0800 Guo, Chaohong chaohong@intel.com wrote: hi, I notice that KMS uses EDID priori to VBT, and some EDID data is not right on some laptops. As Jesse added a workaround into intel_bios.c, we should add the same workaround into drm_edid.c as follows. Probably, we should merge the calculation made in drm_mode_detailed() and parse_panel_data(), and have the two routines call a common sub-routine ? Really you've seen bad EDIDs too? Last time I saw this issue it turned out to be a parser bug that Linus fixed. Linus fixed the Vsync issue, but mine is Hsync: hend = 1446, and htotal = 1443, You can check the attached EDID data in case that my understanding is not right. thanks, -minskey Yes we should make a common routine, and just make the various mode_fixup hooks call it. -- Jesse Barnes, Intel Open Source Technology Center 000 00 ff ff ff ff ff ff 00 06 af ec 21 00 00 00 00 020 01 12 01 03 80 22 13 78 0a 57 55 9c 5a 54 9d 26 040 1a 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 060 01 01 01 01 01 01 12 1b 56 43 50 00 26 30 30 20 100 34 00 58 c1 10 00 00 18 00 00 00 0f 00 00 00 00 120 00 00 00 00 00 00 00 00 00 20 00 00 00 fe 00 41 140 55 4f 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe 160 00 42 31 35 36 58 57 30 32 20 56 31 20 0a 00 44 200 header : 00 ff ff ff ff ff ff 00 Vendor: - vendorid: 06 af - Product : ec 21 - SerialNo: 00 00 00 00 - Week: 01 - Year 12 Verion: 01 Revion: 03 Input: 80 (digital output) size : 22 13 ( Gamma param: 78 feauture: 0a bit 7:5 for DPMS Color:(10 bytes) 57 55 9c 5a 54 9d 26 1a 50 54 Established Timings: 00 00 00 standard timings:(16 bytes) 1. 01 01 2. 01 01 3. 01 01 4. 01 01 5. 01 01 6. 01 01 7. 01 01 8. 01 01 Timings details :(18bytes) 12 1b 56 43 50 00 26 30 30 20 34 00 58 c1 10 00 00 18 00 00 00 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 20 00 00 00 fe 00 41 55 4f 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe 00 42 31 35 36 58 57 30 32 20 56 31 20 0a Ext flag: 00 Checksum: 44 -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] [intel-gfx] :The backlight issue when KMS is used
On Sat, 2009-04-04 at 00:29 +0800, Matthew Garrett wrote: On Fri, Apr 03, 2009 at 09:24:08AM -0700, Jesse Barnes wrote: I'd rather not have a native kernel backlight property (i.e. a property on the LVDS output) exposed at all. I chatted with Matthew about this a little, and I think the best thing to do would be to have the i915 driver register a backlight interface of its own if one doesn't already exist (e.g. in the case of a platform specific i2c interface and no ACPI backlight support). We might have to hack the backlight class code a little to prevent multiple registrations for the same device, but that shouldn't be too hard. Then whichever driver loads first (i915 or acpi video) would create a backlight interface if it could, and the userspace driver could use it; no need for new properties. Right. I'd imagine it as i915 loading and calling is_acpi_backlight(). If that returns false, it should register a backlight device and also a notifier. If a machine-specific platform device (like thinkpad_acpi or dell_laptop or whatever) then loads, i915 should unregister its driver and leave it up to the machine-specific one. The DDX would then use the backlight device under all circumstances. A good idea. When there is no generic ACPI backlight I/F(_BQC/_BCL/_BCM) or platform backlight I/F, a new baclight I/F(using platform I2C command) will be registered in i915 driver. Will this new backlight I/F be registered in both UMS/KMS mode? But if we do so, it seems that we have to solve the dependency issue among acpi_video, i915 and platform driver. For example: I915 driver is loaded firstly and the interface will be registered. But after the acpi video driver/platform driver is loaded, how to send the notification event that i915 should unregister its interface? If the interface is unregistered, we will have to consider the arbiter order. Does this make the problem more complex? Will this new backlight I/F be registered in UMS mode? cc: Richard Purdie Best regards. Yakui -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] [intel-gfx] :The backlight issue when KMS is used
On Tue, Apr 07, 2009 at 11:45:11AM +0800, yakui_zhao wrote: On Sat, 2009-04-04 at 00:29 +0800, Matthew Garrett wrote: Right. I'd imagine it as i915 loading and calling is_acpi_backlight(). If that returns false, it should register a backlight device and also a notifier. If a machine-specific platform device (like thinkpad_acpi or dell_laptop or whatever) then loads, i915 should unregister its driver and leave it up to the machine-specific one. The DDX would then use the backlight device under all circumstances. A good idea. When there is no generic ACPI backlight I/F(_BQC/_BCL/_BCM) or platform backlight I/F, a new baclight I/F(using platform I2C command) will be registered in i915 driver. Will this new backlight I/F be registered in both UMS/KMS mode? No, since in UMS mode the X server handles the backlight registers. But if we do so, it seems that we have to solve the dependency issue among acpi_video, i915 and platform driver. For example: I915 driver is loaded firstly and the interface will be registered. But after the acpi video driver/platform driver is loaded, how to send the notification event that i915 should unregister its interface? If the interface is unregistered, we will have to consider the arbiter order. The acpi case is uninteresting - acpi_video_backlight_support() doesn't require the acpi video driver. The platform driver case is more interesting, but the easiest solution is probably to add a notifier chain for backlight device add and have i915 unregister when a platform device registers. I'm not sure what you mean by arbiter order? -- Matthew Garrett | mj...@srcf.ucam.org -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] [intel-gfx] :The backlight issue when KMS is used
On Tue, 2009-04-07 at 13:57 +0800, Matthew Garrett wrote: On Tue, Apr 07, 2009 at 11:45:11AM +0800, yakui_zhao wrote: On Sat, 2009-04-04 at 00:29 +0800, Matthew Garrett wrote: Right. I'd imagine it as i915 loading and calling is_acpi_backlight(). If that returns false, it should register a backlight device and also a notifier. If a machine-specific platform device (like thinkpad_acpi or dell_laptop or whatever) then loads, i915 should unregister its driver and leave it up to the machine-specific one. The DDX would then use the backlight device under all circumstances. A good idea. When there is no generic ACPI backlight I/F(_BQC/_BCL/_BCM) or platform backlight I/F, a new baclight I/F(using platform I2C command) will be registered in i915 driver. Will this new backlight I/F be registered in both UMS/KMS mode? No, since in UMS mode the X server handles the backlight registers. If so, there is no change about the backlight flowchart in UMS mode. And only when the KMS mode is used, a new backlight I/F is registered. Right? But if we do so, it seems that we have to solve the dependency issue among acpi_video, i915 and platform driver. For example: I915 driver is loaded firstly and the interface will be registered. But after the acpi video driver/platform driver is loaded, how to send the notification event that i915 should unregister its interface? If the interface is unregistered, we will have to consider the arbiter order. The acpi case is uninteresting - acpi_video_backlight_support() doesn't require the acpi video driver. The platform driver case is more interesting, but the easiest solution is probably to add a notifier chain for backlight device add and have i915 unregister when a platform device registers. Yes. We will have to create the communication channel between backlight device and i915 driver. And when a backlight I/F is registered, we will have to check whether the backlight I/F in 915 should be unregistered. Right? Does this make the problem complex? I'm not sure what you mean by arbiter order? What I said is which backlight I/F should be selected if there exist multiple backlight I/F? -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] [intel-gfx] :The backlight issue when KMS is used
On Tue, Apr 07, 2009 at 03:25:23PM +0800, yakui_zhao wrote: On Tue, 2009-04-07 at 13:57 +0800, Matthew Garrett wrote: No, since in UMS mode the X server handles the backlight registers. If so, there is no change about the backlight flowchart in UMS mode. And only when the KMS mode is used, a new backlight I/F is registered. Right? Right. The acpi case is uninteresting - acpi_video_backlight_support() doesn't require the acpi video driver. The platform driver case is more interesting, but the easiest solution is probably to add a notifier chain for backlight device add and have i915 unregister when a platform device registers. Yes. We will have to create the communication channel between backlight device and i915 driver. And when a backlight I/F is registered, we will have to check whether the backlight I/F in 915 should be unregistered. Right? Does this make the problem complex? Not really. It's not a lot of code. I'm not sure what you mean by arbiter order? What I said is which backlight I/F should be selected if there exist multiple backlight I/F? The platform-specific one. -- Matthew Garrett | mj...@srcf.ucam.org -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 21067] Xorg can't enable DRI and can' t load drm anymore with the new kernel 2.6.29
http://bugs.freedesktop.org/show_bug.cgi?id=21067 --- Comment #9 from TeF tefi...@gmail.com 2009-04-07 00:43:20 PST --- (In reply to comment #8) (In reply to comment #7) (In reply to comment #4) Does booting with nopat (on your kernel command line) help? Yes ！It works with nopat options of kernel command line! But my system is hanged when X exited! What the napat option means? PAT = Page Attribute Tables It allows for fine grained control of caching for pages in memory. It seems to have problems with ioremap and AGP. thanks for your patient. I press the Command dmesg | grep drm in my system ,and it shows me some ERROR infomation like this: [**ERROR** could not find ioremap agp regions!] How can I fix this problem complete? Could I use the nopat kernel option permanently? Dose this kernel option affect my system normal running? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13258] rubik xscreensaver is completely grey
http://bugs.freedesktop.org/show_bug.cgi?id=13258 --- Comment #12 from Chris Rankin ranki...@googlemail.com 2009-04-07 00:55:33 PST --- (In reply to comment #11) What card do you have? I think I have traced the bug, but don't have the proper fix yet. Great news :-)!!And I still have the Radeon 9550. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] [intel-gfx] :The backlight issue when KMS is used
On Tue, Apr 07, 2009 at 04:20:34PM +0800, Zhang Rui wrote: All subsystems can register a set of callbacks for backlight control in its own way, e.g. ACPI, platform driver, i915. And the backlight manager only exports one single I/F to users, like: | |brightness |actual_brightness |max_brightness |... |mode and it supports multiple modes, e.g. 1. generic ---ACPI 2. platform---platform drivers 3. legacy-i915 This seems to be a lot of complexity for an uncommon case. Is there any real need to modify the mode at runtime? What happens if the platform driver gets loaded before i915? -- Matthew Garrett | mj...@srcf.ucam.org -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] [intel-gfx] :The backlight issue when KMS is used
On Tue, 2009-04-07 at 15:25 +0800, Zhao, Yakui wrote: But if we do so, it seems that we have to solve the dependency issue among acpi_video, i915 and platform driver. For example: I915 driver is loaded firstly and the interface will be registered. But after the acpi video driver/platform driver is loaded, how to send the notification event that i915 should unregister its interface? If the interface is unregistered, we will have to consider the arbiter order. The acpi case is uninteresting - acpi_video_backlight_support() doesn't require the acpi video driver. The platform driver case is more interesting, but the easiest solution is probably to add a notifier chain for backlight device add and have i915 unregister when a platform device registers. Yes. We will have to create the communication channel between backlight device and i915 driver. And when a backlight I/F is registered, we will have to check whether the backlight I/F in 915 should be unregistered. Right? Does this make the problem complex? that's why I proposed to implement a backlight manager in the sysfs backlight class driver. All subsystems can register a set of callbacks for backlight control in its own way, e.g. ACPI, platform driver, i915. And the backlight manager only exports one single I/F to users, like: | |brightness |actual_brightness |max_brightness |... |mode and it supports multiple modes, e.g. 1. generic ---ACPI 2. platform---platform drivers 3. legacy-i915 The sysfs backlight manager always chooses the mode with highest priority (generic platform legacy), and call the respective callbacks when backlight is changed. For example, the backlight manager switches to the generic mode from legacy mode automatically when ACPI video driver is loaded at runtime. thanks, rui -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] [intel-gfx] :The backlight issue when KMS is used
CC Thomas, Len and linux-acpi mail list. On Tue, 2009-04-07 at 16:22 +0800, Matthew Garrett wrote: On Tue, Apr 07, 2009 at 04:20:34PM +0800, Zhang Rui wrote: All subsystems can register a set of callbacks for backlight control in its own way, e.g. ACPI, platform driver, i915. And the backlight manager only exports one single I/F to users, like: | |brightness |actual_brightness |max_brightness |... |mode and it supports multiple modes, e.g. 1. generic ---ACPI 2. platform---platform drivers 3. legacy-i915 This seems to be a lot of complexity for an uncommon case. Is there any real need to modify the mode at runtime? if this is implemented, the video_detect.c can be removed because we don't need to detect the ACPI video extension when loading platform drivers. every driver that has its own ways to control the backlight can register a set of callbacks and then it's the backlight manager's responsibility to choose which one to use. What happens if the platform driver gets loaded before i915? the backlight manager always choose the one with the highest priority if multiple callbacks are registered. i.e if (ACPI control methods are available) changes to the generic mode else if (platform specific callbacks are available) changes to the platform mode else if (i915 callbacks are available) changes to the legacy mode the backlight manager always run this logic when a new set of callbacks is registered/unregistered. thanks, rui backlight-manager Description: application/mbox -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13258] rubik xscreensaver is completely grey
http://bugs.freedesktop.org/show_bug.cgi?id=13258 --- Comment #13 from Maciej Cencora m.cenc...@gmail.com 2009-04-07 06:18:06 PST --- I think this bug should be marked as duplicate of http://bugs.freedesktop.org/show_bug.cgi?id=17685 I posted a fix there. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 11384] r300: (RS480) Some OpenGL applications have strange rendering characteristics
http://bugs.freedesktop.org/show_bug.cgi?id=11384 Maciej Cencora m.cenc...@gmail.com changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #22 from Maciej Cencora m.cenc...@gmail.com 2009-04-07 06:24:13 PST --- Could you check latest radeon-rewrite branch of mesa? I fixed twosided lighting there (wave prog was affected). Fogcoord have been fixed about two months ago (the fix in master). -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 21067] Xorg can't enable DRI and can' t load drm anymore with the new kernel 2.6.29
http://bugs.freedesktop.org/show_bug.cgi?id=21067 --- Comment #10 from Alex Deucher ag...@yahoo.com 2009-04-07 07:33:20 PST --- (In reply to comment #9) thanks for your patient. I press the Command dmesg | grep drm in my system ,and it shows me some ERROR infomation like this: [**ERROR** could not find ioremap agp regions!] How can I fix this problem complete? Could I use the nopat kernel option permanently? Dose this kernel option affect my system normal running? nopat will work around it for now. AGP should be fixed to work with pat at some point. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13030] i915: possible circular locking dependency detected in i915_gem_execbuffer
http://bugzilla.kernel.org/show_bug.cgi?id=13030
Sérgio M Basto ser...@sergiomb.no-ip.org changed:
What|Removed |Added
CC||ser...@sergiomb.no-ip.org
--- Comment #1 from Sérgio M Basto ser...@sergiomb.no-ip.org 2009-04-07
16:04:04 ---
same here , on boot
Running glxgears
I saw in dmesg
[drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22
===
[ INFO: possible circular locking dependency detected ]
2.6.29.1-42.rc1.sb3.fc10.i686.PAE #1
---
X/2749 is trying to acquire lock:
(mm-mmap_sem){}, at: [c049c6f2] might_fault+0x48/0x85
but task is already holding lock:
(dev-struct_mutex){--..}, at: [f8353b97] i915_gem_execbuffer+0x105/0xad7
[i915]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
- #1 (dev-struct_mutex){--..}:
[c045a398] __lock_acquire+0x9a8/0xb1b
[c045a566] lock_acquire+0x5b/0x81
[c073a7c0] __mutex_lock_common+0xda/0x32e
[c073aabb] mutex_lock_nested+0x33/0x3b
[f81bc7b0] drm_gem_mmap+0x34/0xf8 [drm]
[c04a395f] mmap_region+0x255/0x3f9
[c04a3d4a] do_mmap_pgoff+0x247/0x297
[c040c739] sys_mmap2+0x5f/0x80
[c040966b] sysenter_do_call+0x12/0x3f
[] 0x
- #0 (mm-mmap_sem){}:
[c045a26d] __lock_acquire+0x87d/0xb1b
[c045a566] lock_acquire+0x5b/0x81
[c049c70f] might_fault+0x65/0x85
[c057dbcc] copy_from_user+0x2f/0x117
[f8353d55] i915_gem_execbuffer+0x2c3/0xad7 [i915]
[f81bb8c2] drm_ioctl+0x1c4/0x241 [drm]
[c04c19d7] vfs_ioctl+0x55/0x6e
[c04c1f28] do_vfs_ioctl+0x46f/0x4a8
[c04c1fa6] sys_ioctl+0x45/0x5f
[c040966b] sysenter_do_call+0x12/0x3f
[] 0x
other info that might help us debug this:
1 lock held by X/2749:
#0: (dev-struct_mutex){--..}, at: [f8353b97]
i915_gem_execbuffer+0x105/0xad7 [i915]
stack backtrace:
Pid: 2749, comm: X Not tainted 2.6.29.1-42.rc1.sb3.fc10.i686.PAE #1
Call Trace:
[c0739533] ? printk+0x14/0x19
[c04597d9] print_circular_bug_tail+0x5d/0x68
[c045a26d] __lock_acquire+0x87d/0xb1b
[c045a566] lock_acquire+0x5b/0x81
[c049c6f2] ? might_fault+0x48/0x85
[c049c70f] might_fault+0x65/0x85
[c049c6f2] ? might_fault+0x48/0x85
[c057dbcc] copy_from_user+0x2f/0x117
[f8353d55] i915_gem_execbuffer+0x2c3/0xad7 [i915]
[c04b0e39] ? __slab_alloc+0x3d0/0x445
[c049c72d] ? might_fault+0x83/0x85
[c057dbcc] ? copy_from_user+0x2f/0x117
[f81bb8c2] drm_ioctl+0x1c4/0x241 [drm]
[f8353a92] ? i915_gem_execbuffer+0x0/0xad7 [i915]
[c04c19d7] vfs_ioctl+0x55/0x6e
[c04c1f28] do_vfs_ioctl+0x46f/0x4a8
[c0580d08] ? _raw_spin_unlock+0x74/0x78
[c04b6ca2] ? fsnotify_modify+0x54/0x5f
[c04b6e93] ? do_sync_write+0x0/0xee
[c04b77af] ? vfs_write+0xa9/0xe4
[c04c1fa6] sys_ioctl+0x45/0x5f
[c040966b] sysenter_do_call+0x12/0x3f
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13030] i915: possible circular locking dependency detected in i915_gem_execbuffer
http://bugzilla.kernel.org/show_bug.cgi?id=13030 --- Comment #2 from Sami Liedes slie...@cc.hut.fi 2009-04-07 16:53:22 --- Created an attachment (id=20861) -- (http://bugzilla.kernel.org/attachment.cgi?id=20861) Dmesg output, except the very first seconds that I didn't capture Here's my dmesg. The first seconds are missing, I guess, because of the vast amount of kobject: debug messages before the disk logging started. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] Remove code for tracking per-drawable cliprects.
On Fri, Apr 3, 2009 at 11:56 AM, Kristian Høgsberg k...@bitplanet.net wrote: 2009/4/2 Eric Anholt e...@anholt.net: On Thu, 2009-04-02 at 14:41 -0400, Kristian Høgsberg wrote: This was only used by the i915 driver for the swapbuffer vsync tasklet. That functionality is now gone and nothing uses the kernel side cliprects anymore. Just stub out the ioctls, but make sure we return a non-zero handle in the DRM_IOCTL_ADD_DRAW case. Have you tested old userland to make sure it doesn't freak out? Other than that, I love the idea. I did, ran gears, resized it, and it worked. glxgears is even less of a test suite than it is a benchmark, of course, bu int this case I do believe it tests the code paths in question. The only gotchas would be if some userspace code relies on updating or removing an invalid drawable handle to return -EINVAL or relies on adddraw returning unique drawable handles. In my reading of the xf86dri, aiglx and libgl, I've not come across any such requirement. Do you want to pick it up then or do you want Dave to take it? thanks, Kristian -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13039] New: i915(?): Scheduling while atomic when kdm (display manager) restarting after logging out
http://bugzilla.kernel.org/show_bug.cgi?id=13039 Summary: i915(?): Scheduling while atomic when kdm (display manager) restarting after logging out Product: Drivers Version: 2.5 Kernel Version: 2.6.29.1 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI) AssignedTo: drivers_video-...@kernel-bugs.osdl.org ReportedBy: slie...@cc.hut.fi Regression: No Created an attachment (id=20862) -- (http://bugzilla.kernel.org/attachment.cgi?id=20862) dmesg from the system (but not the crash run), except the first few seconds which weren't logged for some reason Hi, I don't know if this is a DRI bug, please reassign as you see fit. I have a reproducible hard lockup when logging off my KDE session running in kdm after updating to a recent X server from Debian experimental and KDE 4.2.2. So far I have managed to cause the lockup only in this scenario. For example, killing X with /etc/init.d/kdm stop and starting it again with /etc/init.d/kdm start does not cause a crash. killall startkde is sufficient to cause the crash when KDE is running inside kdm (but then is probably equivalent to logging off the session). I managed to catch the panic on netconsole after a couple of tries. Architecture is a x86_64 machine, a Compaq 6720s laptop which generally has worked and works really fine under Linux. Here's the output on netconsole starting before a short KDE session and ending in a crash. Is the panic messed up (lines missing)? I can try again, but netconsole seems to be a bit unreliable in this case... - [ 338.658257] console [netcon0] enabled [ 338.658498] netconsole: network logging started [ 472.474916] kobject: 'vcs7' (8800659adef8): kobject_add_internal: parent: 'vc', set: 'devices' [ 472.475055] kobject: 'vcs7' (8800659adef8): kobject_uevent_env [ 472.475070] kobject: 'vcs7' (8800659adef8): fill_kobj_path: path = '/devices/virtual/vc/vcs7' [ 472.475121] kobject: 'vcsa7' (8800659ad668): kobject_add_internal: parent: 'vc', set: 'devices' [ 472.475172] kobject: 'vcsa7' (8800659ad668): kobject_uevent_env [ 472.475186] kobject: 'vcsa7' (8800659ad668): fill_kobj_path: path = '/devices/virtual/vc/vcsa7' [ 474.908689] kobject: 'cfbfillrect' (a005c090): kobject_add_internal: parent: 'module', set: 'module' [ 474.908932] kobject: 'holders' (8800659ea7f8): kobject_add_internal: parent: 'cfbfillrect', set: 'NULL' [ 474.908966] kobject: 'cfbfillrect' (a005c090): kobject_uevent_env [ 474.909956] kobject: 'cfbfillrect' (a005c090): fill_kobj_path: path = '/module/cfbfillrect' [ 474.914143] kobject: 'notes' (8800659ea908): kobject_add_internal: parent: 'cfbfillrect', set: 'NULL' [ 474.916739] kobject: 'cfbimgblt' (a0101a50): kobject_add_internal: parent: 'module', set: 'module' [ 474.916936] kobject: 'holders' (8800659ea110): kobject_add_internal: parent: 'cfbimgblt', set: 'NULL' [ 474.916972] kobject: 'cfbimgblt' (a0101a50): kobject_uevent_env [ 474.916995] kobject: 'cfbimgblt' (a0101a50): fill_kobj_path: path = '/module/cfbimgblt' [ 474.919054] kobject: 'notes' (8800659ea990): kobject_add_internal: parent: 'cfbimgblt', set: 'NULL' [ 474.934421] kobject: 'cfbcopyarea' (a017aeb0): kobject_add_internal: parent: 'module', set: 'module' [ 474.934620] kobject: 'holders' (8800659ea770): kobject_add_internal: parent: 'cfbcopyarea', set: 'NULL' [ 474.934657] kobject: 'cfbcopyarea' (a017aeb0): kobject_uevent_env [ 474.934723] kobject: 'cfbcopyarea' (a017aeb0): fill_kobj_path: path = '/module/cfbcopyarea' [ 474.934844] kobject: 'notes' (8800659ea330): kobject_add_internal: parent: 'cfbcopyarea', set: 'NULL' [ 474.975853] kobject: 'i2c_algo_bit' (a01a7910): kobject_add_internal: parent: 'module', set: 'module' [ 474.976762] kobject: 'holders' (8800659ea4c8): kobject_add_internal: parent: 'i2c_algo_bit', set: 'NULL' [ 474.976808] kobject: 'i2c_algo_bit' (a01a7910): kobject_uevent_env [ 474.976834] kobject: 'i2c_algo_bit' (a01a7910): fill_kobj_path: path = '/module/i2c_algo_bit' [ 474.978725] kobject: 'notes' (8800659ea440): kobject_add_internal: parent: 'i2c_algo_bit', set: 'NULL' [ 475.013621] kobject: 'drm' (a0308990): kobject_add_internal: parent: 'module', set: 'module' [ 475.029837] kobject: 'holders' (8800659ea880): kobject_add_internal: parent: 'drm', set: 'NULL' [ 475.029922] kobject: 'drm' (a0308990): kobject_uevent_env [ 475.029945] kobject: 'drm' (a0308990): fill_kobj_path: path = '/module/drm' [ 475.032600] kobject: 'notes' (8800659ea198): kobject_add_internal: parent: 'drm', set: 'NULL' [ 475.035718] kobject: 'drm' (8800659aa6d8):
[PATCH] drm: get connector status fix
In drm_mode_getconnector we send the connector status back to userspace. However, we only return the last detected status, rather than performing status detection again, which can lead to trouble if the configuration changes after module load and initial probing is done. Since drm_mode_getconnector currently has full probe semantics, make it return a current status at all times so that config changes are properly picked up. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 94a7688..403e00d 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -1283,10 +1283,14 @@ int drm_mode_getconnector(struct drm_device *dev, void *data, out_resp-connector_id = connector-base.id; out_resp-connector_type = connector-connector_type; out_resp-connector_type_id = connector-connector_type_id; + + /* These values should have been fetched by fill_modes from the EDID */ out_resp-mm_width = connector-display_info.width_mm; out_resp-mm_height = connector-display_info.height_mm; out_resp-subpixel = connector-display_info.subpixel_order; - out_resp-connection = connector-status; + + /* Go see if it's there */ + out_resp-connection = connector-funcs-detect(connector); if (connector-encoder) out_resp-encoder_id = connector-encoder-base.id; else -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13040] New: DRM radeon
http://bugzilla.kernel.org/show_bug.cgi?id=13040
Summary: DRM radeon
Product: Drivers
Version: 2.5
Kernel Version: 2.6.29.1
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Video(DRI)
AssignedTo: drivers_video-...@kernel-bugs.osdl.org
ReportedBy: r...@hellgate.ch
Regression: Yes
Created an attachment (id=20864)
-- (http://bugzilla.kernel.org/attachment.cgi?id=20864)
boot messages (Vanilla Linux 2.6.29.1)
I've been having all kinds of interesting errors with radeon DRM since 2.6.28
(and I filed one report, bug 12333).
With 2.6.29.1, a new X.org server (1.4.2-1.5.3) and a new ATI driver (6.9.0 -
6.12.1), DRM is not working and I am getting these infos:
In dmesg:
[ 160.613947] ===
[ 160.613951] [ INFO: possible circular locking dependency detected ]
[ 160.613953] 2.6.29.1-01 #1
[ 160.613955] ---
[ 160.613958] X/8820 is trying to acquire lock:
[ 160.613960] (dev-struct_mutex){--..}, at: [f879445a] drm_mmap+0x25/0x3f
[drm]
[ 160.613986]
[ 160.613986] but task is already holding lock:
[ 160.613989] (mm-mmap_sem){}, at: [c0106619] sys_mmap2+0x44/0x7b
[ 160.613997]
[ 160.613997] which lock already depends on the new lock.
And in Xorg.0.log:
(II) RADEON(0): [drm] installed DRM signal handler
(EE) RADEON(0): [pci] Out of memory (-12)
(EE) RADEON(0): [pci] PCI failed to initialize. Disabling the DRI.
(II) RADEON(0): [drm] removed 1 reserved context for kernel
(II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xf8684000 at 0xb7be9000
(II) RADEON(0): [drm] Closed DRM master.
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13040] DRM radeon
http://bugzilla.kernel.org/show_bug.cgi?id=13040 --- Comment #1 from Roger Luethi r...@hellgate.ch 2009-04-07 20:09:07 --- Created an attachment (id=20865) -- (http://bugzilla.kernel.org/attachment.cgi?id=20865) X Server log -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13039] i915(?): Scheduling while atomic when kdm (display manager) restarting after logging out
http://bugzilla.kernel.org/show_bug.cgi?id=13039 --- Comment #1 from Sami Liedes slie...@cc.hut.fi 2009-04-07 18:56:01 --- Here's a second try. I do get the feeling there's something missing after those Modules linked in: lines. If you think it would be useful, I might try to comment out that printk() in the kernel source and get another log. [ 2061.55] console [netcon0] enabled [ 2061.222309] netconsole: network logging started [ 2089.861750] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0 [ 2091.852369] general protection fault: [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 2091.852416] last sysfs file: /sys/devices/virtual/backlight/acpi_video0/brightness [ 2091.852426] CPU 0 [ 2091.852441] Modules linked in: netconsole i915 drm i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect ppdev parport_pc lp parport rfcomm l2cap binfmt_misc xt_limit xt_tcpudp ipt_LOG ipt_MASQUERADE ipt_REJECT nf_conntrack_irc nf_conntrack_ftp xt_state cpufreq_conservative cpufreq_ondemand cpufreq_userspace microcode cpufreq_powersave cpufreq_stats freq_table af_packet iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 iptable_mangle iptable_filter ip_tables x_tables fuse coretemp hwmon00 00 [ 2091.853021] RIP [8027acd4] __lock_acquire+0x2d4/0x1de0 [ 2091.853021] RSP 880066031b08 [ 2091.853021] ---[ end trace eea4125cefd22938 ]--- [ 2091.853021] note: Xorg[4751] exited with preempt_count 2 [ 2091.855488] BUG: scheduling while atomic: Xorg/4751/0x1003 [ 2091.855502] INFO: lockdep is turned off. [ 2091.855510] Modules linked in: netconsole i915 drm i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect ppdev parport_pc lp parport rfcomm l2cap binfmt_misc xt_limit xt_tcpudp ipt_LOG ipt_MASQUERADE ipt_REJECT nf_conntrack_irc nf_conntrack_ftp xt_state cpufreq_conservative cpufreq_ondemand cpufreq_userspace microcode cpufreq_powersave cpufreq_stats freq_table af_packet iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 iptable_mangle iptable_filter ip_tables x_tables fuse coretemp hwmon joydev snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_pcm_oss snd_mixer_oss arc4 snd_pcm ecb snd_seq_midi pcspkr psmouse snd_rawmidi snd_seq_midi_event serio_raw output evdev dm_mirror dm_region_hash dm_log dm_snapshot[ 2091.856648] [8024a09f] mmput+0x5f/0xd0 [ 2091.856766] [8024eee7] exit_mm+0x117/0x160 [ 2091.856777] [806495c9] ? _spin_unlock_irq+0x59/0x70 [ 2091.856786] [80250e5d] do_exit+0x14d/0x960 [ 2091.856796] [8064afdc] oops_end+0xdc/0xe0 [ 2091.857102] [803370e0] ? dnotify_parent+0x90/0xa0 [ 2091.857112] [803370e0] ? dnotify_parent+0x90/0xa0 [ 2091.857122] [8064d4a8] ? sub_preempt_count+0xc8/0x130 [ 2091.857131] [8064a403] ? error_sti+0x5/0x6 [ 2091.860012] BUG: spinlock lockup on CPU#0, syslogd/6368, 8800017b0190 [ 2091.860012] Pid: 6368, comm: syslogd Tainted: G D2.6.29.1-tuxonice #2 [ 2091.860012] Call Trace: [ 2091.860012] [8041e038] _raw_spin_lock+0x158/0x170 [ 2091.860012] [80649a73] _spin_lock_irqsave+0x73/0x90 [ 2091.860012] [8023c3d2] ? __wake_up+0x32/0x70 [ 2091.860012] [8023c3d2] __wake_up+0x32/0x70 [ 2091.860012] [80265f21] __wake_up_bit+0x31/0x40 [ 2091.860012] [802cdc2c] unlock_page+0x2c/0x40 [ 2091.860012] [802e46e0] __do_fault+0x210/0x4e0 [ 2091.860012] [802e6be4] handle_mm_fault+0x1e4/0x850 [ 2091.860012] [8064c990] ? do_page_fault+0xd0/0xb20 [ 2091.860012] [8064cb3f] do_page_fault+0x27f/0xb20 [ 2091.860012] [802780e9] ? trace_hardirqs_off_caller+0x29/0xe0 [ 2091.860012] [80279d79] ? trace_hardirqs_on_caller+0x29/0x1e0 [ 2091.860012] [80648f8e] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 2091.860012] [8040ab14] ? __up_read+0x84/0xb0 [ 2091.860012] [80649627] ? _spin_unlock_irqrestore+0x47/0x80 [ 2091.860012] [8020d380] ? restore_args+0x0/0x30 [ 2091.860012] [8064a403] ? error_sti+0x5/0x6 [ 2091.860012] [802780e9] ? trace_hardirqs_off_caller+0x29/0xe0 [ 2091.860012] [80648fcd] ? trace_hardirqs_off_thunk+0x3a/0x3c [ 2091.860012] [8064a28f] page_fault+0x1f/0x30 -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
ttm_bo_move_accel_cleanup unreserve bug ?
Hi Thomas, I think we should not ttm_bo_unreserve the bo in ttm_bo_move_accel_cleanup i am seeing double unreserve which likely lead to kernel list corruption and i think it's due to that one (i am checking through printk but the log is enormous and my script is not yet done with parsing it) I checked code path in via using ttm_bo_move_accel_cleanup and none seems to reserve the buffer before calling ttm_bo_move_accel_cleanup. (Btw my tree is in my fdo drm-next repo drm-next-radeon branch i think they are few more fixes you might have miss but i will do a diff latter and push to mesa/drm repo) Cheers, Jerome -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13040] DRM radeon
http://bugzilla.kernel.org/show_bug.cgi?id=13040 Rafael J. Wysocki r...@sisk.pl changed: What|Removed |Added CC||r...@sisk.pl Blocks||12398 -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12861] Xorg fails to start Failed to allocate space for kernel memory manager
http://bugzilla.kernel.org/show_bug.cgi?id=12861 --- Comment #26 from Rafael J. Wysocki r...@sisk.pl 2009-04-07 21:06:56 --- On Tuesday 07 April 2009, John Emil Karlson wrote: Yes the bug is still present in 2.6.29.1. Venkatesh Pallipadi fixed an apparently similar bug there. I could ask him for advice once I have more time. http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.29.y.git;a=commit;h=e1b427acc979431fc7f57a06d0c636c542fdffcc -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] [intel-gfx] :The backlight issue when KMS is used
On Tue, 07 Apr 2009 16:48:22 +0800 Zhang Rui rui.zh...@intel.com wrote: CC Thomas, Len and linux-acpi mail list. On Tue, 2009-04-07 at 16:22 +0800, Matthew Garrett wrote: On Tue, Apr 07, 2009 at 04:20:34PM +0800, Zhang Rui wrote: All subsystems can register a set of callbacks for backlight control in its own way, e.g. ACPI, platform driver, i915. And the backlight manager only exports one single I/F to users, like: | |brightness |actual_brightness |max_brightness |... |mode and it supports multiple modes, e.g. 1. generic ---ACPI 2. platform---platform drivers 3. legacy-i915 This seems to be a lot of complexity for an uncommon case. Is there any real need to modify the mode at runtime? if this is implemented, the video_detect.c can be removed because we don't need to detect the ACPI video extension when loading platform drivers. every driver that has its own ways to control the backlight can register a set of callbacks and then it's the backlight manager's responsibility to choose which one to use. What happens if the platform driver gets loaded before i915? the backlight manager always choose the one with the highest priority if multiple callbacks are registered. i.e if (ACPI control methods are available) changes to the generic mode else if (platform specific callbacks are available) changes to the platform mode else if (i915 callbacks are available) changes to the legacy mode the backlight manager always run this logic when a new set of callbacks is registered/unregistered. The other option of course (as discussed this morning on IRC w/Dr_Jackob) is to avoid using the sysfs backlight API in the KMS case (KMS clients would be expected to go through output properties instead). This has the disadvantage of essentially deprecating a currently used interface, but OTOH making for a more consistent interface across new output types with brightness control (DDC has bits for this, as does displayport I think). But we'd definitely want to preserve the current ACPI interaction, so we'd have to make the i915 and other DRM drivers clients of the ACPI or platform backlight drivers (at least internally to the kernel) where available. This might be a bit simpler than the de-registration stuff we talked about, and would intuitively extend to other output types that add backlight support in the future. Any thoughts about that? -- Jesse Barnes, Intel Open Source Technology Center -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13030] i915: possible circular locking dependency detected in i915_gem_execbuffer
http://bugzilla.kernel.org/show_bug.cgi?id=13030 Eric Anholt e...@anholt.net changed: What|Removed |Added CC||e...@anholt.net --- Comment #3 from Eric Anholt e...@anholt.net 2009-04-07 23:53:29 --- This has been fixed in master, but hasn't been sent to stable due to known regressions that will be fixed soon. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13030] i915: possible circular locking dependency detected in i915_gem_execbuffer
http://bugzilla.kernel.org/show_bug.cgi?id=13030 --- Comment #4 from Sérgio M Basto ser...@sergiomb.no-ip.org 2009-04-08 01:15:07 --- (In reply to comment #3) This has been fixed in master, but hasn't been sent to stable due to known regressions that will be fixed soon. the master of what ? (drm-next, libdrm, mesa , drv-intel or xserver) -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13039] i915(?): Scheduling while atomic when kdm (display manager) restarting after logging out
http://bugzilla.kernel.org/show_bug.cgi?id=13039 Sami Liedes slie...@cc.hut.fi changed: What|Removed |Added Platform|All |x86-64 -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13030] i915: possible circular locking dependency detected in i915_gem_execbuffer
http://bugzilla.kernel.org/show_bug.cgi?id=13030 --- Comment #5 from Eric Anholt e...@anholt.net 2009-04-08 02:34:41 --- A lock order fix could only occur in the kernel, and master refers to linus. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] Remove code for tracking per-drawable cliprects.
On Tue, 2009-04-07 at 13:08 -0400, Kristian Høgsberg wrote: On Fri, Apr 3, 2009 at 11:56 AM, Kristian Høgsberg k...@bitplanet.net wrote: 2009/4/2 Eric Anholt e...@anholt.net: On Thu, 2009-04-02 at 14:41 -0400, Kristian Høgsberg wrote: This was only used by the i915 driver for the swapbuffer vsync tasklet. That functionality is now gone and nothing uses the kernel side cliprects anymore. Just stub out the ioctls, but make sure we return a non-zero handle in the DRM_IOCTL_ADD_DRAW case. Have you tested old userland to make sure it doesn't freak out? Other than that, I love the idea. I did, ran gears, resized it, and it worked. glxgears is even less of a test suite than it is a benchmark, of course, bu int this case I do believe it tests the code paths in question. The only gotchas would be if some userspace code relies on updating or removing an invalid drawable handle to return -EINVAL or relies on adddraw returning unique drawable handles. In my reading of the xf86dri, aiglx and libgl, I've not come across any such requirement. Do you want to pick it up then or do you want Dave to take it? Since it wasn't in my driver, I was assuming airlied would pick it up. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] Remove code for tracking per-drawable cliprects.
Do you want to pick it up then or do you want Dave to take it? Since it wasn't in my driver, I was assuming airlied would pick it up. Yup I'll grab it, I was going to leave it for the next merge window as I dislike doing anything like this post-merge, and it arrived during this merge. Dave. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13039] i915(?): Scheduling while atomic when kdm (display manager) restarting after logging out
http://bugzilla.kernel.org/show_bug.cgi?id=13039 --- Comment #2 from Sami Liedes slie...@cc.hut.fi 2009-04-08 03:38:22 --- I do not know if this is the same bug or a different one, but since the operating environment and symptoms are pretty much same, by best guess is it's the same issue. The backtrace is slightly different though. Tell me if you wish me to report a new bug. This lockup seems to happen sometimes after using KDE for a while, having switched to a text console with ctrl-alt-F1 and then back to X. Just like the reproducible lockup in my previous comments, the X screen is restored correctly when switching back to X (in the previous cases that amounts to showing the mouse pointer) and the mouse pointer moves, but a hard lockup occurs in less than maybe 2 seconds (judging from the mouse pointer no longer moving). This too is from netconsole, which uses UDP, and I wonder if something is cut out after the Modules linked in: line (note the missing newline after that line). Maybe it's just a cut line if netconsole does one UDP packet per line. I guess I'll try and compile a kernel with that printk() commented out to be more sure about this. Unlike the previous backtraces, the process is not Xorg but setxkbmap. [ 247.380201] console [netcon0] enabled [ 247.380442] netconsole: network logging started [ 265.012862] [drm] Initialized drm 1.1.0 20060810 [ 265.048327] pci :00:02.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [ 265.074306] [drm] Initialized i915 1.6.0 20080730 on minor 0 [ 284.607814] nepomukservices[6707]: segfault at 78 ip 7f5d48ee755e sp 7fff514d6690 error 4 in libQtCore.so.4.4.3[7f5d48e7e000+23] [ 369.857838] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0 [ 1356.490484] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0 [ 1373.529130] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0 [ 3110.287244] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0 [ 3121.921768] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0 [ 3125.121969] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0 [ 3128.827253] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0 [ 3135.647005] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0 [ 3154.698136] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0 [ 4083.234335] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0 [ 4180.192228] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0 [ 4182.833661] general protection fault: [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 4182.833710] last sysfs file: /sys/devices/virtual/backlight/acpi_video0/brightness [ 4182.833721] CPU 0 [ 4182.833737] Modules linked in: i915 drm i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect netconsole xt_limit xt_tcpudp ipt_LOG ipt_MASQUERADE ipt_REJECT nf_conntrack_irc nf_conntrack_ftp xt_state ppdev parport_pc lp parport rfcomm l2cap binfmt_misc cpufreq_conservative cpufreq_ondemand cpufreq_userspace cpufreq_powersave microcode cpufreq_stats freq_table af_packet iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 iptable_mangle iptable_filter ip_tables x_tables snd_pcm_oss [80648fcd] ? trace_hardirqs_off_thunk+0x3a/0x3c [ 4182.834016] [8064a28f] page_fault+0x1f/0x30 [ 4182.834016] Code: 0f 84 af fd [ 4182.836906] BUG: scheduling while atomic: setxkbmap/25291/0x1002 [ 4182.836919] INFO: lockdep is turned off. [ 4182.836927] Modules linked in: i915 drm i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect netconsole xt_limit xt_tcpudp ipt_LOG ipt_MASQUERADE ipt_REJECT nf_conntrack_irc nf_conntrack_ftp xt_state ppdev parport_pc lp parport rfcomm l2cap binfmt_misc cpufreq_conservative cpufreq_ondemand cpufreq_userspace cpufreq_powersave microcode cpufreq_stats freq_table af_packet iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 iptable_mangle iptable_filter ip_tables x_tables fuse coretemp hwmon joydev snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_pcm_oss snd_mixer_oss bluetooth snd_seq_midi_event iwl3945 snd_seq rfkill snd_timer mac80211 led_class lib80211 cfg80211 snd[ 4182.838426] [802e46e0] __do_fault+0x210/0x4e0 [ 4182.838437] [802e6be4] handle_mm_fault+0x1e4/0x850 -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now!
