On Fri, May 25, 2012 at 2:17 AM, Sumit Semwal wrote:
>
> I am really sorry - I goofed up in the git URL (sent the ssh URL
> instead).
I was going to send you an acerbic email asking for your private ssh
key, but then noticed that you had sent another email with the public
version of the git tree.
Oops. This got sent without the right Cc, and the wrong subject (the
people who were *supposed* to be cc'd instead got into the subject
line, and the subject line got dropped entirely).
Linus
On Sun, May 27, 2012 at 4:09 PM, Linus Torvalds
wrote:
> A new wor
On Mon, May 28, 2012 at 12:06 AM, Chris Wilson wrote:
>
> No, the i915_error_state had everything I needed to see. It is the old
> ddx bug that was hardcoding a maximum relocation address that never
> corresponded with an actual hw limit. As soon we try to use memory above
> that value, the GPU de
On Wed, May 30, 2012 at 1:27 AM, Daniel Vetter wrote:
>
> Ok, Chris couldn't reproduce this on his mba. Can you please boot with
> drm.debug=0xe, reproduce the noise and then attach the full dmesg?
Hmm. Now *I* can't reproduce it either.
I have updated my system in the meantime, so maybe this is
On Wed, May 30, 2012 at 9:00 AM, Daniel Vetter wrote:
>
> Hm, that's pretty strange that you can't reproduce this any more. We check
> this has_edp stuff once at boot and then never touch it again.
Actually, I think I just figured out how to reproduce it: try to
suspend with the micro-DP <-> VGA
On Wed, May 30, 2012 at 12:42 AM, Daniel Vetter wrote:
>
> Really, please upgrade your userspace - this is by far not the only bug
> fixed since then that can result in a gpu hang.
I *can't* upgrade my userpsace.
F14 is the last one that has a sane window manager. After that, the
gnome3 shit hap
On Wed, May 30, 2012 at 12:25 AM, Chris Wilson wrote:
>
> You've reported this bug in the past, though maybe on a different machine:
It's quite likely the same machine - but in the past it may have
happened once per six months or something. Now it happened twice in
two days.
Li
This breaks things for me. Bisect says:
9e612a008fa7fe493a473454def56aa321479495 is the first bad commit
commit 9e612a008fa7fe493a473454def56aa321479495
Author: Chris Wilson
Date: Thu May 31 13:08:53 2012 +0100
drm/i915/crt: Do not rely upon the HPD presence pin
Whilst most monitors d
On Fri, Jun 8, 2012 at 3:12 PM, Chris Wilson wrote:
>
> Shock, horror, that's how it is meant to work when we cannot determine
> whether or not there is actually an output attached to the VGA.
We don't break existing installations. And that existing installation
has worked for a long time. You br
On Fri, Jun 8, 2012 at 3:12 PM, Chris Wilson wrote:
>
> So it falls back to
> load-detection, which in your case it cannot do since all the available
> pipes are assigned and so it just reports the VGA connection as unknown.
Btw, it's a singularly stupid decision to say "Ok, I *know* I
On Fri, Jun 8, 2012 at 3:52 PM, Chris Wilson wrote:
>
> And that was my point. You were blaming the patch for making you aware
> of existing behaviour that results in utter confusion, for as Alex
> points out there is no sane way for userspace to handle the unknown
> connection status from the det
On Mon, Jul 16, 2012 at 12:42 PM, Dave Airlie wrote:
>
> Sorry been travelling and a bit neglectful of some of Alan's
> patches,
I actually took the three Alan sent me already, exactly because they
seemed harmless and I didn't know your schedule.
Your pull has a "gma500: Fix frequency detection"
[ This 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 wrote:
> Ping!
>
> No X for me with 3.6-rc2.
Can you possibly bisect it, at least par
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 Tue, Jul 12, 2011 at 11:15 AM, Oleg Nesterov wrote:
>
> I tried many times to ask about the supposed behaviour of
> block_all_signals() in drm, but it seems nobody can answer.
It's always been broken, I think. We've had threads about it before
(years and years ago). I'd certainly be willing to
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, 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
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 Sat, Jun 29, 2013 at 4:52 PM, Sergey Meirovich 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 mkregtable binary
ha
This one may have been going on for some time - I haven't updated the
old Intel Mac Mini in a while.
And by "not updated" I also mean that it's some really old user-space:
the machine is running F14, and cannot be updated to anything newer
without having to reinstall everything because of a stupid
On Sat, Aug 3, 2013 at 6:08 PM, Dave Airlie wrote:
>
> Alex Deucher (1):
> drm/radeon: fix 64 bit divide in SI spm code
That code is stupid. You're asking for a 64-by-64 divide, when the
divisor is clearly an "int" (100 and 1000 respectively).
Why is it doing "div64_s64()" instead of the s
On Fri, Aug 2, 2013 at 2:26 AM, Ville Syrjälä
wrote:
>
> Looks like this could happen when you go to DPMS_OFF. After we've turned
> off the the pipe, get_pipe_config() gives a mostly zeroed pipe_config
> (including pixel_multiplier), and then in the case of SDVO, we go and
> check it against the e
On Thu, Aug 29, 2013 at 4:08 PM, Dave Airlie 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
_
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
On Sat, Aug 31, 2013 at 4:02 PM, Linus Torvalds
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 someho
On Sun, Sep 1, 2013 at 11:54 PM, Daniel Vetter 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
>> sle
On Thu, Sep 5, 2013 at 3:41 AM, Dave Airlie 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 this, I just
On Thu, Sep 5, 2013 at 3:51 PM, Linus Torvalds
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 in
501 - 600 of 1363 matches
Mail list logo
