On Tue, 15 Mar 2005 23:48:54 -0500, Michel Dänzer [EMAIL PROTECTED] wrote:
On Wed, 2005-03-16 at 00:17 +0100, Richard Stellingwerff wrote:
Anyway, the driver works, but it's VERY unstable for me.
If you're using MergedFB (which includes clone mode), see the current
thread '[r200]
I have reported this before, but now I have some more data.
I have an office pc with this video card:
VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon
7000/VE]
In previous reports I found that starting xfree or xorg with dri support
cause a hang after a little while. It
Am Mittwoch, den 16.03.2005, 14:47 +0300 schrieb Sergey Zharkov:
Felix,
I've tried some coding to make savage resume looking at radeon resume
code but failed completely :(( Unfortunately I'am ABAP/4 developer - not
a C guru.
The only thing that may help real dri developers to suggest how
Helge Hafting wrote:
I have reported this before, but now I have some more data.
I have an office pc with this video card:
VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon
7000/VE]
In previous reports I found that starting xfree or xorg with dri support
cause a hang after
Am Mittwoch, den 16.03.2005, 15:17 +0300 schrieb Sergey Zharkov:
Setting BusType to PCI and even BusType AGP with DmaType PCI helps -
the thing resumes. So it seems to be a bug in AGP dma resuming. But not
in kernel one - there is a resume code in via-agp driver, that worked
for DRI 1.0
You
Felix,
I've tried some coding to make savage resume looking at radeon resume
code but failed completely :(( Unfortunately I'am ABAP/4 developer - not
a C guru.
The only thing that may help real dri developers to suggest how to
resume - when I switched DMA mode from command or vertex to None
On Wed, Mar 16, 2005 at 05:31:16PM +1100, Benjamin Herrenschmidt wrote:
On Wed, 2005-03-16 at 00:21 -0500, Michel Dänzer wrote:
Actually people do use it on big-endian systems but since neither the
mach64, ati128 or radeon drivers play with the swapper settings I can
only
On Tue, 15 Mar 2005 18:36:21 -0500, Jung-uk Kim [EMAIL PROTECTED] wrote:
On Tuesday 15 March 2005 05:06 pm, Aapo Tahkola wrote:
After reading all the promising success stories about the r300
project, I am
wondering whether anybody successfully tried it on a *BSD.
Some time ago I tried
Am Mittwoch, den 16.03.2005, 17:35 +0300 schrieb Sergey Zharkov:
Felix,
Unfortunately I never posted a bug for kernel and have no idea how to do
that.
I found a related bug: http://bugzilla.kernel.org/show_bug.cgi?id=3864.
Though that user was not getting lockups, just some distortions.
Roland Scheidegger wrote:
Helge Hafting wrote:
I have reported this before, but now I have some more data.
I have an office pc with this video card:
VGA compatible controller: ATI Technologies Inc Radeon RV100 QY
[Radeon 7000/VE]
In previous reports I found that starting xfree or xorg with dri
Roland Scheidegger wrote:
Helge Hafting wrote:
I have reported this before, but now I have some more data.
I have an office pc with this video card:
VGA compatible controller: ATI Technologies Inc Radeon RV100 QY
[Radeon 7000/VE]
In previous reports I found that starting xfree or xorg with dri
Helge Hafting wrote:
Since it crashes even without 3d sometimes, the problem does not
seem to be related to dri (as in, dri driver).
Stable as rock, _if_ Load dri is commented out from xorg.conf (or
from XF86Config-4)
Well, commenting that out makes the 2d ddx driver not to use the CP, drm
etc.
On Wed, 16 Mar 2005 14:52:39 +0100, Helge Hafting
[EMAIL PROTECTED] wrote:
No usb. The mouse is connected to the ps/2 mouse port. As I mentioned,
this is
not a recent problem. I could never load dri on this machine without
such a crash. I can check whether the IRQ gets shared though.
Can
I found a related bug: http://bugzilla.kernel.org/show_bug.cgi?id=3864.
Though that user was not getting lockups, just some distortions.
Probably with different graphics hardware (no details in the report).
- 2.1.8.2 . Hardware is Twinhead Efio 121A laptop Via KN266 chipset,
Athlon XP-M
On Wednesday 16 March 2005 09:09, Ville Syrjl wrote:
On Wed, Mar 16, 2005 at 05:31:16PM +1100, Benjamin Herrenschmidt wrote:
Well, do they revert it after atyfb/aty128fb/radeonfb set it then ?
it's definitely set on mode switch.
The point is that there can be offscreen surfaces with
Helge == Helge Hafting [EMAIL PROTECTED] writes:
Helge I have reported this before, but now I have some more data. I
Helge have an office pc with this video card: VGA compatible
Helge controller: ATI Technologies Inc Radeon RV100 QY [Radeon
Helge 7000/VE]
FWIW, I have exactly the same problem
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=2746
Summary: Indirect rendering function for glVertexAttrib4bvARB is
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=2747
Summary: Indirect rendering function glGetProgramStringARB fails.
On Wed, Mar 16, 2005 at 12:51:27PM +1100, Benjamin Herrenschmidt wrote:
On Wed, 2005-03-16 at 03:47 +0200, Ville Syrjälä wrote:
There's also the case with Matrox Millennium I/II cards. They must place
the visible frame buffer so that no line crosses the boundary of memory
banks.
http://bugme.osdl.org/show_bug.cgi?id=4337
--- Additional Comments From [EMAIL PROTECTED] 2005-03-16 11:55 ---
For some reason the informational printks were deleted. Can you try the
attached patch and see what it prints in your syslog?
Jesse
--- You are receiving this
http://bugme.osdl.org/show_bug.cgi?id=4337
--- Additional Comments From [EMAIL PROTECTED] 2005-03-16 11:58 ---
Created an attachment (id=4733)
-- (http://bugme.osdl.org/attachment.cgi?id=4733action=view)
debug output for agp backend
--- You are receiving this mail because:
On Wed, Mar 16, 2005 at 02:09:18PM +1100, Benjamin Herrenschmidt wrote:
It's ugly, but that's not the point. The point is that all deployed
versions of X (and even current X.org CVS head still, in fact) make this
assumption.
Oh, that's fine and that's not a problem. I will only repaint
http://bugme.osdl.org/show_bug.cgi?id=4337
--- Additional Comments From [EMAIL PROTECTED] 2005-03-16 12:14 ---
Nevermind, after looking at the log you already pasted, I don't think my patch
will give us any additional info. It looks like AGP at least thinks it
initialized
On Wed, 16 Mar 2005, Michel [ISO-8859-1] Dänzer wrote:
Disclaimer: I don't pretend to understand 100% how all this stuff works
either, but I think my understanding has improved a little recently. :)
Michel, I think we are misunderstanding each other.
I am not talking about synchronization of
On Wed, 2005-03-16 at 15:35 -0500, Vladimir Dergachev wrote:
On Wed, 16 Mar 2005, Michel [ISO-8859-1] Dnzer wrote:
Disclaimer: I don't pretend to understand 100% how all this stuff works
either, but I think my understanding has improved a little recently. :)
Michel, I think we are
On Wed, 2005-03-16 at 22:08 +0200, Ville Syrjl wrote:
I don't see the current system slowly evolving into some superb future
system with an in kernel memory manager. The current APIs just have too
many limitations. I think the memory manager must be the foundation of
everything and after
On Wed, Mar 16, 2005 at 10:49:11AM +1100, Benjamin Herrenschmidt wrote:
In the meantime, can you tell me more about your arbitration scheme ?
There is a lock associated with the graphics card. The lock is always
taken before programming the hardware. Other things wanting access to the
hardware
On Wed, 16 Mar 2005 22:08:08 +0200, Ville Syrjälä [EMAIL PROTECTED] wrote:
On Wed, Mar 16, 2005 at 02:09:18PM +1100, Benjamin Herrenschmidt wrote:
It's ugly, but that's not the point. The point is that all deployed
versions of X (and even current X.org CVS head still, in fact) make this
On Wed, 2005-03-16 at 21:51 +0200, Ville Syrjl wrote:
One thing just popped to my head though. If in the future we are going to
allow graphics cards to render to system memory, using the swapper will no
longer work. I don't see any other solution that having the CPU perform
the byte
On Wed, Mar 16, 2005 at 04:00:26PM -0500, Michel Dänzer wrote:
On Wed, 2005-03-16 at 21:51 +0200, Ville Syrjälä wrote:
One thing just popped to my head though. If in the future we are going to
allow graphics cards to render to system memory, using the swapper will no
longer work. I
On Wed, Mar 16, 2005 at 03:58:07PM -0500, Alex Deucher wrote:
On Wed, 16 Mar 2005 22:08:08 +0200, Ville Syrjälä [EMAIL PROTECTED] wrote:
On Wed, Mar 16, 2005 at 02:09:18PM +1100, Benjamin Herrenschmidt wrote:
It's ugly, but that's not the point. The point is that all deployed
On Wed, 16 Mar 2005 23:08:12 +0200, Ville Syrjälä [EMAIL PROTECTED] wrote:
On Wed, Mar 16, 2005 at 03:58:07PM -0500, Alex Deucher wrote:
On Wed, 16 Mar 2005 22:08:08 +0200, Ville Syrjälä [EMAIL PROTECTED] wrote:
On Wed, Mar 16, 2005 at 02:09:18PM +1100, Benjamin Herrenschmidt wrote:
Vladimir Dergachev wrote:
Well, I thought I'd also point out that this solves the lockups I
was experiecing with the r300 driver, too :-)
Really ? And you can move cursor freely on r300 without lockups ?
I played almost a full game of neverputt... That hasn't happened
with the r300 driver in
On Wednesday 16 March 2005 08:46 am, Jerome Glisse wrote:
On Tue, 15 Mar 2005 18:36:21 -0500, Jung-uk Kim [EMAIL PROTECTED]
wrote:
On Tuesday 15 March 2005 05:06 pm, Aapo Tahkola wrote:
After reading all the promising success stories about the
r300 project, I am
wondering whether
I am quite certain, that, at least on mach64 hardware, an attempt to
access framebuffer by CPU while the GUI engine is active will result in a
hard lockup.
If this was true with Radeons, you'd get a lockup every time the
hardware cursor shape changes. I guess the memory controller has
improved...
On Wed, 2005-03-16 at 11:48 -0500, Adam Jackson wrote:
On Wednesday 16 March 2005 09:09, Ville Syrjälä wrote:
On Wed, Mar 16, 2005 at 05:31:16PM +1100, Benjamin Herrenschmidt wrote:
Well, do they revert it after atyfb/aty128fb/radeonfb set it then ?
it's definitely set on mode switch.
Am Mittwoch, den 16.03.2005, 16:26 +0100 schrieb Felix Kühling:
Am Mittwoch, den 16.03.2005, 17:35 +0300 schrieb Sergey Zharkov:
[snip]
What I'am afraid of is that savage_dri or savage_drv drivers writhe
something into the chip hardware that is not loaded there by kernel
modules start - so
On Wed, 2005-03-16 at 21:51 +0200, Ville Syrjälä wrote:
This was about the DirectFB drivers.
One thing just popped to my head though. If in the future we are going to
allow graphics cards to render to system memory, using the swapper will no
longer work. I don't see any other solution
On Wed, 2005-03-16 at 15:42 -0500, Michel Dänzer wrote:
On Wed, 2005-03-16 at 22:08 +0200, Ville Syrjälä wrote:
I don't see the current system slowly evolving into some superb future
system with an in kernel memory manager. The current APIs just have too
many limitations. I think the
On Wed, 2005-03-16 at 22:55 +0200, Ville Syrjälä wrote:
On Wed, Mar 16, 2005 at 10:49:11AM +1100, Benjamin Herrenschmidt wrote:
In the meantime, can you tell me more about your arbitration scheme ?
There is a lock associated with the graphics card. The lock is always
taken before
On Wed, 2005-03-16 at 16:00 -0500, Michel Dänzer wrote:
On Wed, 2005-03-16 at 21:51 +0200, Ville Syrjälä wrote:
One thing just popped to my head though. If in the future we are going to
allow graphics cards to render to system memory, using the swapper will no
longer work. I don't see
On Wed, 2005-03-16 at 23:08 +0200, Ville Syrjälä wrote:
On Wed, Mar 16, 2005 at 03:58:07PM -0500, Alex Deucher wrote:
I haven't seen anyone coming forward with a design/code for the memory
manager.
In the meantime I'm assuming that people might want to make some use of
their dualhead
On Thu, 17 Mar 2005 10:26:57 +1100, Benjamin Herrenschmidt
[EMAIL PROTECTED] wrote:
On Wed, 2005-03-16 at 15:42 -0500, Michel Dänzer wrote:
On Wed, 2005-03-16 at 22:08 +0200, Ville Syrjälä wrote:
I don't see the current system slowly evolving into some superb future
system with an in
On Thu, 2005-03-17 at 10:28 +1100, Benjamin Herrenschmidt wrote:
On Wed, 2005-03-16 at 16:00 -0500, Michel Dnzer wrote:
On Wed, 2005-03-16 at 21:51 +0200, Ville Syrjl wrote:
One thing just popped to my head though. If in the future we are going to
allow graphics cards to render to
Why don't we modify the new radoenfb driver to have a real
arbitration/management layer. Directfb can continue to use the old
driver. The rule is that you can't mix old and new style fbdev drivers
in a system. Over time DirectFb and X can be fixed to use the new
model.
There is going to
On Thu, Mar 17, 2005 at 10:27:56AM +1100, Benjamin Herrenschmidt wrote:
On Wed, 2005-03-16 at 22:55 +0200, Ville Syrjälä wrote:
On Wed, Mar 16, 2005 at 10:49:11AM +1100, Benjamin Herrenschmidt wrote:
In the meantime, can you tell me more about your arbitration scheme ?
There is a lock
On Thu, 2005-03-17 at 02:14 +0200, Ville Syrjälä wrote:
On Thu, Mar 17, 2005 at 10:27:56AM +1100, Benjamin Herrenschmidt wrote:
On Wed, 2005-03-16 at 22:55 +0200, Ville Syrjälä wrote:
On Wed, Mar 16, 2005 at 10:49:11AM +1100, Benjamin Herrenschmidt wrote:
In the meantime, can you tell me
On Thu, Mar 17, 2005 at 10:30:01AM +1100, Benjamin Herrenschmidt wrote:
On Wed, 2005-03-16 at 23:08 +0200, Ville Syrjälä wrote:
On Wed, Mar 16, 2005 at 03:58:07PM -0500, Alex Deucher wrote:
I haven't seen anyone coming forward with a design/code for the memory
manager.
In the
I understand you can't have userspace program the accelerator while
someone else is doing the same thing. Oh and I now understand that the
same really applies to direct framebuffer access due to the swapper.
And you can't have someone program the accelerator while somebody does
direct
On Thu, Mar 17, 2005 at 12:12:58PM +1100, Benjamin Herrenschmidt wrote:
I understand you can't have userspace program the accelerator while
someone else is doing the same thing. Oh and I now understand that the
same really applies to direct framebuffer access due to the swapper.
And
On Thu, 2005-03-17 at 03:25 +0200, Ville Syrjälä wrote:
On Thu, Mar 17, 2005 at 12:12:58PM +1100, Benjamin Herrenschmidt wrote:
I understand you can't have userspace program the accelerator while
someone else is doing the same thing. Oh and I now understand that the
same really
I backed out the RadeonWaitForIdleMMIO() out of radeon_mergedfb.c.
Also, I am no longer able to observe the lockup on my hardware that I saw
earlier, perhaps something else got fixed.
I am still curious to know what are the rules for accessing Radeon
registers, perhaps, when I have more spare
On Wed, 2005-03-16 at 17:46 -0500, Vladimir Dergachev wrote:
So can we be sure that one can do arbitrary INREG() on Radeons without
fear of lockup ?
I think so, in general.
--
Earthling Michel Dnzer | Debian (powerpc), X and DRI developer
Libre software enthusiast|
53 matches
Mail list logo
