I tried to upgrade an oldish Dell Optiplex GX110 that's now running FC3 to FC5T2,
and this is how far I got:
... Intel 82810E DC-133 cGC [Chipset Graphics Controller]
... Viewsonic P813
1...2...3...4...5.... X server started successfully
mini-wm: Fatal IO error 104 (Connection reset by peer) on Xserver :1.0
and the tail of X.log reads:
(EE) GARTInit: Unable to open /dev/agpgart (No such device)
(EE) I810(0): AGP GART support is not available. Make sure your kernel has
agpgart support or that the agpgart kernel module is loaded.
(EE) Screen(s) found, but none have a usable configuration.
Fatal server error:
no screens found
Known problem? Should I bugzilla? Provide more information?
Thanks, Willem Riede.
PS - appologies for re-posting, I had not used the right subject.
If you send a file to the trash with Konqueror it end up on my system in
If you send something to the trash with Nautilus it end up in
When you are running a gnome desktop the trash icon point to
/home/don/.Trash so you never see the files Konqueror sent to its trash can.
When you switch from a gnome session to a kde session (gnome being your
default) you are then prompted with a dialog asking if you want to make kde
your default manager or just use it for this session only. If you choose
this session only kde still ends up being the default.
If you try opening a file with kwrite from Konqueror (in super user mode
using "kdesu kfmclient openProfile webbrowsing") you get "KDEInit could not
After today's rawhide update (and actually since the big gnome-session
crash creator), gweather-applet-2 still fails to load. When I try to
add to the panel, it dies.
I don't know how to recreate on the command line -
typing /usr/lib/gweather-applet-2 just hangs.
I am using FC5 test2. The problems:
1. Remote installation: I can't install FC5 test2 from a remote ftp
server. The iso is for DVD. When I tried to connect, it responses:
Unable to get the file ftp://192.168.10.1//fc5/repodata/repomd.xml. The
file IS there, and can be accessed, so I wonder if it should be
192.168.10.1/fc5/, not 192.168.10.1//fc5/?
2. Acrobat 7.0.5 can't start when SELinux is running. I have to disable
the SELinux: setenforce 0, otherwise it will not start. It seems an old
problem in a new release.
3. The start menu and the right side panel always be ready to be dead. I
don't know if it's because there's the configuration files from the last
FC4 gnome. I will delete them for a test.
The good news is: Speed Step and ALSA works for the first time on my
laptop. I will never be forced to use OSS.
I was running 6 G5 machines with various FC4 kernels up to and including
2.6.14-1.1656_FC4. However, our two newest 2.7GHz dual processor
machines were be powering off by the therm_pm72 driver because of
overheating. The problem was confirmed by use of the
/sbin/critical_overtemp callback that the therm_pm72 driver provides.
Since we are using these machines as compute boxes, we have been limping
along with a critical_overtemp script that logged the invocation and
rebooted (instead of powering off.)
Recently I saw that there was patch to 2.6.15 to fix a bug in therm_pm72
that was contributing to the overtemp situation, specifically this patch:
Author: Benjamin Herrenschmidt <benh(a)kernel.crashing.org>
Date: Mon Dec 19 11:24:53 2005 +1100
[PATCH] powerpc: g5 thermal overtemp bug
The g5 thermal control for liquid cooled machines has a small bug, when
the temperatures gets too high, it boosts all fans to the max, but
incorrectly sets the liquids pump to the min instead of the max speed,
thus causing the overtemp condition not to clear and the machine to shut
down after a while. This fixes it to set the pumps to max speed instead.
This problem might explain some of the reports of random shutdowns that
some g5 users have been reporting in the past.
Many thanks to Marcus Rothe for spending a lot of time trying various
patches & sending log logs before I found out that typo. Note that
overtemp handling is still not perfect and the machine might still
shutdown, that patch should reduce if not eliminate such occcurences in
"normal" conditions with high load. I'll implement a better handling
with proper slowing down of the CPUs later.
Signed-off-by: Benjamin Herrenschmidt <benh(a)kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds(a)osdl.org>
I saw that the 2.6.15-1.1823_FC4 kernel had this patch so I tried that
but now have a different problem. The cooling system runs full blast
because the hardware is receiving the usually once a second commands
from the OS. This is very similar to the situation with the old FC4
kernels such as 2.6.11-1.1369_FC4 where the therm_pm72 driver was not
enabled because it only checked for PowerMac7,2 machines (as suggested
by pm72 in the driver name) and the new machines were detected as
PowerMac7,3. The machines no longer reboot, but the room that they are
in (a shared office for 3) is not inhabitable because of the noise.
Today I switched to 2.6.15-1.1824_FC4 to confirm that the situation
remains unchanged. The only thing I notice superficially different about
the kernals it that the therm_pm72 was built as a kernel module in all
FC4 kernels until now but this has changed to be built into the kernel
directly. I'm not sure if this could be a problem but I wanted to
In any case, for the short term my officemates and I have fled to other
offices. I'll probably tack a wack at debugging the problem, but wanted
to post to let people know of the problem with the new kernel, and old
kernel for that matter!
P.S. - I'll also note that benh, the driver author said elsewhere that
the overtemp problem is partially a manufacturing problem with the later
machines. We seem to be seeing that as our original 2.7GHz machine that
we got when they first came out does not have any cooling problems even
though its our server and has a far higher load that the other machines.
I'm taking a class on computer graphics and we are using GLUT to
develop OpenGL programs. There seems to be a problem with GLUT on
FC5T2 x86_64 (currently updated). Compiling a simple OpenGL program
with GLUT and running it produces:
./gltest: error while loading shared libraries: libGL.so.1: cannot
enable executable stack as shared object requires: Permission denied
Disabling SELinux yields:
freeglut (./gltest): ERROR: Internal error <Visual with necessary
capabilities not found> in function fgOpenWindow
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 4 (X_DestroyWindow)
Resource id in failed request: 0x0
Serial number of failed request: 16
Current serial number in output stream: 19
$ rpm -qa | grep glut | grep x86_64
$ rpm -qa | grep GL | grep x86_64
I have an nVidia graphics card, but am only using the nv driver for
testing so far. Looking back at the errors, the message "Visual with
necessary capabilities not found" looks suspicious. The program I'm
running is simple and runs on some machines that do not have 3d
accelerated drivers. Either way, the first error from SELinux does
not look good. I can use "execstack -s gltest" to get around that
with SELinux still enabled (but get the same error as with SELinux
Below is the program I'm running, it just brings up a window and draws
a line segment. Just in case someone wants to try it out.
$ cat gltest.c
void LineSegment( void )
glClear( GL_COLOR_BUFFER_BIT );
glColor3f( 1.0, 0.0, 0.0 );
glBegin( GL_LINES );
glVertex2i( 180, 15 );
glVertex2i( 10, 145 );
int main( int argc, char *argv )
glutInit( &argc, argv );
glutInitDisplayMode( GLUT_SINGLE | GLUT_RGB );
glutInitWindowPosition( 50, 100 );
glutInitWindowSize( 400, 300 );
glutCreateWindow( "An Example OpenGL Program" );
glClearColor( 1.0, 1.0, 1.0, 0.0 );
glMatrixMode( GL_PROJECTION );
gluOrtho2D( 0.0, 200.0, 0.0, 150.0 );
glutDisplayFunc( LineSegment );
Just a quick quiz on how many people have a install of fedora that is
unbootable? Where does it stop? When did it stop?
Only reason I am asking is I havent had mine working since early test1
and am nervous about the release of FC5 as it might not support my
laptop. I have used fedora on it since FC3 and have never had any
issues but FC5 tests seem to be causing all hell to break loose.
> > OK, I will try tonight. And the url / path to provide for
> > an http install would then be this, right:
> > http://download.fedora.redhat.comcFedora/RPMS/
> No. Read the responses to your other thread "docs on rescue CD?"
You mean that the actual path to be entered in the install form should be
/pub/fedora/linux/core/development/x86_64/, or something else?
After doing a `yum groupinstall Base` I notice that several packages
such as rootfiles are missing. On further investigation it appears
that Core is no longer a required group in Base.
Should I file a bug against comps in bugzilla?