Re: 3.5-rc7: nouveau doesn't X on NVC0

[ 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 adobri...@gmail.com wrote: Ping! No X for me with 3.6-rc2. Can you possibly bisect

Re: [git pull] drm merge for rc1 (part 1)

On Wed, Oct 3, 2012 at 9:08 PM, Dave Airlie airl...@linux.ie 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

Re: Linux 3.7-rc1 (nouveau_bios_score oops).

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

Re: Linux 3.7-rc1 (nouveau_bios_score oops).

On Fri, Oct 19, 2012 at 3:41 PM, Martin Peres martin.pe...@labri.fr 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

Re: Linux 3.7-rc1 (nouveau_bios_score oops).

On Sun, Oct 21, 2012 at 5:09 AM, Marcin Slusarz marcin.slus...@gmail.com 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

Re: Linux 3.7-rc1 (nouveau_bios_score oops).

On Sun, Oct 21, 2012 at 5:49 PM, Marcin Slusarz marcin.slus...@gmail.com 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

Re: [git pull] drm fixes

On Wed, Nov 21, 2012 at 6:34 PM, Dave Airlie airl...@linux.ie 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

Re: [git pull] drm fixes

[ 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 airl...@gmail.com wrote: Doh!, yes I picked wrong place to generate report from, okay here is one corresponding to what you saw,

Re: [git pull] fbcon locking fixes.

On Thu, Jan 24, 2013 at 4:42 PM, Dave Airlie airl...@linux.ie 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

Re: [git pull] fbcon locking fixes.

On Thu, Jan 24, 2013 at 5:45 PM, Dave Airlie airl...@gmail.com 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.

Re: BUG: circular locking dependency detected

On Thu, Jan 31, 2013 at 9:19 AM, Russell King r...@arm.linux.org.uk 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

Re: BUG: circular locking dependency detected

On Thu, Jan 31, 2013 at 11:13 AM, Russell King r...@arm.linux.org.uk 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

Re: Debugging Thinkpad T430s occasional suspend failure.

On Sat, Feb 16, 2013 at 1:45 PM, Hugh Dickins hu...@google.com 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

Re: [git pull] drm merge for 3.9-rc1

On Mon, Feb 25, 2013 at 4:05 PM, Dave Airlie airl...@linux.ie 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

Re: [git pull] drm merge for 3.9-rc1

On Mon, Feb 25, 2013 at 4:05 PM, Dave Airlie airl...@linux.ie 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

Re: [git pull] drm merge for 3.9-rc1

On Tue, Feb 26, 2013 at 5:39 PM, Linus Torvalds torva...@linux-foundation.org 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, aka

Re: [git pull] drm merge for 3.9-rc1

On Tue, Feb 26, 2013 at 7:30 PM, Dave Airlie airl...@gmail.com 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

Re: linux-next: Tree for Apr 18 [ call-trace: drm | x86 | smp | rcu related? ]

On Fri, Apr 19, 2013 at 2:09 PM, Sedat Dilek sedat.di...@gmail.com 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

Re: linux-next: Tree for Apr 18 [ call-trace: drm | x86 | smp | rcu related? ]

On Fri, Apr 19, 2013 at 3:34 PM, Sedat Dilek sedat.di...@gmail.com 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.

Re: [git pull] drm fixes

On Thu, Jun 6, 2013 at 2:14 PM, Dave Airlie airl...@linux.ie 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

Re: Linux 3.10-rc7

On Sat, Jun 29, 2013 at 8:05 AM, Sergey Meirovich rathamah...@gmail.com 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

Re: Linux 3.10-rc7

On Sat, Jun 29, 2013 at 2:07 PM, Sergey Meirovich rathamah...@gmail.com 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,

Re: Linux 3.10-rc7

On Sat, Jun 29, 2013 at 4:52 PM, Sergey Meirovich rathamah...@gmail.com 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

WARNING: CPU: 1 PID: 2846 at drivers/gpu/drm/i915/intel_sdvo.c:1378

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

Re: [git pull] drm build fix

On Sat, Aug 3, 2013 at 6:08 PM, Dave Airlie airl...@linux.ie 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()

Re: [git pull] drm fixes

On Thu, Aug 29, 2013 at 4:08 PM, Dave Airlie airl...@linux.ie wrote: ssh://people.freedesktop.org/~airlied/linux drm-fixes Please people! When you post ssh addresses, always remember to also post your user name and password or private key with the pull request. Ok? Linus

Re: [git pull] drm fixes

Hmm. I just updated my machine to a i7-4770S (kept everything else the same, just switched out motherboards), and now when my display goes to sleep, it seems to never come back. Any known issues with DVI on Haswell (it seems to show up as HDMI1 as the output, but it's a DVI cable)? I need to get

Re: [git pull] drm fixes

On Sat, Aug 31, 2013 at 4:02 PM, Linus Torvalds torva...@linux-foundation.org wrote: Any known issues with DVI on Haswell (it seems to show up as HDMI1 as the output, but it's a DVI cable)? With a DP cable and the same monitor, the problem doesn't seem to occur. So it does seem to somehow

Re: [git pull] drm fixes

On Sun, Sep 1, 2013 at 11:54 PM, Daniel Vetter dan...@ffwll.ch wrote: On Sat, Aug 31, 2013 at 04:02:16PM -0700, Linus Torvalds wrote: Hmm. I just updated my machine to a i7-4770S (kept everything else the same, just switched out motherboards), and now when my display goes to sleep, it seems

Re: [git pull] drm tree for 3.12-rc1

On Thu, Sep 5, 2013 at 3:41 AM, Dave Airlie airl...@linux.ie wrote: i915: Haswell PC8+ support and eLLC support, HDMI 4K support, initial per-process VMA pieces, watermark reworks, convert to generic hdmi infoframes, encoder reworking, fastboot support, Hmm. The first time I booted

Re: [git pull] drm tree for 3.12-rc1

On Thu, Sep 5, 2013 at 3:51 PM, Linus Torvalds torva...@linux-foundation.org wrote: I've booted a few times since (it's the merge window, so I boot fairly frequently), and it hasn't happened again... .. and of course, after I say that, on the very next boot it then happened three times

Re: [git pull] drm tree for 3.12-rc1

On Thu, Sep 5, 2013 at 3:32 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: On Thu, 5 Sep 2013 12:18:32 -0700 The first time I booted this, I just got a black screen on my Haswell desktop when X11 started up. I could ctrl-alt-BS and ctrl-alt-del to reboot the machine, and neither the

Re: [git pull] drm tree for 3.12-rc1

On Thu, Sep 5, 2013 at 3:51 PM, Linus Torvalds torva...@linux-foundation.org wrote: Looking more closely at the log-file, I notice that the oops, pressed the send-button a bit too early.. Anyway, looking more closely at the log-file, I notice that while it has zero errors, it does seem to end

Re: [git pull] drm tree for 3.12-rc1

On Thu, Sep 5, 2013 at 4:19 PM, Linus Torvalds torva...@linux-foundation.org wrote: So I've decided I'm going to try to bisect this after all. I've done enough pulls for today anyway, I guess. Let's see if I can bisect it by just trying to boot many times each try. Ok, it's not the recent drm

Re: [git pull] drm tree for 3.12-rc1

[ Dave - your linux.ie email generates bounces for me, trying redhat instead ] On Mon, Sep 9, 2013 at 11:25 PM, Sean V Kelley sean.v.kel...@intel.com wrote: I'm also a bit bummed that hw acceleration of video doesn't seem to work on Haswell, meaning that full-screen is now a jerky mess. I fear

Re: [git pull] drm radeon/nouveau/core fixes

On Wed, Sep 18, 2013 at 9:07 PM, Dave Airlie airl...@gmail.com wrote: mostly radeon fixes, with some nouveau bios parser, ttm fix and a fix for AST driver. Ugh. I hope things calm down from here. Linus ___ dri-devel mailing list

Re: drm/sysfs lifetime interaction fixes

On Thu, Oct 10, 2013 at 10:05 PM, Dave Airlie airl...@gmail.com wrote: This is my preferred method of fixing it as I don't think the lifetimes need to be tied so closely, though this requires review my someone to make sure my unregistering etc is correct and in the right place. Apparently

Re: [git pull] drm fixes

On Thu, Oct 10, 2013 at 10:28 PM, Dave Airlie airl...@linux.ie wrote: and one pain in the ass revert, so we have VGA arbitration that when implemented 4-5 years ago really hoped that GPUs could remove themselves from arbitration completely once they had a kernel driver, it seems Intel hw

Re: [PATCH 0/2] drm/i915: Backport vma fixes for 4.10-rc6

On Tue, Jan 31, 2017 at 1:21 AM, Maarten Lankhorst wrote: > > This is marked for rc6 because it seems the issue is triggerable on > mainline and resulting in an oops. So I did apply my obvious "avoid the oops and just warn about it" patch: commit 39cb2c9a316e

Re: [git pull] drm for v4.11 - main pull request

On Thu, Feb 23, 2017 at 5:44 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > AND WHY THE HELL WAS THIS UTTER SHITE SENT TO ME IF IT WAS COMMITTED > YESTERDAY? .. and a slightly less annoying piece of crap in this pull request: that "PRIME_NUMBERS" config t

Re: [git pull] drm for v4.11 - main pull request

On Thu, Feb 23, 2017 at 4:01 PM, Dave Airlie wrote: > > This is the main drm pull request for v4.11. > > Nothing too major, the tinydrm and mmu-less support should make writing > smaller drivers easier for some of the simpler platforms, and there are > a bunch of documentation

[git pull] drm fixes for rc5

On Thu, Sep 1, 2016 at 10:59 PM, Dave Airlie wrote: > > I've tried using a signed tag, let's see if works. Worked fine. But your email was once again marked as spam. Google hates you, and your email habits. Linus

[git pull] drm fixes for 4.8-rc6

On Fri, Sep 16, 2016 at 3:15 PM, Dave Airlie wrote: > > I've sent this from my gmail address to see if I can avoid > the spam folders. You were successful. Thanks, Linus

[git pull] drm for 4.8

What's the status of the 4.9 merge window pull request? The GPU side is the main remaining pile for this merge window according to linux-next. I'd hate to get a last-minute pull at the end of the week ... Linus

[git pull] drm pull for v4.9

On Tue, Oct 11, 2016 at 2:14 PM, Dave Airlie wrote: > > this email is all in small letters because my gpg key expired so I couldn't > sign the tag, and it's too early in the morning for me to go do gpg stuff. I'm happy that you have found alternative identity management model, but I'm not sure

[PULL] drm-intel-fixes

On Thu, Jan 5, 2017 at 3:19 AM, Jani Nikula wrote: > > Hi Dave, or Linus if Dave's on vacation, I'm a bit unsure, I'm going to ignore this on the assumption that Dave is around. But if nothing happens for a few days, ping me again and I'll pull it directly. Ok? Linus

[git pull] drm fixes

On Thu, Apr 21, 2016 at 5:57 PM, Dave Airlie wrote: > > git://people.freedesktop.org/~airlied/linux drm-fixes Hmm. freedesktop.org seems to be feeling a bit under the weather. It's not just the git part - it's not doing web either, and doesn't seem to answer to pings either (I saw _one_ ping

[git pull] drm fixes

On Fri, Apr 22, 2016 at 10:23 AM, Daniel Vetter wrote: > > Works all fine here, http, ssh & git protocols all up well. > Maybe temporary, or just your part of the interwebs fell off? It's up for me now too, so something temporary. I don't think it was at my end, everything else seemed to work

[git pull] drm for v4.8

On Mon, Aug 1, 2016 at 9:32 PM, Dave Airlie wrote: > > This is the main drm pull request for 4.8, I'm down with a cold at the moment > so hopefully this isn't in too bad a state, I finished pulling stuff last > week mostly (nouveau fixes just went in today), so only this message should > be

[git pull] drm for v4.8

On Tue, Aug 2, 2016 at 4:10 AM, Ville Syrjälä wrote: > > I have a couple of pending PSR patches you may want to try as well, > if i915.enable_psr=0 helps. Yes. i915.enable_psr=0 seems to make the bad flickering go away. I'll try your git trees out later, but what exactly changed with regards

[git pull] drm for v4.8

On Tue, Aug 2, 2016 at 4:10 AM, Ville Syrjälä wrote: > > So PSR seems more likely. The underruns might point at some watermark > fail though :( > > I have a couple of pending PSR patches you may want to try as well, > if i915.enable_psr=0 helps. > > First set is here: >

Linux 4.8-rc1 Cirrus QEMU crashes on boot.

On Mon, Aug 8, 2016 at 1:24 PM, Eric W. Biederman wrote: > > Booting up v4.8-rc1 in qemu today I ran I ran into this beautiful oops. > > I am just about to head out the door on vacation until the end of the > month so hopefully I am tossing out enough information to the right > people. > > I

[git pull] drm fixes for 4.9-rc4

On Wed, Nov 2, 2016 at 5:31 PM, Dave Airlie wrote: > > There are a set of fixes for an oops we've been seeing around MST > display unplug, Side note: I heard from a couple of people at the KS that said that they had had problems with suspend/resume after plugging in to a 4k display (but _only_ a

[git pull] drm for 4.5-rc1

On Sun, Jan 17, 2016 at 1:35 PM, Dave Airlie wrote: > > This is the main drm pull request for 4.5. I don't think I've missed anything > too > major, I'm mostly back at work now but I'll probably get some sleep in 5 > years time. Good luck with that. > I think it should fix the i915 warning

[git pull] drm fixes for rc4 or 5

On Sun, Aug 28, 2016 at 2:00 PM, Dave Airlie wrote: > > I probably missed -rc4 by minutes, but maybe pointless GPL enforcement > debates are distracting you enough! Hey, they must be good for _something_. Anyway, the real problem was that this was in my spam-box. Which I've learnt to check

[git pull] drm fixes for rc4 or 5

On Sun, Aug 28, 2016 at 2:31 PM, Linus Torvalds wrote: > > Anyway, the real problem was that this was in my spam-box. Which I've > learnt to check religiously, so I noticed almost immediately. Btw, on a totally unrelated issue: you make thes pull points tags (good), but they are j

[git pull] drm fixes

On Thu, Feb 25, 2016 at 6:20 PM, Dave Airlie wrote: > > This is a bit larger than Id like, but I asked the Intel guys to pull in > some Skylake fixes in the possibly vain hope that Skylake might be more > functional now that I'm seeing production hardware shipping. > > For i915, it's mostly the

[PULL] drm-intel-fixes

On Jan 3, 2016 18:06, "Dave Airlie" wrote: > > can you pull this directly, baby has arrived, but I'm not back at work yet. Assumed so, and already did. It's in rc8, Linus -- next part -- An HTML attachment was scrubbed... URL:

[PATCH] x86: Add an explicit barrier() to clflushopt()

On Mon, Jan 11, 2016 at 3:28 AM, Chris Wilson wrote: > > Bizarrely, > > diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c > index 6000ad7..cf074400 100644 > --- a/arch/x86/mm/pageattr.c > +++ b/arch/x86/mm/pageattr.c > @@ -141,6 +141,7 @@ void clflush_cache_range(void *vaddr, unsigned

[PATCH] x86: Add an explicit barrier() to clflushopt()

On Tue, Jan 12, 2016 at 8:37 AM, Chris Wilson wrote: > On Mon, Jan 11, 2016 at 09:05:06PM +, Chris Wilson wrote: >> I can narrow down the principal buggy path by doing the clflush(vend-1) >> in the callers at least. > > That leads to the suspect path being a read back of a cache line from >

[PATCH] x86: Add an explicit barrier() to clflushopt()

On Tue, Jan 12, 2016 at 1:13 PM, Chris Wilson wrote: > > That is a continual worry. To try and assuage that fear, I sent 8x > flush gpu writes between the end of the copy and setting the "I'm done" > flag. The definition of the GPU flush is that it both flushes all > previous writes before it

[PATCH] x86: Add an explicit barrier() to clflushopt()

On Tue, Jan 12, 2016 at 4:55 PM, Chris Wilson wrote: > > The double clflush() remains a mystery. Actually, I think it's explainable. It's wrong to do the clflush *after* the GPU has done the write, which seems to be what you are doing. Why? If the GPU really isn't cache coherent, what can

[PATCH] x86: Add an explicit barrier() to clflushopt()

On Tue, Jan 12, 2016 at 6:42 PM, Andy Lutomirski wrote: > > Since barriers are on my mind: how strong a barrier is needed to > prevent cache fills from being speculated across the barrier? I don't think there are *any* architectural guarantees. I suspect that a real serializing instruction

[PATCH] x86: Add an explicit barrier() to clflushopt()

On Wed, Jan 13, 2016 at 4:34 AM, Chris Wilson wrote: > > Forgive me for being dense, but if we overwrite the GPU data in the > backing struct page with the cacheline from the CPU, how do we see the > results from the GPU afterwards? Hmm. Good point. Ok, all the symptoms just say "writes from

[git pull] drm for v4.7

On Sun, May 22, 2016 at 11:41 PM, Dave Airlie wrote: > > Here's the main drm pull request for 4.7, it's been > a busy one, and I've been a bit more distracted in > real life this merge window. Hmm. I pulled this, but I think I'll have to unpull again. Neither the diffstat not the shortlog

[git pull] drm for v4.7

On Mon, May 23, 2016 at 11:59 AM, Linus Torvalds wrote: > > I'll test this out and look what happens, but I hate getting different > results than what I'm told to expect. Hmm. I also get a lot of ./usr/include/drm/amdgpu_drm.h:38: userspace cannot reference function or variabl

[git pull] drm for v4.7

On Wed, May 25, 2016 at 1:28 AM, Jani Nikula wrote: > > There may be better ones out there, but Artem's "aiaiai" has some > helpers [1] for diffing build logs, if you want something simple to > integrate into existing scripts. It would be lovely to have some kind of warning detection, but quite

objtool warning: "duplicate frame pointer save"

Josh, my current git version (with gcc 5.3.1) makes objtool warn about "duplicate frame pointer save" in drivers/gpu/drm/vmwgfx/vmwgfx_msg.c for both vmw_send_msg() and vmw_host_get_guestinfo(). The reason is that VMW_PORT_HB_OUT() uses a magic instruction sequence (a "rep outsb") to communicate

objtool warning: "duplicate frame pointer save"

On Wed, May 25, 2016 at 10:56 AM, Josh Poimboeuf wrote: > > I used to have a STACKTOOL_IGNORE_INSN macro that would tell the tool to > skip warnings for specific instructions in inline asm: > > Here's an example of it how it was used: Ok, looking at that, I'm starting to suspect that it is

[PATCH] drm/vmwgfx: fix "duplicate frame pointer save" warning

On Thu, May 26, 2016 at 11:43 AM, Josh Poimboeuf wrote: > > That's fine with me, it is indeed a rare case. We can always add the > per-instruction macro later if needed. Here's a patch. Ingo, I can take this directly, unless you have other things pending that you want to send anyway and would

[git pull] drm amd acp audio support - optional

On Wed, Feb 3, 2016 at 4:04 PM, Dave Airlie wrote: > > I'm happy enough it shouldn't cause any problems, just wanted to > check if you'd take it now or not. Honestly, this feels like "might as well wait for 4.6" to me. I'm generally ok with taking completely new drivers later in the rc if

[PATCH v1 00/12] PCI: Rework shadow ROM handling

On Thu, Mar 3, 2016 at 8:53 AM, Bjorn Helgaas wrote: > The purpose of this series is to: > [ .. ] The patches look ok to me and seem to make sense. Of course, let's see what they break. Hopefully nothing, but any time the PCI resource code changes I get a bit worried. PTSD, I guess.

Linux 4.4.4 [regression]

On Mon, Mar 7, 2016 at 6:20 AM, Jörg-Volker Peetz wrote: > > This same problem with X does happen in 4.5-rc7. And removing the line > introduced by patch b36e52c44ce6728824546d8b5f05b844cede96f1 makes X go again > on > my laptop. Ok, so that's dbb17a21c131eca94eb31136eee9a7fe5aff00d9 in

[PATCH v1 00/12] PCI: Rework shadow ROM handling

On Fri, Mar 11, 2016 at 4:49 PM, Andy Lutomirski wrote: > > FWIW, if I disable all the checks in pci_get_rom_size, I learn that my > video ROM consists entirely of 0xff bytes. Maybe there just isn't a > ROM shadow on my laptop. I think most laptops end up having the graphics ROM be part of the

Stupid NVIDIA 3D vgaarb.c patch

Adding proper people and mailing lists.. The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is appropriate, but hopefully somebody does. The fact that it makes things work certainly argues fairly convincingly for it, but I

git pull] drm for v4.1-rc1

Hmm. The odd Intel PCI resource mess is back. Or maybe it never went away. I get these when suspending. Things *work*, but it's really spamming my logs a fair bit: i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment pci_bus :01: Allocating resources pci_bus

[PATCH] drm/i915: cope with large i2c transfers

On Tue, Apr 21, 2015 at 12:24 AM, Chris Wilson wrote: > > Though I am tempted to say we should impose the 256 byte limit for > stable@ If the docs say 256, I'd suggest using that not just for stable, but for anything. Maybe 511 bytes work everywhere and the docs are just wrong. And maybe it

[PATCH v2] drm/i915: cope with large i2c transfers

On Tue, Apr 21, 2015 at 9:49 AM, Dmitry Torokhov wrote: > The hardware, according to the specs, is limited to 256 byte transfers, > and current driver has no protections in case users attempt to do larger > transfers. The code will just stomp over status register and mayhem > ensues. Thanks,

[PATCH 0/6] File Sealing & memfd_create()

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.

3.14-rc7 crashes in drm ([PATCH] a crash in mga_driver_irq_uninstall)

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

NULL ptr dereference in i915_gem_alloc_object()

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

[PATCH] drm/nouveau/mxm: fix null deref on load

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

[git pull] drm next tree

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

[PATCH 1/1] Revert "drm/i915: drop i915_ prefix from enable_rc6, enable_fbc, enable_ppgtt parameters"

Sorry for the top post, I'm on the road.. In wondering if we couldn't just keep both the old an the new names and have them both point at the same variable? Remove the description for the old name, but keep it working? Linus On Jul 16, 2014 8:34 AM, "Amit Shah" wrote: > This reverts commit

[git pull] drm merge tree

On Wed, Jun 11, 2014 at 5:58 PM, Dave Airlie wrote: > > This is the main drm merge window pull request, changes all over the place, > mostly normal levels of churn. Hmm. I just had the machine reboot on me when booting this and starting X, leaving nothing in the logs. This is on a

[git pull] drm merge tree

On Thu, Jun 12, 2014 at 12:06 PM, Linus Torvalds wrote: > > I just had the machine reboot on me when booting this and starting X, > leaving nothing in the logs. Ok, I can't recreate it, and as such I can't be sure that it was even the drm merge that causes it (although the timing was s

[git pull] drm for 3.19-rc1

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

[git pull] drm for 3.19-rc1

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

[git pull] drm for 3.19-rc1

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

[git pull] drm for 3.19-rc1

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

[PATCH 1/2] drivers: Move iommu/ before gpu/ in Makefile

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

[PULL] drm-intel-fixes

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

[PULL] drm-intel-fixes

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

[PULL] drm-intel-fixes

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 bisect looks sa

[PULL] drm-intel-fixes

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 continue bisecting, but am

[PULL] drm-intel-fixes

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: "drm/i915: Enable PSR

git pull] drm for v4.1-rc1

On Thu, Apr 23, 2015 at 2:56 PM, Matthew Garrett wrote: > On Thu, Apr 23, 2015 at 2:30 PM, Bjorn Helgaas wrote: >> >> int pcibios_add_device(struct pci_dev *dev) >> { >> if (dev-is-default-vga-device) { >> dev->rom = 0xC; >> dev->romlen = 0x2; >> } > > I don't

[REGRESSION] Re: i915 driver crashes on T540p if docking station attached

On Mon, Aug 3, 2015 at 9:25 AM, Theodore Ts'o wrote: > > I've just tried pulling in your updated fixes-stuff, and it avoids the > oops and allows external the monitor to work correctly. Good. Have either of you tested the suspend/resume behavior? Is that fixed too? >

[pull] radeon and amdgpu drm-fixes-4.2

On Wed, Aug 12, 2015 at 10:46 AM, Alex Deucher wrote: > > Dave is on vacation at the moment, so please pull these fixes directly. > Just a few minor things for 4.2: So I've pulled this, but I'm noticing a very alarming pattern in your pull requests: the commits are clearly generated just before

[pull] radeon and amdgpu drm-fixes-4.2

On Wed, Aug 12, 2015 at 12:10 PM, Alex Deucher wrote: > > I always rebase my pull requests against Dave's drm-fixes tree before > I send a pull request. Since he's out of town I rebased against your > tree. I didn't realize that was not the preferred model. I thought > it was preferred to fix

<    1   2   3   4   5   6   7   8   >