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
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
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 there
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 talking about,
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 cleanup
On Tue, Aug 3, 2010 at 12:25 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Mon, 2 Aug 2010 16:55:03 -0700, Andrew Morton a...@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
On Sun, Aug 15, 2010 at 8:30 PM, Dave Airlie airl...@redhat.com 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,
On Sun, Aug 15, 2010 at 9:06 PM, Andy Lutomirski l...@myrealbox.com 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
On Wed, Nov 10, 2010 at 4:24 PM, Dave Airlie airl...@linux.ie 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
On Fri, Nov 12, 2010 at 9:21 AM, Chris Wilson ch...@chris-wilson.co.uk 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
On Thu, Nov 18, 2010 at 3:34 PM, Jan Kara j...@suse.cz 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
On Wed, Dec 22, 2010 at 8:59 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Wed, 22 Dec 2010 17:24:36 +0100, Takashi Iwai ti...@suse.de wrote:
The commit 448f53a1ede54eb854d036abf54573281412d650
drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks
causes a regression on a SandyBridge
On Thu, Dec 23, 2010 at 1:32 AM, Alex Riesen raa.l...@gmail.com wrote:
On Thu, Dec 23, 2010 at 04:54, Linus Torvalds
torva...@linux-foundation.org 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
On Wed, Dec 29, 2010 at 10:21 AM, Randy Dunlap randy.dun...@oracle.com 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
On Thu, Jan 6, 2011 at 2:48 AM, Michal Hocko mho...@suse.cz 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
On Mon, Jan 10, 2011 at 2:59 PM, Dave Airlie airl...@linux.ie 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
On Mon, Jan 10, 2011 at 10:06 PM, Jesse Barnes jbar...@virtuousgeek.org 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
On Tue, Jan 11, 2011 at 8:01 AM, Linus Torvalds
torva...@linux-foundation.org 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
On Tue, Jan 11, 2011 at 11:12 AM, Jesse Barnes jbar...@virtuousgeek.org 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 Tue, Jan 11, 2011 at 11:45 AM, Jesse Barnes jbar...@virtuousgeek.org 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
On Tue, Jan 11, 2011 at 11:25 AM, Linus Torvalds
torva...@linux-foundation.org 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
On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds
torva...@linux-foundation.org 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
On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger
borntrae...@de.ibm.com 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
On Tue, Jan 11, 2011 at 3:01 PM, Linus Torvalds
torva...@linux-foundation.org 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
On Wed, Jan 12, 2011 at 5:32 AM, James Simmons jsimm...@infradead.org 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
On Tue, Jan 11, 2011 at 10:03 PM, Dave Airlie airl...@linux.ie 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
On Wed, Jan 12, 2011 at 11:46 AM, Jesse Barnes jbar...@virtuousgeek.org 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
On Wed, Jan 12, 2011 at 12:27 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Wed, Jan 12, 2011 at 11:46 AM, Jesse Barnes jbar...@virtuousgeek.org
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
On Wed, Jan 12, 2011 at 1:28 PM, Linus Torvalds
torva...@linux-foundation.org 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
On Wed, Jan 12, 2011 at 2:22 PM, Jesse Barnes jbar...@virtuousgeek.org 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
On Sun, Jan 16, 2011 at 12:00 PM, Anca Emanuel anca.eman...@gmail.com 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
On Sun, Jan 16, 2011 at 3:44 PM, Ben Skeggs bske...@redhat.com 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.
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
On Wed, Jan 19, 2011 at 8:55 PM, Jeff Chua jeff.chua.li...@gmail.com 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
On Thu, Jan 20, 2011 at 2:25 AM, Chris Wilson ch...@chris-wilson.co.uk 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
On Thu, Jan 20, 2011 at 9:51 AM, Linus Torvalds
torva...@linux-foundation.org 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, so
On Thu, Feb 3, 2011 at 3:23 AM, Carlos R. Mafra crmaf...@gmail.com 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
On Thu, Feb 3, 2011 at 1:56 PM, Carlos Mafra crmaf...@gmail.com 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
On Thu, Feb 3, 2011 at 2:10 PM, Linus Torvalds
torva...@linux-foundation.org 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) which took
On Thu, Feb 3, 2011 at 4:06 PM, Dave Airlie airl...@gmail.com 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
On Thu, Feb 3, 2011 at 5:05 PM, Keith Packard kei...@keithp.com 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,
On Sat, Feb 19, 2011 at 4:26 AM, Alex Riesen raa.l...@gmail.com wrote:
On Sat, Feb 19, 2011 at 13:11, Alex Riesen raa.l...@gmail.com 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
On Wed, Feb 23, 2011 at 3:17 PM, Dave Airlie airl...@linux.ie 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 pa...@ucw.cz:
On Wed, Feb 23, 2011 at 9:16 AM, Anca Emanuel anca.eman...@gmail.com 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 anca.eman...@gmail.com 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:
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 in...@nul.nu wrote:
So please revert my patch and apply Takashi Iwai's, which fixes the
most
On Thu, Mar 10, 2011 at 5:23 PM, Indan Zupancic in...@nul.nu 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
On Tue, Mar 22, 2011 at 7:19 PM, Linus Torvalds
torva...@linux-foundation.org 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
On Wed, Mar 23, 2011 at 8:33 AM, Jesse Barnes jbar...@virtuousgeek.org 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
ihad...@research.bell-labs.com 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
On Thu, Mar 24, 2011 at 1:05 PM, Dave Airlie airl...@gmail.com 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
On Thu, Mar 24, 2011 at 5:07 PM, Dave Airlie airl...@gmail.com 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
On Thu, Mar 24, 2011 at 5:17 PM, Linus Torvalds
torva...@linux-foundation.org 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
On Mon, Apr 4, 2011 at 6:02 PM, Keith Packard kei...@keithp.com wrote:
On Tue, 5 Apr 2011 01:38:31 +0100 (IST), Dave Airlie airl...@linux.ie 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
On Wed, Apr 13, 2011 at 1:48 PM, Yinghai Lu ying...@kernel.org 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
+++
On Wed, Apr 13, 2011 at 2:23 PM, Yinghai Lu ying...@kernel.org 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
On Wednesday, April 13, 2011, H. Peter Anvin h...@zytor.com 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
On Mon, Apr 18, 2011 at 1:02 PM, Marcin Slusarz
marcin.slus...@gmail.com 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 r...@sisk.pl 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 li...@nerdbynature.de
Date : 2011-04-22 1:57 (9
On Wednesday, April 13, 2011, Linus Torvalds
torva...@linux-foundation.org wrote:
On Wednesday, April 13, 2011, H. Peter Anvin h...@zytor.com 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
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 mi...@elte.hu 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
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
On Tue, May 24, 2011 at 10:36 AM, H. Peter Anvin h...@zytor.com 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
On Tue, Jul 12, 2011 at 11:15 AM, Oleg Nesterov o...@redhat.com 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
On Sun, Aug 28, 2011 at 12:35 PM, Dave Jones da...@redhat.com 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
On Tue, Oct 4, 2011 at 9:34 AM, Dave Airlie airl...@linux.ie 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
On Mon, Nov 7, 2011 at 5:27 AM, Dave Airlie airl...@linux.ie 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
On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki r...@sisk.pl wrote:
Subject : Simultaneous cat and external keyboard input causing kernel panic
Submitter : Timo Jyrinki timo.jyri...@gmail.com
Date : 2011-11-03 12:14
Message-ID :
On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki r...@sisk.pl wrote:
Subject : [3.1 REGRESSION] Commit 5cec93c216db77c45f7ce970d46283bcb1933884
breaks the Chromium seccomp sandbox
Submitter : Nix n...@esperi.org.uk
Date : 2011-11-14 0:40
Message-ID :
On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki r...@sisk.pl wrote:
Subject : hugetlb oops on 3.1.0-rc8-devel
Submitter : Andy Lutomirski l...@amacapital.net
Date : 2011-11-01 22:20
Message-ID :
calcetrw1mpvcz2to5roaz1r6vnno+srhr-dha6_pkri2qic...@mail.gmail.com
References :
On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki r...@sisk.pl wrote:
Subject : [3.1-rc8 REGRESSION] sky2 hangs machine on turning off or
suspending
Submitter : Rafał Miłecki zaj...@gmail.com
Date : 2011-11-09 11:46
Message-ID :
On Tue, Dec 6, 2011 at 8:21 AM, Dave Airlie airl...@linux.ie 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
On Tue, Dec 6, 2011 at 8:36 AM, Dave Airlie airl...@gmail.com 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
On Mon, Dec 26, 2011 at 5:02 PM, Keith Packard kei...@keithp.com 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 Fri, Jan 6, 2012 at 7:06 AM, Dave Airlie airl...@linux.ie 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
On Wed, Jan 25, 2012 at 11:05 AM, Dave Airlie airl...@linux.ie 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
On Thu, Feb 23, 2012 at 11:52 AM, Chris Wilson ch...@chris-wilson.co.uk 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
On Thu, Feb 23, 2012 at 12:15 PM, Linus Torvalds
torva...@linux-foundation.org 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
On Thu, Feb 23, 2012 at 1:36 PM, Eugeni Dodonov
eugeni.dodo...@intel.com wrote:
Perhaps a stupid question, but does you tree has
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-nextid=9292f37e1f5c79400254dca46f83313488093825
from Dave's drm-next?
If it has, it would be the 1st time
On Mon, Mar 5, 2012 at 6:22 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
From: Alan Cox a...@linux.intel.com
[Resending with correct address for Linus]
Should I take this directly, or is there a pending DRM pull that will
contain this?
Linus
Guys,
I don't know if these kinds of things have been forwarded to you, but
there's apparently been several things like this going on - with the
finger pointing to the i915 driver apparently clearing random memory.
Often the end result seems to be list corruption or a NULL pointer
dereference in
On Fri, Mar 16, 2012 at 3:52 PM, Keith Packard kei...@keithp.com wrote:
We had a theory about hibernation -- unflushed FB writes that go astray
when the pages underneath the GTT get reassigned when switching from the
boot kernel to the resumed kernel.
Well, even without hibernation, one
On Sat, Mar 17, 2012 at 1:23 PM, Dave Airlie airl...@gmail.com wrote:
I did however get a flashback in google to this:
http://lists.fedoraproject.org/pipermail/scm-commits/2010-July/456636.html
Linus don't think we ever did work out why that worked, I wonder if we
lost something after that.
On Sat, Mar 17, 2012 at 3:09 PM, Hugh Dickins hu...@google.com wrote:
I've got to go out for an hour: I'll digest more and think more about
this when I get back. If someone could explain the original problem
with _MOVABLE, that would help me:
I do not believe we actually ever uncovered the
On Wed, Mar 21, 2012 at 3:47 AM, Dave Airlie airl...@linux.ie wrote:
(oh and any warnings you see in i915 are gcc's fault from what anyone can
see).
Christ those are annoying. Has anybody contacted the gcc people about this?
Linus
Btw, I think this came in through the DRM merge:
ERROR: mdfld_set_brightness [drivers/gpu/drm/gma500/gma500_gfx.ko]
undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
this is just make ARCH=i386 with allmodconfig.
Linus
On Wed, Mar 21, 2012 at
.
Linus
On Sat, Apr 21, 2012 at 9:07 PM, Nick Bowler nbow...@elliptictech.com 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
These guys seem to be recently introduced:
[drm:gen6_sanitize_pm] *ERROR* Power management discrepancy:
GEN6_RP_INTERRUPT_LIMITS expected 1700, was 1206
[drm:gen6_sanitize_pm] *ERROR* Power management discrepancy:
GEN6_RP_INTERRUPT_LIMITS expected 1707, was 1700
This is on my
On Fri, May 25, 2012 at 2:17 AM, Sumit Semwal sumit.sem...@linaro.org 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
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
torva...@linux-foundation.org wrote
On Mon, May 28, 2012 at 12:06 AM, Chris Wilson ch...@chris-wilson.co.uk 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
On Wed, May 30, 2012 at 1:27 AM, Daniel Vetter dan...@ffwll.ch 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
On Wed, May 30, 2012 at 9:00 AM, Daniel Vetter dan...@ffwll.ch 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
On Wed, May 30, 2012 at 12:42 AM, Daniel Vetter dan...@ffwll.ch 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
On Wed, May 30, 2012 at 12:25 AM, Chris Wilson ch...@chris-wilson.co.uk 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
On Fri, Jun 8, 2012 at 3:12 PM, Chris Wilson ch...@chris-wilson.co.uk 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
On Fri, Jun 8, 2012 at 3:12 PM, Chris Wilson ch...@chris-wilson.co.uk 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
On Fri, Jun 8, 2012 at 3:52 PM, Chris Wilson ch...@chris-wilson.co.uk 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
On Mon, Jul 16, 2012 at 12:42 PM, Dave Airlie airl...@linux.ie 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
1 - 100 of 704 matches
Mail list logo
