This may be a dumb question, but why can't Redhat distribute NVIDIA binary
In NVIDIA's licence (http://www.nvidia.com/object/nv_swlicense.html) it
"2.1.2 Linux Exception. Notwithstanding the foregoing terms of Section
2.1.1, SOFTWARE designed exclusively for use on the Linux operating system
copied and redistributed, provided that the binary files thereof are not
modified in any
way (except for unzipping of compressed files)."
So, what's keeping RedHat from putting the drivers in the distribution? If
it's a GPL
thing, would it be easy to just download it during installation or at
least give the option to the user?
Ok, I have had Yarrow working well for a while now, but yesterday I
started experiencing some odd issues with my mouse. All of a sudden it
stops working correctly. The only thing that seems to fix is to kill X
and run mouse-test, then restart.
Also, I have FC 1 running on a desktop which is hooked up to a KVM
switch. Whenever I go to another PC, and return, the same thing
happens, the mouse goes crazy.
Damian Menscher <menscher(a)uiuc.edu>@redhat.com on 04/07/2004 04:57:13 PM
> On Wed, 7 Apr 2004, Jeff Elkins wrote:
> > I'm getting failure messages on my nfs mounts i.e. :
> > mount to NFS server 'music.elkins' failed: server is down.
> > nsfd appears to be running and I didn't see anything suspicious in the
> > The servers are up and running and have other clients connected.
> You didn't mention what steps you took to debug it:
> Can you ping the server?
> What is the output of rpcinfo -p servername?
> Does the server have access restrictions (firewall, TCP Wrappers, etc)?
I have the same symptoms...
rpcinfo says that nfs et.al. are running.
Something has changed in test 2, since the same PC running RH9
accesses that host just fine.
I don't know the right way to fix this, but something is definitely broken;
and something needs to be fixed, one way or the other. The question is what
exactly needs to be fixed.
Consider something like this:
AC_TRY_LINK_FUNC(res_query, AC_MSG_RESULT(yes), AC_MSG_RESULT(no))
Here's what happens on x86_64:
gcc -o conftest -g -O2 -Wall -I.. -I./.. conftest.c -lresolv >&5
/tmp/ccW7EeDX.o(.text+0x7): In function `main':
/home/mrsam/src/courier/authlib/configure:5160: undefined reference to
collect2: ld returned 1 exit status
configure:5147: $? = 1
configure: failed program was:
[ blah blah blah ]
| /* We use char because int might match the return type of a gcc2
| builtin and then its argument prototype would still apply. */
| char res_query ();
| main ()
| res_query ();
| return 0;
The same exact test on FC1 x86 will work.
The reason appears to be that you have to #include <resolv.conf> on x86_64
in order to succesfully pull res_query() out of libresolv.so. You don't
need to do this on x86, and the test program generated by AC_TRY_LINK_FUNC
does not include any headers, but uses a manual prototype.
So, what now?
I attempted to install FC3T1 on a USB drive using expert mode. It seems
that all the proper files installed on the disk. The disk is a laptop
disk contained inside a usb - ATA adapter and seems to work with the
proper modeles loaded.
Are there any plans to get the module needed to mount USB disks loaded
soon enough to be able to boot from these disks.
My grub.conf file is in the attached file.
There is a lot of interest in getting this concept to work.
The duck hunter trained his retriever to walk on water.....
"Notice anything?" the owner asked eagerly.
"Yes," said his friend, "I see that fool dog of yours can't swim."
# grub.conf generated by anaconda
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd2,0)
# kernel /vmlinuz-version ro root=/dev/sda2
# initrd /initrd-version.img
title Fedora Core (2.6.7-1.478)
kernel /vmlinuz-2.6.7-1.478 ro root=LABEL=/12 rhgb quiet
the plan is to do a kernel update friday or monday (depending on the
amount of things that turn up in this testing). There is a 424 kernel in
the testing dir on the ftp repository and on
One of the last minute changes is a series of patches to the input
subsystem that are supposed to fix a lot of the "tapping my laptops
touchpad doesn't work" bugs. So please beat hard on this kernel...
Arjan van de Ven
>Simon Sedgwick wrote:
>> I've just installed FC3-test1 on a spare box I've got laying >about.
>> was a clean install onto a disk that previously had FC1 on it and
>> fine. I chose a straight workstation install and performance >during
>> install process was okay.
>> After it had finished installing I rebooted the machine and
>> was fine until the kernel had decompressed the it came up with >the
>> following error: (dmesg)
>> agpgart: Detected an Intel i815 Chipset, but could not find the
>> secondary device.
>> agpgart: Detected an Intel i815 Chipset.
>> agpgart: Maximum main memory to use for agp memory: 439M
>> agpgart: AGP aperture is 64M @ 0xf8000000
>> Anything obvious spring to mind chaps?
>What is the second card that you have setup? I have a system with >an
>Intel 815 video card that is working fine.
>With another Dell computer with an Intel 828 656 card (810 driver) >I
>2 hours out of X before the following process die. I thought >rd-bomb
>some 2 hr timer before I found out that it was a screensaver.
>This is an agpgart error also.
>[drm:i830_wait_ring] *ERROR* space: 131052 wanted 131064
>Hopefully this problem will be gone for FC3T2.
Well I don't have a secondary graphics adaptor in it. I tried installing
FC2 and that does the same. Install goes fine but on first boot up it
runs like a dog. I've just reinstalled FC1 to make sure it's not a
hardware problem and thats running sweet. Shame because I was just
getting into this whole spacial Nautilus thing :-(