[git pull] drm fixes

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.

[git pull] drm fixes

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

[PATCH 0/2]: drm/i915: Disable RC6 and semaphores on SNB *again*

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

2.6.38-rc3-git1: Reported regressions 2.6.36 -> 2.6.37

On Thu, Feb 3, 2011 at 3:23 AM, Carlos R. Mafra wrote: > On Thu ?3.Feb'11 at ?1:03:41 +0100, Rafael J. Wysocki wrote: >> >> If you know of any other unresolved post-2.6.36 regressions, please let us >> know >> either and we'll add them to the list. ?Also, please let us know if any >> of the

2.6.38-rc3-git1: Reported regressions 2.6.36 -> 2.6.37

On Thu, Feb 3, 2011 at 1:56 PM, Carlos Mafra wrote: >> >> I added https://bugzilla.kernel.org/show_bug.cgi?id=24982 to the list of >> post-2.6.36 regressions for further tracking. > > I also tested on 2.6.38-rc3+ now and the issue is not solved, > just like Takashi expected. Hmm. That commit

2.6.38-rc3-git1: Reported regressions 2.6.36 -> 2.6.37

On Thu, Feb 3, 2011 at 2:10 PM, Linus Torvalds wrote: > > Maybe the right thing to do is to set it to 'unknown', something like this. > > TOTALLY UNTESTED! Doing some grepping and "git blame", I found this: commit 032d2a0d068 ("drm/i915: Prevent double dpms on&

2.6.38-rc3-git1: Reported regressions 2.6.36 -> 2.6.37

On Thu, Feb 3, 2011 at 4:06 PM, Dave Airlie wrote: > > If we are setting a mode on a connector it automatically will end up > in a DPMS on state, > so this seemed correct from what I can see. The more I look at that function, the more I disagree with you and with that patch. The code is just

2.6.38-rc3-git1: Reported regressions 2.6.36 -> 2.6.37

On Thu, Feb 3, 2011 at 5:05 PM, Keith Packard wrote: > > The goal is to make it so that when you *do* set a mode, DPMS gets set > to ON (as the monitor will actually be "on" at that point). Here's a > patch which does the DPMS_ON precisely when setting a mode. Ok, patch looks sane, but it does

Regression - Xorg start failed

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

[PATCH] fix backlight brightness on intel LVDS panel after reopening lid

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.

[PATCH] fix backlight brightness on intel LVDS panel after reopening lid

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

Linux 2.6.38-rc6

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

[git pull] drm fixes

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

Linux 2.6.38-rc6

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?

Linux 2.6.38-rc6

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:

Linux 2.6.38-rc6

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

Linux 2.6.37

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

[git pull] drm for rc1

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:

[git pull] drm for rc1

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

[git pull] drm for rc1

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 saver was ru

[git pull] drm for rc1

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

[git pull] drm for rc1

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

[git pull] drm for rc1

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 bise

[git pull] drm for rc1

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 wasn't actually th

[git pull] drm for rc1

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

[git pull] drm for rc1

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 kids around n

[git pull] drm for rc1

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

[git pull] drm intel only fixes

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

[git pull] drm intel only fixes

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

[git pull] drm intel only fixes

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 beta flash p

[git pull] drm intel only fixes

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 bisected it down

[git pull] drm intel only fixes

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

[git pull] drm intel only fixes

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.

drm_lock()->block_all_signals() is broken

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

[git pull] drm for 2.6.35-rc1 (revised)

Grrr. Not well tested. On x86, I get several warnings like this: drivers/video/fbmem.c: In function ?fb_do_apertures_overlap?: drivers/video/fbmem.c:1494: warning: format ?%llx? expects type ?long long unsigned int?, but argument 2 has type ?resource_size_t? Please fix. And

[git pull] drm for 2.6.35-rc1 (revised)

On Sat, 22 May 2010, Stephen Rothwell wrote: > > That being said, I did not get the mentioned warning for either an i386 > or x86_64 allmodconfig build - I wonder why not? Compiler differences? > Config differences? (See > http://kisskb.ellerman.id.au/kisskb/buildresult/2617918/ and >

[git pull] drm fixes

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

[git pull] drm fixes

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

[PATCH 0/7] BKL removal follow-up

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

[git pull] drm fixes

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

[git pull] drm fixes

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

[git pull] drm fixes

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

Linux 2.6.39-rc3

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 > +++

Linux 2.6.39-rc3

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

Linux 2.6.39-rc3

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

Linux 2.6.39-rc3

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 >> becau

2.6.39-rc1 nouveau(?) regression (bisected)

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] >

2.6.39-rc5-git4: Reported regressions from 2.6.38

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 ? ?

[Bugme-new] [Bug 16488] New: [i915] Framebuffer ID error after suspend/hibernate leading to X crash

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 >>

Intel graphics CPU usage - SDVO detect bogosity?

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

Intel graphics CPU usage - SDVO detect bogosity?

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_

Intel graphics CPU usage - SDVO detect bogosity?

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

[git pull] drm fixes

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

[git pull] drm fixes

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 >> presumably the

Linux 2.6.37-rc8 (no fb)

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"),

[git pull] drm fixes

On Mon, 7 Jun 2010, Dave Airlie wrote: > > 3 regressions fixes, one radeon loading on IGP, one i865 loading, one and > an evergreen userspace interaction workaround. This is: 26 files changed, 372 insertions(+), 66 deletions(-) and there are apparently several reports of known

[git pull] drm fixes

On Mon, 7 Jun 2010, Al Viro wrote: > > Ho-hum... Speaking of which, what about leak fixes? There's a long-standing > in-core inode leak in jffs2; basically, if you fail directory modification > in symlink() et.al., you get a leaked inode and whinge at umount. Found > after -rc1, had been

[git pull] drm fixes

On Tue, 8 Jun 2010, Dave Airlie wrote: > > ? ? ? ? 26 files changed, 372 insertions(+), 66 deletions(-) > > > > and there are apparently several reports of known problems (the problem > > with modesetting) that isn't even addressed. > > Okay, not sure what the addressed regression you are

[git pull] drm fixes

On Tue, 8 Jun 2010, Dave Airlie wrote: > > Oh the one where I said to the reporter, I've reproduced this, and > will fix it tomorrow when I have proper time and access to my test > machine? > > I didn't think writing a fix in the 5 mins before I left the test > machine and sending it you was

[git pull] drm fixes

On Mon, 7 Jun 2010, David Woodhouse wrote: > > The fix is fairly trivial. There's a "big" patch to fs/jffs2/dir.c which > accounts for the bulk of my pull request, but if you look harder you'll > see it's mostly just a bunch of removing 'return ret;' and adding > 'goto fail;' so the error

[git pull] drm fixes

On Mon, 7 Jun 2010, Al Viro wrote: > On Mon, Jun 07, 2010 at 02:17:23PM -0700, Linus Torvalds wrote: > > jffs2_clear_inode(inode); > > > > into > > > > make_bad_inode(inode); > > iput(inode); > > > > and that changelog does

[PATCH] fix backlight brightness on intel LVDS panel after reopening lid

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

[PATCH] drm/i915: Revive combination mode for backlight control

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

[git pull] drm next tree

So I had hoped - yes, very na?ve of me, I know - that this merge window would be different. But it's not. On Wed, Mar 16, 2011 at 9:09 PM, Dave Airlie wrote: > > i915: big 855 fix, lots of output setup refactoring, lots of misc fixes. .. and apparently a lot of breakage too. My crappy laptop

[git pull] drm next tree

On Tue, Mar 22, 2011 at 7:19 PM, Linus Torvalds wrote: > > Keith/Jesse/Chris - I don't know that it's i915, and it will take > forever to bisect (I'll try). But it does seem pretty likely. Ok, so I'm still bisecting, but it's definitely the DRM pull. Current bisection log attached (t

[git pull] drm next tree

On Wed, Mar 23, 2011 at 8:33 AM, Jesse Barnes wrote: > > Chris mentioned a7a75c8f7 on irc, not sure if it was regarding this > issue though, but it does seem a likely candidate. Yup, that revert fixes it for me. Linus

[git pull] drm fixes

On Thu, Mar 24, 2011 at 4:31 AM, Ilija Hadzic wrote: > > OK, I'll update libdrm side to match this change and send the patch later > today Quite frankly, this whole discussion is a clear example of why DRM has been problematic. Why the hell am I getting pushed stuff that is clearly not baked?

[git pull] drm fixes

On Thu, Mar 24, 2011 at 1:05 PM, Dave Airlie wrote: > > If you think this has anything to do with Intel's ability to break your > hardware > on every merge then you've got your wires crossed. No, it's about the fact that I expect to be pushed code that is WRITTEN AND TESTED BEFORE THE MERGE

[git pull] drm fixes

On Thu, Mar 24, 2011 at 5:07 PM, Dave Airlie wrote: > > Like seriously you really think VFS locking rework wasn't under > development or discussion when you merged it? I'm sure Al would have > something to say about it considering the number of times he cursed in > irc about that code after you

[git pull] drm fixes

On Thu, Mar 24, 2011 at 5:17 PM, Linus Torvalds wrote: > > If this was a one-time event, we wouldn't be having this discussion. > But the DRM tree is one of the BIGGEST issues after the merge window > has closed. And it's EVERY SINGLE RELEASE. .. regardless, it's pulled now.

Linux 2.6.39-rc3

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 >> becau

(Short?) merge window reminder

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"

(Short?) merge window reminder

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

(Short?) merge window reminder

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

(Short?) merge window reminder

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.

[git pull] drm fixes

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

Linux 3.2-rc1

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: > >

Fwd: [PATCH] i915: Fix bug where screen brightness is not restored

Email sent to wrong people/list, Linus -- Forwarded message -- From: Alex Davis Date: Tue, Nov 15, 2011 at 12:42 AM Subject: [PATCH] i915: Fix bug where screen brightness is not restored To: "linux-kernel at vger.kernel.org" , "torvalds at

3.2-rc2+: Reported regressions from 3.0 and 3.1

On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki wrote: > > Subject ? ?: Simultaneous cat and external keyboard input causing kernel panic > Submitter ?: Timo Jyrinki > Date ? ? ? : 2011-11-03 12:14 > Message-ID : CAJtFfxmovJHspHHKbvBVc4pw+u5mjGmUejCXEzdV+GqE=jVSOQ at > mail.gmail.com >

3.2-rc2+: Reported regressions from 3.0 and 3.1

On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki wrote: > > Subject ? ?: [3.1 REGRESSION] Commit 5cec93c216db77c45f7ce970d46283bcb1933884 > breaks the Chromium seccomp sandbox > Submitter ?: Nix > Date ? ? ? : 2011-11-14 0:40 > Message-ID : 8762inleno.fsf at spindle.srvr.nix > References :

3.2-rc2+: Reported regressions from 3.0 and 3.1

On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki wrote: > > Subject ? ?: hugetlb oops on 3.1.0-rc8-devel > Submitter ?: Andy Lutomirski > Date ? ? ? : 2011-11-01 22:20 > Message-ID : CALCETrW1mpVCz2tO5roaz1r6vnno+srHR-dHA6_pkRi2qiCfdw at > mail.gmail.com > References :

3.2-rc2+: Reported regressions from 3.0 and 3.1

On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki wrote: > > Subject ? ?: lockdep warning after aa6afca5bcab: "proc: fix races against > execve() of /proc/PID/fd**" > Submitter ?: Ari Savolainen > Date ? ? ? : 2011-11-08 3:47 > Message-ID : CAEbykaXYZEFhTgWMm2AfaWQ2SaXYuO_ypTnw+6AVWScOYSCuuw

3.2-rc2+: Reported regressions from 3.0 and 3.1

On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki wrote: > > Subject ? ?: [3.1-rc8 REGRESSION] sky2 hangs machine on turning off or > suspending > Submitter ?: Rafa? Mi?ecki > Date ? ? ? : 2011-11-09 11:46 > Message-ID : CACna6ryTdLcWVYgHu=_mRFga1sFivpE_DyZOY-HMmKggkWAJAw at > mail.gmail.com

i915: hangcheck timer elapsed

I haven't gotten one of these in a long time.. [89045.616347] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [89045.616352] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state [89045.621818] [drm:i915_wait_request] *ERROR*

[git pull] drm fixes

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

[PULL] drm-intel-fixes (drm/i915 driver)

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

vmgfx gcc-7.1.1 warning..

This one actually seems to imply that vmw_cmd_invalid() is broken: drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:522:34: warning: the omitted middle operand in ?: will always be ‘true’, suggest explicit middle operand [-Wparentheses] return capable(CAP_SYS_ADMIN) ? : -EINVAL;

Re: [git pull] drm fixes for 4.12-rc8

On Wed, Jun 28, 2017 at 12:18 AM, Dave Airlie wrote: > > I've got next locked down, so whenever you open the merge > window and I get back I'll send it to you. Just checking in on this part.. I think the drm stuff it the major missing piece for 4.13 now. Linus

Re: [git pull] drm for v4.13

On Sun, Jul 9, 2017 at 8:01 PM, Dave Airlie wrote: > > Forgot to add, because I just checked now, there are 2 conflicts, > the drm one with patches from Al, and one in i915_gem_execbuffer.c > which I think resolves best by just taking the code from the pull in place > of code

Re: [PATCH, RESEND 03/14] drm/vmwgfx: avoid gcc-7 parentheses warning

On Fri, Jul 14, 2017 at 12:21 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > NAK. This takes unintentionally insane code and turns it intentionally > insane. Any non-zero return is considered an error. > > The right fix is almost certainly to just return -E

Re: [PATCH 08/14] Input: adxl34x - fix gcc-7 -Wint-in-bool-context warning

On Fri, Jul 14, 2017 at 2:25 AM, Arnd Bergmann wrote: > FIFO_MODE is an macro expression with a '<<' operator, which > gcc points out could be misread as a '<': Yeah, no, NAK again. We don't make the code look worse just because gcc is being a f*cking moron about things. This

Re: [PATCH, RESEND 03/14] drm/vmwgfx: avoid gcc-7 parentheses warning

On Fri, Jul 14, 2017 at 2:25 AM, Arnd Bergmann wrote: > - return capable(CAP_SYS_ADMIN) ? : -EINVAL; > + return capable(CAP_SYS_ADMIN) ? 1 : -EINVAL; NAK. This takes unintentionally insane code and turns it intentionally insane. Any non-zero return is considered an

Re: [git pull] drm fixes for 4.12-rc8

On Wed, Jun 28, 2017 at 12:18 AM, Dave Airlie wrote: > > git://people.freedesktop.org/~airlied/linux drm-fixes-for-v4.12-rc8 That tag does not exist. However: > for you to fetch changes up to 9ff1beb1d19ffe2b26bf9cd2d33e6073d4f4b5fe: That commit 9ff1beb1d19f _is_ the head

Re: [git pull] drm fixes for v4.12-rc1

On Thu, May 11, 2017 at 11:00 PM, Dave Airlie wrote: > > It also has an amdgpu fixes pull, with lots of ongoing work on Vega10 > which is new in this kernel and is preliminary support so may have a > fair bit of movement. Note: I will *not* be taking these kinds of pull

Re: [git pull] drm fixes for v4.12-rc1

On May 12, 2017 12:30 PM, "Dave Airlie" wrote: > > Dave, time to update your scripts and address book.. wierd gmail failed me. I think gmail is sometimes too smart for its own good. It takes the other recipients into account when auto-completing the recipients list, so even

Re: [git pull] drm fixes for v4.12-rc1

.. and here's the email repeated for the new dri-devel list, since apparently Dave sent the pull request to the old no-longer-working one that just sends annoying bounces. Dave, time to update your scripts and address book.. Linus On Fri, May 12, 2017 at 11:54 AM, Linus Torvalds

Re: [git pull] drm pull for v4.12

On Tue, May 2, 2017 at 8:44 PM, Dave Airlie wrote: > > i915: > vblank evasion improvements These may be "improvements", but they end up being very noisy. I geta fair amount of messages like [drm] Atomic update on pipe (A) took 161 us, max time under evasion is 100 us on

Re: [PATCH 00/13] mmu_notifier kill invalidate_page callback

On Tue, Aug 29, 2017 at 4:54 PM, Jérôme Glisse wrote: > > Note this is barely tested. I intend to do more testing of next few days > but i do not have access to all hardware that make use of the mmu_notifier > API. Thanks for doing this. > First 2 patches convert existing

Re: [PULL] drm-misc-fixes

On Thu, Dec 14, 2017 at 6:50 AM, Daniel Vetter wrote: > > Imo that's enough that I figured better not delay until Dave is back. > Linus, can you pls apply? Pulled. Linus ___ dri-devel mailing list

Re: [PATCH] kthread: finer-grained lockdep/cross-release completion

On Sun, Dec 17, 2017 at 11:11 PM, Daniel Vetter wrote: > > This didn't seem to have made it into -rc4. Anything needed to get it > going? Do you actually see the problem in -rc4? Because we ended up removing the cross-release checking due to other developers complaining. It

<    1   2   3   4   5   6   7   8   >