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
--- 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
--- 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
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 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 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 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 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: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 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 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 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 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:
>
> - 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 Wednesday, April 13, 2011, H. Peter Anvin wrote:
>
> Yes. ?However, even if we *do* revert (and the time is running short on
> not reverting) I would like to understand this particular one, simply
> because I think it may very well be a problem that is manifesting itself
> in other ways on othe
On Wednesday, April 13, 2011, Linus Torvalds
wrote:
> On Wednesday, April 13, 2011, H. Peter Anvin wrote:
>>
>> Yes. ?However, even if we *do* revert (and the time is running short on
>> not reverting) I would like to understand this particular one, simply
>> because I think it may very well be a
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=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 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
101 - 120 of 120 matches
Mail list logo
