On Thu, Sep 5, 2013 at 3:32 PM, Jesse Barnes 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 Xorg.0.log nor the dme
On Thu, Sep 5, 2013 at 3:51 PM, Linus Torvalds
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 just where a successf
On Thu, Sep 5, 2013 at 4:19 PM, Linus Torvalds
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 no
On Fri, Apr 19, 2013 at 2:09 PM, Sedat Dilek wrote:
>
> I have applied all three patches and see still call-traces.
> New are apparmor related messages.
Can you try the crazy rcu double-free debug hack?
See
https://lkml.org/lkml/2013/3/30/113
and I'm re-attaching the ugly-ass crazy hack pa
On Fri, Apr 19, 2013 at 3:34 PM, Sedat Dilek wrote:
>
> See attached dmesg.
This still has the bug Davidlohr pointed at:
>> This looks like what Emmanuel was/is running into:
>> https://lkml.org/lkml/2013/3/30/1
you need to move the "IS_ERR()" check before the sem_lock.
Linus
___
On Fri, Apr 19, 2013 at 3:55 PM, Sedat Dilek wrote:
>
> Davidlohr pointed to this patch (tested the triplet):
>
> ipc, sem: do not call sem_lock when bogus sma:
> https://lkml.org/lkml/2013/3/31/12
>
> Is that what you mean?
Yup.
Linus
___
dri-deve
On Thu, Jun 6, 2013 at 2:14 PM, Dave Airlie wrote:
>
> 7 files changed, 32 insertions(+), 42 deletions(-)
That's not at all what I get (including shortlog). I got
29 files changed, 188 insertions(+), 68 deletions(-)
from a lot of commits you don't list.
Linus
__
On Sat, Jun 29, 2013 at 8:05 AM, Sergey Meirovich wrote:
>
> 3.10-rc7 doesn't compile for me
>
> rathamahata@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 include/generated/uap
On Sat, Jun 29, 2013 at 2:07 PM, Sergey Meirovich wrote:
>> (and possibly the
>> mkregtable binary) and trying again might fix it.
>
> Removing mkregtable has indeed the compile issue for me. Thanks!
Ok, so something failed at an earlier build. That error is probably
long gone, though, since the
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 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 not
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 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"), but
On Thu, Jan 6, 2011 at 2:48 AM, Michal Hocko wrote:
>
> It seems that there is still a regression for intel graphic cards
> backlight. One report is https://bugzilla.kernel.org/show_bug.cgi?id=22672.
> I can reproduce the problem easily by:
> xset dpms force standby; sleep 3s; xset dpms force on
>
On Mon, Jan 10, 2011 at 2:59 PM, Dave Airlie wrote:
> Highlights:
> core/drivers: add support for high precision vblank timestamps
> radeon: pageflipping support, Gen2 PCIE support
> nouveau: reworked VRAM and VM support
> intel: better ILK/SNB powersaving support, Full GTT support
Lowlights: it'
On Mon, Jan 10, 2011 at 10:06 PM, Jesse Barnes wrote:
>
> Arg. It's been ok on my ILK systems, but Chris has found some issues with
> out watermarking code iirc; apparently we're underflowing the display FIFO,
> causing all sorts of trouble. If it works before the pull of Dave's tree,
> can y
On Tue, Jan 11, 2011 at 8:01 AM, Linus Torvalds
wrote:
>
> But yes, it worked before pulling Dave's tree, IOW, I haven't seen
> this message on this machine before.
.. and it's not a fluke. It happened again, and once more while I was
away from the machine and the screen
On Tue, Jan 11, 2011 at 11:12 AM, Jesse Barnes wrote:
>
> Have you tried reproducing it using xset dpms force off or similar?
That doesn't seem to do anything bad.
In fact, I think the second time it happened the screen never went
black - just the random photo thing was on. But no, forcing the s
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 t
On Tue, Jan 11, 2011 at 11:25 AM, Linus Torvalds
wrote:
>
> Maybe the screen just has to be inactive for a longer time: do you do
> some dynamic "let's power things down if nothing is changing"?
So since this is _almost_ reproducible for me, I tried bisecting it.
The
On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds
wrote:
>
> I'll test the merge, but I thought I'd send out this note already at
> this point, because I'm pretty sure this is it.
Hmm. The merge already has the *ERROR* Hangcheck (together with jerky
behavior), so it was
On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger
wrote:
>
> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA
> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1))
> During startup the framebuffer shows only stripes and a blank
> screen after suspend
On Tue, Jan 11, 2011 at 3:01 PM, Linus Torvalds
wrote:
>
> ... I'll test that drm-intel-staging commit.
Initial testing _seems_ to confirm that merging drm-intel-staging gets
rid of the problem. But I haven't spent a whole lot of time in the
screen saver. Will start driving kid
On Wed, Jan 12, 2011 at 5:32 AM, James Simmons wrote:
>
> Okay. The nouveau driver also uses the pitch as well. It
> really should be using the pitch field from drm_framebuffer instead of the
> line_length from fb_fix_screeninfo. This patch is just to make sure this
> is the issue. I will submit a
On Tue, Jan 11, 2011 at 10:03 PM, Dave Airlie wrote:
>
> I'm stuck at home with just my i5 laptop due to the office being shut due
> to the ongoing floods. But I've booted and ran this for a few hours and it
> seems to be better than the current tree. It contains a couple of patches
> to fix DMAR
On Wed, Jan 12, 2011 at 11:46 AM, Jesse Barnes wrote:
>
> Since I doubt we're actually offloading to our video decode kernels for
> Flash video on your machine
It's the latest 64-bit beta flash player, so maybe it does use hw acceleration.
> it could very well be a memory
On Wed, Jan 12, 2011 at 12:27 PM, Linus Torvalds
wrote:
> On Wed, Jan 12, 2011 at 11:46 AM, Jesse Barnes
> wrote:
>>
>> Since I doubt we're actually offloading to our video decode kernels for
>> Flash video on your machine
>
> It's the latest 64-bit be
On Wed, Jan 12, 2011 at 1:28 PM, Linus Torvalds
wrote:
>
> Oh, and I'm also seeing corruption on my sandybridge machine. No video
> involved, the gdm login screen is already corrupted this way. Similar
> odd shifted lines etc, so I'd assume it's related.
Hmm. I bi
On Wed, Jan 12, 2011 at 2:22 PM, Jesse Barnes wrote:
>
> Ah, ok. So it could be our internal FDI link is underrunning; it goes
> between the CPU and PCH and carries display bits.
I'm not sure it's an underrun or anything like that: the corruption is
long-term in the non-video case. So I take bac
On Sun, Jan 16, 2011 at 12:00 PM, Anca Emanuel wrote:
>
> In 2.6.37-git5 with the revert, the boot screen is changing the resolution.
> With this version, it don't.
So, can you make a nice report of that - along with 'dmesg' for _both_
cases - to the right people?
In this case, that would be at
On Sun, Jan 16, 2011 at 3:44 PM, Ben Skeggs wrote:
>
> I've tested a bit here, current git with the revert does appear to work
> fine for me.
So Anca has a 8800GT - is that what you're testing?
Also, there may be things like FB config issues and/or kernel command
line arguments. For example, on
Ok, so I have a new issue that I'm currently bisecting but that people
may be able to figure out even befor emy bisect finishes.
On my slow Atom netbook (that I'm planning on using as my traveling
companion for LCA), suspend-to-RAM takes a long time with current git.
It's quite noticeable - it use
On Wed, Jan 19, 2011 at 8:55 PM, Jeff Chua wrote:
>
> Rafael send out two patches earlier. Could be related. I was facing
> issue during resume.
No, I'm aware of the rcu-synchronize thing, this isn't it. This is
really at the suspend stage, and I had bisected it down to the drm
changes.
In fact,
On Thu, Jan 20, 2011 at 2:25 AM, Chris Wilson wrote:
>
> Right, the autoreported HEAD may have been already reset to 0 and so hit
> the wraparound bug which caused it to exit early without actually
> quiescing the ringbuffer.
Yeah, that would explain the issue.
> Another possibility is that I 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
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 master u
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 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 Sat, Feb 12, 2011 at 11:53 PM, Dave Airlie wrote:
>
> Probably should revert first, then work out what is crapping out libpciaccess.
Yeah, I'll revert. The patch is one of those "obviously a good idea,
but in practice it's not something we can change now".
Linus
On Sat, Feb 19, 2011 at 4:26 AM, Alex Riesen wrote:
> On Sat, Feb 19, 2011 at 13:11, Alex Riesen wrote:
>>> Lastly, could you verify that my patch at
>>> https://lkml.org/lkml/2011/2/16/447 fixes
>>> it for you too? (Make sure you're at max brightness before rebooting.)
>>
>> I'll try it now.
>>
On Tue, Feb 22, 2011 at 2:31 PM, Tino Keitel wrote:
>
> I just tried 2.6.38-rc6 on my ThinkPad X61s without any other DRM
> related patches, and my backlight issue is gone.
I applied Indan's fix in -rc6 (commit 951f3512dba5), since it had
several testers and seemed to simplify the code nicely too
On Tue, Feb 22, 2011 at 9:42 PM, Anca Emanuel wrote:
> General protection fault:
> http://i.imgur.com/TBJ6y.jpg
>
> dmesg: http://pastebin.com/qD8pR8QH
> config: http://pastebin.com/XEurtHWi
That's drivers/video/fbmem.c: fb_release(), and the "Code:"
disassembly shows that it is
1b: e8 f7 c0
On Wed, Feb 23, 2011 at 3:17 PM, Dave Airlie wrote:
>
> Nothing too major,
>
> Two regression fixers (one revert that got fixes properly elsewhere), some
> timestamp fixes and an agp module reload fix.
Pulled. However, what about the report from Pavel Machek :
> > drm/i915: Completely d
On Wed, Feb 23, 2011 at 9:16 AM, Anca Emanuel wrote:
>>
>> Looks like nouveafb took over from vesafb. Did you do anything special
>> to trigger this?
>
> No. Just boot the system.
Every boot?
And just out of interest, what happens if you don't have the vesafb
driver at all?
On Thu, Feb 24, 2011 at 5:20 AM, Anca Emanuel wrote:
>>
>> Every boot?
>
> Yes.
>
>> And just out of interest, what happens if you don't have the vesafb
>> driver at all?
>
> I used 'e' option from grub, removed the 'set gfxpayload = $linux_gfx_mode'
> and it works.
>
> dmesg: http://pastebin.com/
On Thu, Feb 24, 2011 at 4:48 PM, Anca Emanuel wrote:
>
> diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
> index e2bf953..e8f8925 100644
> --- a/drivers/video/fbmem.c
> +++ b/drivers/video/fbmem.c
> @@ -1511,6 +1511,7 @@ void remove_conflicting_framebuffers(struct
> apertures_struct *a,
On Thu, Jan 6, 2011 at 2:48 AM, Michal Hocko wrote:
>
> It seems that there is still a regression for intel graphic cards
> backlight. One report is https://bugzilla.kernel.org/show_bug.cgi?id=22672.
> I can reproduce the problem easily by:
> xset dpms force standby; sleep 3s; xset dpms force on
>
On Mon, Jan 10, 2011 at 2:59 PM, Dave Airlie wrote:
> Highlights:
> core/drivers: add support for high precision vblank timestamps
> radeon: pageflipping support, Gen2 PCIE support
> nouveau: reworked VRAM and VM support
> intel: better ILK/SNB powersaving support, Full GTT support
Lowlights: it'
On Mon, Jan 10, 2011 at 10:06 PM, Jesse Barnes
wrote:
>
> Arg. ?It's been ok on my ILK systems, but Chris has found some issues with
> out watermarking code iirc; apparently we're underflowing the display FIFO,
> causing all sorts of trouble. ?If it works before the pull of Dave's tree,
> can
On Tue, Jan 11, 2011 at 8:01 AM, Linus Torvalds
wrote:
>
> But yes, it worked before pulling Dave's tree, IOW, I haven't seen
> this message on this machine before.
.. and it's not a fluke. It happened again, and once more while I was
away from the machine and the screen
On Tue, Jan 11, 2011 at 11:12 AM, Jesse Barnes
wrote:
>
> Have you tried reproducing it using xset dpms force off or similar?
That doesn't seem to do anything bad.
In fact, I think the second time it happened the screen never went
black - just the random photo thing was on. But no, forcing the
On Tue, Jan 11, 2011 at 11:45 AM, Jesse Barnes
wrote:
>>
>> Maybe the screen just has to be inactive for a longer time: do you do
>> some dynamic "let's power things down if nothing is changing"?
>
> There are some timeouts, the FBC engine will recompress about once
> every 15s; the self-refresh
On Tue, Jan 11, 2011 at 11:25 AM, Linus Torvalds
wrote:
>
> Maybe the screen just has to be inactive for a longer time: do you do
> some dynamic "let's power things down if nothing is changing"?
So since this is _almost_ reproducible for me, I tried bisecting it.
The
On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds
wrote:
>
> I'll test the merge, but I thought I'd send out this note already at
> this point, because I'm pretty sure this is it.
Hmm. The merge already has the *ERROR* Hangcheck (together with jerky
behavior), so it was
601 - 700 of 1363 matches
Mail list logo
