[Bug 35312] r600g: Automatic mipmap generation doesn't work properly

[bugzilla-dae...@freedesktop.org]

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=45598

short patch to test problem

Can you try this patch to mesa and say if it fixes the issue?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] Big Endian support for RV730 (Mesa r600)

[Benjamin Herrenschmidt]

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 driver modifications 
> > (http://lists.freedesktop.org/archives/dri-devel/2011-February/008151.html).
> > 
> > I used the mesa-demos to test the driver status on big endian platform. 
> > Nearly all demos renders the same as on Intel architecture. 
> > Nevertheless, there are still some issues in glReadPixels (r600_blit) 
> > with some formats. I can't figure out exactly what and when data must be 
> > swapped (set_tex_resoures, set_render_target...). Review of the patch 
> > would be greatly appreciated.
> > 
> > It seems that r600g will be the default for Mesa 7.11 so I'll try to 
> > enable big endian support for Gallium now.
> 
> Cool stuff !
> 
> I'll try to test that one of these days on various ppc's

BTW. I see you used some FSL embedded board. Do you have your PCIe MMIO
space above 32-bit ? Last I looked, there was a bunch of fixing needing
to be done, among others in the TTM, to make that work.

I had some preliminary patches but they bitrot... mostly the issue is to
make sure than a phys_addr_t is used instead of an unsigned long
whenever it tries to store the physical address of an object.

Ben.

[PATCH] Big Endian support for RV730 (Mesa r600)

[Benjamin Herrenschmidt]

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-February/008151.html).
> 
> I used the mesa-demos to test the driver status on big endian platform. 
> Nearly all demos renders the same as on Intel architecture. 
> Nevertheless, there are still some issues in glReadPixels (r600_blit) 
> with some formats. I can't figure out exactly what and when data must be 
> swapped (set_tex_resoures, set_render_target...). Review of the patch 
> would be greatly appreciated.
> 
> It seems that r600g will be the default for Mesa 7.11 so I'll try to 
> enable big endian support for Gallium now.

Cool stuff !

I'll try to test that one of these days on various ppc's

Cheers,
Ben.

[Bug 28627] 2.6.31.6 is the last kernel where KMS works well on an RV515 card for regular PCI

[bugzilla-dae...@freedesktop.org]

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 note are that the framerates become awful again if I
turn "EXAPixmaps" "off" and that I still have trouble logging out of X. This is
surely a topic for another bug.

Thanks for all the work you've been doing!

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

Linux 2.6.39-rc3

[Joerg Roedel]

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 pointing to e820 RAM. Ignoring.
> [0.00] Your BIOS doesn't leave a aperture memory hole
> [0.00] Please enable the IOMMU option in the BIOS setup
> [0.00] This costs you 64 MB of RAM
> [0.00] memblock_x86_reserve_range: [0xa000-0xa3ff]   
> aperture64
> [0.00] Mapping aperture over 65536 KB of RAM @ a000
> 
> so kernel try to reallocate apperture. because BIOS allocated is pointed to 
> RAM or size is too small.

It is actually beyond 4GB on that machine, this value read here is from
the previous kernel-boot. The BIOS does not reset these values on a
reboot.

> but your radeon does use [0xa000, 0xbfff)

Yes, I suspected that too (and spent a few hours reading radeon code),
but then I talked the Alex Deucher and he explained that these addresses
which the driver prints for GTT and VRAM are in the GPU address space
and do not refer to system ram. So this shouldn't be the problem.

Joerg

Linux 2.6.39-rc3

[Joerg Roedel]

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?
> >>
> >>  before:  f005fe12b90c: x86-64: Move out cleanup higmap [_brk_end, _end) 
> >> out of init_memory_mapping()
> >>   after:  d2137d5af425: Merge branch 'linus' into x86/bootmem
> >>
> >> I've Cc:-ed more people who might have an idea about it.
> > 
> > Okay, I have done some more bisecting and debugging today.
> > 
> 
> First of all, *huge* thanks for this effort.  At least we need to track
> down the bits that need to be reverted -- it is past rc3, and it's time
> to see what we should revert and tell the submitter to try again next cycle.
> 
> This looks to be the same issue as in bugzilla 33012:
> 
>   https://bugzilla.kernel.org/show_bug.cgi?id=33012
> 
> ... so it would be good if we could keep the information in there.

Yes, I try to find my korg bugzilla account again and drop the
information from this email there.

Joerg

Linux 2.6.39-rc3

[Joerg Roedel]

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 this again, but this time I merged v2.6.38-rc5 at every
> > step and was successful. The bad commit in this branch turned out to be
> > 
> > 1a4a678b12c84db9ae5dce424e0e97f0559bb57c
> > 
> > which is related to memblock.
> > 
> > Then I tried to find out which change between 2.6.38-rc4 and 2.6.38-rc5
> > is needed to trigger the failure, so I used f005fe12b90c as a base,
> > bisected between v2.6.38-rc4..v2.6.38-rc5 and merged every bisect step
> > into the base and tested. Here the bad commit turned out to be
> > 
> > e6d2e2b2b1e1455df16d68a78f4a3874c7b3ad20
> > 
> > which is related to gart. It turned out that the gart aperture on that
> > box is on another position with these patches. Before it was as
> > 0xa400 and now it is at 0xa000. It seems like this has something
> > to do with the root-cause.
> > 
> > Reverting commit 1a4a678b12c84db9ae5dce424e0e97f0559bb57c fixes the
> > problem btw. and booting with iommu=soft also works, but I have no idea
> > yet why the aperture at that address is a problem (with the patch
> > reverted the aperture lands at 0x8000).
> > 
> 
> Does reverting e6d2e2b2b1e1455df16d68a78f4a3874c7b3ad20 solve the
> problem for you?

