"Dave Airlie" <[EMAIL PROTECTED]> writes:
>
> On a 64-bit machine GFP_KERNEL can give me any memory... it all works
> fine on 32-bit highmem kernel as I don't get highmem... I really need
> __GFP_DMA32 memory but we don't have a generic allocator that gives
> this out that I can see..
__get_free_
> It might explain why my machine hung when I tried to use
> radeon with DRM on my sparc64 workstation :-) I have
> investigating that on my todo list.
True, maybe the intersection is me + hw like that + radeon :-)
> I don't know what to recommend to you, getting 8MB of linear memory
> really ju
> >
> > On a 64-bit machine GFP_KERNEL can give me any memory... it all works
> > fine on 32-bit highmem kernel as I don't get highmem... I really need
> > __GFP_DMA32 memory but we don't have a generic allocator that gives
> > this out that I can see..
>
> __get_free_pages(..., __GFP_DMA32) on 64b
From: "Dave Airlie" <[EMAIL PROTECTED]>
Date: Mon, 2 Apr 2007 15:15:48 +1000
> > Perhaps we'll have to create something ugly like vmalloc_nobounce().
> >
> > Remind me again why you're ending up with swiotlb'd pages?
> > vmalloc_32() uses GFP_KERNEL which should use entirely lowmem and thus
> > RA
From: "Dave Airlie" <[EMAIL PROTECTED]>
Date: Mon, 2 Apr 2007 14:08:13 +1000
> > >
> > > So when swiotlb happens, as you can guess it all falls apart as the
> > > drm never calls sync functions at any stage...
> >
> > You would have hit this on any platform that does caching
> > in the PCI control
> >
> > So when swiotlb happens, as you can guess it all falls apart as the
> > drm never calls sync functions at any stage...
>
> You would have hit this on any platform that does caching
> in the PCI controller as well.
We must not have a great intersect of radeon and such systems..
>
> Coheren
From: "Dave Airlie" <[EMAIL PROTECTED]>
Date: Mon, 2 Apr 2007 09:44:41 +1000
> Okay I've got a bug reported before and now again about > 4GB + radeon
> blows up the DRM... on Intel hw...
>
> What the drm currently does for the PCI GART table is it allocates a
> chunk of memory (8MB) with vmalloc_
On Sun, Apr 01, 2007 at 06:27:11PM +0200, David Oftedal wrote:
| Too bad it's not as straightforward as I'd hoped... One would have
| hoped the creators of the OpenGL standard would have prepared it for
| steroscopic graphics right from the start, but perhaps they didn't think
| it'd catch on? ...
Okay I've got a bug reported before and now again about > 4GB + radeon
blows up the DRM... on Intel hw...
What the drm currently does for the PCI GART table is it allocates a
chunk of memory (8MB) with vmalloc_32(), then when it decides to use
it it goes through every page of it calls pci_map_sing
http://bugs.freedesktop.org/show_bug.cgi?id=9074
[EMAIL PROTECTED] changed:
What|Removed |Added
Summary|X locks with black screen on|r300 doesn't work with 4 GB
http://bugs.freedesktop.org/show_bug.cgi?id=10499
[EMAIL PROTECTED] changed:
What|Removed |Added
Attachment #9416 is|0 |1
obsolete|
http://bugs.freedesktop.org/show_bug.cgi?id=10499
--- Comment #6 from [EMAIL PROTECTED] 2007-04-01 15:38 PST ---
Created an attachment (id=9419)
--> (http://bugs.freedesktop.org/attachment.cgi?id=9419&action=view)
/etc/X11/xorg.conf
--
Configure bugmail: http://bugs.freedesktop.or
http://bugs.freedesktop.org/show_bug.cgi?id=10499
--- Comment #5 from [EMAIL PROTECTED] 2007-04-01 15:37 PST ---
Created an attachment (id=9418)
--> (http://bugs.freedesktop.org/attachment.cgi?id=9418&action=view)
xorg log
--
Configure bugmail: http://bugs.freedesktop.org/userpref
http://bugs.freedesktop.org/show_bug.cgi?id=9074
--- Comment #26 from [EMAIL PROTECTED] 2007-04-01 15:36 PST ---
Created an attachment (id=9417)
--> (http://bugs.freedesktop.org/attachment.cgi?id=9417&action=view)
4 GB DRM messages with git version and extra debug info
--
Configur
http://bugs.freedesktop.org/show_bug.cgi?id=10499
--- Comment #4 from [EMAIL PROTECTED] 2007-04-01 15:35 PST ---
Created an attachment (id=9416)
--> (http://bugs.freedesktop.org/attachment.cgi?id=9416&action=view)
xorg log
--
Configure bugmail: http://bugs.freedesktop.org/userpref
http://bugs.freedesktop.org/show_bug.cgi?id=9074
--- Comment #25 from [EMAIL PROTECTED] 2007-04-01 15:28 PST ---
Created an attachment (id=9414)
--> (http://bugs.freedesktop.org/attachment.cgi?id=9414&action=view)
3.5 GB DRM messages with git version and extra debug info
--
Config
http://bugs.freedesktop.org/show_bug.cgi?id=10499
[EMAIL PROTECTED] changed:
What|Removed |Added
Severity|critical|blocker
--- Comment #3 from [E
http://bugs.freedesktop.org/show_bug.cgi?id=9074
--- Comment #24 from [EMAIL PROTECTED] 2007-04-01 15:07 PST ---
lspci -vv with 3.5 GB is identical to 4 GB.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: --
http://bugs.freedesktop.org/show_bug.cgi?id=9074
--- Comment #23 from [EMAIL PROTECTED] 2007-04-01 14:55 PST ---
Created an attachment (id=9413)
--> (http://bugs.freedesktop.org/attachment.cgi?id=9413&action=view)
lspci -vv with 4 GB
--
Configure bugmail: http://bugs.freedesktop.o
http://bugs.freedesktop.org/show_bug.cgi?id=9074
--- Comment #22 from [EMAIL PROTECTED] 2007-04-01 14:48 PST ---
Created an attachment (id=9412)
--> (http://bugs.freedesktop.org/attachment.cgi?id=9412&action=view)
dmesg from boot with 3.5GB of RAM enabled
--
Configure bugmail: htt
http://bugs.freedesktop.org/show_bug.cgi?id=9074
[EMAIL PROTECTED] changed:
What|Removed |Added
Attachment #7828 is|0 |1
obsolete|
http://bugs.freedesktop.org/show_bug.cgi?id=10499
[EMAIL PROTECTED] changed:
What|Removed |Added
Severity|blocker |critical
--- Comment #2 from [
http://bugs.freedesktop.org/show_bug.cgi?id=10499
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
--- Comment
Ah, thanks for your explanations.
Too bad it's not as straightforward as I'd hoped... One would have hoped the
creators of the OpenGL standard would have prepared it for steroscopic graphics
right from the start, but perhaps they didn't think it'd catch on? For the time
being I guess I'll just
http://bugs.freedesktop.org/show_bug.cgi?id=9074
--- Comment #20 from [EMAIL PROTECTED] 2007-04-01 08:52 PST ---
(In reply to comment #19)
> -[drm:radeon_cp_init_ring_buffer] ring rptr: offset=0x09963000
> handle=0x04425200
Is the 'offset' value (bus address) here really just 32 bits
http://bugs.freedesktop.org/show_bug.cgi?id=9074
--- Comment #19 from [EMAIL PROTECTED] 2007-04-01 08:46 PST ---
I booted with mem=3584M (call this "good") and without mem= (call this "bad")
and made a diff of the DRI messages with debug=1. In the "bad" case, the kernel
uses all my me
http://bugs.freedesktop.org/show_bug.cgi?id=9074
--- Comment #18 from [EMAIL PROTECTED] 2007-04-01 08:43 PST ---
Created an attachment (id=9408)
--> (http://bugs.freedesktop.org/attachment.cgi?id=9408&action=view)
Difference in kernel messages between booting with mem=3584M (good) an
http://bugs.freedesktop.org/show_bug.cgi?id=10490
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #1 from [
http://bugs.freedesktop.org/show_bug.cgi?id=10499
Summary: S3 savage4
Product: DRI
Version: unspecified
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: blocker
Priority: medium
Component:
29 matches
Mail list logo
