This fixes a race condition with MI_SET_CONTEXT and setting of the
PWRCTXA register. If PWRCTXA ends up getting set before MI_SET_CONTEXT
completes, it's possible that the system will enter rc6, and try to
return to the default render context, which if unset, could cause a GPU
hang
Resolve
On Mon, Mar 14, 2011 at 09:55:01PM -0700, Ben Widawsky wrote:
This fixes a race condition with MI_SET_CONTEXT and setting of the
PWRCTXA register. If PWRCTXA ends up getting set before MI_SET_CONTEXT
completes, it's possible that the system will enter rc6, and try to
return to the default
This fixes a race condition with MI_SET_CONTEXT and setting of the
PWRCTXA register. If PWRCTXA ends up getting set before MI_SET_CONTEXT
completes, it's possible that the system will enter rc6, and try to
return to the default render context, which if unset, could cause a GPU
hang
Resolve
On Mon, Mar 14, 2011 at 10:00:20PM -0700, Ben Widawsky wrote:
On Mon, Mar 14, 2011 at 09:55:01PM -0700, Ben Widawsky wrote:
This fixes a race condition with MI_SET_CONTEXT and setting of the
PWRCTXA register. If PWRCTXA ends up getting set before MI_SET_CONTEXT
completes, it's possible that
On Mon, 14 Mar 2011 21:55:01 -0700, Ben Widawsky b...@bwidawsk.net wrote:
This fixes a race condition with MI_SET_CONTEXT and setting of the
PWRCTXA register. If PWRCTXA ends up getting set before MI_SET_CONTEXT
completes, it's possible that the system will enter rc6, and try to
return to the
On Tue, 15 Mar 2011 02:18:02 +0100 (CET), Indan Zupancic in...@nul.nu wrote:
Hello,
Some nitpicks below.
On Mon, March 14, 2011 18:59, Chris Wilson wrote:
Note: neither the opregion_dev interface or the alse_set_* properly report
failures. As such we have a slight change in behaviour on
On Tue, 15 Mar 2011 00:12:51 -0700, Ben Widawsky b...@bwidawsk.net wrote:
On Mon, Mar 14, 2011 at 10:00:20PM -0700, Ben Widawsky wrote:
On Mon, Mar 14, 2011 at 09:55:01PM -0700, Ben Widawsky wrote:
This fixes a race condition with MI_SET_CONTEXT and setting of the
PWRCTXA register. If
Dear Intel driver folks,
using Debian Sid/unstable with
linux-image-2.6.37-2-686 2.6.37-2 [1]
xserver-xorg-video-intel 2:2.14.0-4 [2]
I noticed the following Linux kernel Oops today when shutting down the
system.
Mar 15 03:43:23 hostname kernel: [ 1189.189626] BUG:
On Tue, March 15, 2011 09:37, Chris Wilson wrote:
On Tue, 15 Mar 2011 02:18:02 +0100 (CET), Indan Zupancic in...@nul.nu
wrote:
Hello,
Some nitpicks below.
On Mon, March 14, 2011 18:59, Chris Wilson wrote:
Note: neither the opregion_dev interface or the alse_set_* properly report
As detect will use hw registers and may modify structures, it needs to be
serialised by use of the dev-mode_config.mutex. Make it so.
Otherwise, we may cause random crashes as the sysfs file is queried
whilst a concurrent hotplug poll is being run. For example:
[ 1189.189626] BUG: unable to
On Tue, March 15, 2011 12:27, Peter Stuge wrote:
coreboot has existed for about eleven years and some 250 mainboards of
varying shapes and sizes (from laptop to server) are supported, but it's
I've been wanting to get rid of BIOSes and use Coreboot for ages,
but the amount of hassle needed to
On Tue, Mar 15, 2011 at 11:40:00 +, Chris Wilson wrote:
[Digression: what is upowerd doing reading those power hungry files?]
Apparently, checking docked status every 30 seconds, by reading the
status of drm outputs. Where docked means more than one output
connected. Yes, it's silly.
On Tue, Mar 15, 2011 at 02:30:55PM +0100, Olivier Galibert wrote:
On Tue, Mar 15, 2011 at 01:52:26AM +, Matthew Garrett wrote:
Now that we've got multiple consumers it's probably not helpful to move
the (potentially chip-specific) VBT handling to general code. We've got
zero
On Tue, Mar 15, 2011 at 01:52:26AM +, Matthew Garrett wrote:
Now that we've got multiple consumers it's probably not helpful to move
the (potentially chip-specific) VBT handling to general code. We've got
zero documentation on how GMA500 handles VBT, and not a great deal more
for i915.
On Tue, Mar 15, 2011 at 01:32:40PM +, Matthew Garrett wrote:
Opregion is one mechanism to provide VBT - it doesn't define it.
Then let me repeat that I haven't seen anything in the VBT tables of
the gma500-using netbook I have that didn't seem to be parsed
correctly by the current
On Tue, 15 Mar 2011 11:40:00 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
As detect will use hw registers and may modify structures, it needs to be
serialised by use of the dev-mode_config.mutex. Make it so.
Otherwise, we may cause random crashes as the sysfs file is queried
whilst a
On Tue, Mar 15, 2011 at 07:59:48AM +, Chris Wilson wrote:
I think I should update the comments to reflect what the spec says about
LOAD_REGISTER_IMM (even though I trust Daniel to have accurately
determined their impact on gen2/3)... The spec implies that the variable
length nature of the
On Tue, March 15, 2011 17:06, Alex Deucher wrote:
On Tue, Mar 15, 2011 at 7:46 AM, Indan Zupancic in...@nul.nu wrote:
They don't give their Linux devs any Fusion hardware, nor do they
open the UVD spec, but at least they release info like this.
They do give us fusion hw; before launch even.
Read the changelog and thread on the patch that disabled this logic, the
failure (or at least inconsistent behaviour with the expectations of the
HP BIOS authors) appears to be in how we initialise ACPI on the HP
machines that causes the initial value of lid state to be incorrect. Since
one
19 matches
Mail list logo