No, reverting that patch doesn't make the problem go away (and the gart
aperture is still on 0xa000). I tested this in 39-rc3, I havn't
tested if it makes a difference on the original bisect-commit from Ingo,
probably it does (don't know if that matters).
Strange about this commit is that it fixes an x86 gart aperture
allocation bug in generic memblock code.

> 1a4a678b12c84db9ae5dce424e0e97f0559bb57c is a memory-allocation-order
> patch, which have a nasty tendency to unmask bugs elsewhere in the
> kernel.  However, e6d2e2b2b1e1455df16d68a78f4a3874c7b3ad20 looks
> positively strange (and it doesn't exactly help that the description is
> written in Yinghai-ese and is therefore nearly impossible to decode,
> never mind tell if it is remotely correct.)

I think that the two commits are okay and the bug is somewhere else, but
I have no idea yet were to look next. I spent some time looking at
radeon code and talking to Alex about it (because it seemed suspicous
that the GTT is on 0xa000 too, but as Alex explained me this is an
address in the GPU address space and shouldn't matter).

Regards,

   Joerg

Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?

[Andy Furniss]

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
> -dumbSched to see if that gets things along any further, but in the end
> there's probably no way around figuring out what causes the lockup and
> fixing that anyway.

I have an old AGP box that locks with 600g + agpgart - It used to give 
GPU lockup to dmesg/log, but (I only test it occasionally) it doesn't 
anymore. I can still sysrq OK.

I wonder if something changed in recent months in the drm/whatever code 
that has changed/blocked the logging.

Linux 2.6.39-rc3

[Linus Torvalds]

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 problem that is manifesting itself
>> in other ways on other systems.

 sorry, fingerfart. Anyway, I agree 100%.

 we definitely want to also understand the reason for things not
working, even if we do revert..

Linus
>> of complete b*llsh*t magic numbers in this
>

Linux 2.6.39-rc3

[Linus Torvalds]

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 other systems.
>
> The other thing that this has uncovered is that we already have a bunch
> of complete b*llsh*t magic numbers in this

Linux 2.6.39-rc3

[H. Peter Anvin]

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 analytic approach (aka "computer sciency" approach),
> where you can actually think about the problem without having any
> pesky "reality" impact the solution is obviously the one we tend to
> prefer. Sadly, it's seldom the one we can use in reality when it comes
> to things like resource allocation, since we end up starting off with
> often buggy approximations of what the actual hardware is all about
> (ie broken firmware tables).
> 
> So I'd love to know exactly why one random number works, and why
> another one doesn't. But as long as we do _not_ know the "Why" of it,
> we will have to revert.
> 

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 other systems.

The other thing that this has uncovered is that we already have a bunch
of complete b*llsh*t magic numbers in this path, some of which are
trivially shown to be wrong or at least completely arbitrary, so there
are more issues here :(

-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Linux 2.6.39-rc3

[H. Peter Anvin]

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 BIOS doesn't leave a aperture memory hole
> [0.00] Please enable the IOMMU option in the BIOS setup
> [0.00] This costs you 64 MB of RAM
> [0.00] memblock_x86_reserve_range: [0xa000-0xa3ff]   
> aperture64
> [0.00] Mapping aperture over 65536 KB of RAM @ a000
> 
> so kernel try to reallocate apperture. because BIOS allocated is pointed to 
> RAM or size is too small.
> 
> but your radeon does use [0xa000, 0xbfff)
> 
> [4.281993] radeon :01:05.0: VRAM: 320M 0xC000 - 
> 0xD3FF (320M used)
> [4.290672] radeon :01:05.0: GTT: 512M 0xA000 - 
> 0xBFFF
> [4.298550] [drm] Detected VRAM RAM=320M, BAR=256M
> [4.309857] [drm] RAM width 32bits DDR
> [4.313748] [TTM] Zone  kernel: Available graphics memory: 1896524 kiB.
> [4.320379] [TTM] Initializing pool allocator.
> [4.324948] [drm] radeon: 320M of VRAM memory ready
> [4.329832] [drm] radeon: 512M of GTT memory ready.
> 
> and the one seems working:
> 
> [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 BIOS doesn't leave a aperture memory hole
> [0.00] Please enable the IOMMU option in the BIOS setup
> [0.00] This costs you 64 MB of RAM
> [0.00] memblock_x86_reserve_range: [0x8000-0x83ff]   
> aperture64
> [0.00] Mapping aperture over 65536 KB of RAM @ 8000
> [0.00] memblock_x86_reserve_range: [0xacb6bdc0-0xacb6bddf]
>   BOOTMEM
> 
> will use different position...
> 
> [4.250159] radeon :01:05.0: VRAM: 320M 0xC000 - 
> 0xD3FF (320M used)
> [4.258830] radeon :01:05.0: GTT: 512M 0xA000 - 
> 0xBFFF
> [4.266742] [drm] Detected VRAM RAM=320M, BAR=256M
> [4.271549] [drm] RAM width 32bits DDR
> [4.275435] [TTM] Zone  kernel: Available graphics memory: 1896526 kiB.
> [4.282066] [TTM] Initializing pool allocator.
> [4.282085] usb 7-2: new full speed USB device number 2 using ohci_hcd
> [4.293076] [drm] radeon: 320M of VRAM memory ready
> [4.298277] [drm] radeon: 512M of GTT memory ready.
> [4.303218] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [4.309854] [drm] Driver supports precise vblank timestamp query.
> [4.315970] [drm] radeon: irq initialized.
> [4.320094] [drm] GART: num cpu pages 131072, num gpu pages 131072
> 
> So question is why radeon is using the address [0xa000 - 0xc00], and 
> in E820 it is RAM 
> 
> [0.00]  BIOS-e820: 0010 - acb8d000 (usable)
> [0.00]  BIOS-e820: acb8d000 - acb8f000 (reserved)
> [0.00]  BIOS-e820: acb8f000 - afce9000 (usable)
> [0.00]  BIOS-e820: afce9000 - afd21000 (reserved)
> [0.00]  BIOS-e820: afd21000 - afd4f000 (usable)
> [0.00]  BIOS-e820: afd4f000 - afdcf000 (reserved)
> [0.00]  BIOS-e820: afdcf000 - afecf000 (ACPI NVS)
> [0.00]  BIOS-e820: afecf000 - afeff000 (ACPI data)
> [0.00]  BIOS-e820: afeff000 - aff0 (usable)
> 
> 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 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 GART is in fact 512 MiB in
size -- 131072 CPU pages -- which now overlaps the BIOS reserved areas.

Alex D., could you comment on the "num cpu pages" bit?

-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

[Bug 32982] Kernel locks up a few minutes after boot

[bugzilla-dae...@bugzilla.kernel.org]

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 similar before with 2.6.39-rc2):

INFO: task kjournald:918 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kjournald   D 880131b9ddb8 0   918  2 0x
 880131b9dd20 0046 880131b9dca0 8108cd6d
 0282 880131b9dfd8 880137729f40 880131b9dfd8
 880131b9c000 880131b9c000 880131b9c000 880131b9dfd8
Call Trace:
 [] ? trace_hardirqs_on_caller+0x14d/0x190
 [] ? sub_preempt_count+0xa9/0xe0
 [] journal_commit_transaction+0x13e/0x1590 [jbd]
 [] ? _raw_spin_unlock_irqrestore+0x65/0x80
 [] ? sub_preempt_count+0xa9/0xe0
 [] ? wake_up_bit+0x40/0x40
 [] ? del_timer_sync+0x8a/0xc0
 [] ? try_to_del_timer_sync+0x110/0x110
 [] kjournald+0xf1/0x250 [jbd]
 [] ? wake_up_bit+0x40/0x40
 [] ? commit_timeout+0x10/0x10 [jbd]
 [] kthread+0x96/0xa0
 [] kernel_thread_helper+0x4/0x10
 [] ? finish_task_switch+0x7b/0xe0
 [] ? _raw_spin_unlock_irq+0x3b/0x60
 [] ? retint_restore_args+0xe/0xe
 [] ? __init_kthread_worker+0x70/0x70
 [] ? gs_change+0xb/0xb
no locks held by kjournald/918.
INFO: task klauncher:5744 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
klauncher   D 0001000297b4 0  5744   5743 0x
 88011dd73938 0046 8801 8108cbef
 813e2535 88011dd73fd8 8801382e1f40 88011dd73fd8
 88011dd72000 88011dd72000 88011dd72000 88011dd73fd8
Call Trace:
 [] ? mark_held_locks+0x6f/0xa0
 [] ? _raw_spin_unlock_irqrestore+0x65/0x80
 [] ? __wait_on_buffer+0x30/0x30
 [] io_schedule+0x59/0x80
 [] sleep_on_buffer+0xe/0x20
 [] __wait_on_bit_lock+0x5a/0xc0
 [] ? __wait_on_buffer+0x30/0x30
 [] out_of_line_wait_on_bit_lock+0x78/0x90
 [] ? autoremove_wake_function+0x50/0x50
 [] __lock_buffer+0x36/0x40
 [] do_get_write_access+0x64d/0x660 [jbd]
 [] ? sub_preempt_count+0xa9/0xe0
 [] ? start_this_handle+0x370/0x470 [jbd]
 [] ? journal_add_journal_head+0xf4/0x220 [jbd]
 [] journal_get_write_access+0x31/0x50 [jbd]
 [] __ext3_journal_get_write_access+0x2d/0x60 [ext3]
 [] ext3_reserve_inode_write+0x83/0xb0 [ext3]
 [] ext3_mark_inode_dirty+0x44/0x70 [ext3]
 [] ext3_dirty_inode+0x5e/0xa0 [ext3]
 [] __mark_inode_dirty+0x3f/0x250
 [] file_update_time+0xec/0x170
 [] ? mutex_lock_nested+0x27d/0x3a0
 [] __generic_file_aio_write+0x1f8/0x440
 [] generic_file_aio_write+0x75/0xf0
 [] do_sync_write+0xda/0x120
 [] ? remove_vma+0x77/0x90
 [] ? trace_hardirqs_on+0xd/0x10
 [] ? remove_vma+0x77/0x90
 [] vfs_write+0xc6/0x170
 [] sys_write+0x51/0x90
 [] system_call_fastpath+0x16/0x1b
2 locks held by klauncher/5744:
 #0:  (>s_type->i_mutex_key#11){+.+.+.}, at: []
generic_file_aio_write+0x59/0xf0
 #1:  (jbd_handle){+.+...}, at: []
start_this_handle+0x370/0x470 [jbd]
INFO: task okular:4180 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
okular  D 00010002a251 0  4180   5743 0x
 880041d13aa8 0046 8800 8108cd6d
 0282 880041d13fd8 880037a59f40 880041d13fd8
 880041d12000 880041d12000 880041d12000 880041d13fd8
Call Trace:
 [] ? trace_hardirqs_on_caller+0x14d/0x190
 [] start_this_handle+0x244/0x470 [jbd]
 [] ? is_module_address+0x33/0x60
 [] ? wake_up_bit+0x40/0x40
 [] journal_start+0xdb/0x120 [jbd]
 [] ext3_journal_start_sb+0x36/0x70 [ext3]
 [] ext3_setattr+0x1a3/0x210 [ext3]
 [] notify_change+0x116/0x360
 [] do_truncate+0x63/0x90
 [] ? sub_preempt_count+0xa9/0xe0
 [] do_last+0x42c/0x820
 [] path_openat+0xd0/0x410
 [] ? might_fault+0x53/0xb0
 [] do_filp_open+0x7f/0xa0
 [] ? sub_preempt_count+0xa9/0xe0
 [] ? _raw_spin_unlock+0x35/0x60
 [] ? alloc_fd+0xf4/0x150
 [] do_sys_open+0x101/0x1e0
 [] sys_open+0x20/0x30
 [] system_call_fastpath+0x16/0x1b
2 locks held by okular/4180:
 #0:  (>s_type->i_mutex_key#11){+.+.+.}, at: []
do_truncate+0x57/0x90
 #1:  (>s_type->i_alloc_sem_key#4){+.+...}, at: []
notify_change+0x2a0/0x360

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

--
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
--

Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?

[Benjamin Herrenschmidt]

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 radeons do so, sometimes it has to do with them not liking
what you ate that day...

The only thing I can see that could be of use would be a bisect

Cheers,
Ben.

[Bug 33222] [RADEON] Oops in worker thread for radeon_unpin_work_func

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=33222


Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com




--- Comment #2 from Alex Deucher   2011-04-13 
17:19:06 ---
This is a duplicate of bug 32402.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

--
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Linux 2.6.39-rc3

[Yinghai Lu]

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 TOTALLY MAGIC NUMBER!
> 
> It makes it come out the same ON THAT ONE MACHINE.  So no, it's not
> "the old value". It's a random value that gets the old value in one
> specific case.

Alexandre's system is working 2.6.38.2 and kernel allocate from 0xa400
Joerg's system working 2.6.39-rc3 while revert the top down bootmem patch 
1a4a678b12c84db9ae5dce424e0e97f0559bb57c
and kernel allocate to 0x8000.
Alexandre's system is working while increasing alignment to 1g, and make kernel 
to
allocate 0x8000 to gart.

they are not working if kernel allocate from 0xa000

the 0xa000 looks like same value from radon GTT.


[4.250159] radeon :01:05.0: VRAM: 320M 0xC000 - 
0xD3FF (320M used)
[4.258830] radeon :01:05.0: GTT: 512M 0xA000 - 
0xBFFF
[4.266742] [drm] Detected VRAM RAM=320M, BAR=256M
[4.271549] [drm] RAM width 32bits DDR
[4.275435] [TTM] Zone  kernel: Available graphics memory: 1896526 kiB.
[4.282066] [TTM] Initializing pool allocator.
[4.282085] usb 7-2: new full speed USB device number 2 using ohci_hcd
[4.293076] [drm] radeon: 320M of VRAM memory ready
[4.298277] [drm] radeon: 512M of GTT memory ready.
[4.303218] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[4.309854] [drm] Driver supports precise vblank timestamp query.
[4.315970] [drm] radeon: irq initialized.
[4.320094] [drm] GART: num cpu pages 131072, num gpu pages 131072

Alex said that 0xa000 is ok and is from GPU address space
---
The VRAM and GTT addresses in the dmesg are internal GPU addresses not
system addresses.  The GPU has it's own internal address space for
on-chip memory clients (texture samplers, render buffers, display
controllers, etc.).  The GPU sets up two apertures in it's internal
address space and on-chip client requests are forwarded to the
appropriate place by the GPU's memory controller.  Addresses in the
GPU's VRAM aperture go to local vram on discrete cards, or to the
stolen memory at the top of system memory for IGP cards.  Addresses in
the GPU's GTT aperture hit a page table and get forwarded to the
appropriate dma pages.
---

> 
>>> Why don't we write code that just works?
>>>
>>> Or absent a "just works" set of patches, why don't we revert to code
>>> that has years of testing?
>>>
>>> This kind of "I broke things, so now I will jiggle things randomly
>>> until they unbreak" is not acceptable.
>>>
>>> Either explain why that fixes a real BUG (and why the magic constants
>>> need to be what they are), or just revert the patch that caused the
>>> problem, and go back to the allocation patters that have years of
>>> experience.
>>>
>>> Guys, we've had this discussion before, in PCI allocation. We don't do
>>> this. We tried switching the PCI region allocations to top-down, and
>>> IT WAS A FAILURE. We reverted it to what we had years of testing with.
>>>
>>> Don't just make random changes. There really are only two acceptable
>>> models of development: "think and analyze" or "years and years of
>>> testing on thousands of machines". Those two really do work.
>>
>> We did do the analyzing, and only difference seems to be:
> 
> No.
> 
> Yinghai, we have had this discussion before, and dammit, you need to
> understand the difference between "understanding the problem" and "put
> in random values until it works on one machine".
> 
> There was absolutely _zero_ analysis done. You do not actually
> understand WHY the numbers matter. You just look at two random
> numbers, and one works, the other does not. That's not "analyzing".
> That's just "random number games".
> 
> If you cannot see and understand the difference between an actual
> analytical solution where you _understand_ what the code is doing and
> why, and "random numbers that happen to work on one machine", I don't
> know what to tell you.
> 
>> good one is using 0x8000
>> and bad one is using 0xa000.
>>
>> We try to figure out if it needs low address and it happen to work
>> because kernel was doing bottom up allocation.
> 
> No.
> 
> Let me repeat my point one more time.
> 
> You have TWO choices. Not more, not less:
> 
>  - choice #1: go back to the old allocation model. It's tested. It
> doesn't regress. Admittedly we may not know exactly _why_ it works,
> and it might not work on all machines, but it doesn't cause
> regressions (ie the machines it doesn't work on it _never_ worked on).
> 
>And this doesn't mean "old value for that _one_ machine". It means
> "old value for _every_ machine". So it means we revert the whole
> bottom-down thing entirely. Not just "change one random number so that
> the totally 

[Bug 33222] [RADEON] Oops in worker thread for radeon_unpin_work_func

[bugzilla-dae...@bugzilla.kernel.org]

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
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

--
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 33222] New: [RADEON] Oops in worker thread for radeon_unpin_work_func

[bugzilla-dae...@bugzilla.kernel.org]

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: Mainline
Status: NEW
  Severity: low
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-dri at kernel-bugs.osdl.org
ReportedBy: thomas at m3y3r.de
Regression: No


Created an attachment (id=54282)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=54282)
Oops - Part 1

Few days ago I stumbled upon the attached oops. Just images. sorry for that.
This is the first time I saw this oops. I just hit it once for 2.6.38.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

--
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Linux 2.6.39-rc3

[Linus Torvalds]

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 THAT ONE MACHINE.  So no, it's not
"the old value". It's a random value that gets the old value in one
specific case.

>> Why don't we write code that just works?
>>
>> Or absent a "just works" set of patches, why don't we revert to code
>> that has years of testing?
>>
>> This kind of "I broke things, so now I will jiggle things randomly
>> until they unbreak" is not acceptable.
>>
>> Either explain why that fixes a real BUG (and why the magic constants
>> need to be what they are), or just revert the patch that caused the
>> problem, and go back to the allocation patters that have years of
>> experience.
>>
>> Guys, we've had this discussion before, in PCI allocation. We don't do
>> this. We tried switching the PCI region allocations to top-down, and
>> IT WAS A FAILURE. We reverted it to what we had years of testing with.
>>
>> Don't just make random changes. There really are only two acceptable
>> models of development: "think and analyze" or "years and years of
>> testing on thousands of machines". Those two really do work.
>
> We did do the analyzing, and only difference seems to be:

No.

Yinghai, we have had this discussion before, and dammit, you need to
understand the difference between "understanding the problem" and "put
in random values until it works on one machine".

There was absolutely _zero_ analysis done. You do not actually
understand WHY the numbers matter. You just look at two random
numbers, and one works, the other does not. That's not "analyzing".
That's just "random number games".

If you cannot see and understand the difference between an actual
analytical solution where you _understand_ what the code is doing and
why, and "random numbers that happen to work on one machine", I don't
know what to tell you.

> good one is using 0x8000
> and bad one is using 0xa000.
>
> We try to figure out if it needs low address and it happen to work
> because kernel was doing bottom up allocation.

No.

Let me repeat my point one more time.

You have TWO choices. Not more, not less:

 - choice #1: go back to the old allocation model. It's tested. It
doesn't regress. Admittedly we may not know exactly _why_ it works,
and it might not work on all machines, but it doesn't cause
regressions (ie the machines it doesn't work on it _never_ worked on).

   And this doesn't mean "old value for that _one_ machine". It means
"old value for _every_ machine". So it means we revert the whole
bottom-down thing entirely. Not just "change one random number so that
the totally different allocation pattern happens to give the same
result on one particular machine".

   Quite frankly, I don't see the point of doing top-to-bottom anyway,
so I think we should do this regardless. Just revert the whole
"allocate from top". It didn't work for PCI, it's not working for this
case either. Stop doing it.

 - 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 analytic approach (aka "computer sciency" approach),
where you can actually think about the problem without having any
pesky "reality" impact the solution is obviously the one we tend to
prefer. Sadly, it's seldom the one we can use in reality when it comes
to things like resource allocation, since we end up starting off with
often buggy approximations of what the actual hardware is all about
(ie broken firmware tables).

So I'd love to know exactly why one random number works, and why
another one doesn't. But as long as we do _not_ know the "Why" of it,
we will have to revert.

It really is that simple. It's _always_ that simple.

So the numbers shouldn't be "magic", they should have real
explanations. And in the absense of real explanation, the model that
works is "this is what we've always done". Including, very much, the
whole allocation order. Not just one random number on one random
machine.

Linus

Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?

[Michel Dänzer]

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, 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 ioctl loop and the logs are: 
> > > > > > 
> > > > > > Which ioctl does it loop on? Please provide the Xorg.0.log file as 
> > > > > > well.
> > > > > 
> > > > > From memory, the code was 0x64, which is DRM_RADEON_GEM_WAIT_IDLE.
> > > > 
> > > > Note that it's normal for this ioctl to be called every time before the
> > > > GPU accessible pixmap memory is accessed by the CPU. Unless the ioctl
> > > > always returns an error, this may not indicate a problem on its own. 
> > > 
> > > It seems to be an infinite loop, always returning EINTR because
> > > of regular SIGALRM delivery.
> > 
> > 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
-dumbSched to see if that gets things along any further, but in the end
there's probably no way around figuring out what causes the lockup and
fixing that anyway.


-- 
Earthling Michel D?nzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer

Linux 2.6.39-rc3

[Alex Deucher]

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 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 successful. The bad commit in this branch turned out to be
>>
>> ? ? ? 1a4a678b12c84db9ae5dce424e0e97f0559bb57c
>>
>> which is related to memblock.
>>
>> Then I tried to find out which change between 2.6.38-rc4 and 2.6.38-rc5
>> is needed to trigger the failure, so I used f005fe12b90c as a base,
>> bisected between v2.6.38-rc4..v2.6.38-rc5 and merged every bisect step
>> into the base and tested. Here the bad commit turned out to be
>>
>> ? ? ? e6d2e2b2b1e1455df16d68a78f4a3874c7b3ad20
>>
>> which is related to gart. It turned out that the gart aperture on that
>> box is on another position with these patches. Before it was as
>> 0xa400 and now it is at 0xa000. It seems like this has something
>> to do with the root-cause.
>>
>> Reverting commit 1a4a678b12c84db9ae5dce424e0e97f0559bb57c fixes the
>> problem btw. and booting with iommu=soft also works, but I have no idea
>> yet why the aperture at that address is a problem (with the patch
>> reverted the aperture lands at 0x8000).
>>
>> I have put some debug-data online. There is my .config and two
>> dmesg-files for good (==2.6.39-rc3 + revert) and bad (==2.6.39-rc3)
>> I also created these dmesg-files again with memblock=debug, maybe that
>> helps to find the problem. The files are at
>>
>> ? ? ? http://www.8bytes.org/~joro/debug/
>
> 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 pointing to e820 RAM. Ignoring.
> [ ? ?0.00] Your BIOS doesn't leave a aperture memory hole
> [ ? ?0.00] Please enable the IOMMU option in the BIOS setup
> [ ? ?0.00] This costs you 64 MB of RAM
> [ ? ?0.00] ? ? memblock_x86_reserve_range: [0xa000-0xa3ff] ? ? ? 
> aperture64
> [ ? ?0.00] Mapping aperture over 65536 KB of RAM @ a000
>
> so kernel try to reallocate apperture. because BIOS allocated is pointed to 
> RAM or size is too small.
>
> but your radeon does use [0xa000, 0xbfff)
>
> [ ? ?4.281993] radeon :01:05.0: VRAM: 320M 0xC000 - 
> 0xD3FF (320M used)
> [ ? ?4.290672] radeon :01:05.0: GTT: 512M 0xA000 - 
> 0xBFFF
> [ ? ?4.298550] [drm] Detected VRAM RAM=320M, BAR=256M
> [ ? ?4.309857] [drm] RAM width 32bits DDR
> [ ? ?4.313748] [TTM] Zone ?kernel: Available graphics memory: 1896524 kiB.
> [ ? ?4.320379] [TTM] Initializing pool allocator.
> [ ? ?4.324948] [drm] radeon: 320M of VRAM memory ready
> [ ? ?4.329832] [drm] radeon: 512M of GTT memory ready.
>
> and the one seems working:
>
> [ ? ?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 BIOS doesn't leave a aperture memory hole
> [ ? ?0.00] Please enable the IOMMU option in the BIOS setup
> [ ? ?0.00] This costs you 64 MB of RAM
> [ ? ?0.00] ? ? memblock_x86_reserve_range: [0x8000-0x83ff] ? ? ? 
> aperture64
> [ ? ?0.00] Mapping aperture over 65536 KB of RAM @ 8000
> [ ? ?0.00] ? ? memblock_x86_reserve_range: [0xacb6bdc0-0xacb6bddf] ? ? ? 
> ? ?BOOTMEM
>
> will use different position...
>
> [ ? ?4.250159] radeon :01:05.0: VRAM: 320M 0xC000 - 
> 0xD3FF (320M used)
> [ ? ?4.258830] radeon :01:05.0: GTT: 512M 0xA000 - 
> 0xBFFF
> [ ? ?4.266742] [drm] Detected VRAM RAM=320M, BAR=256M
> [ ? ?4.271549] [drm] RAM width 32bits DDR
> [ ? ?4.275435] [TTM] Zone ?kernel: Available graphics memory: 1896526 kiB.
> [ ? ?4.282066] [TTM] Initializing pool allocator.
> [ ? ?4.282085] usb 7-2: new full speed USB device number 2 using ohci_hcd
> [ ? ?4.293076] [drm] radeon: 320M of VRAM memory ready
> [ ? ?4.298277] [drm] radeon: 512M of GTT memory ready.
> [ ? ?4.303218] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [ ? ?4.309854] [drm] Driver supports precise vblank timestamp query.
> [ ? ?4.315970] [drm] radeon: irq initialized.
> [ ? ?4.320094] [drm] GART: num cpu pages 131072, num gpu pages 131072
>
> So question is why radeon is using the address [0xa000 - 0xc00], and 
> in E820 it is RAM 

The VRAM and GTT addresses in the dmesg are internal GPU addresses not
system addresses.  The GPU has it's own internal address space for
on-chip memory clients (texture samplers, render buffers, display
controllers, etc.).  The GPU sets up two apertures in it's internal

Linux 2.6.39-rc3

[H. Peter Anvin]

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);
 +  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 alignment. Start could be set to 512M instead and the alignment
>>> can be aper_size as it should. Any reason for such a big alignment?
>>>
>>> Joerg
>>>
>>> P.S.: The box is still in the office, I will try this debug-patch
>>>   tomorrow.
>>
>> The only reason that I can think of is that the aperture itself can be
>> huge, and perhaps 512 MiB is the biggest such known. 
> 
> Well, that would work as well by just using aper_size as alignment, the
> aperture needs to be aligned on its size anyway. This code only runs
> when Linux allocates the aperture itself and if I am mistaken is uses
> always 64MB when doing this.

Yes, I would agree with that.  The sane thing would be to set the base
to whatever address needs to be guarded against (WHICH SHOULD BE
MOTIVATED), and use aper_size as alignment, *unless* we are only using
the initial portion of a much larger hardware structure that needs
natural alignment (which isn't clear to me, I do know we sometimes use
only a fraction of the GART, but that doesn't mean we need to
naturally-align the entire thing, nor that 512 MiB is sufficient to do so.)

-hpa

Linux 2.6.39-rc3

[H. Peter Anvin]

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);
>>
>> Btw, while looking at this code I wondered why the 512M goal is enforced
>> by the alignment. Start could be set to 512M instead and the alignment
>> can be aper_size as it should. Any reason for such a big alignment?
>>
> 
> when using bootmem, try to use big alignment (512M ), so we could avoid take 
> ram range below 512M.
> 

Yes, his question was why on Earth are you using 0 as start if that is
the purpose.

On top of that, where the hell does the magic 512 MiB come from?  It
looks like it is either completly ad hoc, or it has something to do with
where the kexec kernel was allocated once upon a time.

-hpa

Linux 2.6.39-rc3

[H. Peter Anvin]

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 wondered why the 512M goal is enforced
> by the alignment. Start could be set to 512M instead and the alignment
> can be aper_size as it should. Any reason for such a big alignment?
> 
>   Joerg
> 
> P.S.: The box is still in the office, I will try this debug-patch
>   tomorrow.

The only reason that I can think of is that the aperture itself can be
huge, and perhaps 512 MiB is the biggest such known.  512ULL<<21 is of
course a particularly moronic way to write 1 GiB, but it was a debug patch.

The value 512 MiB apparently comes from
7677b2ef6c0c4fddc84f6473f3863f40eb71821b, which is apparently totally ad
hoc; effectively it tries to prevent a collision with kexec by
hardcoding the kdump allocation as it sat at that point in time in the
GART assignment rules.

Yeah.  Brilliant.

-hpa

Linux 2.6.39-rc3

[Yinghai Lu]

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 wondered why the 512M goal is enforced
> by the alignment. Start could be set to 512M instead and the alignment
> can be aper_size as it should. Any reason for such a big alignment?
> 

when using bootmem, try to use big alignment (512M ), so we could avoid take 
ram range below 512M.

commit 7677b2ef6c0c4fddc84f6473f3863f40eb71821b
Author: Yinghai Lu 
Date:   Mon Apr 14 20:40:37 2008 -0700

x86_64: allocate gart aperture from 512M

because we try to reserve dma32 early, so we have chance to get aperture
from 64M.

with some sequence aperture allocated from RAM, could become E820_RESERVED.

and then if doing a kexec with a big kernel that uncompressed size is above
64M we could have a range conflict with still using gart.

So allocate gart aperture from 512M instead.

Also change the fallback_aper_order to 5, because we don't have chance to 
get
2G or 4G aperture.

We can change it back to 32M or make it equal to size.

> 
> P.S.: The box is still in the office, I will try this debug-patch
>   tomorrow.

Alexandre's system is working at 0xa400 with 2.6.38.2

So it is not low address problem. could be other reason like
some other code could need lower address.

Thanks

Yinghai

Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?

[Gabriel Paubert]

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 +0200, Michel D?nzer wrote:
> > > > > > 
> > > > > > With no_wb=1 the driver goes a bit further but the X server ends
> > > > > > up in an infinite ioctl loop and the logs are: 
> > > > > 
> > > > > Which ioctl does it loop on? Please provide the Xorg.0.log file as 
> > > > > well.
> > > > 
> > > > From memory, the code was 0x64, which is DRM_RADEON_GEM_WAIT_IDLE.
> > > 
> > > Note that it's normal for this ioctl to be called every time before the
> > > GPU accessible pixmap memory is accessed by the CPU. Unless the ioctl
> > > always returns an error, this may not indicate a problem on its own. 
> > 
> > It seems to be an infinite loop, always returning EINTR because
> > of regular SIGALRM delivery.
> 
> 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.

Gabriel

Linux 2.6.39-rc3

[Yinghai Lu]

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/x86/kernel/aperture_64.c
>> +++ b/arch/x86/kernel/aperture_64.c
>> @@ -83,7 +83,7 @@ static u32 __init allocate_aperture(void)
>> * so don't use 512M below as gart iommu, leave the space for kernel
>> * code for safe
>> */
>> -   addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<20);
>> +   addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<21);
> 
> 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.

