On Sun, 2005-03-13 at 23:28 -0500, Michel Dänzer wrote:
> On Sun, 2005-03-13 at 17:43 +1100, Benjamin Herrenschmidt wrote:
> >
> > And finally, I want to blank the screen (using the accel engine) before
> > setting the new mode, so that we come out "clean" of the mode setting
> > (without ugly art
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=2702
--- Additional Comments From [EMAIL PROTECTED] 2005-03-13 21:17 ---
What'
On Sun, 2005-03-13 at 23:40 -0500, Jon Smirl wrote:
> On Mon, 14 Mar 2005 15:07:26 +1100, Paul Mackerras <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] removed from CC since I can't post to it.
> >
> > Jon Smirl writes:
> >
> > > It shouldn't hurt to have a parallel non-cached mapping being use
On Mon, 14 Mar 2005 15:07:26 +1100, Paul Mackerras <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] removed from CC since I can't post to it.
>
> Jon Smirl writes:
>
> > It shouldn't hurt to have a parallel non-cached mapping being used in
> > conjuction with this protocol. By definition the non-ca
Andrew Clayton writes:
> 2.6.11-bk2 OK
> 2.6.11-bk3 Lockup
Have you tried the most recent kernel? There were some changes to the
AGP code that caused it to oops for me. Linus took my patch to fix
that this last weekend.
Paul.
---
SF email i
On Sun, 2005-03-13 at 17:43 +1100, Benjamin Herrenschmidt wrote:
>
> And finally, I want to blank the screen (using the accel engine) before
> setting the new mode, so that we come out "clean" of the mode setting
> (without ugly artifact), and I will probably clean both fb's (simpler).
That would
On Mon, 2005-03-14 at 01:32 +0100, Jerome Glisse wrote:
> Maybe the lockup you experiment is linked with the lockup
> Adam gets. Adam have you upgraded you kernel recently ?
> Maybe a 2.6.10 or even previous one could fix this. Thus
To clarify:
2.6.11-bk2 OK
2.6.11-bk3 Lockup
Cheers,
-
[EMAIL PROTECTED] removed from CC since I can't post to it.
Jon Smirl writes:
> It shouldn't hurt to have a parallel non-cached mapping being used in
> conjuction with this protocol. By definition the non-cached mapping
> never gets into an inconsistent state.
According to the PowerPC Architectu
On Sun, 2005-03-13 at 20:47 -0500, Jon Smirl wrote:
> On Mon, 14 Mar 2005 12:05:59 +1100, Benjamin Herrenschmidt
> <[EMAIL PROTECTED]> wrote:
> >
> > > It should be the responsibility of the memory manager. If anything wants
> > > to access the memory it would call lock() and when it's done with t
On Mon, 14 Mar 2005 12:05:59 +1100, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
>
> > It should be the responsibility of the memory manager. If anything wants
> > to access the memory it would call lock() and when it's done with the
> > memory it calls unlock(). That's exactly how DirectFB's
Alright... So drm from both February 14th and January 1st are locking up as
well... Which is odd since I never had any of these problem till this
weekend. I'll start rolling back changes to the Mesa dri driver... Perhaps
this isn't directly related to the drm.
Oh, I've also flashed my BIOS
Hi all,
I just uploaded a new DRIconf version (0.2.3), which features better
support for floating-point ranges like the brilinear option proposed by
Roland Scheidegger. There are also a few bug fixes and usability
improvements as well as updates and additions to the README file.
This version is f
> It should be the responsibility of the memory manager. If anything wants
> to access the memory it would call lock() and when it's done with the
> memory it calls unlock(). That's exactly how DirectFB's memory manager
> works.
In an ideal world ... However, since we are planning to move the
On Mon, 2005-03-14 at 02:39 +0200, Ville Syrjälä wrote:
> On Sun, Mar 13, 2005 at 07:25:15PM -0500, Jon Smirl wrote:
> > On Mon, 14 Mar 2005 10:48:19 +1100, Benjamin Herrenschmidt
> > <[EMAIL PROTECTED]> wrote:
> > >
> > > > > That shouldn't matter the page brought in would be for a speculative
>
Jerome Glisse wrote:
Maybe the lockup you experiment is linked with the lockup
Adam gets. Adam have you upgraded you kernel recently ?
Maybe a 2.6.10 or even previous one could fix this. Thus
telling that the lockup may be due to some usb change or
some others things in the kernel.
Just trying to s
On Mon, Mar 14, 2005 at 11:41:23AM +1100, Paul Mackerras wrote:
> Jon Smirl writes:
>
> > > It works, but it's illegal. That means that the CPU might well speculate
> > > a load from one of these pages in kernel-land just because it happens to
> > > be next to a page where you are iterating an arr
On Sun, 2005-03-13 at 19:25 -0500, Jon Smirl wrote:
> On Mon, 14 Mar 2005 10:48:19 +1100, Benjamin Herrenschmidt
> <[EMAIL PROTECTED]> wrote:
> >
> > > > That shouldn't matter the page brought in would be for a speculative
> > > > read and never accessed. It should just fall out of the cache and n
Jon Smirl writes:
> > It works, but it's illegal. That means that the CPU might well speculate
> > a load from one of these pages in kernel-land just because it happens to
> > be next to a page where you are iterating an array, and may then bring a
> > bit in the cache from that page.
>
> That sh
On Sun, Mar 13, 2005 at 07:25:15PM -0500, Jon Smirl wrote:
> On Mon, 14 Mar 2005 10:48:19 +1100, Benjamin Herrenschmidt
> <[EMAIL PROTECTED]> wrote:
> >
> > > > That shouldn't matter the page brought in would be for a speculative
> > > > read and never accessed. It should just fall out of the cach
On Mon, 14 Mar 2005 10:48:19 +1100, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
>
> > > That shouldn't matter the page brought in would be for a speculative
> > > read and never accessed. It should just fall out of the cache and not
> > > be written back. There is only one cachable mapping.
Maybe the lockup you experiment is linked with the lockup
Adam gets. Adam have you upgraded you kernel recently ?
Maybe a 2.6.10 or even previous one could fix this. Thus
telling that the lockup may be due to some usb change or
some others things in the kernel.
Just trying to see if this is linked
> I don't think "normal" drivers do them at all. I did experiment with
> DirectFB at one point and had it place all offscreen surfaces to AGP
> memory. It worked really well on my hardware (G400 + VIA KT133
> northbridge). I also tried it with PCI transfers and that too worked but
> was natura
On Mon, Mar 14, 2005 at 10:48:19AM +1100, Benjamin Herrenschmidt wrote:
>
> > > That shouldn't matter the page brought in would be for a speculative
> > > read and never accessed. It should just fall out of the cache and not
> > > be written back. There is only one cachable mapping. In this model
> > That shouldn't matter the page brought in would be for a speculative
> > read and never accessed. It should just fall out of the cache and not
> > be written back. There is only one cachable mapping. In this model
> > writes are always followed by a flush before telling the GPU to access
> > t
On Sun, Mar 13, 2005 at 06:00:01PM -0500, Jon Smirl wrote:
> On Mon, 14 Mar 2005 09:20:01 +1100, Benjamin Herrenschmidt
> <[EMAIL PROTECTED]> wrote:
> > Though the flushes may be fast if there is no actual hit in the cache, I
> > agree. Again, that should be benched.
> >
> > In fact, i would _love
> I'm not being clear
>
> Leave AGP memory as normal RAM
> driver does it thing to the memory
> driver executes flush of data cache on CPU
> after flush tell GPU to access the data
>
> The performance hit of executing the flush is probably negligible
> since you probably didn't care about an
On Mon, 14 Mar 2005 09:20:01 +1100, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
> On Sun, 2005-03-13 at 17:10 -0500, Jon Smirl wrote:
> > On Mon, 14 Mar 2005 08:49:13 +1100, Benjamin Herrenschmidt
> > <[EMAIL PROTECTED]> wrote:
> > > > If you are doing fallback calculations in a 6MB buffer th
Adam K Kirchhoff wrote:
Vladimir Dergachev wrote:
don't recall ever seeing message from the kernel about nobody caring
about irq 16, or about radeon_cp_reset... With my 9800, I was getting
radeon_cp_dispatch_swap errors.
I do know, however, that my 9200 was working just last week or the
week
befo
On Sun, 2005-03-13 at 23:21 +0100, Felix Kühling wrote:
> [slightly off topic]
>
> Am Sonntag, den 13.03.2005, 12:56 -0500 schrieb Jon Smirl:
> > On Sun, 13 Mar 2005 19:47:14 +0200, Ville Syrjälä <[EMAIL PROTECTED]> wrote:
> > > I don't understand why we have "GART memory" anyway. It's just main m
On Sun, 2005-03-13 at 17:17 -0500, Jon Smirl wrote:
> On Mon, 14 Mar 2005 08:52:46 +1100, Benjamin Herrenschmidt
> <[EMAIL PROTECTED]> wrote:
> >
> > > The best model would be to chuck the AGP/PCI Express interface on the
> > > board and have a hyperchannel instead. Hyperchannel provides full
> >
On Mon, 14 Mar 2005 08:52:46 +1100, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
>
> > The best model would be to chuck the AGP/PCI Express interface on the
> > board and have a hyperchannel instead. Hyperchannel provides full
> > cache consistency without all of these flushing problems. The
On Sun, 2005-03-13 at 17:10 -0500, Jon Smirl wrote:
> On Mon, 14 Mar 2005 08:49:13 +1100, Benjamin Herrenschmidt
> <[EMAIL PROTECTED]> wrote:
> > > If you are doing fallback calculations in a 6MB buffer that is 1,500
> > > pages. Accessing all of this effectively flushes the data cache. Once
> > >
[slightly off topic]
Am Sonntag, den 13.03.2005, 12:56 -0500 schrieb Jon Smirl:
> On Sun, 13 Mar 2005 19:47:14 +0200, Ville Syrjälä <[EMAIL PROTECTED]> wrote:
> > I don't understand why we have "GART memory" anyway. It's just main memory
> > and I don't see any point going through the GART to acce
Hi,
I played with stencil and this patch is output.
I tested it only on stenciltst from
http://www.sgi.com/products/software/opengl/examples/glut/examples/
This app doesn't use Z_TEST. It show correct output. Somene with more
mesa and r300 knowledge should correct it (there are still problems).
On Gwe, 2005-03-11 at 19:42, Dave Jones wrote:
> We got a bug report in our bugzilla from a user that saw
> SiS DRM crashing when he restarted X.
This object could be vmalloc()'d
---
SF email is sponsored by - The IT Product Guide
Read honest
On Mon, 14 Mar 2005 08:49:13 +1100, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
> > If you are doing fallback calculations in a 6MB buffer that is 1,500
> > pages. Accessing all of this effectively flushes the data cache. Once
> > you are done with it you probably don't want those pages in th
> The best model would be to chuck the AGP/PCI Express interface on the
> board and have a hyperchannel instead. Hyperchannel provides full
> cache consistency without all of these flushing problems. The GPU
> really is another specialized CPU, give it a CPU class memory
> interface.
You mean Hyp
> > If you are doing fallback calculations in a 6MB buffer that is 1,500
> > pages. Accessing all of this effectively flushes the data cache. Once
> > you are done with it you probably don't want those pages in the cache
> > anyway.
>
> I don't understand why we have "GART memory" anyway. It's ju
On Sun, 2005-03-13 at 11:19 -0500, Jon Smirl wrote:
> On Sun, 13 Mar 2005 23:04:59 +1100, Benjamin Herrenschmidt
> <[EMAIL PROTECTED]> wrote:
> >
> > > AGP as it's currently used is pretty much pointless for software fallbacks
> > > since reading from AGP memory is nearly as slow as reading from v
I was getting:
Badness in remove_proc_entry at fs/proc/generic.c:693
[] remove_proc_entry+0x10a/0x150
[] drm_core_exit+0x15/0x48 [drm]
[] sys_delete_module+0x144/0x180
[] do_munmap+0x143/0x180
[] sys_munmap+0x44/0x70
[] syscall_call+0x7/0xb
on rmmod'ing the drm module.
my /proc/dri direc
Hi there.
I have a problem seemingly related to DRM in the current Linus 2.6-bk
tree (2.6.11-bk9 as of this writing). The problem started with
2.6.11-bk3.
Basically the machine is locking up when X (xorg 6.8.1 from FC3) starts
and needs a hard reset to recover. Disabling DRI in X and/or DRM in t
Vladimir Dergachev wrote:
don't recall ever seeing message from the kernel about nobody caring
about irq 16, or about radeon_cp_reset... With my 9800, I was getting
radeon_cp_dispatch_swap errors.
I do know, however, that my 9200 was working just last week or the week
before. Hmmm... I think my
On Sun, 13 Mar 2005 23:04:59 +1100, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
>
> > AGP as it's currently used is pretty much pointless for software fallbacks
> > since reading from AGP memory is nearly as slow as reading from video
> > memory.
>
> Hrm.. I wouldn't expect _that_ slow. It'
On Sun, 13 Mar 2005 19:47:14 +0200, Ville Syrjälä <[EMAIL PROTECTED]> wrote:
> I don't understand why we have "GART memory" anyway. It's just main memory
> and I don't see any point going through the GART to access it with the
> CPU. Only the graphics card needs to use the GART.
I see no need to f
On Sun, Mar 13, 2005 at 11:19:35AM -0500, Jon Smirl wrote:
> On Sun, 13 Mar 2005 23:04:59 +1100, Benjamin Herrenschmidt
> <[EMAIL PROTECTED]> wrote:
> >
> > > AGP as it's currently used is pretty much pointless for software fallbacks
> > > since reading from AGP memory is nearly as slow as reading
don't recall ever seeing message from the kernel about nobody caring
about irq 16, or about radeon_cp_reset... With my 9800, I was getting
radeon_cp_dispatch_swap errors.
I do know, however, that my 9200 was working just last week or the week
before. Hmmm... I think my laptop still has the same
On Sun, 13 Mar 2005 17:43:09 +1100, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
> > In the long term I was hoping to design thing such that the two heads
> > can be used by two independent users, each could be running X or
> > fbdev.
>
> You mean fbcon ? Unless there is proper arbitration, t
Jan Gukelberger wrote:
On Sat, 2005-03-12 at 21:10 -0500, Adam K Kirchhoff wrote:
[snip]
[drm:radeon_cp_reset] *ERROR* radeon_cp_reset called without lock held,
held 0 owner ec8fce80 f7669180
[drm:radeon_cp_start] *ERROR* radeon_cp_start called without lock held,
held -2147483648 owner ec8fc
On Sat, 2005-03-12 at 21:10 -0500, Adam K Kirchhoff wrote:
[snip]
> [drm:radeon_cp_reset] *ERROR* radeon_cp_reset called without lock held,
> held 0 owner ec8fce80 f7669180
> [drm:radeon_cp_start] *ERROR* radeon_cp_start called without lock held,
> held -2147483648 owner ec8fce80 f7669180
> irq
On Sun, 2005-03-13 at 07:43 -0500, Adam K Kirchhoff wrote:
> Nicolai Haehnle wrote:
>
> >On Sunday 13 March 2005 03:10, Adam K Kirchhoff wrote:
> >
> >
> >>>Was it always shared with the USB controller? Can you try changing that?
> >>>
> >>>
> >>Some more info for both of you...
> >>
> >>
Nicolai Haehnle wrote:
On Sunday 13 March 2005 03:10, Adam K Kirchhoff wrote:
Was it always shared with the USB controller? Can you try changing that?
Some more info for both of you...
I remarked, in an earlier e-mail, that glxgears wouldn't cause the
lockups. That's not true. For what
> AGP as it's currently used is pretty much pointless for software fallbacks
> since reading from AGP memory is nearly as slow as reading from video
> memory.
Hrm.. I wouldn't expect _that_ slow. It's uncacheable, right, but still
on a faster bus. Especially if we use it the way we do on ppc wh
On Sunday 13 March 2005 03:10, Adam K Kirchhoff wrote:
> >Was it always shared with the USB controller? Can you try changing that?
>
> Some more info for both of you...
>
> I remarked, in an earlier e-mail, that glxgears wouldn't cause the
> lockups. That's not true. For whatever reason, it do
On Sun, Mar 13, 2005 at 08:20:45PM +1100, Benjamin Herrenschmidt wrote:
> On Sun, 2005-03-13 at 10:22 +0200, Ville Syrjälä wrote:
>
> > >
> > > - We only really need to bother about CPU access for the framebuffer
> > > itself (and possibly the cursor). That is normal non-accelerated fbdev
> > >
Dave Jones wrote:
We got a bug report in our bugzilla from a user that saw
SiS DRM crashing when he restarted X.
The crash seems to be two things.
First, a page allocation failure.
Mar 11 17:52:29 localhost kernel: X: page allocation failure. order:4, mode:0xd0
Mar 11 17:52:29 localhost kernel: []
On Sun, 2005-03-13 at 10:22 +0200, Ville Syrjälä wrote:
> >
> > - We only really need to bother about CPU access for the framebuffer
> > itself (and possibly the cursor). That is normal non-accelerated fbdev
> > operations an mmap'ing of the framebuffer in user space. This is not
> > really a pr
> [EMAIL PROTECTED] schrieb:
>
>>>
>>>the drm version of the patch. Straightforward, I did not apply it to cvs
>>> since
>>>it needs a version bump, and I don't think this feature alone is worth
>>> that.
>>
>>
>> Idx buffer support could be one of such features.
>> Unfortunately no one seems to b
[EMAIL PROTECTED] schrieb:
the drm version of the patch. Straightforward, I did not apply it to cvs
since
it needs a version bump, and I don't think this feature alone is worth that.
Idx buffer support could be one of such features.
Unfortunately no one seems to be interested in writing drm suppo
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=2702
--- Additional Comments From [EMAIL PROTECTED] 2005-03-13 00:45 ---
(In r
On Sun, Mar 13, 2005 at 12:35:43PM +1100, Benjamin Herrenschmidt wrote:
> Hi !
>
> I'm currently rewriting radeonfb to implement support for dual head, and
> ultimately, to make it more friendly to be hooked on DRM for mesa-solo
> style setups.
>
> I have some issues however related to the way me
60 matches
Mail list logo
