2:32 a.m.
Updated Packages:
beagle-0.2.1-12
---------------
* Fri Feb 24 2006 Matthias Clasen <mclasen(a)redhat.com> 0.2.1-12
- Remove more "run from ." nonsense (#182709)
- Don't spew tons of debug output (#182660)
- Try to make the trigger more robust (#182679)
fontconfig-2.3.94-1
-------------------
* Fri Feb 24 2006 Matthias Clasen <mclasen(a)redhat.com> - 2.3.94-1
- Update to 2.3.94
gdm-1:2.13.0.8-6
----------------
* Sat Feb 25 2006 Ray Strode <rstrode(a)redhat.com> - 1:2.13.0.8-6
- fix a broken link
gnome-icon-theme-2.14.1-1
-------------------------
* Sat Feb 25 2006 Matthias Clasen <mclasen(a)redhat.com> 2.14.1-1
- Update to 2.14.1
gnome-utils-1:2.13.93-1
-----------------------
* Sat Feb 25 2006 Matthias Clasen <mclasen(a)redhat.com> - 2.13.93-1
- Update to gnome-utils-2.13.93
- Update to gucharmap 1.5.3
librsvg2-2.14.0-1
-----------------
* Sat Feb 25 2006 Matthias Clasen <mclasen(a)redhat.com> 2.14.0-1
- Update to 2.14.0
mesa-6.4.2-5
------------
* Sat Feb 25 2006 Mike A. Harris <mharris(a)redhat.com> 6.4.2-5
- Disable the expeimental r300 DRI driver, as it has turned out to cause
instability and system hangs for many users.
vte-0.11.19-1.fc5.1
-------------------
* Sat Feb 25 2006 Matthias Clasen <mclasen(a)redhat.com> 0.11.19-1
- Update to 0.11.19
- Drop upstreamed patch
xorg-x11-xfs-1:1.0.1-3
----------------------
* Sat Feb 25 2006 Mike A. Harris <mharris(a)redhat.com> 1:1.0.1-3
- Redirect output of "rm -rf fonts.dir" to /dev/null in xfs.init
Broken deps for i386
----------------------------------------------------------
GFS-kernel - 2.6.15-5.FC5.4.i686 requires kernel = 0:2.6.15-1.1955_FC5
GFS-kernel - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5
GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5smp
cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel =
0:2.6.15-1.1955_FC5
cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires
/lib/modules/2.6.15-1.1955_FC5
cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel-smp =
0:2.6.15-1.1955_FC5
cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires
/lib/modules/2.6.15-1.1955_FC5smp
dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel = 0:2.6.15-1.1955_FC5
dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires
/lib/modules/2.6.15-1.1955_FC5
dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel-smp =
0:2.6.15-1.1955_FC5
dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires
/lib/modules/2.6.15-1.1955_FC5smp
gnbd-kernel - 2.6.15-5.FC5.7.i686 requires kernel = 0:2.6.15-1.1955_FC5
gnbd-kernel - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5
gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp
libbtctl - 0.6.0-5.i386 requires libopenobex.so.1
struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.i386 requires tomcat3
struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.i386 requires tomcat4
Broken deps for ia64
----------------------------------------------------------
libbtctl - 0.6.0-5.ia64 requires libopenobex.so.1()(64bit)
rgmanager - 1.9.31-3.ia64 requires ccs
struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.ia64 requires tomcat3
struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.ia64 requires tomcat4
vconfig - 1.9-1.1.ia64 requires libc.so.6
vconfig - 1.9-1.1.ia64 requires libc.so.6(GLIBC_2.0)
Broken deps for ppc
----------------------------------------------------------
libbtctl - 0.6.0-5.ppc requires libopenobex.so.1
struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.ppc requires tomcat3
struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.ppc requires tomcat4
Broken deps for ppc64
----------------------------------------------------------
emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
libbtctl - 0.6.0-5.ppc64 requires libopenobex.so.1()(64bit)
struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.ppc64 requires tomcat3
struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.ppc64 requires tomcat4
vconfig - 1.9-1.1.ppc64 requires libc.so.6
vconfig - 1.9-1.1.ppc64 requires libc.so.6(GLIBC_2.0)
Broken deps for s390
----------------------------------------------------------
rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1
struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.s390 requires tomcat3
struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.s390 requires tomcat4
Broken deps for s390x
----------------------------------------------------------
rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)
struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.s390x requires tomcat3
struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.s390x requires tomcat4
Broken deps for x86_64
----------------------------------------------------------
GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires /lib/modules/2.6.15-1.1955_FC5
cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires kernel =
0:2.6.15-1.1955_FC5
cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires
/lib/modules/2.6.15-1.1955_FC5
dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires kernel =
0:2.6.15-1.1955_FC5
dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires
/lib/modules/2.6.15-1.1955_FC5
gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5
libbtctl - 0.6.0-5.x86_64 requires libopenobex.so.1()(64bit)
libbtctl - 0.6.0-5.i386 requires libopenobex.so.1
struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.x86_64 requires tomcat3
struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.x86_64 requires tomcat4
7:10 a.m.
Build System wrote:
mesa-6.4.2-5
------------
* Sat Feb 25 2006 Mike A. Harris <mharris(a)redhat.com> 6.4.2-5
- Disable the expeimental r300 DRI driver, as it has turned out to cause
instability and system hangs for many users.
2 questions:
1) disable as in not enable by default / need manual config edit to
enable, or disable as in needs recompile to enable?
2) if disable as in needs recompile, does it cause problems even when
turned of by default. If not then why the disable? In my box the r300
drivers is one of the major features of the new X (if and only if it
works, agreed there)
Regards,
Hans
11:58 a.m.
Hans de Goede wrote:
Build System wrote:
>
> mesa-6.4.2-5
> ------------
> * Sat Feb 25 2006 Mike A. Harris <mharris(a)redhat.com> 6.4.2-5
> - Disable the expeimental r300 DRI driver, as it has turned out to cause
> instability and system hangs for many users.
>
2 questions:
1) disable as in not enable by default / need manual config edit to
enable, or disable as in needs recompile to enable?
Disable as in, r300_dri.so is no longer included in the binary packages.
2) if disable as in needs recompile, does it cause problems even when
turned of by default.
Yes, it causes hangs on many systems, in particular X300 and higher ATI
hardware even if just the dri extension module is loaded and no OpenGL
software has been ran.
If not then why the disable?
Because it was turned on for a short time as an experiment, with the
goal being to disable it completely if there were any signs of severe
instability caused by it. That instability has been observed and
confirmed, so it is now disabled.
In my box the r300 drivers is one of the major features of the new X
(if and only if it works, agreed there)
That is one of the reasons the experiment was tried to begin with. A
number of people have requested r300 DRI support for a long time now,
and finally a very highly experimental driver was created by reverse
engineering. The upstream developers of the r300 driver claim straight
out that it is very experimental, and not ready for mainstream use,
and ATI has confirmed this as well.
There are a handful of people who have installed and tried the driver
and it has worked for them. The exact set of circumstances in which
the driver actually works, is not fully known, and so shipping a
driver that crashes or otherwise screws up one's display or locks up
their system by default, is not an acceptable thing to do.
Part of the experiment of including it in Fedora development was to
try and gauge just how well it worked, if at all, and also to see
the extent of instability it might cause. Since it /is/ experimental,
the intention was always that if we did decide to ship it, DRI would
be disabled by default on all of the chips it supports, requiring
manual override to enable it.
Unfortunately, the number of people it actually works for is very
small compared to the variety of hardware it attempts to cover, and
the majority of reports coming back are of the "my system is screwed"
nature. Doing a bit of investigation has shown that it isn't just the
r300 DRI driver that is instable, but even just loading the X server
DRI module with many r300 or newer cards causes the system to crash,
even if DRI is actually disabled, and even if the r300 DRI driver is
not even present on the system.
In order to resolve the remaining "My r300 or better class card locks
up when X starts if 'Load "dri"' is present in the xorg.conf, and the
problem does not go away if I use 'Option "nodri"', nor even if I
delete the r300_dri.so driver, but the problem goes away if I comment
'Load "dri"' out of the config file.", it looks like we're
going to
have to debug what is causing the hang, and I have a good suspicion
that the kernel DRM is being loaded even if DRI gets disabled, and
that the kernel DRM is probably hanging the system.
Hardware support that is this buggy/unstable does not belong in the
OS until it is stabilized upstream *first*. I'm going to see if
removal of the r300 DRM kernel module resolves the remaining problem,
and if so, we might remove that too for now.
The extremely small subset of users for whom this driver actually
works, and is stable, are free to recompile things if they like, but
with the obvious caveat that we don't support it at all, and don't
support systems that have it loaded any more than we support 3rd
party proprietary drivers.
--
Mike A. Harris * Open Source Advocate * http://mharris.ca
Proud Canadian.
2:38 p.m.
Mike A. Harris wrote:
<snip>
Taking the fact that even if disabled in software this driver causes
stability problems, I fully understand the complete removal, thanks for
explaining.
So I agree with you except for:
The extremely small subset of users for whom this driver actually
works, and is stable, are free to recompile things if they like, but
with the obvious caveat that we don't support it at all, and don't
support systems that have it loaded any more than we support 3rd
party proprietary drivers.
I understand the don't support part, but I have to disagree with the any
more then propietary drivers, that is saying sure its open source but it
really is no better then a closed driver since its reversed engineered.
I agree reverse engineered is less good then based on specs, but it
still beats a closed driver hands down. Especially since specs are
almost always not 100% correct so driver writing is always a bit
guessing / reverse engineering.
Regards,
Hans
6:34 a.m.
Hans de Goede wrote:
> The extremely small subset of users for whom this driver
actually
> works, and is stable, are free to recompile things if they like, but
> with the obvious caveat that we don't support it at all, and don't
> support systems that have it loaded any more than we support 3rd
> party proprietary drivers.
I understand the don't support part, but I have to disagree with the any
more then propietary drivers,
You can disagree with me all you like, but we have never supported
software that does not ship with the OS. That includes open source
kernel modules, X drivers, or any other software. People using
drivers that do not ship with the OS, take full responsibility for
any problems they may encounter doing so. In particular for kernel
modules and X drivers, both of which can cause complete system hangs.
By all means, feel free to install/use whatever drivers you like, but
if they break, and we didn't ship them - you get to keep both pieces,
wether they are open source or not.
that is saying sure its open source but it really is no better then
a closed driver since its reversed engineered.
That's your personal thoughts, not mine. My claim is essentially:
"if we don't ship it, we don't provide maintenance it, wether it is
open source or not period."
If you have a driver installed/loaded in your system which we do not
support, and you have a system hang, you'll need to reproduce the
hang with the unsupported driver removed before we touch the issue.
This is not something new. It's been like this from the beginning of
time, I am only restating it to make sure people are fully aware of it.
I agree reverse engineered is less good then based on specs, but it
still beats a closed driver hands down.
That depends on your perspective I guess. An open source driver is
better than a closed source one from an OSS advocacy perspective, and
that is where my personal ideologies are. However many people would
argue with you that "a functional driver that allows me to use all
of the features of my hardware and actually works" is a better driver,
regardless of wether it is open source or closed source.
The fact is, each individual person has different needs/requirements,
and different ideologies of "what is better". I strongly prefer
open source drivers over proprietary ones - to the point where I have
never installed any of the proprietary drivers on my systems. So in
that regard I agree with you.
Having said that, an open source driver that is non-functional or
which locks up most people's systems is not particularly what I would
call "better" in any sense. At least not until the people developing
it get it into a useable and reliable state anyway.
--
Mike A. Harris * Open Source Advocate * http://mharris.ca
Proud Canadian.
6631
days inactive
6632
days old
4 comments
3 participants
participants (3)
-
Build System -
Hans de Goede -
Mike A. Harris