> 
> Why don't we write code that just works?
> 
> Or absent a "just works" set of patches, why don't we revert to code
> that has years of testing?
> 
> This kind of "I broke things, so now I will jiggle things randomly
> until they unbreak" is not acceptable.
> 
> Either explain why that fixes a real BUG (and why the magic constants
> need to be what they are), or just revert the patch that caused the
> problem, and go back to the allocation patters that have years of
> experience.
> 
> Guys, we've had this discussion before, in PCI allocation. We don't do
> this. We tried switching the PCI region allocations to top-down, and
> IT WAS A FAILURE. We reverted it to what we had years of testing with.
> 
> Don't just make random changes. There really are only two acceptable
> models of development: "think and analyze" or "years and years of
> testing on thousands of machines". Those two really do work.

We did do the analyzing, and only difference seems to be:
good one is using 0x8000
and bad one is using 0xa000.

We try to figure out if it needs low address and it happen to work 
because kernel was doing bottom up allocation.

Thanks

Yinghai

small git lesson [Was: Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?]

[Uwe Kleine-König]

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
> > > 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-rc1
> > v2.6.39-rc2
> > 
> 
> So who is right? I think it was before rc1. 
Yep, correct. I interpreted the output of git name-rev to mean it's not
included in a tag earlier than v2.6.39-rc2, but actually that's wrong.
It's just that it's easier (for some definition of easy) to reach the
commit in question from v2.6.39-rc2 than from v2.6.39-rc1.

> However in this case the main reason to fire gitk was to have a quick look 
> at the patch and its context, and simply reported the "Precedes" line 
> in the display, which is 2.6.39-rc1. It also follow v2.6.37-rc2, which means
> that it has been quite a long time outside the main tree.
I think this conclusion isn't valid in general. (E.g. in git itself a
bug-fix is often done on top of the commit that introduced it and than
merged into master. Still the bugfix might be new.) But looking at the
AuthorDate of 69a07f0b117a seems to support your statement.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-K?nig|
Industrial Linux Solutions | http://www.pengutronix.de/  |

Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?

[Michel Dänzer]

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 goes a bit further but the X server ends
> > > > > up in an infinite ioctl loop and the logs are: 
> > > > 
> > > > Which ioctl does it loop on? Please provide the Xorg.0.log file as well.
> > > 
> > > From memory, the code was 0x64, which is DRM_RADEON_GEM_WAIT_IDLE.
> > 
> > Note that it's normal for this ioctl to be called every time before the
> > GPU accessible pixmap memory is accessed by the CPU. Unless the ioctl
> > always returns an error, this may not indicate a problem on its own. 
> 
> It seems to be an infinite loop, always returning EINTR because
> of regular SIGALRM delivery.

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?


-- 
Earthling Michel D?nzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer

Linux 2.6.39-rc3

[Linus Torvalds]

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/aperture_64.c
> @@ -83,7 +83,7 @@ static u32 __init allocate_aperture(void)
> ? ? ? ? * so don't use 512M below as gart iommu, leave the space for kernel
> ? ? ? ? * code for safe
> ? ? ? ? */
> - ? ? ? addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<20);
> + ? ? ? addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<21);

What are all the magic numbers, and why would 0x8000 be special?

Why don't we write code that just works?

Or absent a "just works" set of patches, why don't we revert to code
that has years of testing?

This kind of "I broke things, so now I will jiggle things randomly
until they unbreak" is not acceptable.

Either explain why that fixes a real BUG (and why the magic constants
need to be what they are), or just revert the patch that caused the
problem, and go back to the allocation patters that have years of
experience.

Guys, we've had this discussion before, in PCI allocation. We don't do
this. We tried switching the PCI region allocations to top-down, and
IT WAS A FAILURE. We reverted it to what we had years of testing with.

Don't just make random changes. There really are only two acceptable
models of development: "think and analyze" or "years and years of
testing on thousands of machines". Those two really do work.

   Linus

Linux 2.6.39-rc3

[Yinghai Lu]

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 size 32 MB
>> [0.00] Aperture pointing to e820 RAM. Ignoring.
>> [0.00] Your BIOS doesn't leave a aperture memory hole
>> [0.00] Please enable the IOMMU option in the BIOS setup
>> [0.00] This costs you 64 MB of RAM
>> [0.00] memblock_x86_reserve_range: [0xa000-0xa3ff]   
>> aperture64
>> [0.00] Mapping aperture over 65536 KB of RAM @ a000
>>
>> so kernel try to reallocate apperture. because BIOS allocated is pointed to 
>> RAM or size is too small.
> 
> It is actually beyond 4GB on that machine, this value read here is from
> the previous kernel-boot. The BIOS does not reset these values on a
> reboot.
> 
>> but your radeon does use [0xa000, 0xbfff)
> 
> Yes, I suspected that too (and spent a few hours reading radeon code),
> but then I talked the Alex Deucher and he explained that these addresses
> which the driver prints for GTT and VRAM are in the GPU address space
> and do not refer to system ram. So this shouldn't be the problem.


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/aperture_64.c
@@ -83,7 +83,7 @@ static u32 __init allocate_aperture(void)
 * so don't use 512M below as gart iommu, leave the space for kernel
 * code for safe
 */
-   addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<20);
+   addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<21);
if (addr == MEMBLOCK_ERROR || addr + aper_size > 0x) {
printk(KERN_ERR
"Cannot allocate aperture memory hole (%lx,%uK)\n",

[Bug 36221] KMS with X1950 XT i2c error --> no ddc

[bugzilla-dae...@freedesktop.org]

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/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 36221] KMS with X1950 XT i2c error --> no ddc

[bugzilla-dae...@freedesktop.org]

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
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 36221] New: KMS with X1950 XT i2c error --> no ddc

[bugzilla-dae...@freedesktop.org]

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
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: revealed at freakmail.de


Hello!

This is the operating system and kernel:

cat /etc/SuSE-release
openSUSE 11.4 (i586)
VERSION = 11.4
CODENAME = Celadon

uname -rio
2.6.37.1-1.2-desktop i386 GNU/Linux


When trying to boot with Kernelmodesetting there is no DDC due to an i2c error
resulting in a blank screen.

I was told in irc channel #radeon to open a bugreport and attache vbios.rom and
dmesg of a boot with KMS enabled;

I hope you can help me out!

Many thanks for all your Help!

Greetings,

R

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

small git lesson [Was: Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?]

[Gabriel Paubert]

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 -rc2.
> 
> $ git tag --contains 69a07f0b117a40fcc1a479358d8e1f41793617f2
> v2.6.39-rc1
> v2.6.39-rc2
> 

So who is right? I think it was before rc1. 

Anyway I'm aware that there are other git commands, although for the option
details I often have to have a look at the man page.

However in this case the main reason to fire gitk was to have a quick look 
at the patch and its context, and simply reported the "Precedes" line 
in the display, which is 2.6.39-rc1. It also follow v2.6.37-rc2, which means
that it has been quite a long time outside the main tree.

Gabriel

Linux 2.6.39-rc3

