Hi,
we have a report of WARNING from 3.7.6 in nouveau at
drivers/gpu/drm/nouveau/core/core/mm.c:242 here:
https://bugzilla.novell.com/show_bug.cgi?id=802347#c11
There is an order 4 allocation failure in nouveau_drm_open ->
nouveau_vm_create, i.e. this one failed:
vm->pgt = kcalloc(vm->lpde - vm->fpde + 1, sizeof(*vm->pgt), GFP_KERNEL);
Then, on the error path in still in nouveau_drm_open, it is followed by
a call to nouveau_cli_destroy. But that one calls nouveau_vm_ref ->
…
[View More]nouveau_mm_fini -> nouveau_vm_del -> nouveau_mm_fini which triggers the
warning.
Any ideas?
thanks,
--
js
suse labs
[View Less]
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_sdvo.c between commit 7ba220cec0bb ("drm/i915:
Enable hotplug interrupts after querying hw capabilities") from Linus'
tree and commit e596a02ccfc6 ("drm/i915: Remove dead code from SDVO
initialisation") from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr(a)canb.auug.org.au
diff --cc …
[View More]drivers/gpu/drm/i915/intel_sdvo.c
index 7d31165,b8e1623..0000000
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@@ -2850,18 -2889,12 +2891,6 @@@ bool intel_sdvo_init(struct drm_device
}
}
- hotplug_mask = 0;
- if (IS_G4X(dev)) {
- hotplug_mask = intel_sdvo->is_sdvob ?
- SDVOB_HOTPLUG_INT_STATUS_G4X : SDVOC_HOTPLUG_INT_STATUS_G4X;
- } else if (IS_GEN4(dev)) {
- hotplug_mask = intel_sdvo->is_sdvob ?
- SDVOB_HOTPLUG_INT_STATUS_I965 : SDVOC_HOTPLUG_INT_STATUS_I965;
- } else {
- hotplug_mask = intel_sdvo->is_sdvob ?
- SDVOB_HOTPLUG_INT_STATUS_I915 : SDVOC_HOTPLUG_INT_STATUS_I915;
- }
-
- /* Only enable the hotplug irq if we need it, to work around noisy
- * hotplug lines.
- */
- if (intel_sdvo->hotplug_active)
- intel_encoder->hpd_pin = HPD_SDVO_B ? HPD_SDVO_B : HPD_SDVO_C;
-
intel_encoder->compute_config = intel_sdvo_compute_config;
intel_encoder->disable = intel_disable_sdvo;
intel_encoder->mode_set = intel_sdvo_mode_set;
[View Less]
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_display.c between commit d62cf62ad07d
("drm/i915: Quirk the pipe A quirk in the modeset state checker") from
Linus' tree and commit 6c49f24180c3 ("drm/i915: hw state readout support
for pixel_multiplier") from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr(a)canb.auug.org.au
diff --…
[View More]cc drivers/gpu/drm/i915/intel_display.c
index 6eb99e1,218bc93..0000000
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@@ -8177,11 -8264,14 +8264,19 @@@ check_crtc_state(struct drm_device *dev
active = dev_priv->display.get_pipe_config(crtc,
&pipe_config);
+
+ /* hw state is inconsistent with the pipe A quirk */
+ if (crtc->pipe == PIPE_A && dev_priv->quirks & QUIRK_PIPEA_FORCE)
+ active = crtc->active;
+
+ list_for_each_entry(encoder, &dev->mode_config.encoder_list,
+ base.head) {
+ if (encoder->base.crtc != &crtc->base)
+ continue;
+ if (encoder->get_config)
+ encoder->get_config(encoder, &pipe_config);
+ }
+
WARN(crtc->active != active,
"crtc active state doesn't match with hw state "
"(expected %i, found %i)\n", crtc->active, active);
[View Less]
https://bugzilla.kernel.org/show_bug.cgi?id=57381
Lan Tianyu <tianyu.lan(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|Hibernation/Suspend |Video(DRI - non Intel)
AssignedTo|tianyu.lan(a)intel.com |drivers_video-dri@kernel-bu
| |gs.osdl.org
Product|Power Management |…
[View More]Drivers
--- Comment #18 from Lan Tianyu <tianyu.lan(a)intel.com> 2013-06-17 02:14:18 ---
Thanks for test. I think you have done a very good job.
(In reply to comment #16)
> Ok, the following statements deactivate async for the graphics card (+ its HDMI
> audio):
> echo disabled > "/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/power/async"
> echo disabled > "/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/power/async"
>
> This seems to have a similar effect as "echo 0 > /sys/power/pm_async".
>
This shows the issue is still related with Graphics driver. Disable pm_async is
just to make all the driver suspend callback to be executed serially.
So reassign this bug to Graphic category.
> With this, I ran a series of 30 hibernate/resume cycles. The 7th and the 29th
> attempts failed (the last one failed twice), with the usual symptoms. So it
> seems that disabling async for the graphics card indeed only alleviates the
> problem. I will perform the same tests with pm_async deactivated just to be
> sure.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
[View Less]
>From 8e61934c3918484bae10d9ff771c93ad1fa73e29 Mon Sep 17 00:00:00 2001
From: Arjan van de Ven <arjanvandeven(a)gmail.com>
Date: Sun, 16 Jun 2013 11:12:53 -0700
Subject: [PATCH 2/2] intel: get rid of the .data section
head_offset and tail_offset are the only two global variables in the
whole library that are
not 0 initialized (and thus make up the .data section)
However, the first thing that drm_intel_decode() does is give them a new value,
and all uses of instr_out() that uses …
[View More]head_offset/etc should come from
drm_intel_decode()
in the first place... so the non-0 initialization is superfluous.
on x86-64, the elf data from before and after:
Before
libdrm_intel.so.1.0.0: 32 relocations, 25 relative (78%), 56 PLT
entries, 11 for local syms (19%)
[11] .text PROGBITS 0000000000002860 00002860
00011db8 0 AX 0 0 16
[13] .rodata PROGBITS 0000000000014640 00014640
00005c63 0 A 0 0 32
[19] .data.rel.ro PROGBITS 000000000021d020 0001d020
00001a08 0 WA 0 0 32
[23] .data PROGBITS 000000000021ee48 0001ee48
00000008 0 WA 0 0 4
[24] .bss NOBITS 000000000021ee50 0001ee50
00000048 0 WA 0 0 8
After
libdrm_intel.so.1.0.0: 32 relocations, 25 relative (78%), 56 PLT
entries, 11 for local syms (19%)
[11] .text PROGBITS 0000000000002860 00002860
00011db8 0 AX 0 0 16
[13] .rodata PROGBITS 0000000000014640 00014640
00005c63 0 A 0 0 32
[19] .data.rel.ro PROGBITS 000000000021d020 0001d020
00001a08 0 WA 0 0 32
[23] .bss NOBITS 000000000021ee48 0001ee48
00000050 0 WA 0 0 8
e.g. no more .data section
Signed-off-by: Arjan van de Ven <arjan(a)linux.intel.com>
---
intel/intel_decode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index fdbbe0c..3c0a1f5 100644
--- a/intel/intel_decode.c
+++ b/intel/intel_decode.c
@@ -80,8 +80,8 @@ struct drm_intel_decode {
static FILE *out;
static uint32_t saved_s2 = 0, saved_s4 = 0;
static char saved_s2_set = 0, saved_s4_set = 0;
-static uint32_t head_offset = 0xffffffff; /* undefined */
-static uint32_t tail_offset = 0xffffffff; /* undefined */
+static uint32_t head_offset;
+static uint32_t tail_offset;
#ifndef ARRAY_SIZE
#define ARRAY_SIZE(A) (sizeof(A)/sizeof(A[0]))
--
1.7.11.7
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=65377
Priority: medium
Bug ID: 65377
Assignee: dri-devel(a)lists.freedesktop.org
Summary: Backlight control via /sys/class/backlight/radeon_bl0
not working
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: bastian.triller(a)gmail.com
Hardware: x86-64 (AMD64)
Status: NEW
Version: XOrg CVS
…
[View More] Component: DRM/Radeon
Product: DRI
This is a Macbook pro 8,2 with an Intel HD Graphics 3000 [8086:0116] and an AMD
Radeon HD 6750M [1002:6741].
The backlight interface in /sys/class/backlight/radeon_bl0 does not work.
Echoing to "brightness" does not change the brightness of the Monitor. There is
also an apple_gmux interface, which works though.
I've bound xbacklight to the brightness keys to control the brightness, but it
looks like it's confused about which interface it should use:
$ xbacklight -inc 5
No outputs have backlight property
When I disable the Radeon card on boot and use the Intel card, xbacklight
works.
--
You are receiving this mail because:
You are the assignee for the bug.
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=65803
Priority: medium
Bug ID: 65803
Assignee: dri-devel(a)lists.freedesktop.org
Summary: r600g: segfault with Kerbal Space Program
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: corey(a)octayn.net
Hardware: x86-64 (AMD64)
Status: NEW
Version: git
Component: Drivers/Gallium/r600
Product: …
[View More]Mesa
Unfortunately the game is closed source and stripped, so I don't have more
information, but the backtrace I get is:
(gdb) where
#0 0x0000000000000000 in ?? ()
#1 0x00007ffff30052ae in pipe_sampler_view_reference (view=0x85d19b0,
ptr=0x768b410) at ../../../../src/gallium/auxiliary/util/u_inlines.h:151
#2 r600_set_sampler_views (pipe=0x7689c90, shader=<optimized out>,
count=<optimized out>, views=0x37395e0, start=<optimized out>) at
r600_state_common.c:626
#3 0x00007ffff2e21a1b in update_textures (st=0x4b2dd80, shader_stage=1,
prog=0x8562a20, max_units=16, sampler_views=0x4b2e710, num_textures=0x4b2e894)
at ../../src/mesa/state_tracker/st_atom_texture.c:316
#4 0x00007ffff2e1d907 in st_validate_state (st=st@entry=0x4b2dd80) at
../../src/mesa/state_tracker/st_atom.c:221
#5 0x00007ffff2e2463a in st_Clear (ctx=0x411f8e0, mask=50) at
../../src/mesa/state_tracker/st_cb_clear.c:396
#6 0x00000000005759c1 in ?? ()
#7 0x000000000057dfa3 in ?? ()
#8 0x00000000005b4ead in ?? ()
#9 0x000000000087db9c in ?? ()
#10 0x0000000000b4d303 in ?? ()
#11 0x00007ffff62dea15 in __libc_start_main () from /usr/lib/libc.so.6
#12 0x0000000000456669 in ?? ()
#13 0x00007fffffffd438 in ?? ()
#14 0x00000000ffffffff in ?? ()
#15 0x0000000000000001 in ?? ()
#16 0x00007fffffffd832 in ?? ()
#17 0x0000000000000000 in ?? ()
I have a trace but it's very large (>500MB) and it doesn't reproduce the crash.
I haven't seen anyone else report the crash. The crash happens on stable mesa
too.
I can reliably reproduce by selecting the first two menu options in the game
launch (Start Game and Settings). The previous versions of the game worked.
--
You are receiving this mail because:
You are the assignee for the bug.
[View Less]