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 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
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
https://bugs.freedesktop.org/show_bug.cgi?id=35312
--- Comment #1 from Francis Whittle 2011-04-13 22:36:09
PDT ---
Created an attachment (id=45598)
View: https://bugs.freedesktop.org/attachment.cgi?id=45598
Review: https://bugs.freedesktop.org/review?bug=35312&attachment=45598
short patch to
https://bugs.freedesktop.org/show_bug.cgi?id=35312
--- Comment #1 from Francis Whittle 2011-04-13
22:36:09 PDT ---
Created an attachment (id=45598)
View: https://bugs.freedesktop.org/attachment.cgi?id=45598
Review: https://bugs.freedesktop.org/review?bug=35312&attachment=45598
short patch to
On Wed, 2011-04-13 at 22:05 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2011-04-12 at 10:01 +0200, C?dric Cano wrote:
> > Hi
> >
> > Here you are a patch that adds big endian support for rv730 in r600
> > classic mesa driver. The BE modifications are almost the same as the DRM
> > / DDX drive
On Tue, 2011-04-12 at 10:01 +0200, C?dric Cano wrote:
> Hi
>
> Here you are a patch that adds big endian support for rv730 in r600
> classic mesa driver. The BE modifications are almost the same as the DRM
> / DDX driver modifications
> (http://lists.freedesktop.org/archives/dri-devel/2011-Febr
https://bugs.freedesktop.org/show_bug.cgi?id=28627
--- Comment #21 from Connor Behan 2011-04-13 21:40:10
PDT ---
This bug largely goes away if I use kernels 2.6.37 and 2.6.38 with the Gallium
Radeon/DRI driver. In fact the glxgears framerates I get that way are slightly
better. Some things to no
https://bugs.freedesktop.org/show_bug.cgi?id=28627
--- Comment #21 from Connor Behan 2011-04-13
21:40:10 PDT ---
This bug largely goes away if I use kernels 2.6.37 and 2.6.38 with the Gallium
Radeon/DRI driver. In fact the glxgears framerates I get that way are slightly
better. Some things to no
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
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
Michel D?nzer wrote:
>>> That does sound like the GPU locks up. Do you get any messages in dmesg
>>> about lockups and attempts to reset the GPU at any time?
>>
>> No.
>
> Hmm, I guess the constant SIGALRMs might prevent the lockup detection
> from kicking in... Maybe you can try starting the X se
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, 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 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, 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
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 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 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]
https://bugzilla.kernel.org/show_bug.cgi?id=32982
--- Comment #6 from Bart Van Assche 2011-04-13
18:49:13 ---
Although I'm still busy bisecting, I'd like to report that I got the following
hung task report with head b73a21fc66fee35b41db755abebfacba48b2fc76 (had
already seen something simila
On Wed, 2011-04-13 at 09:59 +0200, Gabriel Paubert wrote:
>
> Well, X is dead, or rather in an infinite ioctl loop as described
> above.
> IIRC, the display enters a power-down mode and there is nothing to
> see.
So basically the card crashed. There's about an infinite amount of
reasons why radeo
https://bugzilla.kernel.org/show_bug.cgi?id=33222
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #
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 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
https://bugzilla.kernel.org/show_bug.cgi?id=33222
--- Comment #1 from Thomas Meyer 2011-04-13 17:09:48 ---
Created an attachment (id=54292)
--> (https://bugzilla.kernel.org/attachment.cgi?id=54292)
Oops - Part 2
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
---
https://bugzilla.kernel.org/show_bug.cgi?id=33222
Summary: [RADEON] Oops in worker thread for
radeon_unpin_work_func
Product: Drivers
Version: 2.5
Kernel Version: 2.6.38.2
Platform: All
OS/Version: Linux
Tree:
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 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 Mit, 2011-04-13 at 14:27 +0200, Gabriel Paubert wrote:
> On Wed, Apr 13, 2011 at 02:12:16PM +0200, Michel D?nzer wrote:
> > On Mit, 2011-04-13 at 09:59 +0200, Gabriel Paubert wrote:
> > > On Tue, Apr 12, 2011 at 07:29:22PM +0200, Michel D?nzer wrote:
> > > > On Die, 2011-04-12 at 14:00 +0200,
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 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 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: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 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 Wed, Apr 13, 2011 at 02:12:16PM +0200, Michel D?nzer wrote:
> On Mit, 2011-04-13 at 09:59 +0200, Gabriel Paubert wrote:
> > On Tue, Apr 12, 2011 at 07:29:22PM +0200, Michel D?nzer wrote:
> > > On Die, 2011-04-12 at 14:00 +0200, Gabriel Paubert wrote:
> > > > On Tue, Apr 12, 2011 at 01:46:10PM +
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 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
Hello Gabriel
On Wed, Apr 13, 2011 at 12:31:44PM +0200, Gabriel Paubert wrote:
> On Wed, Apr 13, 2011 at 10:59:14AM +0200, Andreas Schwab wrote:
> > Uwe Kleine-K?nig writes:
> >
> > > $ git name-rev --refs=refs/tags/v2.6\*
> > > 69a07f0b117a40fcc1a479358d8e1f41793617f2
> > > 69a07f0b117a40fcc1a4
On Mit, 2011-04-13 at 09:59 +0200, Gabriel Paubert wrote:
> On Tue, Apr 12, 2011 at 07:29:22PM +0200, Michel D?nzer wrote:
> > On Die, 2011-04-12 at 14:00 +0200, Gabriel Paubert wrote:
> > > On Tue, Apr 12, 2011 at 01:46:10PM +0200, Michel D?nzer wrote:
> > > > >
> > > > > With no_wb=1 the driver
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 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 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
https://bugs.freedesktop.org/show_bug.cgi?id=36221
--- Comment #2 from revealed 2011-04-13 13:43:06 PDT ---
Created an attachment (id=45590)
--> (https://bugs.freedesktop.org/attachment.cgi?id=45590)
Full dmesg containing the i2c error
--
Configure bugmail: https://bugs.freedesktop.org/userpre
https://bugs.freedesktop.org/show_bug.cgi?id=36221
--- Comment #1 from revealed 2011-04-13 13:41:58 PDT ---
Created an attachment (id=45589)
--> (https://bugs.freedesktop.org/attachment.cgi?id=45589)
vbios.rom
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- Y
https://bugs.freedesktop.org/show_bug.cgi?id=36221
--- Comment #2 from revealed 2011-04-13 13:43:06 PDT
---
Created an attachment (id=45590)
--> (https://bugs.freedesktop.org/attachment.cgi?id=45590)
Full dmesg containing the i2c error
--
Configure bugmail: https://bugs.freedesktop.org/userpr
https://bugs.freedesktop.org/show_bug.cgi?id=36221
--- Comment #1 from revealed 2011-04-13 13:41:58 PDT
---
Created an attachment (id=45589)
--> (https://bugs.freedesktop.org/attachment.cgi?id=45589)
vbios.rom
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
---
https://bugs.freedesktop.org/show_bug.cgi?id=36221
Summary: KMS with X1950 XT i2c error --> no ddc
Product: DRI
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: critical
Priority: medium
https://bugs.freedesktop.org/show_bug.cgi?id=36221
Summary: KMS with X1950 XT i2c error --> no ddc
Product: DRI
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: critical
Priority: medium
Michel Dänzer wrote:
That does sound like the GPU locks up. Do you get any messages in dmesg
about lockups and attempts to reset the GPU at any time?
No.
Hmm, I guess the constant SIGALRMs might prevent the lockup detection
from kicking in... Maybe you can try starting the X server with
-dum
On Thu, Apr 14, 2011 at 12:52 AM, Alex Deucher wrote:
> On Wed, Apr 13, 2011 at 10:46 AM, Jerome Glisse wrote:
>> On Tue, Apr 12, 2011 at 1:33 PM, Alex Deucher wrote:
>>> Apparently only rv515 asics need the workaround
>>> added in f24d86f1a49505cdea56728b853a5d0a3f8e3d11
>>> (drm/radeon/kms: fi
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 10:59:14AM +0200, Andreas Schwab wrote:
> Uwe Kleine-K?nig writes:
>
> > $ git name-rev --refs=refs/tags/v2.6\*
> > 69a07f0b117a40fcc1a479358d8e1f41793617f2
> > 69a07f0b117a40fcc1a479358d8e1f41793617f2 tags/v2.6.39-rc2~3^2~43^2~4
> >
> > so it was introduced just before -
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 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 Wed, Apr 13, 2011 at 06:16:13PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2011-04-13 at 09:59 +0200, Gabriel Paubert wrote:
> >
> > Well, X is dead, or rather in an infinite ioctl loop as described
> > above.
> > IIRC, the display enters a power-down mode and there is nothing to
> > see.
>
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
https://bugzilla.kernel.org/show_bug.cgi?id=32982
--- Comment #6 from Bart Van Assche 2011-04-13
18:49:13 ---
Although I'm still busy bisecting, I'd like to report that I got the following
hung task report with head b73a21fc66fee35b41db755abebfacba48b2fc76 (had
already seen something simila
https://bugs.freedesktop.org/show_bug.cgi?id=30651
--- Comment #9 from Andy Furniss 2011-04-13
11:38:47 PDT ---
(In reply to comment #8)
> same here.
> and i never got answer about which method is better with amd/ati card and open
> stack now. i hope devs are looking into that stuff.
Maybe ther
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
https://bugs.freedesktop.org/show_bug.cgi?id=30651
--- Comment #9 from Andy Furniss 2011-04-13
11:38:47 PDT ---
(In reply to comment #8)
> same here.
> and i never got answer about which method is better with amd/ati card and open
> stack now. i hope devs are looking into that stuff.
Maybe ther
Uwe Kleine-K?nig writes:
> $ git name-rev --refs=refs/tags/v2.6\*
> 69a07f0b117a40fcc1a479358d8e1f41793617f2
> 69a07f0b117a40fcc1a479358d8e1f41793617f2 tags/v2.6.39-rc2~3^2~43^2~4
>
> so it was introduced just before -rc2.
$ git tag --contains 69a07f0b117a40fcc1a479358d8e1f41793617f2
v2.6.39-rc
On Wed, Apr 13, 2011 at 10:46 AM, Jerome Glisse wrote:
> On Tue, Apr 12, 2011 at 1:33 PM, Alex Deucher
> wrote:
>> Apparently only rv515 asics need the workaround
>> added in f24d86f1a49505cdea56728b853a5d0a3f8e3d11
>> (drm/radeon/kms: fix resume regression for some r5xx laptops).
>>
>> Fixes:
>
https://bugs.freedesktop.org/show_bug.cgi?id=30651
--- Comment #8 from Sergey Kondakov 2011-04-13 10:46:29
PDT ---
same here.
and i never got answer about which method is better with amd/ati card and open
stack now. i hope devs are looking into that stuff.
--
Configure bugmail: https://bugs.fr
On Tue, Apr 12, 2011 at 1:33 PM, Alex Deucher wrote:
> Apparently only rv515 asics need the workaround
> added in f24d86f1a49505cdea56728b853a5d0a3f8e3d11
> (drm/radeon/kms: fix resume regression for some r5xx laptops).
>
> Fixes:
> https://bugs.freedesktop.org/show_bug.cgi?id=34709
>
> Signed-off
https://bugs.freedesktop.org/show_bug.cgi?id=30651
--- Comment #8 from Sergey Kondakov 2011-04-13
10:46:29 PDT ---
same here.
and i never got answer about which method is better with amd/ati card and open
stack now. i hope devs are looking into that stuff.
--
Configure bugmail: https://bugs.fr
https://bugs.freedesktop.org/show_bug.cgi?id=30651
--- Comment #7 from Andy Furniss 2011-04-13
10:23:46 PDT ---
(In reply to comment #6)
> 1) yuv=4 on r600g still have no colours even though with r300g they are ok
yuv=4 with or without bicubic now works for me on 600g
> 2) still there is an o
https://bugs.freedesktop.org/show_bug.cgi?id=30651
--- Comment #7 from Andy Furniss 2011-04-13
10:23:46 PDT ---
(In reply to comment #6)
> 1) yuv=4 on r600g still have no colours even though with r300g they are ok
yuv=4 with or without bicubic now works for me on 600g
> 2) still there is an o
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
https://bugzilla.kernel.org/show_bug.cgi?id=33222
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #2 f
Hello Gabriel
On Wed, Apr 13, 2011 at 12:31:44PM +0200, Gabriel Paubert wrote:
> On Wed, Apr 13, 2011 at 10:59:14AM +0200, Andreas Schwab wrote:
> > Uwe Kleine-König writes:
> >
> > > $ git name-rev --refs=refs/tags/v2.6\*
> > > 69a07f0b117a40fcc1a479358d8e1f41793617f2
> > > 69a07f0b117a40fcc1a4
Uwe Kleine-König writes:
> $ git name-rev --refs=refs/tags/v2.6\*
> 69a07f0b117a40fcc1a479358d8e1f41793617f2
> 69a07f0b117a40fcc1a479358d8e1f41793617f2 tags/v2.6.39-rc2~3^2~43^2~4
>
> so it was introduced just before -rc2.
$ git tag --contains 69a07f0b117a40fcc1a479358d8e1f41793617f2
v2.6.39-rc
On Wed, Apr 13, 2011 at 10:02:04AM +0200, Gabriel Paubert wrote:
> On Tue, Apr 12, 2011 at 01:46:10PM +0200, Michel Dänzer wrote:
> > BTW, if your kernel contains commit
> > 69a07f0b117a40fcc1a479358d8e1f41793617f2, can you try if reverting that
> > helps?
>
> My kernel is pristine 2.6.38 and does
On Wed, Apr 13, 2011 at 10:02:04AM +0200, Gabriel Paubert wrote:
> On Tue, Apr 12, 2011 at 01:46:10PM +0200, Michel D?nzer wrote:
> > BTW, if your kernel contains commit
> > 69a07f0b117a40fcc1a479358d8e1f41793617f2, can you try if reverting that
> > helps?
>
> My kernel is pristine 2.6.38 and does
https://bugzilla.kernel.org/show_bug.cgi?id=33222
--- Comment #1 from Thomas Meyer 2011-04-13 17:09:48 ---
Created an attachment (id=54292)
--> (https://bugzilla.kernel.org/attachment.cgi?id=54292)
Oops - Part 2
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
---
https://bugzilla.kernel.org/show_bug.cgi?id=33222
Summary: [RADEON] Oops in worker thread for
radeon_unpin_work_func
Product: Drivers
Version: 2.5
Kernel Version: 2.6.38.2
Platform: All
OS/Version: Linux
Tree:
On Tue, Apr 12, 2011 at 01:46:10PM +0200, Michel D?nzer wrote:
> BTW, if your kernel contains commit
> 69a07f0b117a40fcc1a479358d8e1f41793617f2, can you try if reverting that
> helps?
My kernel is pristine 2.6.38 and does not include this commit
(was introduced before 2.6.39-rc1 according to gitk)
On Tue, Apr 12, 2011 at 07:29:22PM +0200, Michel D?nzer wrote:
> On Die, 2011-04-12 at 14:00 +0200, Gabriel Paubert wrote:
> > On Tue, Apr 12, 2011 at 01:46:10PM +0200, Michel D?nzer wrote:
> > > >
> > > > With no_wb=1 the driver goes a bit further but the X server ends
> > > > up in an infinite i
From: Dave Airlie
i915 calls the panic handler function on last close to reset the modes,
however this is a really bad idea for multi-gpu machines, esp shareable
gpus machines. So add a new entry point for the driver to just restore
its own fbcon mode.
v2: move code into fb helper, fix panic cod
https://bugs.freedesktop.org/show_bug.cgi?id=25588
Fabio Pedretti changed:
What|Removed |Added
Resolution|WORKSFORME |WONTFIX
Component|Mesa core
https://bugs.freedesktop.org/show_bug.cgi?id=25588
Fabio Pedretti changed:
What|Removed |Added
Resolution|WORKSFORME |WONTFIX
Component|Mesa core
* 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 Wed, 13 Apr 2011 09:35:55 +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> i915 calls the panic handler function on last close to reset the modes,
> however this is a really bad idea for multi-gpu machines, esp shareable
> gpus machines. So add a new entry point for the driver to just restor
On Wed, Apr 13, 2011 at 10:46 AM, Jerome Glisse wrote:
> On Tue, Apr 12, 2011 at 1:33 PM, Alex Deucher wrote:
>> Apparently only rv515 asics need the workaround
>> added in f24d86f1a49505cdea56728b853a5d0a3f8e3d11
>> (drm/radeon/kms: fix resume regression for some r5xx laptops).
>>
>> Fixes:
>> h
1 - 100 of 120 matches
Mail list logo