[Yinghai Lu]

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 again, but this time I merged v2.6.38-rc5 at every
> step and was successful. The bad commit in this branch turned out to be
> 
>   1a4a678b12c84db9ae5dce424e0e97f0559bb57c
> 
> which is related to memblock.
> 
> Then I tried to find out which change between 2.6.38-rc4 and 2.6.38-rc5
> is needed to trigger the failure, so I used f005fe12b90c as a base,
> bisected between v2.6.38-rc4..v2.6.38-rc5 and merged every bisect step
> into the base and tested. Here the bad commit turned out to be
> 
>   e6d2e2b2b1e1455df16d68a78f4a3874c7b3ad20
> 
> which is related to gart. It turned out that the gart aperture on that
> box is on another position with these patches. Before it was as
> 0xa400 and now it is at 0xa000. It seems like this has something
> to do with the root-cause.
> 
> Reverting commit 1a4a678b12c84db9ae5dce424e0e97f0559bb57c fixes the
> problem btw. and booting with iommu=soft also works, but I have no idea
> yet why the aperture at that address is a problem (with the patch
> reverted the aperture lands at 0x8000).
> 
> I have put some debug-data online. There is my .config and two
> dmesg-files for good (==2.6.39-rc3 + revert) and bad (==2.6.39-rc3)
> I also created these dmesg-files again with memblock=debug, maybe that
> helps to find the problem. The files are at
> 
>   http://www.8bytes.org/~joro/debug/

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 pointing to e820 RAM. Ignoring.
[0.00] Your BIOS doesn't leave a aperture memory hole
[0.00] Please enable the IOMMU option in the BIOS setup
[0.00] This costs you 64 MB of RAM
[0.00] memblock_x86_reserve_range: [0xa000-0xa3ff]   
aperture64
[0.00] Mapping aperture over 65536 KB of RAM @ a000

so kernel try to reallocate apperture. because BIOS allocated is pointed to RAM 
or size is too small.

but your radeon does use [0xa000, 0xbfff)

[4.281993] radeon :01:05.0: VRAM: 320M 0xC000 - 
0xD3FF (320M used)
[4.290672] radeon :01:05.0: GTT: 512M 0xA000 - 
0xBFFF
[4.298550] [drm] Detected VRAM RAM=320M, BAR=256M
[4.309857] [drm] RAM width 32bits DDR
[4.313748] [TTM] Zone  kernel: Available graphics memory: 1896524 kiB.
[4.320379] [TTM] Initializing pool allocator.
[4.324948] [drm] radeon: 320M of VRAM memory ready
[4.329832] [drm] radeon: 512M of GTT memory ready.

and the one seems working:

[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 BIOS doesn't leave a aperture memory hole
[0.00] Please enable the IOMMU option in the BIOS setup
[0.00] This costs you 64 MB of RAM
[0.00] memblock_x86_reserve_range: [0x8000-0x83ff]   
aperture64
[0.00] Mapping aperture over 65536 KB of RAM @ 8000
[0.00] memblock_x86_reserve_range: [0xacb6bdc0-0xacb6bddf]  
BOOTMEM

will use different position...

[4.250159] radeon :01:05.0: VRAM: 320M 0xC000 - 
0xD3FF (320M used)
[4.258830] radeon :01:05.0: GTT: 512M 0xA000 - 
0xBFFF
[4.266742] [drm] Detected VRAM RAM=320M, BAR=256M
[4.271549] [drm] RAM width 32bits DDR
[4.275435] [TTM] Zone  kernel: Available graphics memory: 1896526 kiB.
[4.282066] [TTM] Initializing pool allocator.
[4.282085] usb 7-2: new full speed USB device number 2 using ohci_hcd
[4.293076] [drm] radeon: 320M of VRAM memory ready
[4.298277] [drm] radeon: 512M of GTT memory ready.
[4.303218] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[4.309854] [drm] Driver supports precise vblank timestamp query.
[4.315970] [drm] radeon: irq initialized.
[4.320094] [drm] GART: num cpu pages 131072, num gpu pages 131072

So question is why radeon is using the address [0xa000 - 0xc00], and in 
E820 it is RAM 

[0.00]  BIOS-e820: 0010 - acb8d000 (usable)
[0.00]  BIOS-e820: acb8d000 - acb8f000 (reserved)
[0.00]  BIOS-e820: acb8f000 - afce9000 (usable)
[0.00]  BIOS-e820: afce9000 - afd21000 (reserved)
[0.00]  BIOS-e820: afd21000 - afd4f000 (usable)
[0.00]  BIOS-e820: afd4f000 - afdcf000 (reserved)
[0.00]  BIOS-e820: 

Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?

[Gabriel Paubert]

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.
> 
> So basically the card crashed. There's about an infinite amount of
> reasons why radeons do so, sometimes it has to do with them not liking
> what you ate that day...
> 
> The only thing I can see that could be of use would be a bisect

Bisecting for something which I have never got to work (radeon with
KMS) on this machine is something I don't know how to do...

Note that radeon without KMS also always ends up crashing, but it
may take hours. The only case where the machine works reliably is 
when glxinfo claims that it is using software rendering.

Regards,
Gabriel

Linux 2.6.39-rc3

[H. Peter Anvin]

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 successful. The bad commit in this branch turned out to be
> 
>   1a4a678b12c84db9ae5dce424e0e97f0559bb57c
> 
> which is related to memblock.
> 
> Then I tried to find out which change between 2.6.38-rc4 and 2.6.38-rc5
> is needed to trigger the failure, so I used f005fe12b90c as a base,
> bisected between v2.6.38-rc4..v2.6.38-rc5 and merged every bisect step
> into the base and tested. Here the bad commit turned out to be
> 
>   e6d2e2b2b1e1455df16d68a78f4a3874c7b3ad20
> 
> which is related to gart. It turned out that the gart aperture on that
> box is on another position with these patches. Before it was as
> 0xa400 and now it is at 0xa000. It seems like this has something
> to do with the root-cause.
> 
> Reverting commit 1a4a678b12c84db9ae5dce424e0e97f0559bb57c fixes the
> problem btw. and booting with iommu=soft also works, but I have no idea
> yet why the aperture at that address is a problem (with the patch
> reverted the aperture lands at 0x8000).
> 

Does reverting e6d2e2b2b1e1455df16d68a78f4a3874c7b3ad20 solve the
problem for you?

1a4a678b12c84db9ae5dce424e0e97f0559bb57c is a memory-allocation-order
patch, which have a nasty tendency to unmask bugs elsewhere in the
kernel.  However, e6d2e2b2b1e1455df16d68a78f4a3874c7b3ad20 looks
positively strange (and it doesn't exactly help that the description is
written in Yinghai-ese and is therefore nearly impossible to decode,
never mind tell if it is remotely correct.)

-hpa

Linux 2.6.39-rc3

[H. Peter Anvin]

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, _end) out 
>> of init_memory_mapping()
>>   after:  d2137d5af425: Merge branch 'linus' into x86/bootmem
>>
>> I've Cc:-ed more people who might have an idea about it.
> 
> Okay, I have done some more bisecting and debugging today.
> 

First of all, *huge* thanks for this effort.  At least we need to track
down the bits that need to be reverted -- it is past rc3, and it's time
to see what we should revert and tell the submitter to try again next cycle.

This looks to be the same issue as in bugzilla 33012:

https://bugzilla.kernel.org/show_bug.cgi?id=33012

... so it would be good if we could keep the information in there.

-hpa

[Bug 30651] [RADEON:KMS:R600G] gl output in mplayer have no colors if used with a fragment program with additional lookup and bicubic B-spline filtering

[bugzilla-dae...@freedesktop.org]

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 there isn't an answer as such for that question.

I guess someone with an on-board low spec GPU may be more limited than a high
end card with fast vram.

Quality wise - I can't see any difference, the higher yuv= numbers give more
features like gamma correction (not sure how to use it though).

It would be nice if 600g could beat or equal 600c - it does for 3D, but for
some reason not this.

I said classic was twice as fast - it's actually more than that if I discount
time taken by the codec.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

small git lesson [Was: Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?]

[Andreas Schwab]

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-rc1
v2.6.39-rc2

Andreas.

-- 
Andreas Schwab, schwab at redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."

[PATCH] drm/radeon/kms: fix suspend on rv530 asics

