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://freedesktop.org/bugzilla/show_bug.cgi?id=1657
--- Additional Comments From [EMAIL PROTECTED] 2004-10-21 02:20 ---
I finaly
Roland Scheidegger wrote:
Jon Smirl wrote:
I checked in a fix for freeing uninitialized i2c channels.
Works fine (tested with drm-core), thanks.
Actually, it doesn't.
I can rmmod the radeon module just fine now, but it causes oopses when
removing other i2c drivers.
Oct 21 11:52:44 ZakTower
I fixed up every error path that I can think of in the radeon i2c
code. It's checked into CVS. Let me know if I've fixed the problem. I
still haven't figure out how to reproduce it so I'm just fixing
everything that could possibly be wrong.
Don't use the new radeonfb with it, it is likely broken
On Iau, 2004-10-21 at 16:49, Thomas Hellstrm wrote:
architecture-independent library should be able to determine whether the
connection is local or not. Any hints on how to do best do this without
using drm?
Try DRM first and see if it fails.
There really isn't much else you can do - local
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://freedesktop.org/bugzilla/show_bug.cgi?id=760
--- Additional Comments From [EMAIL PROTECTED] 2004-10-21 11:17 ---
This is a
Jon Smirl wrote:
I fixed up every error path that I can think of in the radeon i2c
code. It's checked into CVS. Let me know if I've fixed the problem. I
still haven't figure out how to reproduce it so I'm just fixing
everything that could possibly be wrong.
Yes, that seems to have fixed it. I can
As pci_find_device is going away I've replaced it with pci_get_device.
for_each_pci_dev is a macro wrapper around pci_get_device.
If someone with this hardware could test it I would appreciate it.
Thanks.
Hanna Linder
IBM Linux Technology Center
Signed-off-by: Hanna Linder [EMAIL PROTECTED]
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://freedesktop.org/bugzilla/show_bug.cgi?id=960
[EMAIL PROTECTED] changed:
What|Removed |Added
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://freedesktop.org/bugzilla/show_bug.cgi?id=960
--- Additional Comments From [EMAIL PROTECTED] 2004-10-21 13:02 ---
What does
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://freedesktop.org/bugzilla/show_bug.cgi?id=760
--- Additional Comments From [EMAIL PROTECTED] 2004-10-21 13:03 ---
As has been
Can everyone give the linux-core DRM version more testing. I think we
have the compatibilty with vesafb ironed out now. I also added some
fixes so that the radeon driver can tolerate non-functional i2c ports
without failing.
Is it time to move linux-core into the snapshots instead of linux-2.6?
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://freedesktop.org/bugzilla/show_bug.cgi?id=960
--- Additional Comments From [EMAIL PROTECTED] 2004-10-21 14:18 ---
Argh, 1024.
Am Donnerstag, 21. Oktober 2004 20:15 schrieb Roland Scheidegger:
Jon Smirl wrote:
I fixed up every error path that I can think of in the radeon i2c
code. It's checked into CVS. Let me know if I've fixed the problem. I
still haven't figure out how to reproduce it so I'm just fixing
Am Donnerstag, 21. Oktober 2004 22:32 schrieb Jon Smirl:
Can everyone give the linux-core DRM version more testing. I think we
have the compatibilty with vesafb ironed out now. I also added some
fixes so that the radeon driver can tolerate non-functional i2c ports
without failing.
What about
How close is this to being ready for the kernel? All outstanding
problems I know of are fixed as of today.
I've been trying to get some time to make a bk tree for Andrews tree,
hopefully this weekend, I think it is ready for adapting into the kernel
(I may have to drop some pieces of stuff in
On Thu, 21 Oct 2004 22:52:56 +0100 (IST), Dave Airlie [EMAIL PROTECTED] wrote:
How close is this to being ready for the kernel? All outstanding
problems I know of are fixed as of today.
I've been trying to get some time to make a bk tree for Andrews tree,
hopefully this weekend, I think
Dieter Nützel wrote:
Am Freitag, 15. Oktober 2004 22:51 schrieb Nicolai Haehnle:
There is disagreement about the meaning of the CLIPSPAN _n parameter in
CVS.
The drivers I have looked at and drivers/dri/common/spantmp.h treat _n as
the number of pixels in the span after clipping.
depthtmp.h and
On Thu, Oct 21, 2004 at 03:35:21PM -0700, Ian Romanick wrote:
Dieter Nützel wrote:
Am Freitag, 15. Oktober 2004 22:51 schrieb Nicolai Haehnle:
There is disagreement about the meaning of the CLIPSPAN _n parameter in
CVS.
The drivers I have looked at and drivers/dri/common/spantmp.h treat
Alan Cox wrote:
On Iau, 2004-10-21 at 16:49, Thomas Hellstrm wrote:
architecture-independent library should be able to determine whether the
connection is local or not. Any hints on how to do best do this without
using drm?
Try DRM first and see if it fails.
There
Hello,
After realizing that the R200 driver bundled with xorg 6.8 wasn't
stable, I installed the CVS of DRI (as of 2 hours ago).
The problem *was* :
random lockups / freezes when playing UT (original one) or
Q3A (latest patch) ; those lockups happen within 30 seconds of starting
any of these
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://freedesktop.org/bugzilla/show_bug.cgi?id=960
[EMAIL PROTECTED] changed:
What|Removed |Added
21 matches
Mail list logo
