All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Cree <mcree@orcon.net.nz>
To: Dave Airlie <airlied@gmail.com>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	mattst88@gmail.com, linux-kernel@vger.kernel.org,
	linux-alpha@vger.kernel.org, rth@twiddle.net,
	ink@jurassic.park.msu.ru, jbarnes@virtuousgeek.org,
	linux-pci@vger.kernel.org, dri-devel@lists.freedesktop.org,
	alexdeucher@gmail.com, jglisse@redhat.com
Subject: Re: Problems with alpha/pci + radeon/ttm
Date: Thu, 24 Jun 2010 21:51:40 +1200	[thread overview]
Message-ID: <4C232AAC.2010200@orcon.net.nz> (raw)
In-Reply-To: <AANLkTilMfDfy7BPiuAh9u-tR3kw1Vt_SebMziLUtLM6S@mail.gmail.com>

On 22/06/10 20:32, Dave Airlie wrote:
> On Tue, Jun 22, 2010 at 3:59 PM, FUJITA Tomonori
> <fujita.tomonori@lab.ntt.co.jp>  wrote:
>> On Mon, 21 Jun 2010 17:19:43 -0400
>> Matt Turner<mattst88@gmail.com>  wrote:
>>
>>> Michael Cree and I have been debugging FDO bug 26403 [1]. I tried
>>> booting with `radeon.test=1` and found this, which I think is related:

Note that my radeon card is PCI whereas I think Matt may be using an AGP 
card.

My logs are very similar to Matt's except I don't see the following line:

>>>> pci_map_single failed: could not allocate dma page tables


>> This happens in the latest git, right?

Indeed, testing 2.6.35-rc3 (plus a couple or so extra patches to fix 
unrelated compile errors).

>> Is this a regression (what kernel version worked)?
>>
>> Seems that the IOMMU can't find 128 pages. It's likely due to:
>>
>> - out of the IOMMU space (possibly someone doesn't free the IOMMU
>>   space).
>>
>> or
>>
>> - the mapping parameters (such as align) aren't appropriate so the
>>   IOMMU can't find space.
>
> I don't think KMS drivers have ever worked on alpha so its not a
> regression, they are working fine on x86 + powerpc and sparc has been
> run at least once.

KMS on the console boot up has worked since about 2.6.32, but starting 
up the X server has always failed and, in my case, the system becomes 
unstable and eventually OOPs.

> I suspect we are simply hitting the limits of the iommu, how big an
> address space does it handle? since generally graphics drivers try to
> bind a lot of things to the GART.

No idea on the address space limit.  I applied the patch of Fujita that 
logs all IOMMU allocations, and also inserted some extra printks in the 
ttm kernel code so that I could see which routines failed and the error 
code returned.  Running the radeon test on boot exhibits the following:

[  238.712768] [drm] Tested GTT->VRAM and VRAM->GTT copy for GTT offset 
0x1a312000
[  239.281127] [drm] Tested GTT->VRAM and VRAM->GTT copy for GTT offset 
0x1a412000
[  239.281127] ttm_tt_bind belched -12
[  239.282104] ttm_bo_handle_move_mem belched -12
[  239.282104] ttm_bo_move_buffer belched -12
[  239.282104] ttm_bo_validate belched -12
[  239.282104] radeon 0000:01:00.0: object_init failed for (1048576, 
0x00000002) err=-12
[  239.282104] [drm:radeon_test_moves] *ERROR* Failed to create GTT 
object 419
[  239.399291] Error while testing BO move.

Note that no IOMMU allocations are printed while radeon_test_moves is 
running so iommu_arena_alloc doesn't appear to be called.  Also the 
error code returned up to radeon_test_moves is -12 which is ENOMEM.  So 
does appear to be some memory limit.

> It might be worth limiting the PCIGART in radeon to 32MB to see if the
> lower limit helps.

So, how does one do that?

Cheers
Michael.

  reply	other threads:[~2010-06-24  9:51 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-21 21:19 Problems with alpha/pci + radeon/ttm Matt Turner
2010-06-21 21:19 ` Matt Turner
2010-06-22  5:59 ` FUJITA Tomonori
2010-06-22  8:32   ` Dave Airlie
2010-06-24  9:51     ` Michael Cree [this message]
2010-06-24 15:02       ` Matt Turner
2010-06-24 15:02         ` Matt Turner
2010-06-27  4:20       ` FUJITA Tomonori
2010-06-27 10:46         ` Michael Cree
2010-06-27 23:14           ` Dave Airlie
2010-06-27 23:14             ` Dave Airlie
2010-06-28  9:03             ` Michael Cree
2010-06-28 16:08               ` Richard Henderson
2010-06-24 14:53   ` Matt Turner
2010-06-27  4:20     ` FUJITA Tomonori
2010-06-27  4:20       ` FUJITA Tomonori
2010-06-27  4:58       ` Matt Turner
2010-06-27  4:58         ` Matt Turner
2010-06-30 18:43         ` Konrad Rzeszutek Wilk
2010-06-30 18:43           ` Konrad Rzeszutek Wilk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C232AAC.2010200@orcon.net.nz \
    --to=mcree@orcon.net.nz \
    --cc=airlied@gmail.com \
    --cc=alexdeucher@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=ink@jurassic.park.msu.ru \
    --cc=jbarnes@virtuousgeek.org \
    --cc=jglisse@redhat.com \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mattst88@gmail.com \
    --cc=rth@twiddle.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.