[Alex Deucher]

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=34709
>>
>> Signed-off-by: Alex Deucher 
>> Cc: stable at kernel.org
>> ---
>> ?drivers/gpu/drm/radeon/atom.c | ? ?6 +-
>> ?1 files changed, 5 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
>> index 258fa5e..d71d375 100644
>> --- a/drivers/gpu/drm/radeon/atom.c
>> +++ b/drivers/gpu/drm/radeon/atom.c
>> @@ -32,6 +32,7 @@
>> ?#include "atom.h"
>> ?#include "atom-names.h"
>> ?#include "atom-bits.h"
>> +#include "radeon.h"
>>
>> ?#define ATOM_COND_ABOVE ? ? ? ? ? ? ? ?0
>> ?#define ATOM_COND_ABOVEOREQUAL 1
>> @@ -101,7 +102,9 @@ static void debug_print_spaces(int n)
>> ?static uint32_t atom_iio_execute(struct atom_context *ctx, int base,
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? uint32_t index, uint32_t data)
>> ?{
>> + ? ? ? struct radeon_device *rdev = ctx->card->dev->dev_private;
>> ? ? ? ?uint32_t temp = 0xCDCDCDCD;
>> +
>> ? ? ? ?while (1)
>> ? ? ? ? ? ? ? ?switch (CU8(base)) {
>> ? ? ? ? ? ? ? ?case ATOM_IIO_NOP:
>> @@ -112,7 +115,8 @@ static uint32_t atom_iio_execute(struct atom_context 
>> *ctx, int base,
>> ? ? ? ? ? ? ? ? ? ? ? ?base += 3;
>> ? ? ? ? ? ? ? ? ? ? ? ?break;
>> ? ? ? ? ? ? ? ?case ATOM_IIO_WRITE:
>> - ? ? ? ? ? ? ? ? ? ? ? (void)ctx->card->ioreg_read(ctx->card, CU16(base + 
>> 1));
>> + ? ? ? ? ? ? ? ? ? ? ? if (rdev->family == CHIP_RV515)
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (void)ctx->card->ioreg_read(ctx->card, 
>> CU16(base + 1));
>> ? ? ? ? ? ? ? ? ? ? ? ?ctx->card->ioreg_write(ctx->card, CU16(base + 1), 
>> temp);
>> ? ? ? ? ? ? ? ? ? ? ? ?base += 3;
>> ? ? ? ? ? ? ? ? ? ? ? ?break;
>> --
>> 1.7.1.1
>>
>
>
> So this patch enable io write only for one family ? This looks utterly 
> strange.

No, it just does a read before write for rv515.  I don't know why it
needs it, but it seems to.

Alex

>
> Cheers,
> Jerome
>

[PATCH] drm/radeon/kms: fix suspend on rv530 asics

[Jerome Glisse]

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-by: Alex Deucher 
> Cc: stable at kernel.org
> ---
> ?drivers/gpu/drm/radeon/atom.c | ? ?6 +-
> ?1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
> index 258fa5e..d71d375 100644
> --- a/drivers/gpu/drm/radeon/atom.c
> +++ b/drivers/gpu/drm/radeon/atom.c
> @@ -32,6 +32,7 @@
> ?#include "atom.h"
> ?#include "atom-names.h"
> ?#include "atom-bits.h"
> +#include "radeon.h"
>
> ?#define ATOM_COND_ABOVE ? ? ? ? ? ? ? ?0
> ?#define ATOM_COND_ABOVEOREQUAL 1
> @@ -101,7 +102,9 @@ static void debug_print_spaces(int n)
> ?static uint32_t atom_iio_execute(struct atom_context *ctx, int base,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? uint32_t index, uint32_t data)
> ?{
> + ? ? ? struct radeon_device *rdev = ctx->card->dev->dev_private;
> ? ? ? ?uint32_t temp = 0xCDCDCDCD;
> +
> ? ? ? ?while (1)
> ? ? ? ? ? ? ? ?switch (CU8(base)) {
> ? ? ? ? ? ? ? ?case ATOM_IIO_NOP:
> @@ -112,7 +115,8 @@ static uint32_t atom_iio_execute(struct atom_context 
> *ctx, int base,
> ? ? ? ? ? ? ? ? ? ? ? ?base += 3;
> ? ? ? ? ? ? ? ? ? ? ? ?break;
> ? ? ? ? ? ? ? ?case ATOM_IIO_WRITE:
> - ? ? ? ? ? ? ? ? ? ? ? (void)ctx->card->ioreg_read(ctx->card, CU16(base + 
> 1));
> + ? ? ? ? ? ? ? ? ? ? ? if (rdev->family == CHIP_RV515)
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (void)ctx->card->ioreg_read(ctx->card, 
> CU16(base + 1));
> ? ? ? ? ? ? ? ? ? ? ? ?ctx->card->ioreg_write(ctx->card, CU16(base + 1), 
> temp);
> ? ? ? ? ? ? ? ? ? ? ? ?base += 3;
> ? ? ? ? ? ? ? ? ? ? ? ?break;
> --
> 1.7.1.1
>


So this patch enable io write only for one family ? This looks utterly strange.

Cheers,
Jerome

[Bug 30651] [RADEON:KMS:R600G] gl output in mplayer have no colors if used with a fragment program with additional lookup and bicubic B-spline filtering

[bugzilla-dae...@freedesktop.org]

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.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 30651] [RADEON:KMS:R600G] gl output in mplayer have no colors if used with a fragment program with additional lookup and bicubic B-spline filtering

[bugzilla-dae...@freedesktop.org]

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 overbright glitch in some white places in some videos 
> with
> yuv=6. but again, it may be a mplayer bug since it present with r300g too (but
> not software rasterizer), i'm not sure.

This is still the same.

One general observation is the with 600g perf is poor compared to 600c or xv,
which are at least 2x faster when benchmarking with HD streams.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

small git lesson [Was: Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?]

[Uwe Kleine-König]

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 not include this commit
> (was introduced before 2.6.39-rc1 according to gitk).
gitk is not the best tool to find this out.

$ 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.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-K?nig|
Industrial Linux Solutions | http://www.pengutronix.de/  |

Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?

[Gabriel Paubert]

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).

Gabriel

Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?

[Gabriel Paubert]

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 ioctl loop and the logs are: 
> > > 
> > > Which ioctl does it loop on? Please provide the Xorg.0.log file as well.
> > 
> > From memory, the code was 0x64, which is DRM_RADEON_GEM_WAIT_IDLE.
> 
> Note that it's normal for this ioctl to be called every time before the
> GPU accessible pixmap memory is accessed by the CPU. Unless the ioctl
> always returns an error, this may not indicate a problem on its own. 

It seems to be an infinite loop, always returning EINTR because
of regular SIGALRM delivery.

> 
> 
> > The Xorg.0.log from the previous boot is attached.
> 
> I don't see any obvious problems in it. Can you describe the symptoms of
> the problem you're having with X a bit more?

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.

> 
> One thing I notice is that the X server/driver are rather oldish. Maybe
> you can try newer versions from testing, sid or even experimental to see
> if that makes any difference.

I lack time to do it until early May (being away for 2 weeks starting on 
Friday and busy on urgent things). I'm indeed Debian stable (Squeeze),
which is rather recent and the machine is about 2 1/2 years old.

Gabriel

[PATCH] drm/i915: restore only the mode of this driver on lastclose (v2)

[Dave Airlie]

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 code to block mode change on
powered off GPUs.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_fb_helper.c  |   27 ---
 drivers/gpu/drm/i915/i915_dma.c  |2 +-
 drivers/gpu/drm/i915/intel_drv.h |1 +
 drivers/gpu/drm/i915/intel_fb.c  |   10 ++
 include/drm/drm_fb_helper.h  |1 +
 5 files changed, 33 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 9507204..11d7a72 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -342,9 +342,22 @@ int drm_fb_helper_debug_leave(struct fb_info *info)
 }
 EXPORT_SYMBOL(drm_fb_helper_debug_leave);

+bool drm_fb_helper_restore_fbdev_mode(struct drm_fb_helper *fb_helper)
+{
+   bool error = false;
+   int i, ret;
+   for (i = 0; i < fb_helper->crtc_count; i++) {
+   struct drm_mode_set *mode_set = 
_helper->crtc_info[i].mode_set;
+   ret = drm_crtc_helper_set_config(mode_set);
+   if (ret)
+   error = true;
+   }
+   return error;
+}
+EXPORT_SYMBOL(drm_fb_helper_restore_fbdev_mode);
+
 bool drm_fb_helper_force_kernel_mode(void)
 {
-   int i = 0;
bool ret, error = false;
struct drm_fb_helper *helper;

@@ -352,12 +365,12 @@ bool drm_fb_helper_force_kernel_mode(void)
return false;

list_for_each_entry(helper, _fb_helper_list, kernel_fb_list) {
-   for (i = 0; i < helper->crtc_count; i++) {
-   struct drm_mode_set *mode_set = 
>crtc_info[i].mode_set;
-   ret = drm_crtc_helper_set_config(mode_set);
-   if (ret)
-   error = true;
-   }
+   if (helper->dev->switch_power_state == DRM_SWITCH_POWER_OFF)
+   continue;
+
+   ret = drm_fb_helper_restore_fbdev_mode(helper);
+   if (ret)
+   error = true;
}
return error;
 }
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 7273037..12876f2 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -2207,7 +2207,7 @@ void i915_driver_lastclose(struct drm_device * dev)
drm_i915_private_t *dev_priv = dev->dev_private;

if (!dev_priv || drm_core_check_feature(dev, DRIVER_MODESET)) {
-   drm_fb_helper_restore();
+   intel_fb_restore_mode(dev);
vga_switcheroo_process_delayed_switch();
return;
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index f5b0d83..1d20712 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -338,4 +338,5 @@ extern int intel_overlay_attrs(struct drm_device *dev, void 
*data,
   struct drm_file *file_priv);

 extern void intel_fb_output_poll_changed(struct drm_device *dev);
+extern void intel_fb_restore_mode(struct drm_device *dev);
 #endif /* __INTEL_DRV_H__ */
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index 5127827..ec49bae 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -264,3 +264,13 @@ void intel_fb_output_poll_changed(struct drm_device *dev)
drm_i915_private_t *dev_priv = dev->dev_private;
drm_fb_helper_hotplug_event(_priv->fbdev->helper);
 }
+
+void intel_fb_restore_mode(struct drm_device *dev)
+{
+   int ret;
+   drm_i915_private_t *dev_priv = dev->dev_private;
+
+   ret = drm_fb_helper_restore_fbdev_mode(_priv->fbdev->helper);
+   if (ret)
+   DRM_DEBUG("failed to restore crtc mode\n");
+}
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index f22e7fe..ade09d7 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -118,6 +118,7 @@ int drm_fb_helper_setcolreg(unsigned regno,
unsigned transp,
struct fb_info *info);

+bool drm_fb_helper_restore_fbdev_mode(struct drm_fb_helper *fb_helper);
 void drm_fb_helper_restore(void);
 void drm_fb_helper_fill_var(struct fb_info *info, struct drm_fb_helper 
*fb_helper,
uint32_t fb_width, uint32_t fb_height);
-- 
1.7.1

[Bug 25588] Lots of ARB_vertex_program/fragment_program parser errors in ETQW (if GLSL is unavailable)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=25588

Fabio Pedretti  changed:

   What|Removed |Added

 Resolution|WORKSFORME  |WONTFIX
  Component|Mesa core   |Drivers/DRI/r300
 AssignedTo|mesa-dev at lists.freedesktop. |dri-devel at 
lists.freedesktop
   |org |.org

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

Linux 2.6.39-rc3

[Ingo Molnar]

* 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 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
> fine.
>
> During the bisect I tested commits from Yinghai which were good. It seems 
> like the problem appeared with the merge.

There's a similar looking bug being debugged here:

  https://bugzilla.kernel.org/show_bug.cgi?id=33012

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:  d2137d5af425: Merge branch 'linus' into x86/bootmem

I've Cc:-ed more people who might have an idea about it.

Thanks,

Ingo

[PATCH] drm/i915: restore only the mode of this driver on lastclose (v2)

[Chris Wilson]

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 restore
> its own fbcon mode.
> 
> v2: move code into fb helper, fix panic code to block mode change on
> powered off GPUs.

2 bugs in one patch?  This could be split into 3 steps... ;-)

Aside from that, looks good.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 35502] Regression: black screen with Radeon KMS in 2.6.38 (2.6.37.4 worked fine)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=35502

Michel D?nzer  changed:

   What|Removed |Added

 CC||bryce at canonical.com

--- Comment #9 from Michel D?nzer  2011-04-13 04:45:42 
PDT ---
*** Bug 36007 has been marked as a duplicate of this bug. ***

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

This should have gone out a few days ago, but I was trapped watching 
Disney shows with my daughter at home and I wanted to check it on a few 
more machines,

Its got two reverts, one for a change I pushed out by accident to -fixes, 
the other for a Xen/TTM change, that looks to be causing non-Xen 
problems so punting on it for now. The rest is mostly nouveau + radeon 
fixes, the radeon ones fix a few regressions and stability problems on 
newer cards.

I suspect I'll have a few more intel fixes and v2 of the i915 patch I 
reverted out of this pull, it fixes a problem on the dual-gpu laptops reported 
a 
long while ago.

The following changes since commit 94c8a984ae2adbd9a9626fb42e0f2faf3e36e86f:

  Merge branch 'bugfixes' of git://git.linux-nfs.org/projects/trondmy/nfs-2.6 
(2011-04-08 11:47:35 -0700)

are available in the git repository at:

  ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes

Alex Deucher (7):
  drm/radeon/kms: pll tweaks for rv6xx
  drm/radeon/kms: make radeon i2c put/get bytes less noisy
  drm/radeon/kms: clean up gart dummy page handling
  drm/radeon/kms: fix suspend on rv530 asics
  drm/radeon/kms: fix pcie_p callbacks on btc and cayman
  drm/radeon/kms: add voltage type to atom set voltage function
  drm/radeon/kms: properly program vddci on evergreen+

Ben Skeggs (5):
  drm/nouveau: implement init table opcode 0x5c
  drm/nouveau: quirk for XFX GT-240X-YA
  drm/nv50: use "nv86" tlb flush method on everything except 0x50/0xac
  drm/nv50-nvc0: remove some code that doesn't belong here
  drm/nvc0: improve vm flush function

Dave Airlie (4):
  i915: restore only the mode of this driver on lastclose
  Merge remote branch 'nouveau/drm-nouveau-fixes' of 
/ssd/git/drm-nouveau-next into drm-fixes
  Revert "ttm: Utilize the DMA API for pages that have TTM_PAGE_FLAG_DMA32 
set."
  Revert "i915: restore only the mode of this driver on lastclose"

David Dillow (1):
  drm/nv50-nvc0: work around an evo channel hang that some people see

Emil Velikov (1):
  nv30: Fix parsing of perf table

Konstantin Khlebnikov (1):
  i915: select VIDEO_OUTPUT_CONTROL for ACPI_VIDEO

Marcin Slusarz (1):
  drm/nouveau: fix oops on unload with disabled LVDS panel

Michel D?nzer (2):
  radeon: Fix KMS CP writeback on big endian machines.
  drm/radeon: Fix KMS legacy backlight support if 
CONFIG_BACKLIGHT_CLASS_DEVICE=m.

Roy Spliet (1):
  drm/nouveau: correct memtiming table parsing for nv4x

 drivers/gpu/drm/Kconfig |1 +
 drivers/gpu/drm/nouveau/nouveau_bios.c  |   53 +++-
 drivers/gpu/drm/nouveau/nouveau_drv.h   |2 +-
 drivers/gpu/drm/nouveau/nouveau_mem.c   |   76 +++
 drivers/gpu/drm/nouveau/nouveau_perf.c  |2 +-
 drivers/gpu/drm/nouveau/nouveau_state.c |   12 +---
 drivers/gpu/drm/nouveau/nv04_dfp.c  |   13 ++--
 drivers/gpu/drm/nouveau/nv50_crtc.c |3 -
 drivers/gpu/drm/nouveau/nv50_evo.c  |1 +
 drivers/gpu/drm/nouveau/nv50_graph.c|2 +-
 drivers/gpu/drm/nouveau/nvc0_vm.c   |   24 +---
 drivers/gpu/drm/radeon/atom.c   |6 ++-
 drivers/gpu/drm/radeon/atombios_crtc.c  |6 ++
 drivers/gpu/drm/radeon/evergreen.c  |   17 +++---
 drivers/gpu/drm/radeon/r600.c   |6 +--
 drivers/gpu/drm/radeon/radeon.h |   12 +++-
 drivers/gpu/drm/radeon/radeon_asic.c|2 +-
 drivers/gpu/drm/radeon/radeon_atombios.c|   30 ++---
 drivers/gpu/drm/radeon/radeon_fence.c   |2 +-
 drivers/gpu/drm/radeon/radeon_gart.c|2 +
 drivers/gpu/drm/radeon/radeon_i2c.c |4 +-
 drivers/gpu/drm/radeon/radeon_legacy_encoders.c |2 +-
 drivers/gpu/drm/radeon/radeon_pm.c  |   11 +++-
 drivers/gpu/drm/radeon/radeon_ring.c|2 +-
 drivers/gpu/drm/radeon/rs600.c  |2 +-
 drivers/gpu/drm/radeon/rv770.c  |6 +--
 drivers/gpu/drm/ttm/ttm_page_alloc.c|   26 +---
 drivers/gpu/stub/Kconfig|1 +
 28 files changed, 201 insertions(+), 125 deletions(-)

[Bug 34534] resolution 3840x1024 stopped to work on HD5850 after switch to 2.6.37 kernel

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=34534

--- Comment #16 from Peter Hercek  2011-04-13 01:37:03 
PDT ---
(In reply to comment #14)
> Does this patch help?

No, the image stays corrupted, I still need to do this to fix it:
# radeonreg regset 0x770c 0x00020004
OLD: 0x770c (770c)0x00010005 (65541)
NEW: 0x770c (770c)0x00010004 (65540)
#

I applied and tested the patch with 2.6.38.2-vanilla.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 34534] resolution 3840x1024 stopped to work on HD5850 after switch to 2.6.37 kernel

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=34534

--- Comment #15 from Peter Hercek  2011-04-13 00:37:56 
PDT ---
Created an attachment (id=45562)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=45562)
xrandr --verbose output on 2.6.38.2-vanilla (with 3840x1024 fixed using
radeonreg regset 0x770c 0x00020004)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

Re: [PATCH] drm/i915: restore only the mode of this driver on lastclose (v2)

[Chris Wilson]

On Wed, 13 Apr 2011 09:35:55 +1000, Dave Airlie airl...@gmail.com wrote:
 From: Dave Airlie airl...@redhat.com
 
 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 code to block mode change on
 powered off GPUs.

2 bugs in one patch?  This could be split into 3 steps... ;-)

Aside from that, looks good.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 2.6.39-rc3

[Ingo Molnar]

* 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 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
 fine.

 During the bisect I tested commits from Yinghai which were good. It seems 
 like the problem appeared with the merge.

There's a similar looking bug being debugged here:

  https://bugzilla.kernel.org/show_bug.cgi?id=33012

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:  d2137d5af425: Merge branch 'linus' into x86/bootmem

I've Cc:-ed more people who might have an idea about it.

Thanks,

Ingo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 34534] resolution 3840x1024 stopped to work on HD5850 after switch to 2.6.37 kernel

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=34534

--- Comment #15 from Peter Hercek pher...@gmail.com 2011-04-13 00:37:56 PDT 
---
Created an attachment (id=45562)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=45562)
xrandr --verbose output on 2.6.38.2-vanilla (with 3840x1024 fixed using
radeonreg regset 0x770c 0x00020004)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?

[Gabriel Paubert]

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 ioctl loop and the logs are: 
   
   Which ioctl does it loop on? Please provide the Xorg.0.log file as well.
  
  From memory, the code was 0x64, which is DRM_RADEON_GEM_WAIT_IDLE.
 
 Note that it's normal for this ioctl to be called every time before the
 GPU accessible pixmap memory is accessed by the CPU. Unless the ioctl
 always returns an error, this may not indicate a problem on its own. 

It seems to be an infinite loop, always returning EINTR because
of regular SIGALRM delivery.

 
 
  The Xorg.0.log from the previous boot is attached.
 
 I don't see any obvious problems in it. Can you describe the symptoms of
 the problem you're having with X a bit more?

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.

 
 One thing I notice is that the X server/driver are rather oldish. Maybe
 you can try newer versions from testing, sid or even experimental to see
 if that makes any difference.

I lack time to do it until early May (being away for 2 weeks starting on 
Friday and busy on urgent things). I'm indeed Debian stable (Squeeze),
which is rather recent and the machine is about 2 1/2 years old.

Gabriel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?

[Gabriel Paubert]

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).

Gabriel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 34534] resolution 3840x1024 stopped to work on HD5850 after switch to 2.6.37 kernel

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=34534

--- Comment #16 from Peter Hercek pher...@gmail.com 2011-04-13 01:37:03 PDT 
---
(In reply to comment #14)
 Does this patch help?

No, the image stays corrupted, I still need to do this to fix it:
# radeonreg regset 0x770c 0x00020004
OLD: 0x770c (770c)0x00010005 (65541)
NEW: 0x770c (770c)0x00010004 (65540)
#

I applied and tested the patch with 2.6.38.2-vanilla.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?

[Benjamin Herrenschmidt]

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 radeons do so, sometimes it has to do with them not liking
what you ate that day...

The only thing I can see that could be of use would be a bisect

Cheers,
Ben.


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?

[Gabriel Paubert]

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.
 
 So basically the card crashed. There's about an infinite amount of
 reasons why radeons do so, sometimes it has to do with them not liking
 what you ate that day...
 
 The only thing I can see that could be of use would be a bisect

Bisecting for something which I have never got to work (radeon with
KMS) on this machine is something I don't know how to do...

Note that radeon without KMS also always ends up crashing, but it
may take hours. The only case where the machine works reliably is 
when glxinfo claims that it is using software rendering.
 
Regards,
Gabriel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: small git lesson [Was: Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?]

[Gabriel Paubert]

On Wed, Apr 13, 2011 at 10:59:14AM +0200, Andreas Schwab wrote:
 Uwe Kleine-König u.kleine-koe...@pengutronix.de 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-rc1
 v2.6.39-rc2
 

So who is right? I think it was before rc1. 

Anyway I'm aware that there are other git commands, although for the option
details I often have to have a look at the man page.

However in this case the main reason to fire gitk was to have a quick look 
at the patch and its context, and simply reported the Precedes line 
in the display, which is 2.6.39-rc1. It also follow v2.6.37-rc2, which means
that it has been quite a long time outside the main tree.

Gabriel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] Big Endian support for RV730 (Mesa r600)

