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
On Sun, Apr 17, 2011 at 10:09 AM, Joerg Roedel j...@8bytes.org wrote:
On Sat, Apr 16, 2011 at 02:54:04PM -0400, Jerome Glisse wrote:
If you want to go the printk way you can add printk before each test
ring_test, ib_test in r600.c this 2 functions are the own that might
trigger the first GPU
On Mon, Apr 18, 2011 at 11:23 AM, Alex Deucher alexdeuc...@gmail.com wrote:
On Sun, Apr 17, 2011 at 10:09 AM, Joerg Roedel j...@8bytes.org wrote:
On Sat, Apr 16, 2011 at 02:54:04PM -0400, Jerome Glisse wrote:
If you want to go the printk way you can add printk before each test
ring_test,
On Mon, Apr 18, 2011 at 11:33 AM, Alex Deucher alexdeuc...@gmail.com wrote:
On Mon, Apr 18, 2011 at 11:29 AM, Jerome Glisse j.gli...@gmail.com wrote:
On Mon, Apr 18, 2011 at 11:23 AM, Alex Deucher alexdeuc...@gmail.com wrote:
On Sun, Apr 17, 2011 at 10:09 AM, Joerg Roedel j...@8bytes.org wrote:
On Mon, Apr 18, 2011 at 11:59 AM, Jerome Glisse j.gli...@gmail.com wrote:
On Mon, Apr 18, 2011 at 11:33 AM, Alex Deucher alexdeuc...@gmail.com wrote:
On Mon, Apr 18, 2011 at 11:29 AM, Jerome Glisse j.gli...@gmail.com wrote:
On Mon, Apr 18, 2011 at 11:23 AM, Alex Deucher alexdeuc...@gmail.com
On Sat, Apr 16, 2011 at 02:54:04PM -0400, Jerome Glisse wrote:
If you want to go the printk way you can add printk before each test
ring_test, ib_test in r600.c this 2 functions are the own that might
trigger the first GPU gart activities.
Okay, I found the place in source that triggers this.
On Sun, Apr 17, 2011 at 10:09 AM, Joerg Roedel j...@8bytes.org wrote:
On Sat, Apr 16, 2011 at 02:54:04PM -0400, Jerome Glisse wrote:
If you want to go the printk way you can add printk before each test
ring_test, ib_test in r600.c this 2 functions are the own that might
trigger the first GPU
On Fri, Apr 15, 2011 at 09:06:41PM +0200, Ingo Molnar wrote:
* Alexandre Demers alexandre.f.dem...@gmail.com wrote:
On 11-04-15 10:27 AM, Joerg Roedel wrote:
On Fri, Apr 15, 2011 at 10:16:59AM -0400, Alexandre Demers wrote:
Ok, I'll test it today. Should I apply it on a clean rc3
On Fri, Apr 15, 2011 at 12:18:02PM -0700, Yinghai Lu wrote:
On 04/15/2011 12:06 PM, Ingo Molnar wrote:
Joerg, mind submitting it with a changelog that includes everything we
learned
about this bug and all the Tested-by's in place?
Is anyone of the opinion that we should try to
* Joerg Roedel j...@8bytes.org wrote:
On Fri, Apr 15, 2011 at 09:06:41PM +0200, Ingo Molnar wrote:
* Alexandre Demers alexandre.f.dem...@gmail.com wrote:
On 11-04-15 10:27 AM, Joerg Roedel wrote:
On Fri, Apr 15, 2011 at 10:16:59AM -0400, Alexandre Demers wrote:
Ok, I'll test
On Fri, Apr 15, 2011 at 12:11:28PM -0400, Jerome Glisse wrote:
Do you also got the write if you load radeon with radeon.no_wb=1 ?
I think at this address it's the wb page, or maybe the cp as wb likely
take only one page
radeon.no_wb=1 makes no difference. The box still reboots.
Joerg
On Sat, Apr 16, 2011 at 12:35 PM, Joerg Roedel j...@8bytes.org wrote:
On Fri, Apr 15, 2011 at 12:11:28PM -0400, Jerome Glisse wrote:
Do you also got the write if you load radeon with radeon.no_wb=1 ?
I think at this address it's the wb page, or maybe the cp as wb likely
take only one page
On Thu, Apr 14, 2011 at 05:34:46PM -0400, Alex Deucher wrote:
On Thu, Apr 14, 2011 at 5:09 PM, Joerg Roedel j...@8bytes.org wrote:
Actually, the nb gart is part of the cpu. It is part of the cpu north
bridge and can translate io and cpu accesses. In fact, it is a remapper
of physical
On Don, 2011-04-14 at 23:09 +0200, Joerg Roedel wrote:
On Thu, Apr 14, 2011 at 10:28:43AM -0400, Alex Deucher wrote:
On Thu, Apr 14, 2011 at 4:56 AM, Joerg Roedel j...@8bytes.org wrote:
And this makes a difference, with this change on-top of -rc3 the box boots
fine. So there seems to be
On Fri, Apr 15, 2011 at 10:26:34AM +0200, Michel Dänzer wrote:
On Don, 2011-04-14 at 23:09 +0200, Joerg Roedel wrote:
On Thu, Apr 14, 2011 at 10:28:43AM -0400, Alex Deucher wrote:
On Thu, Apr 14, 2011 at 4:56 AM, Joerg Roedel j...@8bytes.org wrote:
And this makes a difference, with this
On Wed, Apr 13, 2011 at 07:33:40PM -0700, Linus Torvalds wrote:
we definitely want to also understand the reason for things not
working, even if we do revert..
Okay, here it is.
After experimenting with different configurations for the north-bridge
it turned out that a GART related MCE fires
* Joerg Roedel j...@8bytes.org wrote:
On Wed, Apr 13, 2011 at 07:33:40PM -0700, Linus Torvalds wrote:
we definitely want to also understand the reason for things not
working, even if we do revert..
Okay, here it is.
After experimenting with different configurations for the
On Fri, Apr 15, 2011 at 04:04:45PM +0200, Andreas Herrmann wrote:
What about tagging this patch for stable/longterm releases?
Potentially there are other cases where certain combinations of
hardware(GPUs)/drivers/whatsoever might trigger a GartTlbWlkErr. If
the BIOS doesn't follow the BKDG
On Fri, Apr 15, 2011 at 03:16:50PM +0200, Ingo Molnar wrote:
Ok, but how did the allocation changes start triggering this error in
v2.6.39-rc1? There must still be some layout specific thing here, right?
Do we understand the details of that as well?
Well, thinking again about this, the GPU
On Fri, Apr 15, 2011 at 10:33 AM, Joerg Roedel j...@8bytes.org wrote:
On Fri, Apr 15, 2011 at 03:16:50PM +0200, Ingo Molnar wrote:
Ok, but how did the allocation changes start triggering this error in
v2.6.39-rc1? There must still be some layout specific thing here, right?
Do we understand the
On Fri, Apr 15, 2011 at 11:46 AM, Joerg Roedel j...@8bytes.org wrote:
On Fri, Apr 15, 2011 at 03:16:50PM +0200, Ingo Molnar wrote:
Ok, but how did the allocation changes start triggering this error in
v2.6.39-rc1? There must still be some layout specific thing here, right?
Do we understand the
On Fri, Apr 15, 2011 at 03:11:52PM +0200, Joerg Roedel wrote:
On Wed, Apr 13, 2011 at 07:33:40PM -0700, Linus Torvalds wrote:
we definitely want to also understand the reason for things not
working, even if we do revert..
Okay, here it is.
After experimenting with different
On Thu, Apr 14, 2011 at 05:34:46PM -0400, Alex Deucher wrote:
On Thu, Apr 14, 2011 at 5:09 PM, Joerg Roedel j...@8bytes.org wrote:
On Thu, Apr 14, 2011 at 10:28:43AM -0400, Alex Deucher wrote:
On Thu, Apr 14, 2011 at 4:56 AM, Joerg Roedel j...@8bytes.org wrote:
And this makes a difference,
On 11-04-15 10:27 AM, Joerg Roedel wrote:
On Fri, Apr 15, 2011 at 10:16:59AM -0400, Alexandre Demers wrote:
Ok, I'll test it today. Should I apply it on a clean rc3 without any of
the other patches?
Yes, apply it just on -rc3 without any other patch.
BTW, may I suggest adding the info under
* Alexandre Demers alexandre.f.dem...@gmail.com wrote:
On 11-04-15 10:27 AM, Joerg Roedel wrote:
On Fri, Apr 15, 2011 at 10:16:59AM -0400, Alexandre Demers wrote:
Ok, I'll test it today. Should I apply it on a clean rc3 without any of
the other patches?
Yes, apply it just on -rc3
On 04/15/2011 12:06 PM, Ingo Molnar wrote:
Joerg, mind submitting it with a changelog that includes everything we
learned
about this bug and all the Tested-by's in place?
Is anyone of the opinion that we should try to revert the allocation
order/alignment changes in addition to this
On 04/13/2011 07:07 PM, Dave Airlie wrote:
Okay, staring at this, it definitely seems toxic to overlay the GART
over memory areas reserved by the BIOS. If I were to guess, I would say
that the problem here seems to be that the kernel thinks it is
overlaying 64 MiB of memory, but the actual
On Wed, 13 Apr 2011 19:33:40 -0700
Linus Torvalds torva...@linux-foundation.org wrote:
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
On Wed, Apr 13, 2011 at 06:58:46PM -0700, H. Peter Anvin wrote:
On 04/13/2011 12:14 PM, Yinghai Lu wrote:
so looks bios program wrong address to the radon card?
Okay, staring at this, it definitely seems toxic to overlay the GART
over memory areas reserved by the BIOS. If I were to
On Thu, Apr 14, 2011 at 6:56 PM, Joerg Roedel j...@8bytes.org wrote:
On Wed, Apr 13, 2011 at 06:58:46PM -0700, H. Peter Anvin wrote:
On 04/13/2011 12:14 PM, Yinghai Lu wrote:
so looks bios program wrong address to the radon card?
Okay, staring at this, it definitely seems toxic to
On Thu, Apr 14, 2011 at 01:03:37PM +0900, Tejun Heo wrote:
Hello,
On Wed, Apr 13, 2011 at 07:33:40PM -0700, Linus Torvalds wrote:
On Wednesday, April 13, 2011, Linus Torvalds
torva...@linux-foundation.org wrote:
On Wednesday, April 13, 2011, H. Peter Anvin h...@zytor.com wrote:
On Thu, Apr 14, 2011 at 4:56 AM, Joerg Roedel j...@8bytes.org wrote:
On Wed, Apr 13, 2011 at 06:58:46PM -0700, H. Peter Anvin wrote:
On 04/13/2011 12:14 PM, Yinghai Lu wrote:
so looks bios program wrong address to the radon card?
Okay, staring at this, it definitely seems toxic to
On 04/14/2011 02:11 AM, Ingo Molnar wrote:
I'd strongly suggest we revert back to the old and proven allocation order,
as
long as it results in valid layouts. Even if we figure out this particular
GART/GTT assumption there might be a dozen others in other types of hardware.
Yes, but we
On Thu, Apr 14, 2011 at 10:28:43AM -0400, Alex Deucher wrote:
On Thu, Apr 14, 2011 at 4:56 AM, Joerg Roedel j...@8bytes.org wrote:
And this makes a difference, with this change on-top of -rc3 the box boots
fine. So there seems to be some dependency between the GART base and the GTT
base
On Thu, Apr 14, 2011 at 5:09 PM, Joerg Roedel j...@8bytes.org wrote:
On Thu, Apr 14, 2011 at 10:28:43AM -0400, Alex Deucher wrote:
On Thu, Apr 14, 2011 at 4:56 AM, Joerg Roedel j...@8bytes.org wrote:
And this makes a difference, with this change on-top of -rc3 the box boots
fine. So there
* Joerg Roedel j...@8bytes.org wrote:
The problem does not happen with 2.6.38. I try to bisect this further
down to a commit. Alex, please let me know if you need any further
information.
If you can bisect it, that would be great. Thanks,
Bisecting actually gave a very weird
On Wed, Apr 13, 2011 at 08:46:09AM +0200, Ingo Molnar wrote:
Could you please send the before/after bootlog (in particular all memory init
messages included) and your .config?
before: f005fe12b90c: x86-64: Move out cleanup higmap [_brk_end, _end) out
of init_memory_mapping()
after:
On 04/13/2011 10:21 AM, Joerg Roedel wrote:
First of all, I bisected between v2.6.37-rc2..f005fe12b90c which where
only a couple of patches and merged v2.6.38-rc4 in at every step. There
was no failure found.
Then I tried this again, but this time I merged v2.6.38-rc5 at every
step and was
On 04/13/2011 10:21 AM, Joerg Roedel wrote:
On Wed, Apr 13, 2011 at 08:46:09AM +0200, Ingo Molnar wrote:
First of all, I bisected between v2.6.37-rc2..f005fe12b90c which where
only a couple of patches and merged v2.6.38-rc4 in at every step. There
was no failure found.
Then I tried this
On 04/13/2011 10:21 AM, Joerg Roedel wrote:
On Wed, Apr 13, 2011 at 08:46:09AM +0200, Ingo Molnar wrote:
Could you please send the before/after bootlog (in particular all memory
init
messages included) and your .config?
before: f005fe12b90c: x86-64: Move out cleanup higmap [_brk_end,
On Wed, Apr 13, 2011 at 11:51:39AM -0700, H. Peter Anvin wrote:
On 04/13/2011 10:21 AM, Joerg Roedel wrote:
First of all, I bisected between v2.6.37-rc2..f005fe12b90c which where
only a couple of patches and merged v2.6.38-rc4 in at every step. There
was no failure found.
Then I tried
On Wed, Apr 13, 2011 at 11:39:29AM -0700, H. Peter Anvin wrote:
On 04/13/2011 10:21 AM, Joerg Roedel wrote:
On Wed, Apr 13, 2011 at 08:46:09AM +0200, Ingo Molnar wrote:
Could you please send the before/after bootlog (in particular all memory
init
messages included) and your .config?
On Wed, Apr 13, 2011 at 12:14:55PM -0700, Yinghai Lu wrote:
thanks for the bisecting...
so those two patches uncover some problems.
[0.00] Checking aperture...
[0.00] No AGP bridge found
[0.00] Node 0: aperture @ a000 size 32 MB
[0.00] Aperture
On Wed, Apr 13, 2011 at 3:14 PM, Yinghai Lu ying...@kernel.org wrote:
On 04/13/2011 10:21 AM, Joerg Roedel wrote:
On Wed, Apr 13, 2011 at 08:46:09AM +0200, Ingo Molnar wrote:
First of all, I bisected between v2.6.37-rc2..f005fe12b90c which where
only a couple of patches and merged v2.6.38-rc4
On 04/13/2011 12:34 PM, Joerg Roedel wrote:
On Wed, Apr 13, 2011 at 12:14:55PM -0700, Yinghai Lu wrote:
thanks for the bisecting...
so those two patches uncover some problems.
[0.00] Checking aperture...
[0.00] No AGP bridge found
[0.00] Node 0: aperture @ a000
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 04/13/2011 01:54 PM, Linus Torvalds wrote:
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
---
On Wed, Apr 13, 2011 at 01:48:48PM -0700, Yinghai Lu wrote:
- addr = memblock_find_in_range(0, 1ULL32, aper_size, 512ULL20);
+ addr = memblock_find_in_range(0, 1ULL32, aper_size, 512ULL21);
Btw, while looking at this code I wondered why the 512M goal is enforced
by the alignment. Start
On 04/13/2011 02:50 PM, Joerg Roedel wrote:
On Wed, Apr 13, 2011 at 01:48:48PM -0700, Yinghai Lu wrote:
-addr = memblock_find_in_range(0, 1ULL32, aper_size, 512ULL20);
+addr = memblock_find_in_range(0, 1ULL32, aper_size, 512ULL21);
Btw, while looking at this code I wondered why the
On 04/13/2011 02:50 PM, Joerg Roedel wrote:
On Wed, Apr 13, 2011 at 01:48:48PM -0700, Yinghai Lu wrote:
-addr = memblock_find_in_range(0, 1ULL32, aper_size, 512ULL20);
+addr = memblock_find_in_range(0, 1ULL32, aper_size, 512ULL21);
Btw, while looking at this code I wondered why the
On 04/13/2011 02:59 PM, Yinghai Lu wrote:
On 04/13/2011 02:50 PM, Joerg Roedel wrote:
On Wed, Apr 13, 2011 at 01:48:48PM -0700, Yinghai Lu wrote:
- addr = memblock_find_in_range(0, 1ULL32, aper_size, 512ULL20);
+ addr = memblock_find_in_range(0, 1ULL32, aper_size, 512ULL21);
Btw, while
On Wed, Apr 13, 2011 at 03:01:10PM -0700, H. Peter Anvin wrote:
On 04/13/2011 02:50 PM, Joerg Roedel wrote:
On Wed, Apr 13, 2011 at 01:48:48PM -0700, Yinghai Lu wrote:
- addr = memblock_find_in_range(0, 1ULL32, aper_size, 512ULL20);
+ addr = memblock_find_in_range(0, 1ULL32, aper_size,
On 04/13/2011 03:22 PM, Joerg Roedel wrote:
On Wed, Apr 13, 2011 at 03:01:10PM -0700, H. Peter Anvin wrote:
On 04/13/2011 02:50 PM, Joerg Roedel wrote:
On Wed, Apr 13, 2011 at 01:48:48PM -0700, Yinghai Lu wrote:
- addr = memblock_find_in_range(0, 1ULL32, aper_size, 512ULL20);
+ addr =
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 04/13/2011 04:39 PM, Linus Torvalds wrote:
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
On 04/13/2011 12:14 PM, Yinghai Lu wrote:
so those two patches uncover some problems.
[0.00] Checking aperture...
[0.00] No AGP bridge found
[0.00] Node 0: aperture @ a000 size 32 MB
[0.00] Aperture pointing to e820 RAM. Ignoring.
[0.00] Your
On 04/13/2011 04:39 PM, Linus Torvalds wrote:
- Choice #2: understand exactly _what_ goes wrong, and fix it
analytically (ie by _understanding_ the problem, and being able to
solve it exactly, and in a way you can argue about without having to
resort to magic happens).
Now, the whole
On Wed, 2011-04-13 at 18:58 -0700, H. Peter Anvin wrote:
On 04/13/2011 12:14 PM, Yinghai Lu wrote:
so those two patches uncover some problems.
[0.00] Checking aperture...
[0.00] No AGP bridge found
[0.00] Node 0: aperture @ a000 size 32 MB
[
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
Hello,
On Wed, Apr 13, 2011 at 07:33:40PM -0700, Linus Torvalds wrote:
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 Mon, Apr 11, 2011 at 05:40:11PM -0700, Linus Torvalds wrote:
Let's hope the release cycle continues like this. I _like_ it when
people really seem to follow the whole big changes during the merge
window rules.
Sorry for disturbing the silence, but radeon seems to have issues. I
tested -rc3
On Tue, Apr 12, 2011 at 5:02 AM, Joerg Roedel j...@8bytes.org wrote:
On Mon, Apr 11, 2011 at 05:40:11PM -0700, Linus Torvalds wrote:
Let's hope the release cycle continues like this. I _like_ it when
people really seem to follow the whole big changes during the merge
window rules.
Sorry for
On Tue, Apr 12, 2011 at 10:15:11AM -0400, Alex Deucher wrote:
On Tue, Apr 12, 2011 at 5:02 AM, Joerg Roedel j...@8bytes.org wrote:
On Mon, Apr 11, 2011 at 05:40:11PM -0700, Linus Torvalds wrote:
Let's hope the release cycle continues like this. I _like_ it when
people really seem to follow
Already tracking it here: https://bugzilla.kernel.org/show_bug.cgi?id=33012
Same problem, same culprit commit.
--
Alexandre Demers
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, 12 Apr 2011, Joerg Roedel wrote:
Bisecting actually gave a very weird result. It points to
d2137d5af4259f50c19addb8246a186c9ffac325
which is a merge-commit in the x86 tree. Even more weird is that this
notebook is the only machine with these symptoms, all my other boxes are
65 matches
Mail list logo
