[ This got dropped somehow - it's in my draft folder. The bisection
may be irrelevant now: does it work with current git, since we've had
some nouveau changes? ]
On Tue, Aug 28, 2012 at 8:26 AM, Alexey Dobriyan wrote:
> Ping!
>
> No X for me with 3.6-rc2.
Can you possibly bisect it, at least par
[ This got dropped somehow - it's in my draft folder. The bisection
may be irrelevant now: does it work with current git, since we've had
some nouveau changes? ]
On Tue, Aug 28, 2012 at 8:26 AM, Alexey Dobriyan wrote:
> Ping!
>
> No X for me with 3.6-rc2.
Can you possibly bisect it, at least par
On Mon, Jul 16, 2012 at 12:42 PM, Dave Airlie wrote:
>
> Sorry been travelling and a bit neglectful of some of Alan's
> patches,
I actually took the three Alan sent me already, exactly because they
seemed harmless and I didn't know your schedule.
Your pull has a "gma500: Fix frequency detection"
On Mon, Jul 16, 2012 at 12:42 PM, Dave Airlie wrote:
>
> Sorry been travelling and a bit neglectful of some of Alan's
> patches,
I actually took the three Alan sent me already, exactly because they
seemed harmless and I didn't know your schedule.
Your pull has a "gma500: Fix frequency detection"
On Fri, Jun 8, 2012 at 3:52 PM, Chris Wilson wrote:
>
> And that was my point. You were blaming the patch for making you aware
> of existing behaviour that results in utter confusion, for as Alex
> points out there is no sane way for userspace to handle the unknown
> connection status from the det
On Fri, Jun 8, 2012 at 3:52 PM, Chris Wilson
wrote:
>
> And that was my point. You were blaming the patch for making you aware
> of existing behaviour that results in utter confusion, for as Alex
> points out there is no sane way for userspace to handle the unknown
> connection status from the de
On Fri, Jun 8, 2012 at 3:12 PM, Chris Wilson wrote:
>
> So it falls back to
> load-detection, which in your case it cannot do since all the available
> pipes are assigned and so it just reports the VGA connection as unknown.
Btw, it's a singularly stupid decision to say "Ok, I *know* I
On Fri, Jun 8, 2012 at 3:12 PM, Chris Wilson
wrote:
>
> So it falls back to
> load-detection, which in your case it cannot do since all the available
> pipes are assigned and so it just reports the VGA connection as unknown.
Btw, it's a singularly stupid decision to say "Ok, I *know* I
On Fri, Jun 8, 2012 at 3:12 PM, Chris Wilson wrote:
>
> Shock, horror, that's how it is meant to work when we cannot determine
> whether or not there is actually an output attached to the VGA.
We don't break existing installations. And that existing installation
has worked for a long time. You br
On Fri, Jun 8, 2012 at 3:12 PM, Chris Wilson
wrote:
>
> Shock, horror, that's how it is meant to work when we cannot determine
> whether or not there is actually an output attached to the VGA.
We don't break existing installations. And that existing installation
has worked for a long time. You b
This breaks things for me. Bisect says:
9e612a008fa7fe493a473454def56aa321479495 is the first bad commit
commit 9e612a008fa7fe493a473454def56aa321479495
Author: Chris Wilson
Date: Thu May 31 13:08:53 2012 +0100
drm/i915/crt: Do not rely upon the HPD presence pin
Whilst most monitors d
This breaks things for me. Bisect says:
9e612a008fa7fe493a473454def56aa321479495 is the first bad commit
commit 9e612a008fa7fe493a473454def56aa321479495
Author: Chris Wilson
Date: Thu May 31 13:08:53 2012 +0100
drm/i915/crt: Do not rely upon the HPD presence pin
Whilst most monitors d
On Wed, May 30, 2012 at 12:25 AM, Chris Wilson wrote:
>
> You've reported this bug in the past, though maybe on a different machine:
It's quite likely the same machine - but in the past it may have
happened once per six months or something. Now it happened twice in
two days.
Li
On Wed, May 30, 2012 at 12:42 AM, Daniel Vetter wrote:
>
> Really, please upgrade your userspace - this is by far not the only bug
> fixed since then that can result in a gpu hang.
I *can't* upgrade my userpsace.
F14 is the last one that has a sane window manager. After that, the
gnome3 shit hap
On Wed, May 30, 2012 at 9:00 AM, Daniel Vetter wrote:
>
> Hm, that's pretty strange that you can't reproduce this any more. We check
> this has_edp stuff once at boot and then never touch it again.
Actually, I think I just figured out how to reproduce it: try to
suspend with the micro-DP <-> VGA
On Wed, May 30, 2012 at 12:25 AM, Chris Wilson
wrote:
>
> You've reported this bug in the past, though maybe on a different machine:
It's quite likely the same machine - but in the past it may have
happened once per six months or something. Now it happened twice in
two days.
L
On Wed, May 30, 2012 at 12:42 AM, Daniel Vetter wrote:
>
> Really, please upgrade your userspace - this is by far not the only bug
> fixed since then that can result in a gpu hang.
I *can't* upgrade my userpsace.
F14 is the last one that has a sane window manager. After that, the
gnome3 shit hap
On Wed, May 30, 2012 at 9:00 AM, Daniel Vetter wrote:
>
> Hm, that's pretty strange that you can't reproduce this any more. We check
> this has_edp stuff once at boot and then never touch it again.
Actually, I think I just figured out how to reproduce it: try to
suspend with the micro-DP <-> VGA
On Wed, May 30, 2012 at 1:27 AM, Daniel Vetter wrote:
>
> Ok, Chris couldn't reproduce this on his mba. Can you please boot with
> drm.debug=0xe, reproduce the noise and then attach the full dmesg?
Hmm. Now *I* can't reproduce it either.
I have updated my system in the meantime, so maybe this is
On Wed, May 30, 2012 at 1:27 AM, Daniel Vetter wrote:
>
> Ok, Chris couldn't reproduce this on his mba. Can you please boot with
> drm.debug=0xe, reproduce the noise and then attach the full dmesg?
Hmm. Now *I* can't reproduce it either.
I have updated my system in the meantime, so maybe this is
On Mon, May 28, 2012 at 12:06 AM, Chris Wilson wrote:
>
> No, the i915_error_state had everything I needed to see. It is the old
> ddx bug that was hardcoding a maximum relocation address that never
> corresponded with an actual hw limit. As soon we try to use memory above
> that value, the GPU de
On Mon, May 28, 2012 at 12:06 AM, Chris Wilson
wrote:
>
> No, the i915_error_state had everything I needed to see. It is the old
> ddx bug that was hardcoding a maximum relocation address that never
> corresponded with an actual hw limit. As soon we try to use memory above
> that value, the GPU d
More i915 error reports.. Is the freedesktop bugzilla the right place
for these? I'm an email kind of person, and the bugs.freedesktop.org
bugzilla setup for xorg seems kind of broken.
I did fill in this, though:
https://bugs.freedesktop.org/show_bug.cgi?id=50405
but here is the info by email
Oops. This got sent without the right Cc, and the wrong subject (the
people who were *supposed* to be cc'd instead got into the subject
line, and the subject line got dropped entirely).
Linus
On Sun, May 27, 2012 at 4:09 PM, Linus Torvalds
wrote:
> A new wor
Oops. This got sent without the right Cc, and the wrong subject (the
people who were *supposed* to be cc'd instead got into the subject
line, and the subject line got dropped entirely).
Linus
On Sun, May 27, 2012 at 4:09 PM, Linus Torvalds
wrote:
> A new wor
On Fri, May 25, 2012 at 2:17 AM, Sumit Semwal wrote:
>
> I am really sorry - I goofed up in the git URL (sent the ssh URL
> instead).
I was going to send you an acerbic email asking for your private ssh
key, but then noticed that you had sent another email with the public
version of the git tree.
On Fri, May 25, 2012 at 2:17 AM, Sumit Semwal
wrote:
>
> I am really sorry - I goofed up in the git URL (sent the ssh URL
> instead).
I was going to send you an acerbic email asking for your private ssh
key, but then noticed that you had sent another email with the public
version of the git tree
These guys seem to be recently introduced:
[drm:gen6_sanitize_pm] *ERROR* Power management discrepancy:
GEN6_RP_INTERRUPT_LIMITS expected 1700, was 1206
[drm:gen6_sanitize_pm] *ERROR* Power management discrepancy:
GEN6_RP_INTERRUPT_LIMITS expected 1707, was 1700
This is on my
These guys seem to be recently introduced:
[drm:gen6_sanitize_pm] *ERROR* Power management discrepancy:
GEN6_RP_INTERRUPT_LIMITS expected 1700, was 1206
[drm:gen6_sanitize_pm] *ERROR* Power management discrepancy:
GEN6_RP_INTERRUPT_LIMITS expected 1707, was 1700
This is on my
On Mon, May 7, 2012 at 4:13 PM, Stéphane Marchesin wrote:
>
> In the end, I came up with the ugly workaround of just leaking the
> offending pages in shmem.c.
Don't leak it.
Instead, add it to some RCU list, and free it using RCU. Or some
one-second timer or something.
That kind of approach sho
On Mon, May 7, 2012 at 4:13 PM, St?phane Marchesin
wrote:
>
> In the end, I came up with the ugly workaround of just leaking the
> offending pages in shmem.c.
Don't leak it.
Instead, add it to some RCU list, and free it using RCU. Or some
one-second timer or something.
That kind of approach sh
bisection.
Linus
On Sat, Apr 21, 2012 at 9:07 PM, Nick Bowler wrote:
> On 2012-04-21 15:43 -0700, Linus Torvalds wrote:
>> But none of it really looks all that scary. It looks like the 3.4
>> release is all on track, but please do holler if you see regressions.
>
> OK, I'll
bisection.
Linus
On Sat, Apr 21, 2012 at 9:07 PM, Nick Bowler
wrote:
> On 2012-04-21 15:43 -0700, Linus Torvalds wrote:
>> But none of it really looks all that scary. It looks like the 3.4
>> release is all on track, but please do holler if you see regressions.
>
> OK, I'll
Btw, I think this came in through the DRM merge:
ERROR: "mdfld_set_brightness" [drivers/gpu/drm/gma500/gma500_gfx.ko]
undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
this is just "make ARCH=i386" with allmodconfig.
Linus
On Wed, Mar 21, 2012
Btw, I think this came in through the DRM merge:
ERROR: "mdfld_set_brightness" [drivers/gpu/drm/gma500/gma500_gfx.ko]
undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
this is just "make ARCH=i386" with allmodconfig.
Linus
On Wed, Mar 21, 2012
On Wed, Mar 21, 2012 at 3:47 AM, Dave Airlie wrote:
>
> (oh and any warnings you see in i915 are gcc's fault from what anyone can
> see).
Christ those are annoying. Has anybody contacted the gcc people about this?
Linus
___
dri-deve
On Wed, Mar 21, 2012 at 3:47 AM, Dave Airlie wrote:
>
> (oh and any warnings you see in i915 are gcc's fault from what anyone can
> see).
Christ those are annoying. Has anybody contacted the gcc people about this?
Linus
On Sat, Mar 17, 2012 at 3:09 PM, Hugh Dickins wrote:
>
> I've got to go out for an hour: I'll digest more and think more about
> this when I get back. If someone could explain the original problem
> with _MOVABLE, that would help me:
I do not believe we actually ever uncovered the original probl
On Sat, Mar 17, 2012 at 3:09 PM, Hugh Dickins wrote:
>
> I've got to go out for an hour: I'll digest more and think more about
> this when I get back. ?If someone could explain the original problem
> with _MOVABLE, that would help me:
I do not believe we actually ever uncovered the original probl
On Sat, Mar 17, 2012 at 1:23 PM, Dave Airlie wrote:
>
> I did however get a flashback in google to this:
>
> http://lists.fedoraproject.org/pipermail/scm-commits/2010-July/456636.html
>
> Linus don't think we ever did work out why that worked, I wonder if we
> lost something after that.
Hmm. Mayb
On Sat, Mar 17, 2012 at 1:23 PM, Dave Airlie wrote:
>
> I did however get a flashback in google to this:
>
> http://lists.fedoraproject.org/pipermail/scm-commits/2010-July/456636.html
>
> Linus don't think we ever did work out why that worked, I wonder if we
> lost something after that.
Hmm. Mayb
On Fri, Mar 16, 2012 at 3:52 PM, Keith Packard wrote:
>
> We had a theory about hibernation -- unflushed FB writes that go astray
> when the pages underneath the GTT get reassigned when switching from the
> boot kernel to the resumed kernel.
Well, even without hibernation, one theory was about th
On Fri, Mar 16, 2012 at 3:52 PM, Keith Packard wrote:
>
> We had a theory about hibernation -- unflushed FB writes that go astray
> when the pages underneath the GTT get reassigned when switching from the
> boot kernel to the resumed kernel.
Well, even without hibernation, one theory was about th
Guys,
I don't know if these kinds of things have been forwarded to you, but
there's apparently been several things like this going on - with the
finger pointing to the i915 driver apparently clearing random memory.
Often the end result seems to be list corruption or a NULL pointer
dereference in t
Guys,
I don't know if these kinds of things have been forwarded to you, but
there's apparently been several things like this going on - with the
finger pointing to the i915 driver apparently clearing random memory.
Often the end result seems to be list corruption or a NULL pointer
dereference in t
On Mon, Mar 5, 2012 at 2:36 PM, Keith Packard wrote:
> <#part sign=pgpmime>
> On Mon, 5 Mar 2012 14:09:13 -0800, Linus Torvalds
> wrote:
>> Hmm. Is freedesktop.org having trouble?
>
> ECC memory errors -- we're moving this stuff to a new machine as quickly
>
On Mon, Mar 5, 2012 at 2:36 PM, Keith Packard wrote:
> <#part sign=pgpmime>
> On Mon, 5 Mar 2012 14:09:13 -0800, Linus Torvalds linux-foundation.org> wrote:
>> Hmm. Is freedesktop.org having trouble?
>
> ECC memory errors -- we're moving this stuff to a new machi
On Mon, Mar 5, 2012 at 10:57 AM, Dave Airlie wrote:
>
> git://people.freedesktop.org/~airlied/linux drm-fixes
Hmm. Is freedesktop.org having trouble?
I got
fatal: unable to connect to people.freedesktop.org:
people.freedesktop.org[0: 131.252.210.176]: errno=Connection refused
and an the t
On Mon, Mar 5, 2012 at 10:57 AM, Dave Airlie wrote:
>
> ?git://people.freedesktop.org/~airlied/linux drm-fixes
Hmm. Is freedesktop.org having trouble?
I got
fatal: unable to connect to people.freedesktop.org:
people.freedesktop.org[0: 131.252.210.176]: errno=Connection refused
and an the t
On Mon, Mar 5, 2012 at 6:22 AM, Alan Cox wrote:
> From: Alan Cox
>
> [Resending with correct address for Linus]
Should I take this directly, or is there a pending DRM pull that will
contain this?
Linus
___
dri-devel mailing list
d
On Mon, Mar 5, 2012 at 6:22 AM, Alan Cox wrote:
> From: Alan Cox
>
> [Resending with correct address for Linus]
Should I take this directly, or is there a pending DRM pull that will
contain this?
Linus
On Thu, Feb 23, 2012 at 1:36 PM, Eugeni Dodonov
wrote:
>
> Perhaps a stupid question, but does you tree has
> http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=9292f37e1f5c79400254dca46f83313488093825
> from Dave's drm-next?
>
> If it has, it would be the 1st time that I see xrandr
On Thu, Feb 23, 2012 at 1:36 PM, Eugeni Dodonov
wrote:
>
> Perhaps a stupid question, but does you tree has
> http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=9292f37e1f5c79400254dca46f83313488093825
> from Dave's drm-next?
>
> If it has, it would be the 1st time that I see xrandr
On Thu, Feb 23, 2012 at 12:15 PM, Linus Torvalds
wrote:
>
> Sadly, this doesn't seem to make any difference to my case. My xrandr
> stays at 0.555s even with this patch.
Btw, profiling with call chains seems to say that it all comes from
intel_sdvo_get_analog_edid() (a
On Thu, Feb 23, 2012 at 12:15 PM, Linus Torvalds
wrote:
>
> Sadly, this doesn't seem to make any difference to my case. My xrandr
> stays at 0.555s even with this patch.
Btw, profiling with call chains seems to say that it all comes from
intel_sdvo_get_analog_edid() (a
On Thu, Feb 23, 2012 at 11:52 AM, Chris Wilson wrote:
>
> i2c retries if sees an EGAIN, drm_do_probe_ddc_edid retries until it
> gets a result and *then* drm_do_get_edid retries until it gets a result
> it is happy with. All in all, that is a lot of processor intensive
> looping in cases where we
On Thu, Feb 23, 2012 at 11:52 AM, Chris Wilson
wrote:
>
> i2c retries if sees an EGAIN, drm_do_probe_ddc_edid retries until it
> gets a result and *then* drm_do_get_edid retries until it gets a result
> it is happy with. All in all, that is a lot of processor intensive
> looping in cases where we
On Wed, Jan 25, 2012 at 11:05 AM, Dave Airlie wrote:
>
> bunch of regression fixes since TTM rework and radeon initialisation,
> modesetting fixes for Alex to fix some black screens on kms start type
> issues, and two radeon ACPI fixes that make some laptops no oops on
> startup.
Does that includ
On Wed, Jan 25, 2012 at 11:05 AM, Dave Airlie wrote:
>
> bunch of regression fixes since TTM rework and radeon initialisation,
> modesetting fixes for Alex to fix some black screens on kms start type
> issues, and two radeon ACPI fixes that make some laptops no oops on
> startup.
Does that includ
On Fri, Jan 6, 2012 at 7:06 AM, Dave Airlie wrote:
>
> Now we've all agreed that the initial implementation is a good baseline
> for us to move forward on, but its messy working with others when the core
> code is out of tree. So we'd like to merge the core dma-buf code now so we
> can all build o
On Fri, Jan 6, 2012 at 7:06 AM, Dave Airlie wrote:
>
> Now we've all agreed that the initial implementation is a good baseline
> for us to move forward on, but its messy working with others when the core
> code is out of tree. So we'd like to merge the core dma-buf code now so we
> can all build o
On Mon, Dec 26, 2011 at 5:02 PM, Keith Packard wrote:
> This leaves them enabled on IVB, but disables them on SNB as we've
> discovered (yet again) that there are hardware combinations that
> simply cannot run with them.
Oh well.
Applied,
Linus
___
On Mon, Dec 26, 2011 at 5:02 PM, Keith Packard wrote:
> This leaves them enabled on IVB, but disables them on SNB as we've
> discovered (yet again) that there are hardware combinations that
> simply cannot run with them.
Oh well.
Applied,
Linus
On Tue, Dec 6, 2011 at 8:36 AM, Dave Airlie wrote:
>
> Well I do care about kexec but only due to being forced into caring
> about it for a certain enterprise distro that uses it a lot, so maybe
> I was a bit biased in this case, and I dislike random memory
> corruptions due to my subsystem even i
On Tue, Dec 6, 2011 at 8:36 AM, Dave Airlie wrote:
>
> Well I do care about kexec but only due to being forced into caring
> about it for a certain enterprise distro that uses it a lot, so maybe
> I was a bit biased in this case, and I dislike random memory
> corruptions due to my subsystem even i
On Tue, Dec 6, 2011 at 8:21 AM, Dave Airlie wrote:
>
> 3 fixes, one for an ongoing Intel VT-d/Ironlake GPU that I've been
> testing, and one kexec fix from Jerome for an issue reported on the list
> where the gpu writeback engines need to be switched off, along with a
> trivial fix from Alex.
Qui
On Tue, Dec 6, 2011 at 8:21 AM, Dave Airlie wrote:
>
> 3 fixes, one for an ongoing Intel VT-d/Ironlake GPU that I've been
> testing, and one kexec fix from Jerome for an issue reported on the list
> where the gpu writeback engines need to be switched off, along with a
> trivial fix from Alex.
Qui
I haven't gotten one of these in a long time..
[89045.616347] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer
elapsed... GPU hung
[89045.616352] [drm] capturing error event; look for more information in
/debug/dri/0/i915_error_state
[89045.621818] [drm:i915_wait_request] *ERROR* i91
On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki wrote:
>
> Subject : [3.1-rc8 REGRESSION] sky2 hangs machine on turning off or
> suspending
> Submitter : Rafał Miłecki
> Date : 2011-11-09 11:46
> Message-ID :
> CACna6ryTdLcWVYgHu=_mrfga1sfivpe_dyzoy-hmmkggkwa...@mail.gmail.com
> Re
On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki wrote:
>
> Subject ? ?: [3.1-rc8 REGRESSION] sky2 hangs machine on turning off or
> suspending
> Submitter ?: Rafa? Mi?ecki
> Date ? ? ? : 2011-11-09 11:46
> Message-ID : CACna6ryTdLcWVYgHu=_mRFga1sFivpE_DyZOY-HMmKggkWAJAw at
> mail.gmail.com
>
On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki wrote:
>
> Subject : lockdep warning after aa6afca5bcab: "proc: fix races against
> execve() of /proc/PID/fd**"
> Submitter : Ari Savolainen
> Date : 2011-11-08 3:47
> Message-ID :
> caebykaxyzefhtgwmm2afawq2saxyuo_yptnw+6avwscoysc...
On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki wrote:
>
> Subject ? ?: lockdep warning after aa6afca5bcab: "proc: fix races against
> execve() of /proc/PID/fd**"
> Submitter ?: Ari Savolainen
> Date ? ? ? : 2011-11-08 3:47
> Message-ID : CAEbykaXYZEFhTgWMm2AfaWQ2SaXYuO_ypTnw+6AVWScOYSCuuw at
On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki wrote:
>
> Subject : hugetlb oops on 3.1.0-rc8-devel
> Submitter : Andy Lutomirski
> Date : 2011-11-01 22:20
> Message-ID :
> calcetrw1mpvcz2to5roaz1r6vnno+srhr-dha6_pkri2qic...@mail.gmail.com
> References : http://marc.info/?l=linux-k
On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki wrote:
>
> Subject ? ?: hugetlb oops on 3.1.0-rc8-devel
> Submitter ?: Andy Lutomirski
> Date ? ? ? : 2011-11-01 22:20
> Message-ID : CALCETrW1mpVCz2tO5roaz1r6vnno+srHR-dHA6_pkRi2qiCfdw at
> mail.gmail.com
> References : http://marc.info/?l=linu
On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki wrote:
>
> Subject : [3.1 REGRESSION] Commit 5cec93c216db77c45f7ce970d46283bcb1933884
> breaks the Chromium seccomp sandbox
> Submitter : Nix
> Date : 2011-11-14 0:40
> Message-ID : 8762inleno@spindle.srvr.nix
> References : http:/
On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki wrote:
>
> Subject ? ?: [3.1 REGRESSION] Commit 5cec93c216db77c45f7ce970d46283bcb1933884
> breaks the Chromium seccomp sandbox
> Submitter ?: Nix
> Date ? ? ? : 2011-11-14 0:40
> Message-ID : 8762inleno.fsf at spindle.srvr.nix
> References : htt
On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki wrote:
>
> Subject : Simultaneous cat and external keyboard input causing kernel panic
> Submitter : Timo Jyrinki
> Date : 2011-11-03 12:14
> Message-ID :
> CAJtFfxmovJHspHHKbvBVc4pw+u5mjGmUejCXEzdV+GqE=jv...@mail.gmail.com
> Reference
On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki wrote:
>
> Subject ? ?: Simultaneous cat and external keyboard input causing kernel panic
> Submitter ?: Timo Jyrinki
> Date ? ? ? : 2011-11-03 12:14
> Message-ID : CAJtFfxmovJHspHHKbvBVc4pw+u5mjGmUejCXEzdV+GqE=jVSOQ at
> mail.gmail.com
> Refere
Email sent to wrong people/list,
Linus
-- Forwarded message --
From: Alex Davis
Date: Tue, Nov 15, 2011 at 12:42 AM
Subject: [PATCH] i915: Fix bug where screen brightness is not restored
To: "linux-kernel at vger.kernel.org" ,
"torvalds at linux-foundation.org"
Fr
Email sent to wrong people/list,
Linus
-- Forwarded message --
From: Alex Davis
Date: Tue, Nov 15, 2011 at 12:42 AM
Subject: [PATCH] i915: Fix bug where screen brightness is not restored
To: "linux-ker...@vger.kernel.org" ,
"torva...@linux-foundation.org"
From: Al
Hmm, I don't know what caused this to trigger, but I'm adding both the
i915 people and the HDA people to the cc, and they can fight to the
death about this in the HDMI Thunderdome.
Guys: One.. Two.. Three.. FIGHT!
Linus
On Tue, Nov 8, 2011 at 6:55 AM, Nick Bowler wrote:
>
> Mod
Hmm, I don't know what caused this to trigger, but I'm adding both the
i915 people and the HDA people to the cc, and they can fight to the
death about this in the HDMI Thunderdome.
Guys: One.. Two.. Three.. FIGHT!
Linus
On Tue, Nov 8, 2011 at 6:55 AM, Nick Bowler wrote:
>
> Mod
On Mon, Nov 7, 2011 at 5:27 AM, Dave Airlie wrote:
>
> are available in the git repository at:
>
> ssh://people.freedesktop.org/~/linux drm-fixes
No they are *not* available there.
Fix your pull script already! I mentioned this once earlier, your pull
requests are wrong, and point to things tha
On Mon, Nov 7, 2011 at 5:27 AM, Dave Airlie wrote:
>
> are available in the git repository at:
>
> ?ssh://people.freedesktop.org/~/linux drm-fixes
No they are *not* available there.
Fix your pull script already! I mentioned this once earlier, your pull
requests are wrong, and point to things tha
On Thu, Sep 29, 2011 at 6:18 PM, Keith Packard wrote:
>
> Here are three tiny patches, two new bug fixes and one regression fix
> that disables FBC on Ironlake and older chips.
So I got this error notice at bootup with the current -git tree.
Everything seems to work despite it, but I thought I'd
On Thu, Sep 29, 2011 at 6:18 PM, Keith Packard wrote:
>
> Here are three tiny patches, two new bug fixes and one regression fix
> that disables FBC on Ironlake and older chips.
So I got this error notice at bootup with the current -git tree.
Everything seems to work despite it, but I thought I'd
On Tue, Oct 4, 2011 at 9:34 AM, Dave Airlie wrote:
>
> all radeon fixes, one nasty startup crash and/or memory corruption on one
> family of radeon hd6450s resulted in a patch to stop setting a bunch of
> regs in the drivers and let the BIOS set them correctly, displayport
> regression fix, and so
On Tue, Oct 4, 2011 at 9:34 AM, Dave Airlie wrote:
>
> all radeon fixes, one nasty startup crash and/or memory corruption on one
> family of radeon hd6450s resulted in a patch to stop setting a bunch of
> regs in the drivers and let the BIOS set them correctly, displayport
> regression fix, and so
On Sun, Aug 28, 2011 at 12:35 PM, Dave Jones wrote:
> On Sun, Aug 28, 2011 at 08:22:05PM +0200, Rafael J. Wysocki wrote:
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=41742
> > Subject : duplicate filename for intel_backlight with the
> i915 driver
> > Submitter
On Sun, Aug 28, 2011 at 12:35 PM, Dave Jones wrote:
> On Sun, Aug 28, 2011 at 08:22:05PM +0200, Rafael J. Wysocki wrote:
>
> ?> Bug-Entry ? ?: http://bugzilla.kernel.org/show_bug.cgi?id=41742
> ?> Subject ? ? ? ? ? ? ?: duplicate filename ?for intel_backlight with the
> i915 driver
> ?> Submitter
On Tue, Jul 12, 2011 at 11:15 AM, Oleg Nesterov wrote:
>
> I tried many times to ask about the supposed behaviour of
> block_all_signals() in drm, but it seems nobody can answer.
It's always been broken, I think. We've had threads about it before
(years and years ago). I'd certainly be willing to
On Tue, Jul 12, 2011 at 11:15 AM, Oleg Nesterov wrote:
>
> I tried many times to ask about the supposed behaviour of
> block_all_signals() in drm, but it seems nobody can answer.
It's always been broken, I think. We've had threads about it before
(years and years ago). I'd certainly be willing to
On Tue, May 24, 2011 at 10:36 AM, H. Peter Anvin wrote:
>
> I think this whole discussion misses the essence of the new development
> model, which is that we no longer do these kinds of feature-based major
> milestones.
Indeed.
It's not about features. It hasn't been about features for forever.
On Tue, May 24, 2011 at 10:36 AM, H. Peter Anvin wrote:
>
> I think this whole discussion misses the essence of the new development
> model, which is that we no longer do these kinds of feature-based major
> milestones.
Indeed.
It's not about features. It hasn't been about features for forever.
Another advantage of switching numbering models (ie 3.0 instead of
2.8.x) would be that it would also make the "odd numbers are also
numbers" transition much more natural.
Because of our historical even/odd model, I wouldn't do a 2.7.x -
there's just too much history of 2.1, 2.3, 2.5 being develop
Another advantage of switching numbering models (ie 3.0 instead of
2.8.x) would be that it would also make the "odd numbers are also
numbers" transition much more natural.
Because of our historical even/odd model, I wouldn't do a 2.7.x -
there's just too much history of 2.1, 2.3, 2.5 being develop
On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote:
>
> I really hope there's also a voice that tells you to wait until .42 before
> cutting 3.0.0! :-)
So I'm toying with 3.0 (and in that case, it really would be "3.0",
not "3.0.0" - the stable team would get the third digit rather than
the four
On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote:
>
> I really hope there's also a voice that tells you to wait until .42 before
> cutting 3.0.0! :-)
So I'm toying with 3.0 (and in that case, it really would be "3.0",
not "3.0.0" - the stable team would get the third digit rather than
the four
So I've been busily merging stuff, and just wanted to send out a quick
reminder that I warned people in the 39 announcement that this might
be a slightly shorter merge window than usual, so that I can avoid
having to make the -rc1 release from Japan using my slow laptop (doing
"allyesconfig" builds
So I've been busily merging stuff, and just wanted to send out a quick
reminder that I warned people in the 39 announcement that this might
be a slightly shorter merge window than usual, so that I can avoid
having to make the -rc1 release from Japan using my slow laptop (doing
"allyesconfig" builds
501 - 600 of 745 matches
Mail list logo