[Benjamin Herrenschmidt]

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-February/008151.html).
 
 I used the mesa-demos to test the driver status on big endian platform. 
 Nearly all demos renders the same as on Intel architecture. 
 Nevertheless, there are still some issues in glReadPixels (r600_blit) 
 with some formats. I can't figure out exactly what and when data must be 
 swapped (set_tex_resoures, set_render_target...). Review of the patch 
 would be greatly appreciated.
 
 It seems that r600g will be the default for Mesa 7.11 so I'll try to 
 enable big endian support for Gallium now.

Cool stuff !

I'll try to test that one of these days on various ppc's

Cheers,
Ben.


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] Big Endian support for RV730 (Mesa r600)

[Benjamin Herrenschmidt]

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 driver modifications 
  (http://lists.freedesktop.org/archives/dri-devel/2011-February/008151.html).
  
  I used the mesa-demos to test the driver status on big endian platform. 
  Nearly all demos renders the same as on Intel architecture. 
  Nevertheless, there are still some issues in glReadPixels (r600_blit) 
  with some formats. I can't figure out exactly what and when data must be 
  swapped (set_tex_resoures, set_render_target...). Review of the patch 
  would be greatly appreciated.
  
  It seems that r600g will be the default for Mesa 7.11 so I'll try to 
  enable big endian support for Gallium now.
 
 Cool stuff !
 
 I'll try to test that one of these days on various ppc's

BTW. I see you used some FSL embedded board. Do you have your PCIe MMIO
space above 32-bit ? Last I looked, there was a bunch of fixing needing
to be done, among others in the TTM, to make that work.

I had some preliminary patches but they bitrot... mostly the issue is to
make sure than a phys_addr_t is used instead of an unsigned long
whenever it tries to store the physical address of an object.

Ben.
 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?

[Michel Dänzer]

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 goes a bit further but the X server ends
 up in an infinite ioctl loop and the logs are: 

Which ioctl does it loop on? Please provide the Xorg.0.log file as well.
   
   From memory, the code was 0x64, which is DRM_RADEON_GEM_WAIT_IDLE.
  
  Note that it's normal for this ioctl to be called every time before the
  GPU accessible pixmap memory is accessed by the CPU. Unless the ioctl
  always returns an error, this may not indicate a problem on its own. 
 
 It seems to be an infinite loop, always returning EINTR because
 of regular SIGALRM delivery.

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?


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?

[Gabriel Paubert]

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 +0200, Michel Dänzer wrote:
  
  With no_wb=1 the driver goes a bit further but the X server ends
  up in an infinite ioctl loop and the logs are: 
 
 Which ioctl does it loop on? Please provide the Xorg.0.log file as 
 well.

From memory, the code was 0x64, which is DRM_RADEON_GEM_WAIT_IDLE.
   
   Note that it's normal for this ioctl to be called every time before the
   GPU accessible pixmap memory is accessed by the CPU. Unless the ioctl
   always returns an error, this may not indicate a problem on its own. 
  
  It seems to be an infinite loop, always returning EINTR because
  of regular SIGALRM delivery.
 
 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.

Gabriel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon/kms: fix suspend on rv530 asics

[Jerome Glisse]

On Tue, Apr 12, 2011 at 1:33 PM, Alex Deucher alexdeuc...@gmail.com 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-by: Alex Deucher alexdeuc...@gmail.com
 Cc: sta...@kernel.org
 ---
  drivers/gpu/drm/radeon/atom.c |    6 +-
  1 files changed, 5 insertions(+), 1 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
 index 258fa5e..d71d375 100644
 --- a/drivers/gpu/drm/radeon/atom.c
 +++ b/drivers/gpu/drm/radeon/atom.c
 @@ -32,6 +32,7 @@
  #include atom.h
  #include atom-names.h
  #include atom-bits.h
 +#include radeon.h

  #define ATOM_COND_ABOVE                0
  #define ATOM_COND_ABOVEOREQUAL 1
 @@ -101,7 +102,9 @@ static void debug_print_spaces(int n)
  static uint32_t atom_iio_execute(struct atom_context *ctx, int base,
                                 uint32_t index, uint32_t data)
  {
 +       struct radeon_device *rdev = ctx-card-dev-dev_private;
        uint32_t temp = 0xCDCDCDCD;
 +
        while (1)
                switch (CU8(base)) {
                case ATOM_IIO_NOP:
 @@ -112,7 +115,8 @@ static uint32_t atom_iio_execute(struct atom_context 
 *ctx, int base,
                        base += 3;
                        break;
                case ATOM_IIO_WRITE:
 -                       (void)ctx-card-ioreg_read(ctx-card, CU16(base + 
 1));
 +                       if (rdev-family == CHIP_RV515)
 +                               (void)ctx-card-ioreg_read(ctx-card, 
 CU16(base + 1));
                        ctx-card-ioreg_write(ctx-card, CU16(base + 1), 
 temp);
                        base += 3;
                        break;
 --
 1.7.1.1



So this patch enable io write only for one family ? This looks utterly strange.

Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon/kms: fix suspend on rv530 asics

[Alex Deucher]

On Wed, Apr 13, 2011 at 10:46 AM, Jerome Glisse j.gli...@gmail.com wrote:
 On Tue, Apr 12, 2011 at 1:33 PM, Alex Deucher alexdeuc...@gmail.com 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-by: Alex Deucher alexdeuc...@gmail.com
 Cc: sta...@kernel.org
 ---
  drivers/gpu/drm/radeon/atom.c |    6 +-
  1 files changed, 5 insertions(+), 1 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
 index 258fa5e..d71d375 100644
 --- a/drivers/gpu/drm/radeon/atom.c
 +++ b/drivers/gpu/drm/radeon/atom.c
 @@ -32,6 +32,7 @@
  #include atom.h
  #include atom-names.h
  #include atom-bits.h
 +#include radeon.h

  #define ATOM_COND_ABOVE                0
  #define ATOM_COND_ABOVEOREQUAL 1
 @@ -101,7 +102,9 @@ static void debug_print_spaces(int n)
  static uint32_t atom_iio_execute(struct atom_context *ctx, int base,
                                 uint32_t index, uint32_t data)
  {
 +       struct radeon_device *rdev = ctx-card-dev-dev_private;
        uint32_t temp = 0xCDCDCDCD;
 +
        while (1)
                switch (CU8(base)) {
                case ATOM_IIO_NOP:
 @@ -112,7 +115,8 @@ static uint32_t atom_iio_execute(struct atom_context 
 *ctx, int base,
                        base += 3;
                        break;
                case ATOM_IIO_WRITE:
 -                       (void)ctx-card-ioreg_read(ctx-card, CU16(base + 
 1));
 +                       if (rdev-family == CHIP_RV515)
 +                               (void)ctx-card-ioreg_read(ctx-card, 
 CU16(base + 1));
                        ctx-card-ioreg_write(ctx-card, CU16(base + 1), 
 temp);
                        base += 3;
                        break;
 --
 1.7.1.1



 So this patch enable io write only for one family ? This looks utterly 
 strange.

No, it just does a read before write for rv515.  I don't know why it
needs it, but it seems to.

Alex


 Cheers,
 Jerome

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 25588] Lots of ARB_vertex_program/fragment_program parser errors in ETQW (if GLSL is unavailable)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=25588

Fabio Pedretti fabio@libero.it changed:

   What|Removed |Added

 Resolution|WORKSFORME  |WONTFIX
  Component|Mesa core   |Drivers/DRI/r300
 AssignedTo|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
   |org |.org

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 33222] New: [RADEON] Oops in worker thread for radeon_unpin_work_func

[bugzilla-daemon]

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: Mainline
Status: NEW
  Severity: low
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-...@kernel-bugs.osdl.org
ReportedBy: tho...@m3y3r.de
Regression: No


Created an attachment (id=54282)
 -- (https://bugzilla.kernel.org/attachment.cgi?id=54282)
Oops - Part 1

Few days ago I stumbled upon the attached oops. Just images. sorry for that.
This is the first time I saw this oops. I just hit it once for 2.6.38.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

--
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
--
___
Dri-devel mailing list
dri-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 33222] [RADEON] Oops in worker thread for radeon_unpin_work_func

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=33222





--- Comment #1 from Thomas Meyer tho...@m3y3r.de  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
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

--
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
--
___
Dri-devel mailing list
dri-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

small git lesson [Was: Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?]

[Uwe Kleine-König]

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 not include this commit
 (was introduced before 2.6.39-rc1 according to gitk).
gitk is not the best tool to find this out.

$ 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.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: small git lesson [Was: Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?]

[Andreas Schwab]

Uwe Kleine-König u.kleine-koe...@pengutronix.de 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-rc1
v2.6.39-rc2

Andreas.

-- 
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
And now for something completely different.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: small git lesson [Was: Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?]

[Uwe Kleine-König]

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 u.kleine-koe...@pengutronix.de 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-rc1
  v2.6.39-rc2
  
 
 So who is right? I think it was before rc1. 
Yep, correct. I interpreted the output of git name-rev to mean it's not
included in a tag earlier than v2.6.39-rc2, but actually that's wrong.
It's just that it's easier (for some definition of easy) to reach the
commit in question from v2.6.39-rc2 than from v2.6.39-rc1.

 However in this case the main reason to fire gitk was to have a quick look 
 at the patch and its context, and simply reported the Precedes line 
 in the display, which is 2.6.39-rc1. It also follow v2.6.37-rc2, which means
 that it has been quite a long time outside the main tree.
I think this conclusion isn't valid in general. (E.g. in git itself a
bug-fix is often done on top of the commit that introduced it and than
merged into master. Still the bugfix might be new.) But looking at the
AuthorDate of 69a07f0b117a seems to support your statement.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 33222] [RADEON] Oops in worker thread for radeon_unpin_work_func

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=33222


Alex Deucher alexdeuc...@gmail.com changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com




--- Comment #2 from Alex Deucher alexdeuc...@gmail.com  2011-04-13 17:19:06 
---
This is a duplicate of bug 32402.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

--
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
--
___
Dri-devel mailing list
dri-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 2.6.39-rc3

[Joerg Roedel]

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:  d2137d5af425: Merge branch 'linus' into x86/bootmem
 
 I've Cc:-ed more people who might have an idea about it.

Okay, I have done some more bisecting and debugging today.

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 successful. The bad commit in this branch turned out to be

1a4a678b12c84db9ae5dce424e0e97f0559bb57c

which is related to memblock.

Then I tried to find out which change between 2.6.38-rc4 and 2.6.38-rc5
is needed to trigger the failure, so I used f005fe12b90c as a base,
bisected between v2.6.38-rc4..v2.6.38-rc5 and merged every bisect step
into the base and tested. Here the bad commit turned out to be

e6d2e2b2b1e1455df16d68a78f4a3874c7b3ad20

which is related to gart. It turned out that the gart aperture on that
box is on another position with these patches. Before it was as
0xa400 and now it is at 0xa000. It seems like this has something
to do with the root-cause.

Reverting commit 1a4a678b12c84db9ae5dce424e0e97f0559bb57c fixes the
problem btw. and booting with iommu=soft also works, but I have no idea
yet why the aperture at that address is a problem (with the patch
reverted the aperture lands at 0x8000).

I have put some debug-data online. There is my .config and two
dmesg-files for good (==2.6.39-rc3 + revert) and bad (==2.6.39-rc3)
I also created these dmesg-files again with memblock=debug, maybe that
helps to find the problem. The files are at

http://www.8bytes.org/~joro/debug/

Or someone else has an idea about the issue...

Joerg

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 30651] [RADEON:KMS:R600G] gl output in mplayer have no colors if used with a fragment program with additional lookup and bicubic B-spline filtering

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=30651

--- Comment #7 from Andy Furniss li...@andyfurniss.entadsl.com 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 overbright glitch in some white places in some videos 
 with
 yuv=6. but again, it may be a mplayer bug since it present with r300g too (but
 not software rasterizer), i'm not sure.

This is still the same.

One general observation is the with 600g perf is poor compared to 600c or xv,
which are at least 2x faster when benchmarking with HD streams.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 30651] [RADEON:KMS:R600G] gl output in mplayer have no colors if used with a fragment program with additional lookup and bicubic B-spline filtering

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=30651

--- Comment #8 from Sergey Kondakov virtuous...@gmail.com 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.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 30651] [RADEON:KMS:R600G] gl output in mplayer have no colors if used with a fragment program with additional lookup and bicubic B-spline filtering

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=30651

--- Comment #9 from Andy Furniss li...@andyfurniss.entadsl.com 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 there isn't an answer as such for that question.

I guess someone with an on-board low spec GPU may be more limited than a high
end card with fast vram.

Quality wise - I can't see any difference, the higher yuv= numbers give more
features like gamma correction (not sure how to use it though).

It would be nice if 600g could beat or equal 600c - it does for 3D, but for
some reason not this.

I said classic was twice as fast - it's actually more than that if I discount
time taken by the codec.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 32982] Kernel locks up a few minutes after boot

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=32982





--- Comment #6 from Bart Van Assche bart.vanass...@gmail.com  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 similar before with 2.6.39-rc2):

INFO: task kjournald:918 blocked for more than 120 seconds.
echo 0  /proc/sys/kernel/hung_task_timeout_secs disables this message.
kjournald   D 880131b9ddb8 0   918  2 0x
 880131b9dd20 0046 880131b9dca0 8108cd6d
 0282 880131b9dfd8 880137729f40 880131b9dfd8
 880131b9c000 880131b9c000 880131b9c000 880131b9dfd8
Call Trace:
 [8108cd6d] ? trace_hardirqs_on_caller+0x14d/0x190
 [81048419] ? sub_preempt_count+0xa9/0xe0
 [a00c615e] journal_commit_transaction+0x13e/0x1590 [jbd]
 [813e2535] ? _raw_spin_unlock_irqrestore+0x65/0x80
 [81048419] ? sub_preempt_count+0xa9/0xe0
 [81075280] ? wake_up_bit+0x40/0x40
 [8106258a] ? del_timer_sync+0x8a/0xc0
 [81062500] ? try_to_del_timer_sync+0x110/0x110
 [a00ca1a1] kjournald+0xf1/0x250 [jbd]
 [81075280] ? wake_up_bit+0x40/0x40
 [a00ca0b0] ? commit_timeout+0x10/0x10 [jbd]
 [81074c66] kthread+0x96/0xa0
 [813e4294] kernel_thread_helper+0x4/0x10
 [8103cebb] ? finish_task_switch+0x7b/0xe0
 [813e24ab] ? _raw_spin_unlock_irq+0x3b/0x60
 [813e2944] ? retint_restore_args+0xe/0xe
 [81074bd0] ? __init_kthread_worker+0x70/0x70
 [813e4290] ? gs_change+0xb/0xb
