On Wed, Aug 12, 2015 at 12:35 PM, Linus Torvalds
wrote:
>
> Generally, the preferred model is:
>
> - strive to base your development on a well-characterized base (for
> example, a previous release), and _stay_ on that base (ie don't get
> distracted by what other unrelated de
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
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*
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
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 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
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 machine as
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
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
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.
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
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
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 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
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
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 worry ab
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
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
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
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
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.
On Wed, Nov 21, 2012 at 6:34 PM, Dave Airlie wrote:
>
> its vmware/nouveua/radeon/intel/ttm scattered.
Hmm. That's not what I see. I just see nouveau and soem PCI ID addition.
> 21 files changed, 108 insertions(+), 31 deletions(-)
I get
14 files changed, 70 insertions(+), 21 deletions(-)
[ Hmm. For some reason this seems to have never gone out, and was in
my drafts folder. If you get it twice, my bad ]
On Thu, Nov 22, 2012 at 12:57 AM, Dave Airlie wrote:
>
> Doh!, yes I picked wrong place to generate report from, okay here is
> one corresponding to what you saw,
You should
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
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
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
Dave, mind sending me a pull request for drm fixes?
There's now at least these two:
- "drm/radeon/aux: fix hpd assignment for aux bus"
- "drm/radeon: use fixed PPL ref divider if needed"
that look like fairly fatal regressions when they affect somebody.
The fact that we already had *two*
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
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
[ 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
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
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
This one may have been going on for some time - I haven't updated the
old Intel Mac Mini in a while.
And by "not updated" I also mean that it's some really old user-space:
the machine is running F14, and cannot be updated to anything newer
without having to reinstall everything because of a
On Sat, Aug 3, 2013 at 6:08 PM, Dave Airlie wrote:
>
> Alex Deucher (1):
> drm/radeon: fix 64 bit divide in SI spm code
That code is stupid. You're asking for a 64-by-64 divide, when the
divisor is clearly an "int" (100 and 1000 respectively).
Why is it doing "div64_s64()" instead of the
On Fri, Aug 2, 2013 at 2:26 AM, Ville Syrj?l?
wrote:
>
> Looks like this could happen when you go to DPMS_OFF. After we've turned
> off the the pipe, get_pipe_config() gives a mostly zeroed pipe_config
> (including pixel_multiplier), and then in the case of SDVO, we go and
> check it against the
On Tue, Dec 17, 2013 at 4:33 PM, Dave Airlie wrote:
>
> are available in the git repository at:
>
> git://people.freedesktop.org/~airlied/linux
Nope.
I assume you meant the 'drm-fixes' branch, but you didn't actually
*say* that, and when I pull it I don't get the same diffstat you
claim, so
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
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
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
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
On Thu, Jan 24, 2013 at 4:42 PM, Dave Airlie wrote:
>
> These patches have been sailing around long enough, waiting for a maintainer
> to reappear, so I've decided enough is enough, lockdep is kinda useful to
> have.
Last this was tried, these patches failed miserably.
They caused instant
On Thu, Jan 24, 2013 at 5:45 PM, Dave Airlie wrote:
>
> Okay I've just sent out another fbcon patch to fix the locking harder.
>
> There was a path going into set_con2fb_path if an fb driver was
> already registered, I just pushed the locking out further on anyone
> going in there.
>
> it boots
On Thu, Jan 31, 2013 at 9:19 AM, Russell King wrote:
>
> So... what you seem to be telling me is that 3.9 is going to be a
> release which issues lockdep complaints when the console blanks, and
> you think that's acceptable?
>
> Adding Linus and Andrew so they're aware of this issue...
Oh, we're
On Thu, Jan 31, 2013 at 11:13 AM, Russell King wrote:
>
> Which may or may not be a good thing depending how you look at it; it
> means that once your kernel blanks, you get a lockdep dump. At that
> point you lose lockdep checking for everything else because lockdep
> disables itself after the
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 at 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
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
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
On Thu, Dec 10, 2015 at 10:58 PM, Dave Airlie wrote:
>
> So since Xmas is coming up and I've got an impending new arrival, I'm
> betting this merge window might get a bit haphazard. So I'd like
> people to start telling me now via git pull's what they'd like to get
> in.
So the rest of the world
On Wed, Dec 23, 2015 at 2:40 AM, Jani Nikula wrote:
>
> Hi Dave (and/or Linus, depending on the new arrival and eggnog
> schedules) -
I'll pull it directly. Dave just sent me his pending drm fixes, he may
or may not be around any more, it's already christmas eve down under.
Linus
On Wed, Dec 23, 2015 at 2:40 AM, Jani Nikula wrote:
>
>
> git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2015-12-23
Btw, since you're already using tags, mind using *signed* tags
instead? It's just good housekeeping..
Linus
On Mon, Sep 7, 2015 at 9:56 PM, Dave Airlie wrote:
>
> i.e. 59 commits in a 5000 commit tree is likely not that bad, 59
> commits in a 20 commit tree would be bad.
I think it's about size of the commits. If it's 59 clean oneliner
fixes, I don't think it's a big deal. If it's 59 patches that add
On Fri, Jun 26, 2015 at 1:37 PM, Dave Airlie wrote:
>
> No generally Linus likes to do his own merges with hints from us.
>
> unless it's really tricky.
Yup. And this time all the merges were trivial. My merge ended up
differing from Dave's simply because of an ordering of statements that
could
On Thu, Jun 25, 2015 at 6:00 PM, Dave Airlie wrote:
>
> This is the main drm pull request for v4.2.
It seems to work ok for me, but it causes quite a few new warnings on
my Sony VAIO Pro laptop. It's (once more) a regular i5-4200U CPU (aka
Haswell, aka 4th gen Intel Core i5)
Most of them are in
On Sat, Feb 28, 2015 at 11:27 PM, Linus Torvalds
wrote:
>
> I'll try to narrow it down at least a *bit* more, even if it's a
> painfully slow machine.
It was brought in by either
Merge tag 'topic/atomic-core-2015-01-05'
or
Merge tag 'topic/core-stuff-2014-12-19'
with the ato
On Sun, Mar 1, 2015 at 12:35 PM, Linus Torvalds
wrote:
>
> The compiles should be going faster now that I'm getting closer, so
> I'll have a tighter bisect soon. Knock wood.
Grr.
I found:
ccfc08655d5fd5076828f45fb09194c070f2f63a is the first bad commit
but that boot failure is a
On Sun, Mar 1, 2015 at 1:00 PM, Linus Torvalds
wrote:
>
> Back to the drawing board.
Ok, many hours later, but I found it.
The bisection was a disaster, having to work around other bugs in this
area, but it ended up getting "close enough" that I figured out
On Mon, Mar 2, 2015 at 1:04 AM, Daniel Vetter wrote:
>
> And can you please attach a bactrace of the WARN in your patch, just to
> double-check you blow up at the same spot?
So the dmesg I attached had a backtrace for the new WARN_ONCE() (in
addition to an unrelated(?) one from
On Tue, Mar 3, 2015 at 8:31 AM, Daniel Vetter wrote:
>
> Fix this all by applying the same duct-tape as for the legacy setcrtc
> ioctl code and set crtc->primary->crtc properly.
Ack. Tests fine on the machine that showed issues for me.
I'll apply it manually directly to my tree, since I want to
On Tue, Mar 3, 2015 at 9:11 AM, Daniel Vetter wrote:
>
> Fine with me. If you haven't pushed out yet can you maybe clarify the
> commit message?
Oh well. I already applied and tagged it, so it's what it is..
Linus
On Fri, Mar 20, 2015 at 2:49 PM, Dave Airlie wrote:
>
> In other news I've some problem with my git tree and git request-pull
> [airlied at dreadlord-bne-redhat-com linux]$ git request-pull linus/master
> origin
>
> warn: No match for commit 8265d4486d5c2448a1c645fdc20d4e62873d9c3d found at
>
drm/i915: Don't try to reference the fb in get_initial_plane_config()
On Mon, Mar 23, 2015 at 7:11 PM, Dave Airlie wrote:
>
> a few people reported an oops that looks to be fixed in drm-next already,
> so I've pulled the patch back.
Hmm. At least from Josh's report, he also needs
On Wed, Nov 18, 2015 at 12:29 AM, Jani Nikula
wrote:
> On Tue, 17 Nov 2015, Daniel Vetter wrote:
>>
>> Imo revert. With all the QA awol fail we've suffered the past few
>> months we've become a bit too lax imo with reverting fast, and the
>> point of the split-out commit was to allow exactly
On Thu, Nov 19, 2015 at 8:07 PM, Dave Airlie wrote:
>
> core: Atomic fixes and Atomic helper fixes
> i915: Revert for the backlight regression along with a bunch of fixes.
So I have no idea if the GPU updates are my problem, but my main
desktop machine has been hanging silently a few times
On Sun, Nov 29, 2015 at 11:33 PM, Daniel Vetter wrote:
>
> Yeah I just hunted down a test infrastructure failure on my Haswell the
> past few days with various loads and output configs. Seemed very happy.
> And not aware of anything else blowing up (bdw/skl would be less
> surprising).
So I'm
On Wed, Jan 28, 2015 at 8:11 PM, Dave Airlie wrote:
>
> Linus, this came up a while back I finally got some confirmation
> that it fixes those servers.
I'm certainly ok with this. which way should it go in? The users are:
- drivers/tty/vt/vt.c (Greg KH, "tty layer")
- drivers/video/console/*
On Thu, Jan 29, 2015 at 3:57 PM, Greg Kroah-Hartman
wrote:
>
> I can take this through the tty tree, but can I put it in linux-next and
> wait for the 3.20 merge window to give people who might notice a
> slow-down a chance to object?
Yes. The problem only affects one (or a couple of) truly
On Sun, Jul 12, 2015 at 1:03 AM, Jörg Otte wrote:
>
> BUG: unable to handle kernel NULL pointer dereference at 0009
> IP: [] 0xbd3447bb
Ugh. Please enable KALLSYMS to get sane symbols.
But yes, "crtc_state->base.active" is at offset 9 from "crtc_state",
so it's pretty
On Wed, Jul 29, 2015 at 6:39 PM, Theodore Ts'o wrote:
>
> It's here: https://goo.gl/photos/xHjn2Z97JQEw6k2C9
You didn't catch enough of the code line to decode the code, but it's
early enough in drm_crtc_index() (just five bytes in) that it's almost
certainly the very first dereference, so it's
On Thu, Jul 30, 2015 at 8:57 AM, Takashi Iwai wrote:
> On Thu, 30 Jul 2015 17:32:28 +0200,
> Theodore Ts'o wrote:
>>
>> BTW, is there any chance that I can suspend my laptop, and then move
>> it from my docking station at home (where I have a Dell 30" display)
>> to my docking station at work
On Fri, Jul 31, 2015 at 9:54 AM, Daniel Vetter
wrote:
>
> I delayed my -fixes pull a bit hoping that I could include a fix for the
> dp mst stuff but looks a bit more nasty than that. So just 3 other
> regression fixes, one 4.2 other two cc: stable.
Quick question: you can now reproduce the mst
On Fri, Jun 5, 2015 at 11:58 PM, Dave Airlie wrote:
>
> i915 has a bunch of fixes [..]
.. but nof ix for the regression that Stefan Lippers-Hollmann
reported? An oops in intel_modeset_update_connector_atomic_state() due
to commit 08d9bc920d46 ("drm/i915: Allocate connector state together
with
On Sun, Feb 15, 2015 at 10:43 PM, Dave Airlie wrote:
>
> This is the main drm pull, it has a shared branch with some alsa crossover
> but everything should be acked by relevant people.
Ugh. Your diffstat is crap, because you don't show the inexact renames
that are very abundant in the nouveau
On Fri, Feb 20, 2015 at 8:27 AM, Sumit Semwal
wrote:
>
> Could you please pull a few dma-buf changes for 3.20-rc1? Nothing
> fancy, minor cleanups.
No.
I pulled, and immediately unpulled again.
This is complete shit, and the compiler even tells you so:
drivers/staging/android/ion/ion.c:
Hmm. I haven't updated the old Mac Mini I have in a *long* time, but
today I decided to try.
And it causes problems in drm.
I'm not sure how new these problems are, I think the previous kernel I
booted on this machine was 3.16. But I thought I'd better report them
as-is, because bisection on
On Sat, Feb 28, 2015 at 9:40 PM, Linus Torvalds
wrote:
>
> I'm not sure how new these problems are, I think the previous kernel I
> booted on this machine was 3.16.
Hmm. 3.19 works fine, even if it ends up spewing
WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/drm_irq.c:1121
drm_wait_o
On Sat, Feb 28, 2015 at 10:08 PM, Linus Torvalds
wrote:
>
> I'll see how painful it is to bisect it,
Not surprisingly, it went right for the drm merge.
Commit 8c334ce8f0fe ("Merge branch 'timers-core-for-linus'..") is
good, while the next merge commit 796e1c55717e ("M
So my el-cheapo UHD Dell monitor is unhappy with dmps, and just never
wakes up from it.
I work around it with just doing "xset -dpms" and it's not a big deal,
but I thought I'd report it anyway, since there are actual debug
messages, and maybe there's a better way to handle it. Does anybody
have
On Tue, Jan 6, 2015 at 10:21 PM, Robert Morell wrote:
>
> FWIW, I've seen that exact symptom on some monitors when the +5V pin on
> the DVI or HDMI cable from the GPU isn't enabled (or isn't providing
> enough current). Some monitors power the i2c/edid/DDC logic from that
> +5V either
On Tue, Jan 6, 2015 at 11:32 PM, Daniel Vetter wrote:
>
> Yeah if the edid probe fails userspace will get a hotplug and
> autodisable the output. With a failsafe X session (just a dumb
> terminal) we can avoid that to check that dpms on itself would work or
> whether the edid probe fail here is
On Wed, Jan 7, 2015 at 9:51 AM, Daniel Vetter wrote:
>
> Not sure whether that'd be the same voltage rails, but
> i915.disable_power_wells=0 disable all the runtime pm we do (which
> does kick in for dpms off and shut down the entire display block and a
> bunch more)
I still get the "No HDMI
On Mon, Jan 26, 2015 at 6:06 PM, Dave Airlie wrote:
>
> are available in the git repository at:
>
> git://people.freedesktop.org/~airlied/linux drm-fixes
No they aren't, actually, because you've screwed up your repository.
It looks like you were using an alternates that has gone away:
On Tue, Mar 24, 2015 at 5:04 PM, Dave Airlie wrote:
>
> Yes, Daniel indicated to Jani this morning we should pull this, so
> I'll sidestep the middle man here for expediency.
I'm going to wait a bit more with this, since clearly things are still
in flux, and these two commits don't actually fix
On Wed, Mar 25, 2015 at 3:43 PM, Linus Torvalds
wrote:
>
> I'm going to wait a bit more with this, since clearly things are still
> in flux, and these two commits don't actually fix everything at all.
>
> There's apparently at least one more fix necessary.
Indeed. I can see the
On Thu, May 21, 2015 at 8:39 PM, Dave Airlie wrote:
>
> radeon has two displayport fixes, one for a regressions,
> i915 regression flicker fix needed to 4.0 can get fixed.
Ok, I'm used to fixing up your whitespace and lack of capitalization,
but you're getting so incoherent that I can no longer
On Fri, May 22, 2015 at 4:20 PM, Dave Airlie wrote:
>
> Really ^to^so
Ahh. That simple one-letter substitution makes all the difference, now
it's suddenly parseable.
Thanks,
Linus
This thing isn't repeatable, and it can go days without happening, but
it has happened several times now over the last several weeks, to the
point where it is very annoying.
I get:
[drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
[drm] capturing error event; look for
tion.
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 holler.
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
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() (about
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=9292f37e1f5c79400254dca46f83313488093825
> from Dave's drm-next?
>
> If it has, it would be the 1st time that I see xrandr
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
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
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
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
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
> ?>
201 - 300 of 709 matches
Mail list logo
