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=2733
Summary: Blender crashes after using renderer for more than 2
http://bugme.osdl.org/show_bug.cgi?id=4337
--- Additional Comments From [EMAIL PROTECTED] 2005-03-15 02:26 ---
Can you do some testing of -bk2, -bk6 as well?
-bk2 should be fine, if -bk6 is broken then it is the multi-bridge AGP stuff
that is broken, and if -bk6 works but -bk8
Hi all,
Andrew Clayton reported lockups on the dri list issues since -bk2
and bug 4337 on bugzilla.kernel.org looks like it might be the same
thing..
This leads me to think the AGP multi-bridge patches are at fault... (for
once my laziness in merging late instead of early gave a good gap
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=2733
--- Additional Comments From [EMAIL PROTECTED] 2005-03-15 02:40 ---
It's
Hello.
I'm locking /drivers/char/drm/(on last 2.6.11-bkX) and I
found some problems (bugs?)
in file drivers/char/drm/drm_ioctl.c :
/**
* Setversion ioctl.
*
* \param inode device inode.
* \param filp file pointer.
* \param cmd command.
* \param arg user argument, pointing to a drm_lock
Thanks,
I have CCed the relevant maintainers for their comment.
On Fri, Mar 04, 2005 at 12:31:34PM -0500, Aaron M. Ucko wrote:
Package: kernel
Severity: normal
Tags: patch upstream
The kernel's build system insists that users of x86_64 hardware use
AGP_INTEL_MCH rather than AGP_INTEL.
On Tue, 15 Mar 2005, Ville [iso-8859-1] Syrjl wrote:
I think that making the assumption that all memory is preserved when the
memory layout (virtual resolution and depth) doesn't change is perfectly
valid too. That would allow X to do it's Ctrl-Alt-+ and - things without
repainting the
Ville Syrjälä wrote:
I think that making the assumption that all memory is preserved when
the
memory layout (virtual resolution and depth) doesn't change is perfectly
valid too. That would allow X to do it's Ctrl-Alt-+ and - things without
repainting the whole screen.
I'm not sure I agree
Am Dienstag, den 15.03.2005, 01:41 +0100 schrieb Roland Scheidegger:
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
On Tue, Mar 15, 2005 at 12:30:56PM +0100, Roland Scheidegger wrote:
Ville Syrjälä wrote:
I think that making the assumption that all memory is preserved when
the
memory layout (virtual resolution and depth) doesn't change is perfectly
valid too. That would allow X to do it's Ctrl-Alt-+
Vladimir Dergachev wrote:
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
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-15 05:34 ---
(In
On Tue, Mar 15, 2005 at 09:51:40AM +0100, Geert Uytterhoeven wrote:
On Tue, 15 Mar 2005, Ville [iso-8859-1] Syrj??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
On Tue, Mar 15, 2005 at 05:59:42PM +1100, Benjamin Herrenschmidt wrote:
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
On Tue, 15 Mar 2005 16:00:05 +0200, Ville Syrjälä [EMAIL PROTECTED] wrote:
DirectFB has it's own asbitration mechanism. It doesn't support using
multiple framebuffer devices at the same time. For that to work DirectFB
would just have to know if some of the framebuffer devices are actually
On Tue, Mar 15, 2005 at 07:43:54PM +0900, Horms wrote:
Thanks,
I have CCed the relevant maintainers for their comment.
The AGP change already went into Linus' tree, along with
removal of the _MCH driver.
Dave
---
SF
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 a very long time :-)
On Tue, Mar 15, 2005 at 10:38:30AM +, Dave Airlie wrote:
Hi all,
Andrew Clayton reported lockups on the dri list issues since -bk2
and bug 4337 on bugzilla.kernel.org looks like it might be the same
thing..
This leads me to think the AGP multi-bridge patches are at
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 Mon, 14 Mar 2005 22:14:25 -0500 (EST), Vladimir Dergachev
[EMAIL PROTECTED] wrote:
On Mon, 14 Mar 2005, Adam K Kirchhoff wrote:
Michel Dänzer 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
On Tue, Mar 15, 2005 at 10:29:22AM -0500, Aaron M. Ucko wrote:
Dave Jones [EMAIL PROTECTED] writes:
On Tue, Mar 15, 2005 at 07:43:54PM +0900, Horms wrote:
Thanks,
I have CCed the relevant maintainers for their comment.
Thanks.
The AGP change already went into
http://bugme.osdl.org/show_bug.cgi?id=4337
--- Additional Comments From [EMAIL PROTECTED] 2005-03-15 08:18 ---
-bk2 works fine, bk6 (and the current .3-bk1) have the same problem (or a
similar^^) the screen is black in the upper part (to be exact 1/4, not 1/3)
and the system is
I might get time to do a code review, my main worry is that all the
problems reported with those patches in -mm made it into the patchset that
went into Linus.. mainly things like forgetting to memset certain
structures to 0 and sillies like that...
I saw one report where the
I have made a RPM, SRPM and SPEC file of driconf available. The RPM
was made under Fedora Core 3. The link is in the Download section on
this page:
http://dri.freedesktop.org/wiki/DriConf
I will do my best to track releases to keep them updated, but if you can't
wait it should be easy to
Am Dienstag, den 15.03.2005, 10:36 -0600 schrieb D. Hageman:
I have made a RPM, SRPM and SPEC file of driconf available. The RPM
was made under Fedora Core 3. The link is in the Download section on
this page:
http://dri.freedesktop.org/wiki/DriConf
Could you also add a note near the top
On Tue, Mar 15, 2005 at 11:18:17AM -0500, Aaron M. Ucko wrote:
Dave Jones [EMAIL PROTECTED] writes:
I just grabbed 2.6.11.3-bk1 to take a look; although the _MCH driver
has indeed disappeared, the Kconfig stanza for AGP_INTEL still
specifies !X86_64 AFAICT.
It went into
Dave Jones [EMAIL PROTECTED] writes:
I just grabbed 2.6.11.3-bk1 to take a look; although the _MCH driver
has indeed disappeared, the Kconfig stanza for AGP_INTEL still
specifies !X86_64 AFAICT.
It went into Linus' tree, not GregKH's.
I've also checked 2.6.11-bk10; same deal. (Or is
On Tue, Mar 15, 2005 at 09:37:35AM -0500, Dave Jones wrote:
On Tue, Mar 15, 2005 at 07:43:54PM +0900, Horms wrote:
Thanks,
I have CCed the relevant maintainers for their comment.
The AGP change already went into Linus' tree, along with
removal of the _MCH driver.
Thanks, I thought
Dave Jones [EMAIL PROTECTED] writes:
On Tue, Mar 15, 2005 at 07:43:54PM +0900, Horms wrote:
Thanks,
I have CCed the relevant maintainers for their comment.
Thanks.
The AGP change already went into Linus' tree, along with
removal of the _MCH driver.
I just grabbed 2.6.11.3-bk1 to
On Tue, Mar 15, 2005 at 04:15:42PM +, Dave Airlie wrote:
I saw one report where the recent drm security hole fix broke dri
for one user. Whilst it seems an isolated incident, could this have
more impact than we first realised ?
the radeon security changes? I've gotten no bad
On Tue, Mar 15, 2005 at 04:15:42PM +, Dave Airlie wrote:
I might get time to do a code review, my main worry is that all the
problems reported with those patches in -mm made it into the patchset
that
went into Linus.. mainly things like forgetting to memset certain
the multi-bridge stuff is definitely broken as I've seen radeon and r128
reports on it .. and it looks most like 2.6.11-bk2 broke things and I
haven't merged anything until -bk7 ...
Wait, -bk2 broke things ? The big agp changes went into -bk3,
so this seems odd.
sorry bk2-bk3 broke
On Tue, 2005-03-15 at 12:30 +0100, Roland Scheidegger wrote:
Ville Syrjl wrote:
I think that making the assumption that all memory is preserved when
the
memory layout (virtual resolution and depth) doesn't change is perfectly
valid too. That would allow X to do it's Ctrl-Alt-+ and -
G'Day,
I've just committed the start of multitexturing support to CVS.
The code works for me, but I've left the old code intact, and can be
re-enabled by changing a couple of ifdefs in r300_state.c.
Here's what remains to be done:
1. Implement the remaining texenv functions, I believe I left
On Tue, 2005-03-15 at 09:29 -0500, Jon Smirl wrote:
Aonther approach would be to just say you have to choose to run one of
X, DirectFB, FBUI, XGL and you can't switch between them. Other than
developers I don't know if anyone really runs more than one of these
at a time.
FWIW, yes we do.
I added to the Installation instructions:
Packages are available for Linux distributions utilizing RPM package
management in the Download section. We currently do not have Debian
packages available. If you are interested in the role of Debian package
manager for this project please send an
On Tuesday, March 15, 2005 6:36 am, Dave Jones wrote:
I saw one report where the recent drm security hole fix broke dri
for one user. Whilst it seems an isolated incident, could this have
more impact than we first realised ?
Worse case scenario we can drop out the multi-bridge support for
Am Dienstag, den 15.03.2005, 11:37 -0600 schrieb D. Hageman:
I added to the Installation instructions:
Packages are available for Linux distributions utilizing RPM package
management in the Download section. We currently do not have Debian
packages available. If you are interested in the
On Tue, 2005-03-15 at 11:53 -0500, Dave Jones wrote:
On Tue, Mar 15, 2005 at 04:15:42PM +, Dave Airlie wrote:
I might get time to do a code review, my main worry is that all the
problems reported with those patches in -mm made it into the patchset
that
went into
Dave Jones [EMAIL PROTECTED] writes:
I've fixed this in my tree. Will ask Linus to pull for the next
-bk snapshot.
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
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 on DragonFly BSD and in Xorg.0.log I found a message
that DRI was enabled, but glxinfo said direct rendering: No.
Thanks,
Johannes
Johannes Hofmann 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 on DragonFly BSD and in Xorg.0.log I found a message
that DRI was enabled, but glxinfo said direct rendering: No.
Jesse Barnes [EMAIL PROTECTED] wrote:
I'd be happy to test and fix things, but the page table walker patches broke
ia64... Once that's cleared up I can go digging.
We're hoping that davem's fix (committed yesterday) fixed that.
ChangeSet 1.2181.1.2, 2005/03/14 21:16:17-08:00, [EMAIL
On Tuesday, March 15, 2005 11:25 am, Andrew Morton wrote:
Jesse Barnes [EMAIL PROTECTED] wrote:
I'd be happy to test and fix things, but the page table walker patches
broke ia64... Once that's cleared up I can go digging.
We're hoping that davem's fix (committed yesterday) fixed that.
On Tue, 2005-03-15 at 11:37 -0600, D. Hageman wrote:
I added to the Installation instructions:
Packages are available for Linux distributions utilizing RPM package
management in the Download section. We currently do not have Debian
packages available. If you are interested in the role of
Hi All,
I just installed the latest snapshot of the radeon DRI driver from
http://dri.freedesktop.org/snapshots/radeon-20050314-linux.i386.tar.bz2.
Installation went without problems, but direct rendering is disabled.
output of 'dmesg':
[drm] Initialized radeon 1.15.0 20050208 on minor 0: ATI
On Tue, 2005-03-15 at 22:10 +0100, Richard Stellingwerff wrote:
I just installed the latest snapshot of the radeon DRI driver from
http://dri.freedesktop.org/snapshots/radeon-20050314-linux.i386.tar.bz2.
Installation went without problems, but direct rendering is disabled.
output of
On Tue, 2005-03-15 at 09:53 -0500, Alex Deucher wrote:
On Mon, 14 Mar 2005 22:14:25 -0500 (EST), Vladimir Dergachev
[EMAIL PROTECTED] wrote:
This would mean that on r300 this fix is not needed, but rv350 locks up
without it.
In that case perhaps it makes sense to only wait for idle on
On Tue, 15 Mar 2005 16:13:21 -0500, Michel Dänzer [EMAIL PROTECTED] wrote:
On Tue, 2005-03-15 at 22:10 +0100, Richard Stellingwerff wrote:
[drm] Initialized radeon 1.15.0 20050208 on minor 0: ATI Technologies
Inc RV250 5c61 [Radeon Mobility 9200 M9+]
You need an r200 snapshot for that
Jon Smirl wrote:
Can we put in our own fault handler for the mmap, trap the directfb
accesses and do the proper locking?
Some SGI hardware used to work like that. When they asked Linus for
some kernel hooks to support that type of thing, well...I'm just glad
*I* wasn't in the line of fire. ;)
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 on DragonFly BSD and in Xorg.0.log I found a message
that DRI was enabled, but glxinfo said direct rendering: No.
DRMs BSD support
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
[EMAIL PROTECTED] changed:
What|Removed |Added
Am Dienstag, den 15.03.2005, 15:59 -0500 schrieb Michel Dänzer:
On Tue, 2005-03-15 at 11:37 -0600, D. Hageman wrote:
I added to the Installation instructions:
Packages are available for Linux distributions utilizing RPM package
management in the Download section. We currently do not
DirectFB assumes all memory outside var.yres_virtual * fix.line_length is
preserved. A totally valid assumption in my opinion.
Except that you can't know in advance how much fix.line_length will be.
The fix isn't really fixed. Different cards will have different
requirements depending on the
On Wed, Mar 16, 2005 at 09:44:19AM +1100, Benjamin Herrenschmidt wrote:
DirectFB assumes all memory outside var.yres_virtual * fix.line_length is
preserved. A totally valid assumption in my opinion.
Except that you can't know in advance how much fix.line_length will be.
The fix isn't
On Tue, 15 Mar 2005 23:41:14 +0100, khaqq [EMAIL PROTECTED] wrote:
On Tue, 15 Mar 2005 22:22:32 +0100
Richard Stellingwerff [EMAIL PROTECTED] wrote:
Ah, I'll try that. I got confused, because it used to work with the
radeon driver that comes with Xorg 6.8.
Radeon is the name of the 2D
Jesse Barnes [EMAIL PROTECTED] wrote:
We're hoping that davem's fix (committed yesterday) fixed that.
ChangeSet 1.2181.1.2, 2005/03/14 21:16:17-08:00, [EMAIL PROTECTED]
[MM]: Restore pgd_index() iteration to clear_page_range().
Yep, seems to have worked (at least my system boots).
I once did a similar thing for an embedded prototype: take a fixed amount of
memory for both frame buffers (this was a UMA system), fb0 starts from the
top,
fb1 starts from the bottom. You can enlarge each frame buffer, until you
read
the memory of the other. Each
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 on DragonFly BSD and in Xorg.0.log I found
a message that DRI was enabled,
On Tue, 2005-03-15 at 16:00 +0200, Ville Syrjälä wrote:
DirectFB has it's own asbitration mechanism. It doesn't support using
multiple framebuffer devices at the same time. For that to work DirectFB
would just have to know if some of the framebuffer devices are actually
different outputs
On Tuesday 15 March 2005 21:36, Ville Syrjälä wrote:
On Tue, Mar 15, 2005 at 09:51:40AM +0100, Geert Uytterhoeven wrote:
On Tue, 15 Mar 2005, Ville [iso-8859-1] Syrj??wrote:
If radeonfb will allocate the buffer for the second head from the top
of the memory users would basically have to
On Wed, 2005-03-16 at 01:05 +0200, Ville Syrjälä wrote:
True. Currently DirectFB doesn't handle this correctly. But that could be
easily fixed if only line_length wasn't totally misplaced. It really
belongs to fb_var_screeninfo. We could first test the mode with
FB_ACTIVATE_TEST and
On Wed, 2005-03-16 at 07:37 +0800, Antonino A. Daplas wrote:
On Tuesday 15 March 2005 21:36, Ville Syrjälä wrote:
On Tue, Mar 15, 2005 at 09:51:40AM +0100, Geert Uytterhoeven wrote:
On Tue, 15 Mar 2005, Ville [iso-8859-1] Syrj??wrote:
If radeonfb will allocate the buffer for the second
On Tue, 15 Mar 2005, Michel [ISO-8859-1] Dnzer wrote:
On Tue, 2005-03-15 at 09:53 -0500, Alex Deucher wrote:
On Mon, 14 Mar 2005 22:14:25 -0500 (EST), Vladimir Dergachev
[EMAIL PROTECTED] wrote:
This would mean that on r300 this fix is not needed, but rv350 locks up
without it.
In that case
On Tue, 15 Mar 2005, Vladimir Dergachev wrote:
On Tue, 15 Mar 2005, Michel [ISO-8859-1] Dänzer wrote:
On Tue, 2005-03-15 at 09:53 -0500, Alex Deucher wrote:
On Mon, 14 Mar 2005 22:14:25 -0500 (EST), Vladimir Dergachev
[EMAIL PROTECTED] wrote:
This would mean that on r300 this fix is not needed,
On Wed, Mar 16, 2005 at 10:50:52AM +1100, Benjamin Herrenschmidt wrote:
On Wed, 2005-03-16 at 07:37 +0800, Antonino A. Daplas wrote:
On Tuesday 15 March 2005 21:36, Ville Syrjälä wrote:
On Tue, Mar 15, 2005 at 09:51:40AM +0100, Geert Uytterhoeven wrote:
On Tue, 15 Mar 2005, Ville
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. matroxfb deals with that by moving the buffer and changing
smem_start and smem_len
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 the
framebuffer on bit depth or line lenght changes. I'm trying to talk
about
On Wed, 2005-03-16 at 10:33 +1100, Benjamin Herrenschmidt wrote:
Now, I agree that cutting the vram in half, and reserving both halves
to the offscreen needs to each head may help avoiding mode switch on
one head busting things used by whoever works on the second head, but
I'm not sure that
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] Lockups...'.
--
Earthling Michel Dnzer | Debian (powerpc), X and DRI
Disclaimer: I don't pretend to understand 100% how all this stuff works
either, but I think my understanding has improved a little recently. :)
On Tue, 2005-03-15 at 20:07 -0500, Vladimir Dergachev wrote:
On Tue, 15 Mar 2005, Vladimir Dergachev wrote:
My understanding was that for
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
assume that they haven't been tested very extensively.
You are wrong
72 matches
Mail list logo
