On Wed, Oct 3, 2012 at 9:08 PM, Dave Airlie wrote:
>
> So this pull is for my drm-next-merged branch which is my drm-next branch
> merged with your tree, and some fixups applied to the merge.
Ok, as usual I actually wanted to do the merge myself despite the
annoying conflicts (this *really* is th
Added more appropriate people to this. Added both i915 and nouveau
people, since apparently that fine piece of hardware has both.
Guys, any ideas?
Paweł, could you perhaps get a photo of the oops and post it
somewhere? I'm assuming the oops happens early during boot and you
never get a usable mac
On Fri, Oct 19, 2012 at 3:41 PM, Martin Peres wrote:
>
> You must have missed the oops that was attached to the mail:
> http://www.spinics.net/lists/kernel/msg1420355.html
I did indeed. So never mind about that dmesg request, Paweł ;-p
> Paweł, could you try the attached patch please ?
Thanks f
On Sun, Oct 21, 2012 at 5:09 AM, Marcin Slusarz
wrote:
>
> This looks like ACPI bug...
I'm _shocked_ to hear that firmware would be fragile.
Anyway, here's the #1 thing to keep in mind about firmware:
- firmware is *always* buggy.
It's that simple. Don't expect anything else. Firmware is writ
On Sun, Oct 21, 2012 at 5:49 PM, Marcin Slusarz
wrote:
>
> I know. But this bug is not about broken firmware. It's about Linux kernel
> ACPI implementation, which (I think) wrongly interprets ACPI script.
Hmm. Len, care to comment? Marcin quoted the AML and our arguments in
an earlier thing. I do
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 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 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
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
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
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 : [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 : 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 : 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 : [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 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: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 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 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 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 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 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 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 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 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 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
>
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 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 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 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 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
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
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
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
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 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.
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 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 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 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: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 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
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 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:
>
> 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: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 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 Sat, Feb 16, 2013 at 1:45 PM, Hugh Dickins wrote:
>
> I hacked around on your PM_TRACE set_magic_time() / read_magic_time()
> yesterday, to save an oopsing core kernel ip there, instead of hashed
> pm trace info (it makes sense in this case to invert your sequence,
> putting the high order into
On Mon, Feb 25, 2013 at 4:05 PM, Dave Airlie wrote:
>
> So up front, this has a massive merge conflict in
> drivers/gpu/drm/radeon/evergreen_cs.c I've fixed it up in drm-next-merged
> in the same tree, I fixed up some small ordering issues in my merge as
> well, however they aren't important if yo
On Mon, Feb 25, 2013 at 4:05 PM, Dave Airlie wrote:
>
> Highlights:
>
> i915: all over the map, haswell power well enhancements, valleyview macro
> horrors cleaned up, killing lots of legacy GTT
> code,
Lowlight:
There's something wrong with i915 DP detection or whatever. I get
stuff like this:
On Tue, Feb 26, 2013 at 5:39 PM, Linus Torvalds
wrote:
>
> Lowlight:
>
> [5.710827] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
> signal timeout (has irq: 1)!
Oh, forgot to mention - this is my trusty old Westmere chip (aka "Core
i5-670", aka Clarkdale, a
On Tue, Feb 26, 2013 at 7:30 PM, Dave Airlie wrote:
>
> If you want to just bump it so Ironlake isn't affected, (patch attached).
It works fine 95% of the time and isn't a hard failure when it
doesn't, so this isn't critical. I can wait for it to be fixed a
while.
> Is this external DP monitor o
On Fri, Apr 19, 2013 at 2:09 PM, Sedat Dilek wrote:
>
> I have applied all three patches and see still call-traces.
> New are apparmor related messages.
Can you try the crazy rcu double-free debug hack?
See
https://lkml.org/lkml/2013/3/30/113
and I'm re-attaching the ugly-ass crazy hack pa
On Fri, Apr 19, 2013 at 3:34 PM, Sedat Dilek wrote:
>
> See attached dmesg.
This still has the bug Davidlohr pointed at:
>> This looks like what Emmanuel was/is running into:
>> https://lkml.org/lkml/2013/3/30/1
you need to move the "IS_ERR()" check before the sem_lock.
Linus
___
On Fri, Apr 19, 2013 at 3:55 PM, Sedat Dilek wrote:
>
> Davidlohr pointed to this patch (tested the triplet):
>
> ipc, sem: do not call sem_lock when bogus sma:
> https://lkml.org/lkml/2013/3/31/12
>
> Is that what you mean?
Yup.
Linus
___
dri-deve
On Thu, Jun 6, 2013 at 2:14 PM, Dave Airlie wrote:
>
> 7 files changed, 32 insertions(+), 42 deletions(-)
That's not at all what I get (including shortlog). I got
29 files changed, 188 insertions(+), 68 deletions(-)
from a lot of commits you don't list.
Linus
__
On Sat, Jun 29, 2013 at 8:05 AM, Sergey Meirovich wrote:
>
> 3.10-rc7 doesn't compile for me
>
> rathamahata@piledriver /usr/local/src/linux-3.10-rc7 $ make -j1 bzImage
> modules
> make[1]: Nothing to be done for `all'.
> make[1]: Nothing to be done for `relocs'.
> CHK include/generated/uap
On Sat, Jun 29, 2013 at 2:07 PM, Sergey Meirovich wrote:
>> (and possibly the
>> mkregtable binary) and trying again might fix it.
>
> Removing mkregtable has indeed the compile issue for me. Thanks!
Ok, so something failed at an earlier build. That error is probably
long gone, though, since the
On Sat, Jun 29, 2013 at 4:52 PM, Sergey Meirovich wrote:
>
> There was overheating issue, that caused forced power off in the
> middle of the first compile.
Ok, then the thing is easily explained by simply the filesystem being
shut down in an incomplete state. Sounds like the mkregtable binary
ha
On Mon, Apr 4, 2011 at 6:02 PM, Keith Packard wrote:
> On Tue, 5 Apr 2011 01:38:31 +0100 (IST), Dave Airlie wrote:
>
>> drm/i915: Reset GMBUS controller after NAK
>
> We've got a report of a regression from this patch and have a fix in
> review right now. Please don't merge this to master u
On Wed, Apr 13, 2011 at 1:48 PM, Yinghai Lu wrote:
>
> can you try following change ? it will push gart to 0x8000
>
> diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
> index 86d1ad4..3b6a9d5 100644
> --- a/arch/x86/kernel/aperture_64.c
> +++ b/arch/x86/kernel/apertur
On Wed, Apr 13, 2011 at 2:23 PM, Yinghai Lu wrote:
>>
>> What are all the magic numbers, and why would 0x8000 be special?
>
> that is the old value when kernel was doing bottom-up bootmem allocation.
I understand, BUT THAT IS STILL A TOTALLY MAGIC NUMBER!
It makes it come out the same ON THA
On Wednesday, April 13, 2011, H. Peter Anvin wrote:
>
> Yes. However, even if we *do* revert (and the time is running short on
> not reverting) I would like to understand this particular one, simply
> because I think it may very well be a problem that is manifesting itself
> in other ways on othe
On Wednesday, April 13, 2011, Linus Torvalds
wrote:
> On Wednesday, April 13, 2011, H. Peter Anvin wrote:
>>
>> Yes. However, even if we *do* revert (and the time is running short on
>> not reverting) I would like to understand this particular one, simply
>> because
On Mon, Apr 18, 2011 at 1:02 PM, Marcin Slusarz
wrote:
>
> It's some nasty corruption:
Looks like something wrote 0x to free'd memory.
Enabling DEBUG_PAGEALLOC *might* show where it happens.
>
> [ 6.523867]
> ==
On Sat, Apr 30, 2011 at 12:42 PM, Rafael J. Wysocki wrote:
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=34012
> Subject : 2.6.39-rc4+: oom-killer busy killing tasks
> Submitter : Christian Kujau
> Date : 2011-04-22 1:57 (9 days old)
> Message-ID :
On Wednesday, April 13, 2011, Linus Torvalds
wrote:
> On Wednesday, April 13, 2011, H. Peter Anvin wrote:
>>
>> Yes. However, even if we *do* revert (and the time is running short on
>> not reverting) I would like to understand this particular one, simply
>> because
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
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
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 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, 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 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 Wed, Nov 10, 2010 at 4:24 PM, Dave Airlie wrote:
>
> I've started taking Chris's pull requests now, so all the intel drm
> changes should start coming via my tree always now, unless they are pretty
> exceptional or I'm away.
Btw, Chris - don't do this:
commit 08deebf98783d3de553eed2c9b6b8dc
On Fri, Nov 12, 2010 at 9:21 AM, Chris Wilson wrote:
>
> My bad, I cherry-picked it from our public drm-intel-next tree and thought
> it wise to include the cross-reference to explain the duplication and
> merge conflicts and to provide some additional test history into the commit.
> Obviously not
On Thu, Nov 18, 2010 at 3:34 PM, Jan Kara wrote:
>
> Just for info, UDF BKL removal patches seem to work fine but I want to
> give them some final SMP testing on Monday before pushing them to -next.
> I'm not sure how much people hurry with disabling the lock so if I should
> push them ASAP or wh
On Fri, Nov 19, 2010 at 2:02 AM, Chris Wilson wrote:
>
> Note it also contains a couple of fluff fallout patches from the recent
> drm-fixes rebase. (I thought it would be wise to include any core drm
> changes in our testing before sending the request...)
F*%^ me, why does drm always have to be
On Fri, Nov 19, 2010 at 12:24 PM, Dave Airlie wrote:
>
> I also wonder if its partly psychological on your part, if I sent a
> number of smaller pull requests rather than queuing up things would
> you notice the line count less? If Chris sends things direct to you
> instead of me merging them and
On Wed, Dec 22, 2010 at 8:59 AM, Chris Wilson wrote:
> On Wed, 22 Dec 2010 17:24:36 +0100, Takashi Iwai wrote:
>> The commit 448f53a1ede54eb854d036abf54573281412d650
>> drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks
>>
>> causes a regression on a SandyBridge machine here.
>> The laptop
On Thu, Dec 23, 2010 at 1:32 AM, Alex Riesen wrote:
> On Thu, Dec 23, 2010 at 04:54, Linus Torvalds
> wrote:
>> Why does that code need to figure out some LVDS clock from the BIOS?
>> Why can't the code look at the actual hardware state or similar, since
>> presumabl
On Wed, Dec 29, 2010 at 10:21 AM, Randy Dunlap wrote:
>
> The only significant difference that I can see in the kernel message log
> is this:
Hmm. I suspect that difference should have gone away with commit
92971021c6328 (Revert "drm: Don't try and disable an encoder that was
never enabled"), but
On Thu, Jan 6, 2011 at 2:48 AM, Michal Hocko wrote:
>
> It seems that there is still a regression for intel graphic cards
> backlight. One report is https://bugzilla.kernel.org/show_bug.cgi?id=22672.
> I can reproduce the problem easily by:
> xset dpms force standby; sleep 3s; xset dpms force on
>
On Mon, Jan 10, 2011 at 2:59 PM, Dave Airlie wrote:
> Highlights:
> core/drivers: add support for high precision vblank timestamps
> radeon: pageflipping support, Gen2 PCIE support
> nouveau: reworked VRAM and VM support
> intel: better ILK/SNB powersaving support, Full GTT support
Lowlights: it'
On Mon, Jan 10, 2011 at 10:06 PM, Jesse Barnes wrote:
>
> Arg. It's been ok on my ILK systems, but Chris has found some issues with
> out watermarking code iirc; apparently we're underflowing the display FIFO,
> causing all sorts of trouble. If it works before the pull of Dave's tree,
> can y
On Tue, Jan 11, 2011 at 8:01 AM, Linus Torvalds
wrote:
>
> But yes, it worked before pulling Dave's tree, IOW, I haven't seen
> this message on this machine before.
.. and it's not a fluke. It happened again, and once more while I was
away from the machine and the screen
On Tue, Jan 11, 2011 at 11:12 AM, Jesse Barnes wrote:
>
> Have you tried reproducing it using xset dpms force off or similar?
That doesn't seem to do anything bad.
In fact, I think the second time it happened the screen never went
black - just the random photo thing was on. But no, forcing the s
On Tue, Jan 11, 2011 at 11:45 AM, Jesse Barnes wrote:
>>
>> Maybe the screen just has to be inactive for a longer time: do you do
>> some dynamic "let's power things down if nothing is changing"?
>
> There are some timeouts, the FBC engine will recompress about once
> every 15s; the self-refresh t
On Tue, Jan 11, 2011 at 11:25 AM, Linus Torvalds
wrote:
>
> Maybe the screen just has to be inactive for a longer time: do you do
> some dynamic "let's power things down if nothing is changing"?
So since this is _almost_ reproducible for me, I tried bisecting it.
The
On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds
wrote:
>
> I'll test the merge, but I thought I'd send out this note already at
> this point, because I'm pretty sure this is it.
Hmm. The merge already has the *ERROR* Hangcheck (together with jerky
behavior), so it was
On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger
wrote:
>
> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA
> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1))
> During startup the framebuffer shows only stripes and a blank
> screen after suspend
On Tue, Jan 11, 2011 at 3:01 PM, Linus Torvalds
wrote:
>
> ... I'll test that drm-intel-staging commit.
Initial testing _seems_ to confirm that merging drm-intel-staging gets
rid of the problem. But I haven't spent a whole lot of time in the
screen saver. Will start driving kid
On Wed, Jan 12, 2011 at 5:32 AM, James Simmons wrote:
>
> Okay. The nouveau driver also uses the pitch as well. It
> really should be using the pitch field from drm_framebuffer instead of the
> line_length from fb_fix_screeninfo. This patch is just to make sure this
> is the issue. I will submit a
On Tue, Jan 11, 2011 at 10:03 PM, Dave Airlie wrote:
>
> I'm stuck at home with just my i5 laptop due to the office being shut due
> to the ongoing floods. But I've booted and ran this for a few hours and it
> seems to be better than the current tree. It contains a couple of patches
> to fix DMAR
On Wed, Jan 12, 2011 at 11:46 AM, Jesse Barnes wrote:
>
> Since I doubt we're actually offloading to our video decode kernels for
> Flash video on your machine
It's the latest 64-bit beta flash player, so maybe it does use hw acceleration.
> it could very well be a memory
On Wed, Jan 12, 2011 at 12:27 PM, Linus Torvalds
wrote:
> On Wed, Jan 12, 2011 at 11:46 AM, Jesse Barnes
> wrote:
>>
>> Since I doubt we're actually offloading to our video decode kernels for
>> Flash video on your machine
>
> It's the latest 64-bit be
On Wed, Jan 12, 2011 at 1:28 PM, Linus Torvalds
wrote:
>
> Oh, and I'm also seeing corruption on my sandybridge machine. No video
> involved, the gdm login screen is already corrupted this way. Similar
> odd shifted lines etc, so I'd assume it's related.
Hmm. I bi
On Wed, Jan 12, 2011 at 2:22 PM, Jesse Barnes wrote:
>
> Ah, ok. So it could be our internal FDI link is underrunning; it goes
> between the CPU and PCH and carries display bits.
I'm not sure it's an underrun or anything like that: the corruption is
long-term in the non-video case. So I take bac
On Sun, Jan 16, 2011 at 12:00 PM, Anca Emanuel wrote:
>
> In 2.6.37-git5 with the revert, the boot screen is changing the resolution.
> With this version, it don't.
So, can you make a nice report of that - along with 'dmesg' for _both_
cases - to the right people?
In this case, that would be at
On Sun, Jan 16, 2011 at 3:44 PM, Ben Skeggs wrote:
>
> I've tested a bit here, current git with the revert does appear to work
> fine for me.
So Anca has a 8800GT - is that what you're testing?
Also, there may be things like FB config issues and/or kernel command
line arguments. For example, on
Ok, so I have a new issue that I'm currently bisecting but that people
may be able to figure out even befor emy bisect finishes.
On my slow Atom netbook (that I'm planning on using as my traveling
companion for LCA), suspend-to-RAM takes a long time with current git.
It's quite noticeable - it use
401 - 500 of 765 matches
Mail list logo
