On Tue, Aug 3, 2010 at 12:25 AM, Chris Wilson
wrote:
> On Mon, 2 Aug 2010 16:55:03 -0700, Andrew Morton linux-foundation.org> wrote:
>>
>> (switched to email. ?Please respond via emailed reply-to-all, not via the
>> bugzilla web interface).
>>
>> On Sun, 1 Aug 2010 08:55:49 GMT
>> bugzilla-daemo
I started wondering why 'top' was showing an otherwise idle system as
having a load average of 0.5+, and worker threads constantly using the
CPU.
So I did a system-wide profile, and got the attached output (look at
it in a really wide terminal).
There seems to be something _seriously_ wrong with
On Sun, Aug 15, 2010 at 8:30 PM, Dave Airlie wrote:
>
> At least we should replace mdelay with msleep in those functions.
How precise does the timing have to be? I think i2c is self-clocking,
so it's ok to see big skews? Becuase msleep() can be off by quite a
bit (mdelay can too, but it's _way_ m
On Sun, Aug 15, 2010 at 9:06 PM, Andy Lutomirski wrote:
>
> You might be hitting the infamous hotplug storm [1]. ?The symptoms vary by
> kernel version.
Hmm. I don't think it's a storm. The drm.debug=4 thing shows things
just every 10 seconds. That seems pretty controlled.
Of course, it seems to
On Sat, Feb 12, 2011 at 11:53 PM, Dave Airlie wrote:
>
> Probably should revert first, then work out what is crapping out libpciaccess.
Yeah, I'll revert. The patch is one of those "obviously a good idea,
but in practice it's not something we can change now".
Linus
On Sat, Feb 19, 2011 at 4:26 AM, Alex Riesen wrote:
> On Sat, Feb 19, 2011 at 13:11, Alex Riesen wrote:
>>> Lastly, could you verify that my patch at
>>> https://lkml.org/lkml/2011/2/16/447 fixes
>>> it for you too? (Make sure you're at max brightness before rebooting.)
>>
>> I'll try it now.
>>
On Tue, Feb 22, 2011 at 2:31 PM, Tino Keitel wrote:
>
> I just tried 2.6.38-rc6 on my ThinkPad X61s without any other DRM
> related patches, and my backlight issue is gone.
I applied Indan's fix in -rc6 (commit 951f3512dba5), since it had
several testers and seemed to simplify the code nicely too
On Tue, Feb 22, 2011 at 9:42 PM, Anca Emanuel wrote:
> General protection fault:
> http://i.imgur.com/TBJ6y.jpg
>
> dmesg: http://pastebin.com/qD8pR8QH
> config: http://pastebin.com/XEurtHWi
That's drivers/video/fbmem.c: fb_release(), and the "Code:"
disassembly shows that it is
1b: e8 f7 c0
On Wed, Feb 23, 2011 at 3:17 PM, Dave Airlie wrote:
>
> Nothing too major,
>
> Two regression fixers (one revert that got fixes properly elsewhere), some
> timestamp fixes and an agp module reload fix.
Pulled. However, what about the report from Pavel Machek :
> > drm/i915: Completely d
On Wed, Feb 23, 2011 at 9:16 AM, Anca Emanuel wrote:
>>
>> Looks like nouveafb took over from vesafb. Did you do anything special
>> to trigger this?
>
> No. Just boot the system.
Every boot?
And just out of interest, what happens if you don't have the vesafb
driver at all?
On Thu, Feb 24, 2011 at 5:20 AM, Anca Emanuel wrote:
>>
>> Every boot?
>
> Yes.
>
>> And just out of interest, what happens if you don't have the vesafb
>> driver at all?
>
> I used 'e' option from grub, removed the 'set gfxpayload = $linux_gfx_mode'
> and it works.
>
> dmesg: http://pastebin.com/
On Thu, Feb 24, 2011 at 4:48 PM, Anca Emanuel wrote:
>
> diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
> index e2bf953..e8f8925 100644
> --- a/drivers/video/fbmem.c
> +++ b/drivers/video/fbmem.c
> @@ -1511,6 +1511,7 @@ void remove_conflicting_framebuffers(struct
> apertures_struct *a,
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
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
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
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
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 ba
On Wed, Jan 12, 2011 at 2:40 PM, Chris Wilson
wrote:
>
> Wow. That should have had zero visible impact upon the rendering. All it
> should have done is reorder the sequence in which we pin the buffers into
> the GTT before applying the relocations, just to allow some pathological
> execbuffers.
>
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
On Wed, Jan 19, 2011 at 8:55 PM, Jeff Chua wrote:
>
> Rafael send out two patches earlier. Could be related. I was facing
> issue during resume.
No, I'm aware of the rcu-synchronize thing, this isn't it. This is
really at the suspend stage, and I had bisected it down to the drm
changes.
In fact,
On Thu, Jan 20, 2011 at 2:25 AM, Chris Wilson
wrote:
>
> Right, the autoreported HEAD may have been already reset to 0 and so hit
> the wraparound bug which caused it to exit early without actually
> quiescing the ringbuffer.
Yeah, that would explain the issue.
> Another possibility is that I a
On Thu, Jan 20, 2011 at 9:38 AM, Chris Wilson
wrote:
>
>> because from looking at the code, I get the notion that
>> "intel_read_status_page()" may not be exact. But what happens if that
>> inexact value matches our cached ring->actual_head, so we never even
>> try to read the exact case? Does it
On Thu, Jan 20, 2011 at 9:51 AM, Linus Torvalds
wrote:
>
> So how about just doing this in the loop? It will mean that the
> _first_ read uses the fast cached one (the common case, hopefully),
> but then if we loop, we'll use the slow exact one.
>
> (cut-and-paste, s
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
Alex, can you confirm that the revert of 951f3512dba5 plus the
one-liner patch from Takashi that Indan quoted also works for you?
Linus
On Thu, Mar 3, 2011 at 10:53 PM, Indan Zupancic wrote:
>
> So please revert my patch and apply Takashi Iwai's, which fixes the
> most immediate bu
On Thu, Mar 10, 2011 at 5:23 PM, Indan Zupancic wrote:
>
> After this patch, combined with my new patch
>
> "drm/i915: Fix DPMS and suspend interaction for intel_panel.c"
>
> all known backlight problems should be fixed.
Btw, can you repost that one as a new email (and cc keithp too)? I
think it
On Wed, Mar 19, 2014 at 12:06 PM, David Herrmann
wrote:
>
> Unlike existing techniques that provide similar protection, sealing allows
> file-sharing without any trust-relationship. This is enforced by rejecting
> seal
> modifications if you don't own an exclusive reference to the given file.
I
On Sun, Mar 23, 2014 at 5:15 AM, Andreas Mohr wrote:
>
> which did end up flawless on 3.12.0-rc2+, too
> (but failed to improve the issue on 3.14.0-rc7+).
>
> So, for all intents and purposes, drm infrastructure seems unavoidably
> (neither dri disable nor libdrm upgrade helps) affected.
> Does an
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
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 stupid
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 s
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 e
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"
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 b
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 de
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 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 linux-foundation.org> wrote:
>> Hmm. Is freedesktop.org having trouble?
>
> ECC memory errors -- we're moving this stuff to a new machi
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
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
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* inde
On Fri, Aug 8, 2014 at 7:34 AM, Daniel Vetter wrote:
>
> git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-08-08
Hmm. My laptop no longer resumes properly.
Or rather, I suspect it resumes, but the screen is black.
I will bisect, and I *will* revert if I find the offending comm
On Fri, Aug 8, 2014 at 12:19 PM, Linus Torvalds
wrote:
> On Fri, Aug 8, 2014 at 7:34 AM, Daniel Vetter
> wrote:
>>
>> git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-08-08
>
> Hmm. My laptop no longer resumes properly.
The problem seems to exist alr
On Fri, Aug 8, 2014 at 12:37 PM, Linus Torvalds
wrote:
>
> The problem seems to exist already with just the plain drm pull from
> Dave. I thought I had tested that, but apparently not.
Still busy bisecting (and it's going into the i915 part of Dave's drm
pull, so the bisec
On Fri, Aug 8, 2014 at 10:30 AM, Linus Torvalds
wrote:
>
> This is a Sony Vaio Pro 11, so it's bog-standard intel graphics (Haswell ULT).
Got this while bisecting. I'm not sure it's related, the behavior was
a bit different from the other cases. So I'll try to contin
On Fri, Aug 8, 2014 at 1:52 PM, Linus Torvalds
wrote:
>
> Got this while bisecting. I'm not sure it's related
It's not.
The actual bug was panel self refresh. It's still broken, and doesn't
work. So enabling it by default was a big mistake (commit
b6d547791fd3: &
On Sun, Dec 14, 2014 at 11:17 PM, Dave Airlie wrote:
>
> i915:
> Initial Skylake (SKL) support
> gen3/4 reset work
> start of dri1/ums removal
> infoframe tracking
> fixes for lots of things.
So I'm not sure how happy I am about this. It seems to work, but
On Mon, Dec 15, 2014 at 4:48 PM, Dave Airlie wrote:
>
> I'd be inclined to just revert this for now, it is annoying we let
> userspace away with this, but we probably need to find a better
> way to enforce it, since the cat is out of the bag.
.. why did that commit ever even get far enough to get
On Mon, Dec 15, 2014 at 5:50 PM, Dave Airlie wrote:
>
> Now you might complain that printing anything in this case is bad,
I don't mind it if it's *one* line, and if people realize that the
commentary in the commit in question was pure and utter shit.
Because talking about how it's going to beco
On Mon, Dec 15, 2014 at 6:37 PM, Dave Airlie wrote:
>
> Now I've no idea if this happens with SNA it probably does, but it it
> didn't then F20 is using UXA so hardly anyone at Intel would see it.
Ugh, ok. I haven't upgraded to F21 yet, and won't until the merge
window is over and my life is back
On Tue, Dec 23, 2014 at 4:09 AM, Oded Gabbay wrote:
> Hello Linus,
> Dave Airlie asked me to send this patch to you for review.
I'm not entirely happy about the fix, since we generally *should*
order things by the different init-levels, but we've done the link
order thing before, and I guess it's
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 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 lockd
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
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 f
On Sun, Jan 19, 2014 at 9:31 AM, Daniel Vetter wrote:
>
> This took much longer than I'll ever dare to admit, but I think I've
> stitched a testcase together for this and pushed it to our i915 test repo:
So I was testing a patch that limits one user to fewer than the global
system resource files,
Ok, I applied this, even though I hate the timing.
I also suspect that that whole commit 61b365a50 ("drm/nouveau:
populate master subdev pointer only when fully constructed") is just
completely buggered and the wrong thing to do. It also caused another
nasty change (fdd239ac99a0 "drm/nouveau: fix
On Wed, Jan 29, 2014 at 6:49 PM, Dave Airlie wrote:
>
> For some reason the request-pull and the merge into your tree look different,
> since some of the changes in this have already gone in via the arm-soc tree
> and dma stuff, all for tegra. Hopefully nobody rebased when they shouldn't.
Looks m
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
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
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 d
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.
L
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
> or
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
drm/i9
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 e
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
601 - 700 of 765 matches
Mail list logo