no locks held by kjournald/918.
INFO: task klauncher:5744 blocked for more than 120 seconds.
echo 0  /proc/sys/kernel/hung_task_timeout_secs disables this message.
klauncher   D 0001000297b4 0  5744   5743 0x
 88011dd73938 0046 8801 8108cbef
 813e2535 88011dd73fd8 8801382e1f40 88011dd73fd8
 88011dd72000 88011dd72000 88011dd72000 88011dd73fd8
Call Trace:
 [8108cbef] ? mark_held_locks+0x6f/0xa0
 [813e2535] ? _raw_spin_unlock_irqrestore+0x65/0x80
 [8115b830] ? __wait_on_buffer+0x30/0x30
 [813df0e9] io_schedule+0x59/0x80
 [8115b83e] sleep_on_buffer+0xe/0x20
 [813df89a] __wait_on_bit_lock+0x5a/0xc0
 [8115b830] ? __wait_on_buffer+0x30/0x30
 [813df978] out_of_line_wait_on_bit_lock+0x78/0x90
 [810752d0] ? autoremove_wake_function+0x50/0x50
 [8115b886] __lock_buffer+0x36/0x40
 [a00c56ad] do_get_write_access+0x64d/0x660 [jbd]
 [81048419] ? sub_preempt_count+0xa9/0xe0
 [a00c33e0] ? start_this_handle+0x370/0x470 [jbd]
 [a00cb594] ? journal_add_journal_head+0xf4/0x220 [jbd]
 [a00c58f1] journal_get_write_access+0x31/0x50 [jbd]
 [a00efe6d] __ext3_journal_get_write_access+0x2d/0x60 [ext3]
 [a00e2423] ext3_reserve_inode_write+0x83/0xb0 [ext3]
 [a00e2494] ext3_mark_inode_dirty+0x44/0x70 [ext3]
 [a00e4ffe] ext3_dirty_inode+0x5e/0xa0 [ext3]
 [8115412f] __mark_inode_dirty+0x3f/0x250
 [8114627c] file_update_time+0xec/0x170
 [813dfecd] ? mutex_lock_nested+0x27d/0x3a0
 [810e4138] __generic_file_aio_write+0x1f8/0x440
 [810e43f5] generic_file_aio_write+0x75/0xf0
 [8112ca6a] do_sync_write+0xda/0x120
 [8110a2d7] ? remove_vma+0x77/0x90
 [8108cdbd] ? trace_hardirqs_on+0xd/0x10
 [8110a2d7] ? remove_vma+0x77/0x90
 [8112d186] vfs_write+0xc6/0x170
 [8112d481] sys_write+0x51/0x90
 [813e31eb] system_call_fastpath+0x16/0x1b
2 locks held by klauncher/5744:
 #0:  (sb-s_type-i_mutex_key#11){+.+.+.}, at: [810e43d9]
generic_file_aio_write+0x59/0xf0
 #1:  (jbd_handle){+.+...}, at: [a00c33e0]
start_this_handle+0x370/0x470 [jbd]
INFO: task okular:4180 blocked for more than 120 seconds.
echo 0  /proc/sys/kernel/hung_task_timeout_secs disables this message.
okular  D 00010002a251 0  4180   5743 0x
 880041d13aa8 0046 8800 8108cd6d
 0282 880041d13fd8 880037a59f40 880041d13fd8
 880041d12000 880041d12000 880041d12000 880041d13fd8
Call Trace:
 [8108cd6d] ? trace_hardirqs_on_caller+0x14d/0x190
 [a00c32b4] start_this_handle+0x244/0x470 [jbd]
 [8109a633] ? is_module_address+0x33/0x60
 [81075280] ? wake_up_bit+0x40/0x40
 [a00c370b] journal_start+0xdb/0x120 [jbd]
 [a00eb436] ext3_journal_start_sb+0x36/0x70 [ext3]
 [a00e2663] ext3_setattr+0x1a3/0x210 [ext3]
 [81148556] notify_change+0x116/0x360
 [8112b803] do_truncate+0x63/0x90
 [81048419] ? sub_preempt_count+0xa9/0xe0
 [8113abac] do_last+0x42c/0x820
 [8113c3b0] path_openat+0xd0/0x410
 [81102ad3] ? 

Re: Linux 2.6.39-rc3

[H. Peter Anvin]

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 successful. The bad commit in this branch turned out to be
 
   1a4a678b12c84db9ae5dce424e0e97f0559bb57c
 
 which is related to memblock.
 
 Then I tried to find out which change between 2.6.38-rc4 and 2.6.38-rc5
 is needed to trigger the failure, so I used f005fe12b90c as a base,
 bisected between v2.6.38-rc4..v2.6.38-rc5 and merged every bisect step
 into the base and tested. Here the bad commit turned out to be
 
   e6d2e2b2b1e1455df16d68a78f4a3874c7b3ad20
 
 which is related to gart. It turned out that the gart aperture on that
 box is on another position with these patches. Before it was as
 0xa400 and now it is at 0xa000. It seems like this has something
 to do with the root-cause.
 
 Reverting commit 1a4a678b12c84db9ae5dce424e0e97f0559bb57c fixes the
 problem btw. and booting with iommu=soft also works, but I have no idea
 yet why the aperture at that address is a problem (with the patch
 reverted the aperture lands at 0x8000).
 

Does reverting e6d2e2b2b1e1455df16d68a78f4a3874c7b3ad20 solve the
problem for you?

1a4a678b12c84db9ae5dce424e0e97f0559bb57c is a memory-allocation-order
patch, which have a nasty tendency to unmask bugs elsewhere in the
kernel.  However, e6d2e2b2b1e1455df16d68a78f4a3874c7b3ad20 looks
positively strange (and it doesn't exactly help that the description is
written in Yinghai-ese and is therefore nearly impossible to decode,
never mind tell if it is remotely correct.)

-hpa


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 2.6.39-rc3

[Yinghai Lu]

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 again, but this time I merged v2.6.38-rc5 at every
 step and was successful. The bad commit in this branch turned out to be
 
   1a4a678b12c84db9ae5dce424e0e97f0559bb57c
 
 which is related to memblock.
 
 Then I tried to find out which change between 2.6.38-rc4 and 2.6.38-rc5
 is needed to trigger the failure, so I used f005fe12b90c as a base,
 bisected between v2.6.38-rc4..v2.6.38-rc5 and merged every bisect step
 into the base and tested. Here the bad commit turned out to be
 
   e6d2e2b2b1e1455df16d68a78f4a3874c7b3ad20
 
 which is related to gart. It turned out that the gart aperture on that
 box is on another position with these patches. Before it was as
 0xa400 and now it is at 0xa000. It seems like this has something
 to do with the root-cause.
 
 Reverting commit 1a4a678b12c84db9ae5dce424e0e97f0559bb57c fixes the
 problem btw. and booting with iommu=soft also works, but I have no idea
 yet why the aperture at that address is a problem (with the patch
 reverted the aperture lands at 0x8000).
 
 I have put some debug-data online. There is my .config and two
 dmesg-files for good (==2.6.39-rc3 + revert) and bad (==2.6.39-rc3)
 I also created these dmesg-files again with memblock=debug, maybe that
 helps to find the problem. The files are at
 
   http://www.8bytes.org/~joro/debug/

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 pointing to e820 RAM. Ignoring.
[0.00] Your BIOS doesn't leave a aperture memory hole
[0.00] Please enable the IOMMU option in the BIOS setup
[0.00] This costs you 64 MB of RAM
[0.00] memblock_x86_reserve_range: [0xa000-0xa3ff]   
aperture64
[0.00] Mapping aperture over 65536 KB of RAM @ a000

so kernel try to reallocate apperture. because BIOS allocated is pointed to RAM 
or size is too small.

but your radeon does use [0xa000, 0xbfff)

[4.281993] radeon :01:05.0: VRAM: 320M 0xC000 - 
0xD3FF (320M used)
[4.290672] radeon :01:05.0: GTT: 512M 0xA000 - 
0xBFFF
[4.298550] [drm] Detected VRAM RAM=320M, BAR=256M
[4.309857] [drm] RAM width 32bits DDR
[4.313748] [TTM] Zone  kernel: Available graphics memory: 1896524 kiB.
[4.320379] [TTM] Initializing pool allocator.
[4.324948] [drm] radeon: 320M of VRAM memory ready
[4.329832] [drm] radeon: 512M of GTT memory ready.

and the one seems working:

