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 ad
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 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 entri
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 (bf9
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 doubl
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 cra
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 le
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,
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 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
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
___
dri-devel mail
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? It
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 WIND
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 me
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 p
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 ple
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
> http://ki
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 probl
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 ther
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 talki
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 ac
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 clean
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
On Tue, Aug 3, 2010 at 12:25 AM, Chris Wilson wrote:
> On Mon, 2 Aug 2010 16:55:03 -0700, Andrew Morton
> 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-dae...@bugzilla.kernel.or
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 Tue, Oct 4, 2011 at 9:34 AM, Dave Airlie wrote:
>
> all radeon fixes, one nasty startup crash and/or memory corruption on one
> family of radeon hd6450s resulted in a patch to stop setting a bunch of
> regs in the drivers and let the BIOS set them correctly, displayport
> regression fix, and so
On Thu, Sep 29, 2011 at 6:18 PM, Keith Packard wrote:
>
> Here are three tiny patches, two new bug fixes and one regression fix
> that disables FBC on Ironlake and older chips.
So I got this error notice at bootup with the current -git tree.
Everything seems to work despite it, but I thought I'd
bisection.
Linus
On Sat, Apr 21, 2012 at 9:07 PM, Nick Bowler
wrote:
> On 2012-04-21 15:43 -0700, Linus Torvalds wrote:
>> But none of it really looks all that scary. It looks like the 3.4
>> release is all on track, but please do holler if you see regressions.
>
> OK, I'll
This thing isn't repeatable, and it can go days without happening, but
it has happened several times now over the last several weeks, to the
point where it is very annoying.
I get:
[drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
[drm] capturing error event; look for more
On Thu, Feb 23, 2012 at 11:52 AM, Chris Wilson
wrote:
>
> i2c retries if sees an EGAIN, drm_do_probe_ddc_edid retries until it
> gets a result and *then* drm_do_get_edid retries until it gets a result
> it is happy with. All in all, that is a lot of processor intensive
> looping in cases where we
On Thu, Feb 23, 2012 at 12:15 PM, Linus Torvalds
wrote:
>
> Sadly, this doesn't seem to make any difference to my case. My xrandr
> stays at 0.555s even with this patch.
Btw, profiling with call chains seems to say that it all comes from
intel_sdvo_get_analog_edid() (a
On Thu, Feb 23, 2012 at 1:36 PM, Eugeni Dodonov
wrote:
>
> Perhaps a stupid question, but does you tree has
> http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=9292f37e1f5c79400254dca46f83313488093825
> from Dave's drm-next?
>
> If it has, it would be the 1st time that I see xrandr
On Fri, Jan 6, 2012 at 7:06 AM, Dave Airlie wrote:
>
> Now we've all agreed that the initial implementation is a good baseline
> for us to move forward on, but its messy working with others when the core
> code is out of tree. So we'd like to merge the core dma-buf code now so we
> can all build o
On Wed, Jan 25, 2012 at 11:05 AM, Dave Airlie wrote:
>
> bunch of regression fixes since TTM rework and radeon initialisation,
> modesetting fixes for Alex to fix some black screens on kms start type
> issues, and two radeon ACPI fixes that make some laptops no oops on
> startup.
Does that includ
On 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 maste
On Wed, Apr 13, 2011 at 1:48 PM, Yinghai Lu wrote:
>
> can you try following change ? it will push gart to 0x8000
>
> diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
> index 86d1ad4..3b6a9d5 100644
> --- a/arch/x86/kernel/aperture_64.c
> +++ b/arch/x86/kernel/apertur
On Wed, Apr 13, 2011 at 2:23 PM, Yinghai Lu wrote:
>>
>> What are all the magic numbers, and why would 0x8000 be special?
>
> that is the old value when kernel was doing bottom-up bootmem allocation.
I understand, BUT THAT IS STILL A TOTALLY MAGIC NUMBER!
It makes it come out the same ON THA
On Wednesday, April 13, 2011, H. Peter Anvin wrote:
>
> Yes. ?However, even if we *do* revert (and the time is running short on
> not reverting) I would like to understand this particular one, simply
> because I think it may very well be a problem that is manifesting itself
> in other ways on othe
On Wednesday, April 13, 2011, Linus Torvalds
wrote:
> On Wednesday, April 13, 2011, H. Peter Anvin wrote:
>>
>> Yes. ?However, even if we *do* revert (and the time is running short on
>> not reverting) I would like to understand this particular one, simply
>> because
On Mon, Apr 18, 2011 at 1:02 PM, Marcin Slusarz
wrote:
>
> It's some nasty corruption:
Looks like something wrote 0x to free'd memory.
Enabling DEBUG_PAGEALLOC *might* show where it happens.
>
> [ ? ?6.523867]
> ==
On Sat, Apr 30, 2011 at 12:42 PM, Rafael J. Wysocki wrote:
>
> Bug-Entry ? ? ? : http://bugzilla.kernel.org/show_bug.cgi?id=34012
> Subject ? ? ? ? : 2.6.39-rc4+: oom-killer busy killing tasks
> Submitter ? ? ? : Christian Kujau
> Date ? ? ? ? ? ?: 2011-04-22 1:57 (9 days old)
> Message-ID ? ? ?:
On Sun, Aug 28, 2011 at 12:35 PM, Dave Jones wrote:
> On Sun, Aug 28, 2011 at 08:22:05PM +0200, Rafael J. Wysocki wrote:
>
> ?> Bug-Entry ? ?: http://bugzilla.kernel.org/show_bug.cgi?id=41742
> ?> Subject ? ? ? ? ? ? ?: duplicate filename ?for intel_backlight with the
> i915 driver
> ?> Submitter
On Tue, Dec 6, 2011 at 8:21 AM, Dave Airlie wrote:
>
> 3 fixes, one for an ongoing Intel VT-d/Ironlake GPU that I've been
> testing, and one kexec fix from Jerome for an issue reported on the list
> where the gpu writeback engines need to be switched off, along with a
> trivial fix from Alex.
Qui
On Tue, Dec 6, 2011 at 8:36 AM, Dave Airlie wrote:
>
> Well I do care about kexec but only due to being forced into caring
> about it for a certain enterprise distro that uses it a lot, so maybe
> I was a bit biased in this case, and I dislike random memory
> corruptions due to my subsystem even i
On Mon, Dec 26, 2011 at 5:02 PM, Keith Packard wrote:
> This leaves them enabled on IVB, but disables them on SNB as we've
> discovered (yet again) that there are hardware combinations that
> simply cannot run with them.
Oh well.
Applied,
Linus
On 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 entri
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 (bf9
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 doubl
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 cra
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 le
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 t
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
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
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? It
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 WIND
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 me
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 p
On Wednesday, April 13, 2011, Linus Torvalds
wrote:
> On Wednesday, April 13, 2011, H. Peter Anvin wrote:
>>
>> Yes. ?However, even if we *do* revert (and the time is running short on
>> not reverting) I would like to understand this particular one, simply
>> because
So I've been busily merging stuff, and just wanted to send out a quick
reminder that I warned people in the 39 announcement that this might
be a slightly shorter merge window than usual, so that I can avoid
having to make the -rc1 release from Japan using my slow laptop (doing
"allyesconfig" builds
On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote:
>
> I really hope there's also a voice that tells you to wait until .42 before
> cutting 3.0.0! :-)
So I'm toying with 3.0 (and in that case, it really would be "3.0",
not "3.0.0" - the stable team would get the third digit rather than
the four
Another advantage of switching numbering models (ie 3.0 instead of
2.8.x) would be that it would also make the "odd numbers are also
numbers" transition much more natural.
Because of our historical even/odd model, I wouldn't do a 2.7.x -
there's just too much history of 2.1, 2.3, 2.5 being develop
On Tue, May 24, 2011 at 10:36 AM, H. Peter Anvin wrote:
>
> I think this whole discussion misses the essence of the new development
> model, which is that we no longer do these kinds of feature-based major
> milestones.
Indeed.
It's not about features. It hasn't been about features for forever.
On Mon, Nov 7, 2011 at 5:27 AM, Dave Airlie wrote:
>
> are available in the git repository at:
>
> ?ssh://people.freedesktop.org/~/linux drm-fixes
No they are *not* available there.
Fix your pull script already! I mentioned this once earlier, your pull
requests are wrong, and point to things tha
Hmm, I don't know what caused this to trigger, but I'm adding both the
i915 people and the HDA people to the cc, and they can fight to the
death about this in the HDMI Thunderdome.
Guys: One.. Two.. Three.. FIGHT!
Linus
On Tue, Nov 8, 2011 at 6:55 AM, Nick Bowler wrote:
>
> Mod
Email sent to wrong people/list,
Linus
-- Forwarded message --
From: Alex Davis
Date: Tue, Nov 15, 2011 at 12:42 AM
Subject: [PATCH] i915: Fix bug where screen brightness is not restored
To: "linux-kernel at vger.kernel.org" ,
"torvalds at linux-foundation.org"
Fr
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
> Refere
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 : htt
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 : http://marc.info/?l=linu
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 at
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
>
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* i91
On Wed, Dec 22, 2010 at 8:59 AM, Chris Wilson
wrote:
> On Wed, 22 Dec 2010 17:24:36 +0100, Takashi Iwai wrote:
>> The commit 448f53a1ede54eb854d036abf54573281412d650
>> ? drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks
>>
>> causes a regression on a SandyBridge machine here.
>> The laptop
On Thu, Dec 23, 2010 at 1:32 AM, Alex Riesen wrote:
> On Thu, Dec 23, 2010 at 04:54, Linus Torvalds
> wrote:
>> Why does that code need to figure out some LVDS clock from the BIOS?
>> Why can't the code look at the actual hardware state or similar, since
>> presumabl
On Wed, Dec 29, 2010 at 10:21 AM, Randy Dunlap
wrote:
>
> The only significant difference that I can see in the kernel message log
> is this:
Hmm. I suspect that difference should have gone away with commit
92971021c6328 (Revert "drm: Don't try and disable an encoder that was
never enabled"), bu
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 probl
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 ther
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 talki
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 ac
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 clean
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
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 ple
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
> http://ki
On Wed, Nov 10, 2010 at 4:24 PM, Dave Airlie wrote:
>
> I've started taking Chris's pull requests now, so all the intel drm
> changes should start coming via my tree always now, unless they are pretty
> exceptional or I'm away.
Btw, Chris - don't do this:
commit 08deebf98783d3de553eed2c9b6b8dc
On Fri, Nov 12, 2010 at 9:21 AM, Chris Wilson
wrote:
>
> My bad, I cherry-picked it from our public drm-intel-next tree and thought
> it wise to include the cross-reference to explain the duplication and
> merge conflicts and to provide some additional test history into the commit.
> Obviously no
On Thu, Nov 18, 2010 at 3:34 PM, Jan Kara wrote:
>
> ?Just for info, UDF BKL removal patches seem to work fine but I want to
> give them some final SMP testing on Monday before pushing them to -next.
> I'm not sure how much people hurry with disabling the lock so if I should
> push them ASAP or wh
On Fri, Nov 19, 2010 at 2:02 AM, Chris Wilson
wrote:
>
> Note it also contains a couple of fluff fallout patches from the recent
> drm-fixes rebase. (I thought it would be wise to include any core drm
> changes in our testing before sending the request...)
F*%^ me, why does drm always have to be
On Fri, Nov 19, 2010 at 12:24 PM, Dave Airlie wrote:
>
> I also wonder if its partly psychological on your part, if I sent a
> number of smaller pull requests rather than queuing up things would
> you notice the line count less? If Chris sends things direct to you
> instead of me merging them and
On Thu, Oct 10, 2013 at 10:05 PM, Dave Airlie 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 this fixes the pr
On Thu, Oct 10, 2013 at 10:28 PM, Dave Airlie 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 designers decide
501 - 600 of 765 matches
Mail list logo
