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 I think it may very well be a
On Mon, Apr 18, 2011 at 11:59 AM, Jerome Glisse wrote:
> On Mon, Apr 18, 2011 at 11:33 AM, Alex Deucher wrote:
>> On Mon, Apr 18, 2011 at 11:29 AM, Jerome Glisse wrote:
>>> On Mon, Apr 18, 2011 at 11:23 AM, Alex Deucher
>>> wrote:
On Sun, Apr 17, 2011 at 10:09 AM, Joerg Roedel wrote:
>>>
On Mon, Apr 18, 2011 at 11:33 AM, Alex Deucher wrote:
> On Mon, Apr 18, 2011 at 11:29 AM, Jerome Glisse wrote:
>> On Mon, Apr 18, 2011 at 11:23 AM, Alex Deucher wrote:
>>> On Sun, Apr 17, 2011 at 10:09 AM, Joerg Roedel wrote:
On Sat, Apr 16, 2011 at 02:54:04PM -0400, Jerome Glisse wrote:
>
On Mon, Apr 18, 2011 at 11:29 AM, Jerome Glisse wrote:
> On Mon, Apr 18, 2011 at 11:23 AM, Alex Deucher wrote:
>> On Sun, Apr 17, 2011 at 10:09 AM, Joerg Roedel 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
On Mon, Apr 18, 2011 at 11:23 AM, Alex Deucher wrote:
> On Sun, Apr 17, 2011 at 10:09 AM, Joerg Roedel 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 funct
On Sun, Apr 17, 2011 at 10:09 AM, Joerg Roedel 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 gart act
On Sun, Apr 17, 2011 at 10:09 AM, Joerg Roedel 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 gart act
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 thi
On Sat, Apr 16, 2011 at 12:35 PM, Joerg Roedel 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
>
> radeon.no
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.
Joer
* Joerg Roedel wrote:
> On Fri, Apr 15, 2011 at 09:06:41PM +0200, Ingo Molnar wrote:
> >
> > * Alexandre Demers 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
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 sh
On Fri, Apr 15, 2011 at 09:06:41PM +0200, Ingo Molnar wrote:
>
> * Alexandre Demers 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
> > >>
On 04/15/2011 12:18 PM, 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 revert the all
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
* Alexandre Demers 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 without any other patch.
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 inf
On Thu, Apr 14, 2011 at 05:34:46PM -0400, Alex Deucher wrote:
> On Thu, Apr 14, 2011 at 5:09 PM, 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 wrote:
> >> > And this makes a difference, with this change on-
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 con
On Fri, Apr 15, 2011 at 11:46 AM, Joerg Roedel 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 details
On Fri, Apr 15, 2011 at 10:33 AM, Joerg Roedel 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 details
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 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?
No, I must admit that I lack enough knowl
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 BK
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 bug 33012 in kernel bugzilla?
> This c
On 11-04-15 09:11 AM, 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 configurations for the north-
* 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 configurations for the north-bridge
> it
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
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 wrote:
> > > > And this makes a difference, with this chang
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 wrote:
> > > And this makes a difference, with this change on-top of -rc3 the box boots
> > > fine. So there seems to be some de
On Thu, Apr 14, 2011 at 05:34:46PM -0400, Alex Deucher wrote:
> On Thu, Apr 14, 2011 at 5:09 PM, Joerg Roedel 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 memory address
On Thu, Apr 14, 2011 at 5:09 PM, 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 wrote:
>> > And this makes a difference, with this change on-top of -rc3 the box boots
>> > fine. So there seems to be some depende
On Thu, Apr 14, 2011 at 10:28:43AM -0400, Alex Deucher wrote:
> On Thu, Apr 14, 2011 at 4:56 AM, Joerg Roedel 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 even when th
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, b
On Thu, Apr 14, 2011 at 4:56 AM, Joerg Roedel 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 overla
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
> > wrote:
> > > On Wednesday, April 13, 2011, H. Peter Anvin wrote:
> > >>
> > >> Yes. However, even if we *d
* Joerg Roedel 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 overlay the GART
> > over
On Thu, Apr 14, 2011 at 6:56 PM, Joerg Roedel 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 overla
On Wed, Apr 13, 2011 at 03:31:09PM -0700, H. Peter Anvin wrote:
> 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:
>
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
On Wed, 13 Apr 2011 19:33:40 -0700
Linus Torvalds wrote:
> 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 understa
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
Hello,
On Wed, Apr 13, 2011 at 07:33:40PM -0700, Linus Torvalds wrote:
> 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 lik
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 I think it may very well be a
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 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 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 w
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]
On 04/13/2011 04:39 PM, Linus Torvalds wrote:
> 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 TOT
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 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, 1ULL<<32, aper_size, 512ULL<<20);
>>>
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, 1ULL<<32, aper_size, 512ULL<<20);
> >> + addr = memblock_find_in_range(0, 1ULL<<32,
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, 1ULL<<32, aper_size, 512ULL<<20);
>>> + addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<21)
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, 1ULL<<32, aper_size, 512ULL<<20);
>> +addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<21);
>
> Btw, while looking at this code I wond
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, 1ULL<<32, aper_size, 512ULL<<20);
>> +addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<21);
>
> Btw, while looking at this code I wond
On Wed, Apr 13, 2011 at 01:48:48PM -0700, Yinghai Lu wrote:
> - addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<20);
> + addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<21);
Btw, while looking at this code I wondered why the 512M goal is enforced
by the alignmen
On 04/13/2011 01:54 PM, Linus Torvalds wrote:
> 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/x8
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 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: apertu
On Wed, Apr 13, 2011 at 3:14 PM, Yinghai Lu 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 in at every
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 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 .
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.
> > The
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 [_br
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 a
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
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()
> afte
* Joerg Roedel 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 r
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
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, Apr 12, 2011 at 10:15:11AM -0400, Alex Deucher wrote:
> On Tue, Apr 12, 2011 at 5:02 AM, Joerg Roedel 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 who
On Tue, Apr 12, 2011 at 5:02 AM, Joerg Roedel 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 distu
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 -
73 matches
Mail list logo
