On Sun, 13 Mar 2005, Adam K Kirchhoff wrote:
While it's possible, it seems unlikely. I did recently upgrade from 2.6.10
to 2.6.11 (about a week before reinstalling Debian)... However, my lockups
only ever happen with running a 3D client, not just X.
*However,* I've been playing with different
On Sunday 13 March 2005 23:46, Adam K Kirchhoff wrote:
Adam K Kirchhoff wrote:
I really am confused. This was all working (with my 9200) prior to
reinstalling Debian on my system on Friday. Thankfully it still works
(with drm 1.15.0) on my FreeBSD installation. Not really sure if that
Vladimir Dergachev wrote:
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.
On Mon, 14 Mar 2005, Adam K Kirchhoff wrote:
Vladimir Dergachev wrote:
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...
Vladimir Dergachev wrote:
On Mon, 14 Mar 2005, Adam K Kirchhoff wrote:
Vladimir Dergachev wrote:
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
On Sun, Mar 13, 2005 at 11:04:59PM +1100, Benjamin Herrenschmidt wrote:
I must be missing something something obvious because I don't quite
understand what major drawbacks there are with the non-overlapping mode.
As I see it you get at least the same amount of CPU accessible memory as
On Mon, 2005-03-14 at 15:32 +1100, Paul Mackerras wrote:
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
It was still broken with -bk9.
AGP code that caused it to oops for me. Linus took my patch to fix
On Mon, 2005-03-14 at 07:34 -0500, Adam K Kirchhoff wrote:
glxgears usually runs fine till I move the mouse... The mouse will
stutter.
I suspect this is caused by the RADEONWaitForIdleMMIO() call Vladimir
added to RADEONChooseCursorCRTC() on February 18th. I think this
function will be
On Mon, 2005-03-14 at 18:12 +1100, Benjamin Herrenschmidt wrote:
On Sun, 2005-03-13 at 23:28 -0500, Michel Dnzer 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
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
In an ideal world ... However, since we are planning to move the memory
manager to the kernel, that would mean a kernel access (syscall, ioctl,
whatever...) twice per access to AGP memory. Not realistic.
Could the user space driver batch many
On Mon, Mar 14, 2005 at 05:30:04PM +0100, Soeren Sandmann wrote:
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
In an ideal world ... However, since we are planning to move the memory
manager to the kernel, that would mean a kernel access (syscall, ioctl,
whatever...) twice per access
Michel Dnzer wrote:
On Mon, 2005-03-14 at 07:34 -0500, Adam K Kirchhoff wrote:
glxgears usually runs fine till I move the mouse... The mouse will
stutter.
I suspect this is caused by the RADEONWaitForIdleMMIO() call Vladimir
added to RADEONChooseCursorCRTC() on February 18th. I think
On Mon, 2005-03-14 at 11:45 -0500, Adam K Kirchhoff wrote:
Michel Dnzer wrote:
On Mon, 2005-03-14 at 07:34 -0500, Adam K Kirchhoff wrote:
glxgears usually runs fine till I move the mouse... The mouse will
stutter.
I suspect this is caused by the RADEONWaitForIdleMMIO() call Vladimir
Michel Dnzer wrote:
On Mon, 2005-03-14 at 11:45 -0500, Adam K Kirchhoff wrote:
Michel Dnzer wrote:
On Mon, 2005-03-14 at 07:34 -0500, Adam K Kirchhoff wrote:
glxgears usually runs fine till I move the mouse... The mouse will
stutter.
I suspect this is caused by the
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-14 09:42 ---
(In
http://bugme.osdl.org/show_bug.cgi?id=4337
Summary: ATI Rage 128: messed up X
Kernel Version: from at least 2.6.11-bk8 to bk10
Status: NEW
Severity: high
Owner: [EMAIL PROTECTED]
Submitter: [EMAIL PROTECTED]
Distribution: Debian Sarge
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-14 12:28 ---
(In
On Mon, 2005-03-14 at 15:32 +1100, Paul Mackerras wrote:
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.
2.6.11-bk10 is a slight improvement.
When X starts the screen goes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ville Syrjälä wrote:
Makes me wish I had a PPC box alongside the x86 one.
You might like to try http://pearpc.sourceforge.net/.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Ok so the problem is byte swapping. Looking at atyfb for example it uses
the big-endian aperture on big-endian systems and selects the byte
swapping method according to the bit depth. If that really means that all
host access to the aperture gets byte swapped then I don't see how the
On Mon, 2005-03-14 at 11:20 -0500, Michel Dänzer wrote:
On Mon, 2005-03-14 at 18:12 +1100, Benjamin Herrenschmidt wrote:
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
On Mon, 2005-03-14 at 17:30 +0100, Soeren Sandmann wrote:
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
In an ideal world ... However, since we are planning to move the memory
manager to the kernel, that would mean a kernel access (syscall, ioctl,
whatever...) twice per access to AGP
On Tue, 2005-03-15 at 08:52 +1100, Benjamin Herrenschmidt wrote:
On Mon, 2005-03-14 at 11:20 -0500, Michel Dnzer wrote:
On Mon, 2005-03-14 at 18:12 +1100, Benjamin Herrenschmidt wrote:
On Sun, 2005-03-13 at 23:28 -0500, Michel Dnzer wrote:
On Sun, 2005-03-13 at 17:43 +1100, Benjamin
Be that as it may, it remains a fact that such a change would break
existing installations...
I think that mode setting and memory allocation should be separated. X
will always reserve enough video RAM for the largest resolution it uses
for the screen contents.
But X has no control on
On Mon, 14 Mar 2005, Michel [ISO-8859-1] Dnzer wrote:
On Mon, 2005-03-14 at 11:45 -0500, Adam K Kirchhoff wrote:
Michel Dnzer wrote:
On Mon, 2005-03-14 at 07:34 -0500, Adam K Kirchhoff wrote:
glxgears usually runs fine till I move the mouse... The mouse will
stutter.
I suspect this is caused by
Vladimir Dergachev wrote:
On Mon, 14 Mar 2005, Michel [ISO-8859-1] Dnzer wrote:
On Mon, 2005-03-14 at 11:45 -0500, Adam K Kirchhoff wrote:
Michel Dnzer wrote:
On Mon, 2005-03-14 at 07:34 -0500, Adam K Kirchhoff wrote:
glxgears usually runs fine till I move the mouse... The mouse will
stutter.
I
On Mon, 2005-03-14 at 20:49 +, Andrew Clayton wrote:
On Mon, 2005-03-14 at 15:32 +1100, Paul Mackerras wrote:
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.
Michel Dnzer wrote:
I also made it set the source pitch based on the image width. If the
image width is less than 64, we have a problem if the image height is
more than 1 (if the height is 1 the pitch doesn't matter). I made it
return an EINVAL error in that case. I didn't see that case ever
On Mon, 2005-03-14 at 18:05 -0500, Vladimir Dergachev wrote:
I am unsure of how to fix it though, as the call *is* needed, we should
not be reading from registers with engine busy.
Something may be needed, but probably not a wait for idle (which may
never succeed on an SMP system). Other
(resend)
Fix sparse NULL/0 warning:
drivers/char/drm/radeon_state.c:1845:15: warning: Using plain integer as NULL
pointer
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
diffstat:=
drivers/char/drm/radeon_state.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -Naurp
On Tue, 2005-03-15 at 10:53 +1100, Benjamin Herrenschmidt wrote:
[snip]
You are using radeonfb ? if yes, try without and let me know.
Just using the basic vga console.
Ben.
Andrew
---
SF email is sponsored by - The IT Product Guide
Michel Dnzer wrote:
On Mon, 2005-03-14 at 18:05 -0500, Vladimir Dergachev wrote:
I am unsure of how to fix it though, as the call *is* needed, we should
not be reading from registers with engine busy.
Something may be needed, but probably not a wait for idle (which may
never succeed on an
Felix Kühling wrote:
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
[[[
I am also cross posting to xorg mailing list.
The e-mail below discusses a RADEONWaitForIdleMMIO() call I put in
radeon_mergedfb.c before OUTREGP() calls in cursor functions.
The call was needed as OUTREGP() calls INREG() implicitly.
However, it turns out that this call breaks on SMP systems
On Mon, 14 Mar 2005, Adam K Kirchhoff wrote:
Michel Dnzer wrote:
On Mon, 2005-03-14 at 18:05 -0500, Vladimir Dergachev wrote:
I am unsure of how to fix it though, as the call *is* needed, we should
not be reading from registers with engine busy.
Something may be needed, but probably not a wait
On Tue, 2005-03-15 at 09:37 +1100, Benjamin Herrenschmidt wrote:
Be that as it may, it remains a fact that such a change would break
existing installations...
I think that mode setting and memory allocation should be separated. X
will always reserve enough video RAM for the largest
On Mon, 14 Mar 2005 23:59:37 -0500, Michel Dänzer [EMAIL PROTECTED] wrote:
On Tue, 2005-03-15 at 09:37 +1100, Benjamin Herrenschmidt wrote:
Be that as it may, it remains a fact that such a change would break
existing installations...
I think that mode setting and memory allocation
On Tue, 15 Mar 2005 09:37:53 +1100, Benjamin Herrenschmidt
[EMAIL PROTECTED] wrote:
Be that as it may, it remains a fact that such a change would break
existing installations...
I think that mode setting and memory allocation should be separated. X
will always reserve enough video RAM
On Mon, Mar 14, 2005 at 11:59:37PM -0500, Michel Dänzer wrote:
On Tue, 2005-03-15 at 09:37 +1100, Benjamin Herrenschmidt wrote:
Be that as it may, it remains a fact that such a change would break
existing installations...
I think that mode setting and memory allocation should be
On Mon, 2005-03-14 at 23:59 -0500, Michel Dänzer wrote:
On Tue, 2005-03-15 at 09:37 +1100, Benjamin Herrenschmidt wrote:
Be that as it may, it remains a fact that such a change would break
existing installations...
I think that mode setting and memory allocation should be separated.
On Tue, 2005-03-15 at 00:30 -0500, Jon Smirl wrote:
I agree that X has to be fixed to work cooperatively in this environment.
The alternative is to just leave X alone and make all of this work for XGL.
The user would then choose which environment they want to run.
I'm leaning toward just
On Tue, 2005-03-15 at 08:01 +0200, Ville Syrjälä wrote:
If radeonfb will allocate the buffer for the second head from the top of
the memory users would basically have to guess it's location. matroxfb
simply cuts the memory in two pieces and allocates the buffers from the
start of each
42 matches
Mail list logo