[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 BIOS doesn't leave a aperture memory hole
[0.00] Please enable the IOMMU option in the BIOS setup
[0.00] This costs you 64 MB of RAM
[0.00] memblock_x86_reserve_range: [0x8000-0x83ff]   
aperture64
[0.00] Mapping aperture over 65536 KB of RAM @ 8000
[0.00] memblock_x86_reserve_range: [0xacb6bdc0-0xacb6bddf]  
BOOTMEM

will use different position...

[4.250159] radeon :01:05.0: VRAM: 320M 0xC000 - 
0xD3FF (320M used)
[4.258830] radeon :01:05.0: GTT: 512M 0xA000 - 
0xBFFF
[4.266742] [drm] Detected VRAM RAM=320M, BAR=256M
[4.271549] [drm] RAM width 32bits DDR
[4.275435] [TTM] Zone  kernel: Available graphics memory: 1896526 kiB.
[4.282066] [TTM] Initializing pool allocator.
[4.282085] usb 7-2: new full speed USB device number 2 using ohci_hcd
[4.293076] [drm] radeon: 320M of VRAM memory ready
[4.298277] [drm] radeon: 512M of GTT memory ready.
[4.303218] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[4.309854] [drm] Driver supports precise vblank timestamp query.
[4.315970] [drm] radeon: irq initialized.
[4.320094] [drm] GART: num cpu pages 131072, num gpu pages 131072

So question is why radeon is using the address [0xa000 - 0xc00], and in 
E820 it is RAM 

[0.00]  BIOS-e820: 0010 - acb8d000 (usable)
[0.00]  BIOS-e820: acb8d000 - acb8f000 (reserved)
[0.00]  BIOS-e820: acb8f000 - afce9000 (usable)
[0.00]  BIOS-e820: afce9000 - afd21000 (reserved)
[0.00]  BIOS-e820: afd21000 - afd4f000 (usable)
[0.00]  BIOS-e820: afd4f000 - afdcf000 (reserved)
[0.00]  BIOS-e820: afdcf000 - afecf000 (ACPI NVS)
[  

Re: Linux 2.6.39-rc3

[H. Peter Anvin]

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, _end) out 
 of init_memory_mapping()
   after:  d2137d5af425: Merge branch 'linus' into x86/bootmem

 I've Cc:-ed more people who might have an idea about it.
 
 Okay, I have done some more bisecting and debugging today.
 

First of all, *huge* thanks for this effort.  At least we need to track
down the bits that need to be reverted -- it is past rc3, and it's time
to see what we should revert and tell the submitter to try again next cycle.

This looks to be the same issue as in bugzilla 33012:

https://bugzilla.kernel.org/show_bug.cgi?id=33012

... so it would be good if we could keep the information in there.

-hpa
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 2.6.39-rc3

[Joerg Roedel]

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 this again, but this time I merged v2.6.38-rc5 at every
  step and was successful. The bad commit in this branch turned out to be
  
  1a4a678b12c84db9ae5dce424e0e97f0559bb57c
  
  which is related to memblock.
  
  Then I tried to find out which change between 2.6.38-rc4 and 2.6.38-rc5
  is needed to trigger the failure, so I used f005fe12b90c as a base,
  bisected between v2.6.38-rc4..v2.6.38-rc5 and merged every bisect step
  into the base and tested. Here the bad commit turned out to be
  
  e6d2e2b2b1e1455df16d68a78f4a3874c7b3ad20
  
  which is related to gart. It turned out that the gart aperture on that
  box is on another position with these patches. Before it was as
  0xa400 and now it is at 0xa000. It seems like this has something
  to do with the root-cause.
  
  Reverting commit 1a4a678b12c84db9ae5dce424e0e97f0559bb57c fixes the
  problem btw. and booting with iommu=soft also works, but I have no idea
  yet why the aperture at that address is a problem (with the patch
  reverted the aperture lands at 0x8000).
  
 
 Does reverting e6d2e2b2b1e1455df16d68a78f4a3874c7b3ad20 solve the
 problem for you?

No, reverting that patch doesn't make the problem go away (and the gart
aperture is still on 0xa000). I tested this in 39-rc3, I havn't
tested if it makes a difference on the original bisect-commit from Ingo,
probably it does (don't know if that matters).
Strange about this commit is that it fixes an x86 gart aperture
allocation bug in generic memblock code.

 1a4a678b12c84db9ae5dce424e0e97f0559bb57c is a memory-allocation-order
 patch, which have a nasty tendency to unmask bugs elsewhere in the
 kernel.  However, e6d2e2b2b1e1455df16d68a78f4a3874c7b3ad20 looks
 positively strange (and it doesn't exactly help that the description is
 written in Yinghai-ese and is therefore nearly impossible to decode,
 never mind tell if it is remotely correct.)

I think that the two commits are okay and the bug is somewhere else, but
I have no idea yet were to look next. I spent some time looking at
radeon code and talking to Alex about it (because it seemed suspicous
that the GTT is on 0xa000 too, but as Alex explained me this is an
address in the GPU address space and shouldn't matter).

Regards,

   Joerg

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 2.6.39-rc3

[Joerg Roedel]

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?
 
   before:  f005fe12b90c: x86-64: Move out cleanup higmap [_brk_end, _end) 
  out of init_memory_mapping()
after:  d2137d5af425: Merge branch 'linus' into x86/bootmem
 
  I've Cc:-ed more people who might have an idea about it.
  
  Okay, I have done some more bisecting and debugging today.
  
 
 First of all, *huge* thanks for this effort.  At least we need to track
 down the bits that need to be reverted -- it is past rc3, and it's time
 to see what we should revert and tell the submitter to try again next cycle.
 
 This looks to be the same issue as in bugzilla 33012:
 
   https://bugzilla.kernel.org/show_bug.cgi?id=33012
 
 ... so it would be good if we could keep the information in there.

Yes, I try to find my korg bugzilla account again and drop the
information from this email there.

Joerg

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 2.6.39-rc3

[Joerg Roedel]

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 pointing to e820 RAM. Ignoring.
 [0.00] Your BIOS doesn't leave a aperture memory hole
 [0.00] Please enable the IOMMU option in the BIOS setup
 [0.00] This costs you 64 MB of RAM
 [0.00] memblock_x86_reserve_range: [0xa000-0xa3ff]   
 aperture64
 [0.00] Mapping aperture over 65536 KB of RAM @ a000
 
 so kernel try to reallocate apperture. because BIOS allocated is pointed to 
 RAM or size is too small.

It is actually beyond 4GB on that machine, this value read here is from
the previous kernel-boot. The BIOS does not reset these values on a
reboot.

 but your radeon does use [0xa000, 0xbfff)

Yes, I suspected that too (and spent a few hours reading radeon code),
but then I talked the Alex Deucher and he explained that these addresses
which the driver prints for GTT and VRAM are in the GPU address space
and do not refer to system ram. So this shouldn't be the problem.

Joerg

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 2.6.39-rc3

[Alex Deucher]

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 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 successful. The bad commit in this branch turned out to be

       1a4a678b12c84db9ae5dce424e0e97f0559bb57c

 which is related to memblock.

 Then I tried to find out which change between 2.6.38-rc4 and 2.6.38-rc5
 is needed to trigger the failure, so I used f005fe12b90c as a base,
 bisected between v2.6.38-rc4..v2.6.38-rc5 and merged every bisect step
 into the base and tested. Here the bad commit turned out to be

       e6d2e2b2b1e1455df16d68a78f4a3874c7b3ad20

 which is related to gart. It turned out that the gart aperture on that
 box is on another position with these patches. Before it was as
 0xa400 and now it is at 0xa000. It seems like this has something
 to do with the root-cause.

 Reverting commit 1a4a678b12c84db9ae5dce424e0e97f0559bb57c fixes the
 problem btw. and booting with iommu=soft also works, but I have no idea
 yet why the aperture at that address is a problem (with the patch
 reverted the aperture lands at 0x8000).

 I have put some debug-data online. There is my .config and two
 dmesg-files for good (==2.6.39-rc3 + revert) and bad (==2.6.39-rc3)
 I also created these dmesg-files again with memblock=debug, maybe that
 helps to find the problem. The files are at

       http://www.8bytes.org/~joro/debug/

 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 pointing to e820 RAM. Ignoring.
 [    0.00] Your BIOS doesn't leave a aperture memory hole
 [    0.00] Please enable the IOMMU option in the BIOS setup
 [    0.00] This costs you 64 MB of RAM
 [    0.00]     memblock_x86_reserve_range: [0xa000-0xa3ff]       
 aperture64
 [    0.00] Mapping aperture over 65536 KB of RAM @ a000

 so kernel try to reallocate apperture. because BIOS allocated is pointed to 
 RAM or size is too small.

 but your radeon does use [0xa000, 0xbfff)

 [    4.281993] radeon :01:05.0: VRAM: 320M 0xC000 - 
 0xD3FF (320M used)
 [    4.290672] radeon :01:05.0: GTT: 512M 0xA000 - 
 0xBFFF
 [    4.298550] [drm] Detected VRAM RAM=320M, BAR=256M
 [    4.309857] [drm] RAM width 32bits DDR
 [    4.313748] [TTM] Zone  kernel: Available graphics memory: 1896524 kiB.
 [    4.320379] [TTM] Initializing pool allocator.
 [    4.324948] [drm] radeon: 320M of VRAM memory ready
 [    4.329832] [drm] radeon: 512M of GTT memory ready.

 and the one seems working:

 [    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 BIOS doesn't leave a aperture memory hole
 [    0.00] Please enable the IOMMU option in the BIOS setup
 [    0.00] This costs you 64 MB of RAM
 [    0.00]     memblock_x86_reserve_range: [0x8000-0x83ff]       
 aperture64
 [    0.00] Mapping aperture over 65536 KB of RAM @ 8000
 [    0.00]     memblock_x86_reserve_range: [0xacb6bdc0-0xacb6bddf]        
   BOOTMEM

 will use different position...

 [    4.250159] radeon :01:05.0: VRAM: 320M 0xC000 - 
 0xD3FF (320M used)
 [    4.258830] radeon :01:05.0: GTT: 512M 0xA000 - 
 0xBFFF
 [    4.266742] [drm] Detected VRAM RAM=320M, BAR=256M
 [    4.271549] [drm] RAM width 32bits DDR
 [    4.275435] [TTM] Zone  kernel: Available graphics memory: 1896526 kiB.
 [    4.282066] [TTM] Initializing pool allocator.
 [    4.282085] usb 7-2: new full speed USB device number 2 using ohci_hcd
 [    4.293076] [drm] radeon: 320M of VRAM memory ready
 [    4.298277] [drm] radeon: 512M of GTT memory ready.
 [    4.303218] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
 [    4.309854] [drm] Driver supports precise vblank timestamp query.
 [    4.315970] [drm] radeon: irq initialized.
 [    4.320094] [drm] GART: num cpu pages 131072, num gpu pages 131072

 So question is why radeon is using the address [0xa000 - 0xc00], and 
 in E820 it is RAM 

The VRAM and GTT addresses in the dmesg are internal GPU addresses not
system addresses.  The GPU has it's own internal address space for
on-chip memory clients (texture samplers, render buffers, display
controllers, etc.).  The GPU sets up two apertures in it's internal
address space and on-chip client requests are forwarded to the
appropriate place by the GPU's memory controller.  Addresses 

Re: [PATCH] drm/radeon/kms: fix suspend on rv530 asics

[Dave Airlie]

On Thu, Apr 14, 2011 at 12:52 AM, Alex Deucher alexdeuc...@gmail.com wrote:
 On Wed, Apr 13, 2011 at 10:46 AM, Jerome Glisse j.gli...@gmail.com wrote:
 On Tue, Apr 12, 2011 at 1:33 PM, Alex Deucher alexdeuc...@gmail.com 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-by: Alex Deucher alexdeuc...@gmail.com
 Cc: sta...@kernel.org
 ---
  drivers/gpu/drm/radeon/atom.c |    6 +-
  1 files changed, 5 insertions(+), 1 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
 index 258fa5e..d71d375 100644
 --- a/drivers/gpu/drm/radeon/atom.c
 +++ b/drivers/gpu/drm/radeon/atom.c
 @@ -32,6 +32,7 @@
  #include atom.h
  #include atom-names.h
  #include atom-bits.h
 +#include radeon.h

  #define ATOM_COND_ABOVE                0
  #define ATOM_COND_ABOVEOREQUAL 1
 @@ -101,7 +102,9 @@ static void debug_print_spaces(int n)
  static uint32_t atom_iio_execute(struct atom_context *ctx, int base,
                                 uint32_t index, uint32_t data)
  {
 +       struct radeon_device *rdev = ctx-card-dev-dev_private;
        uint32_t temp = 0xCDCDCDCD;
 +
        while (1)
                switch (CU8(base)) {
                case ATOM_IIO_NOP:
 @@ -112,7 +115,8 @@ static uint32_t atom_iio_execute(struct atom_context 
 *ctx, int base,
                        base += 3;
                        break;
                case ATOM_IIO_WRITE:
 -                       (void)ctx-card-ioreg_read(ctx-card, CU16(base + 
 1));
 +                       if (rdev-family == CHIP_RV515)
 +                               (void)ctx-card-ioreg_read(ctx-card, 
 CU16(base + 1));
                        ctx-card-ioreg_write(ctx-card, CU16(base + 1), 
 temp);
                        base += 3;
                        break;
 --
 1.7.1.1



 So this patch enable io write only for one family ? This looks utterly 
 strange.

 No, it just does a read before write for rv515.  I don't know why it
 needs it, but it seems to.


Yeah I really wish I knew why either,

Thinkpad T60 with X1300, no resume without this, it failed in the
memory initialisation table. this was the only thing I could find to
fix it.

My x1300 desktop card works fine without this.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?

[Andy Furniss]

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
-dumbSched to see if that gets things along any further, but in the end
there's probably no way around figuring out what causes the lockup and
fixing that anyway.


I have an old AGP box that locks with 600g + agpgart - It used to give 
GPU lockup to dmesg/log, but (I only test it occasionally) it doesn't 
anymore. I can still sysrq OK.


I wonder if something changed in recent months in the drm/whatever code 
that has changed/blocked the logging.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36221] New: KMS with X1950 XT i2c error -- no ddc

[bugzilla-daemon]

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
 Component: DRM/Radeon
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: revea...@freakmail.de


Hello!

This is the operating system and kernel:

cat /etc/SuSE-release
openSUSE 11.4 (i586)
VERSION = 11.4
CODENAME = Celadon

uname -rio
2.6.37.1-1.2-desktop i386 GNU/Linux


When trying to boot with Kernelmodesetting there is no DDC due to an i2c error
resulting in a blank screen.

I was told in irc channel #radeon to open a bugreport and attache vbios.rom and
dmesg of a boot with KMS enabled;

I hope you can help me out!

Many thanks for all your Help!

Greetings,

R

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36221] KMS with X1950 XT i2c error -- no ddc

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36221

--- Comment #1 from revealed revea...@freakmail.de 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
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36221] KMS with X1950 XT i2c error -- no ddc

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36221

--- Comment #2 from revealed revea...@freakmail.de 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/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 2.6.39-rc3

[Yinghai Lu]

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 size 32 MB
 [0.00] Aperture pointing to e820 RAM. Ignoring.
 [0.00] Your BIOS doesn't leave a aperture memory hole
 [0.00] Please enable the IOMMU option in the BIOS setup
 [0.00] This costs you 64 MB of RAM
 [0.00] memblock_x86_reserve_range: [0xa000-0xa3ff]   
 aperture64
 [0.00] Mapping aperture over 65536 KB of RAM @ a000

 so kernel try to reallocate apperture. because BIOS allocated is pointed to 
 RAM or size is too small.
 
 It is actually beyond 4GB on that machine, this value read here is from
 the previous kernel-boot. The BIOS does not reset these values on a
 reboot.
 
 but your radeon does use [0xa000, 0xbfff)
 
 Yes, I suspected that too (and spent a few hours reading radeon code),
 but then I talked the Alex Deucher and he explained that these addresses
 which the driver prints for GTT and VRAM are in the GPU address space
 and do not refer to system ram. So this shouldn't be the problem.


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/aperture_64.c
@@ -83,7 +83,7 @@ static u32 __init allocate_aperture(void)
 * so don't use 512M below as gart iommu, leave the space for kernel
 * code for safe
 */
-   addr = memblock_find_in_range(0, 1ULL32, aper_size, 512ULL20);
+   addr = memblock_find_in_range(0, 1ULL32, aper_size, 512ULL21);
if (addr == MEMBLOCK_ERROR || addr + aper_size  0x) {
printk(KERN_ERR
Cannot allocate aperture memory hole (%lx,%uK)\n,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 2.6.39-rc3

[Linus Torvalds]

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
 +++ b/arch/x86/kernel/aperture_64.c
 @@ -83,7 +83,7 @@ static u32 __init allocate_aperture(void)
         * so don't use 512M below as gart iommu, leave the space for kernel
         * code for safe
         */
 -       addr = memblock_find_in_range(0, 1ULL32, aper_size, 512ULL20);
 +       addr = memblock_find_in_range(0, 1ULL32, aper_size, 512ULL21);

What are all the magic numbers, and why would 0x8000 be special?

Why don't we write code that just works?

Or absent a just works set of patches, why don't we revert to code
that has years of testing?

This kind of I broke things, so now I will jiggle things randomly
until they unbreak is not acceptable.

Either explain why that fixes a real BUG (and why the magic constants
need to be what they are), or just revert the patch that caused the
problem, and go back to the allocation patters that have years of
experience.

Guys, we've had this discussion before, in PCI allocation. We don't do
this. We tried switching the PCI region allocations to top-down, and
IT WAS A FAILURE. We reverted it to what we had years of testing with.

Don't just make random changes. There really are only two acceptable
models of development: think and analyze or years and years of
testing on thousands of machines. Those two really do work.

   Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 2.6.39-rc3

[Yinghai Lu]

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
 --- a/arch/x86/kernel/aperture_64.c
 +++ b/arch/x86/kernel/aperture_64.c
 @@ -83,7 +83,7 @@ static u32 __init allocate_aperture(void)
 * so don't use 512M below as gart iommu, leave the space for kernel
 * code for safe
 */
 -   addr = memblock_find_in_range(0, 1ULL32, aper_size, 512ULL20);
 +   addr = memblock_find_in_range(0, 1ULL32, aper_size, 512ULL21);
 
 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.

 
 Why don't we write code that just works?
 
 Or absent a just works set of patches, why don't we revert to code
 that has years of testing?
 
 This kind of I broke things, so now I will jiggle things randomly
 until they unbreak is not acceptable.
 
 Either explain why that fixes a real BUG (and why the magic constants
 need to be what they are), or just revert the patch that caused the
 problem, and go back to the allocation patters that have years of
 experience.
 
 Guys, we've had this discussion before, in PCI allocation. We don't do
 this. We tried switching the PCI region allocations to top-down, and
 IT WAS A FAILURE. We reverted it to what we had years of testing with.
 
 Don't just make random changes. There really are only two acceptable
 models of development: think and analyze or years and years of
 testing on thousands of machines. Those two really do work.

We did do the analyzing, and only difference seems to be:
good one is using 0x8000
and bad one is using 0xa000.

We try to figure out if it needs low address and it happen to work 
because kernel was doing bottom up allocation.

Thanks

Yinghai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 2.6.39-rc3

[Joerg Roedel]

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 could be set to 512M instead and the alignment
can be aper_size as it should. Any reason for such a big alignment?

Joerg

P.S.: The box is still in the office, I will try this debug-patch
  tomorrow.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 2.6.39-rc3

[Yinghai Lu]

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 512M goal is enforced
 by the alignment. Start could be set to 512M instead and the alignment
 can be aper_size as it should. Any reason for such a big alignment?
 

when using bootmem, try to use big alignment (512M ), so we could avoid take 
ram range below 512M.

commit 7677b2ef6c0c4fddc84f6473f3863f40eb71821b
Author: Yinghai Lu yhlu.kernel.s...@gmail.com
Date:   Mon Apr 14 20:40:37 2008 -0700

x86_64: allocate gart aperture from 512M

because we try to reserve dma32 early, so we have chance to get aperture
from 64M.

with some sequence aperture allocated from RAM, could become E820_RESERVED.

and then if doing a kexec with a big kernel that uncompressed size is above
64M we could have a range conflict with still using gart.

So allocate gart aperture from 512M instead.

Also change the fallback_aper_order to 5, because we don't have chance to 
get
2G or 4G aperture.

We can change it back to 32M or make it equal to size.

 
 P.S.: The box is still in the office, I will try this debug-patch
   tomorrow.

Alexandre's system is working at 0xa400 with 2.6.38.2

So it is not low address problem. could be other reason like
some other code could need lower address.

Thanks

Yinghai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel