2:59 a.m.
Here is something we have all needed for some time.
Getting all the information is going to take some time, but
it will be worth it...
ALL Programs in FC3 should have a new section in their MAN
pages listing the ports they use.
These days all of us are sitting behind a Firewall, and I find
it a real pain having to go search to find out what ports a
given program might assume are 'open'. Getting this information
listed in one place would be a great help.
--
Reg.Clemens
reg(a)dwf.com
5:04 a.m.
On Sat, 24 Jul 2004 17:59:08 -0600, Reg Clemens <reg(a)dwf.com> wrote:
Here is something we have all needed for some time.
Getting all the information is going to take some time, but
it will be worth it...
ALL Programs in FC3 should have a new section in their MAN
pages listing the ports they use.
Better still... have a global used_port file or directory that is
populated on-the-fly by programs that need to open a port?
Then to find out which port an app might be using, you cat used_ports
| grep `rpm -qf packagename`
- Michel
5:10 a.m.
On Sun, Jul 25, 2004 at 09:04:27AM +0700, Michel Salim wrote:
On Sat, 24 Jul 2004 17:59:08 -0600, Reg Clemens <reg(a)dwf.com>
wrote:
> ALL Programs in FC3 should have a new section in their MAN
> pages listing the ports they use.
Better still... have a global used_port file or directory that is
populated on-the-fly by programs that need to open a port?
What's wrong with netstat?
netstat -nlp
netstat -nap
The problem with a list, is that port numbers may be dynamically
allocated at runtime.
7:05 a.m.
On Sat, 24 Jul 2004 22:10:45 -0400, Charles R. Anderson <cra(a)wpi.edu> wrote:
On Sun, Jul 25, 2004 at 09:04:27AM +0700, Michel Salim wrote:
> On Sat, 24 Jul 2004 17:59:08 -0600, Reg Clemens <reg(a)dwf.com> wrote:
> > ALL Programs in FC3 should have a new section in their MAN
> > pages listing the ports they use.
> Better still... have a global used_port file or directory that is
> populated on-the-fly by programs that need to open a port?
What's wrong with netstat?
netstat -nlp
netstat -nap
The problem with a list, is that port numbers may be dynamically
allocated at runtime.
True, though some applications (like Bittorrent and aMule, which are
prime candidates for a sysadmin to block) have preferred port ranges.
It would be nice to be able to look up all port information in one
place.
The problem with using netstat is, of course, that it only works for
applications already running?
- Michel
7:27 a.m.
On Saturday 24 July 2004 23:05, Michel Salim wrote:
True, though some applications (like Bittorrent and aMule, which
are prime candidates for a sysadmin to block) have preferred port
ranges. It would be nice to be able to look up all port information
in one place.
The problem with using netstat is, of course, that it only works
for applications already running?
- Michel
/etc/services is probably a great start ??
Regards, Mike Klinke
9:33 a.m.
On Sat, 2004-07-24 at 23:27, Mike Klinke wrote:
On Saturday 24 July 2004 23:05, Michel Salim wrote:
> True, though some applications (like Bittorrent and aMule, which
> are prime candidates for a sysadmin to block) have preferred port
> ranges. It would be nice to be able to look up all port information
> in one place.
>
> The problem with using netstat is, of course, that it only works
> for applications already running?
>
> - Michel
/etc/services is probably a great start ??
So is RFC1700.txt. Although nearly ten years old and now badly out of
date, this "Internet Standard 2" remains the most comprehensive single
list of services. Its editor, Jon Postel, was _the_ Internet Assigned
Numbers Authority (IANA). Jon died of a heart attack in October 1998
before he could update it. (See also Vint Cerf's RFC2468.txt.)
--Doc
Robert G. (Doc) Savage, BSE(EE), CISSP, RHCE | Fairview Heights, IL
Fedora Core 1 kernel 2.4.22-1.2197.nptl on P-III/M IBM Thinkpad A22p
"Perfection is the enemy of good enough."
-- Admiral of the Fleet Sergei G. Gorshkov
7:36 p.m.
On Sun, Jul 25, 2004 at 01:33:44AM -0500, Robert G. (Doc) Savage wrote:
So is RFC1700.txt. Although nearly ten years old and now badly out
of
date, this "Internet Standard 2" remains the most comprehensive single
RFC1700 is obsoleted by IANA's Assigned Numbers document:
http://www.iana.org/numbers.html
7 p.m.
New subject: FC3T1 - After Install, can no longer SSH into system from FC1
Harry Putnam <reader newsguy com> writes:
richard mullens <mullens ntlworld com> writes:
> The FC1 advice on overcoming this wasn't helpful to a
newbie.
> Of course this is a problem with FC1. Don't know if this happens on FC3T1.
It sounds FC3 related to me if as you say, it worked before
installing FC3.
One way to get some better info is to run ssh -vv <HOST> from
the FC1 box
and post the output.
Thanks for your remarks. Here is the output that you suggested that I post:-
OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090701f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.0.25 [192.168.0.25] port 22.
debug1: Connection established.
debug1: identity file /home/richard/.ssh/identity type -1
debug1: identity file /home/richard/.ssh/id_rsa type -1
debug1: identity file /home/richard/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.8.1p1
debug1: match: OpenSSH_3.8.1p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.6.1p2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc(a)lysator.liu.se
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc(a)lysator.liu.se
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160(a)openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160(a)openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc(a)lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc(a)lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160(a)openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160(a)openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 131/256
debug2: bits set: 1055/2048
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
13:af:4d:8e:e9:eb:18:6c:f2:9c:6a:d6:ce:44:db:e2.
Please contact your system administrator.
Add correct host key in /home/richard/.ssh/known_hosts to get rid of this message.
Offending key in /home/richard/.ssh/known_hosts:4
RSA host key for 192.168.0.25 has changed and you have requested strict checking.
Host key verification failed.
debug1: Calling cleanup 0x8062d10(0x0)
10:29 p.m.
New subject: FC3T1 - After Install, can no longer SSH into system from FC1
On Sun, Jul 25, 2004 at 05:00:16PM +0100, richard mullens wrote:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
13:af:4d:8e:e9:eb:18:6c:f2:9c:6a:d6:ce:44:db:e2.
Please contact your system administrator.
Add correct host key in /home/richard/.ssh/known_hosts to get rid of this
message.
Offending key in /home/richard/.ssh/known_hosts:4
RSA host key for 192.168.0.25 has changed and you have requested strict
checking.
Host key verification failed.
You have an SSH host key cached for that IP address/hostname that is
different from the SSH host key on the freshly installed system with
that IP/hostname. Delete line 4 from your .ssh/known_hosts file to
get rid of the stale cached value.
12:12 a.m.
New subject: FC3T1 - After Install, can no longer SSH into system from FC1
Charles R. Anderson wrote:
On Sun, Jul 25, 2004 at 05:00:16PM +0100, richard mullens wrote:
>@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
>@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
>Someone could be eavesdropping on you right now (man-in-the-middle attack)!
>It is also possible that the RSA host key has just been changed.
>The fingerprint for the RSA key sent by the remote host is
>13:af:4d:8e:e9:eb:18:6c:f2:9c:6a:d6:ce:44:db:e2.
>Please contact your system administrator.
>Add correct host key in /home/richard/.ssh/known_hosts to get rid of this
>message.
>Offending key in /home/richard/.ssh/known_hosts:4
>RSA host key for 192.168.0.25 has changed and you have requested strict
>checking.
>Host key verification failed.
>
You have an SSH host key cached for that IP address/hostname that is
different from the SSH host key on the freshly installed system with
that IP/hostname. Delete line 4 from your .ssh/known_hosts file to
get rid of the stale cached value.
Many thanks. This worked - as did Harry's method. Of course now I
remember ":4" takes one to line 4 in vi.
10:35 p.m.
New subject: FC3T1 - After Install, can no longer SSH into system from FC1
richard mullens <mullens(a)ntlworld.com> writes:
Thanks for your remarks. Here is the output that you suggested that
I post:-
Near the end it says:
Add correct host key in /home/richard/.ssh/known_hosts to get rid of
this message. Offending key in /home/richard/.ssh/known_hosts:4
It means since you installed a new OS there, ssh thinks someone has
been meddling with you host keys file. Unless you have important
added files in ~/.ssh just do this on FC1
rm -rf .ssh
Then try ssh again. It should prompt if you want to store the new
host key... and should be ok from there.
7:57 p.m.
On Sun, 2004-07-25 at 11:36, Charles R. Anderson wrote:
On Sun, Jul 25, 2004 at 01:33:44AM -0500, Robert G. (Doc) Savage
wrote:
> So is RFC1700.txt. Although nearly ten years old and now badly out of
> date, this "Internet Standard 2" remains the most comprehensive single
RFC1700 is obsoleted by IANA's Assigned Numbers document:
http://www.iana.org/numbers.html
Charles,
Great find. Thanks!
--Doc
Robert G. (Doc) Savage, BSE(EE), CISSP, RHCE | Fairview Heights, IL
Fedora Core 1 kernel 2.4.22-1.2197.nptl on P-III/M IBM Thinkpad A22p
"Perfection is the enemy of good enough."
-- Admiral of the Fleet Sergei G. Gorshkov
9:52 a.m.
Mike Klinke wrote:
On Saturday 24 July 2004 23:05, Michel Salim wrote:
>True, though some applications (like Bittorrent and aMule, which
>are prime candidates for a sysadmin to block)
>
you should know the few ports of the applications you have to allow
and all others should be blocked.
>have preferred port
>ranges. It would be nice to be able to look up all port information
>in one place.
>
>The problem with using netstat is, of course, that it only works
>for applications already running?
>
>- Michel
>
>
/etc/services is probably a great start ??
i prefer the nmap list
/usr/share/nmap/nmap-services
--
shrek-m
10:45 a.m.
New subject: Kernel-2.6.7-1.494 and Nvidia Drivers
Hi,
Regarding Kernel-2.6.7-1.494 and Nvidia Drivers,
I don't know if this has been mentioned before, but I've noticed some
nasty problems with this kernel release (the rpm) and the Nvidia drivers
while running Quake3 based games.
First of all, performance is terrible. I could barely get Return to
Castle Wolfenstein to run acceptably at 800x600x32 despite the fact that
normally, it runs flawlessly on my Geforce2go at 1024x768x32 under
normal circumstances. Secondly, it seems that some of the hardware
lighting instructions break under this kernel.
After fooling around with some things to try to fix this problem, I
noticed that the kacpid process crashes for some reason, causing it to
race and use >50% cpu.
I did some looking around and noticed that some people have had issues
with the PREEMPT_VOLUNTARY patch that was applied to this kernel and had
a hunch that perhaps this patch was in some way screwing up the ACPI
subsystem in the kernel. Rather than follow the same old mantra of
adding an acpi=off line to grub (especially since this machine is a
laptop), I rebuilt the kernel _without_ PREEMPT_VOLUNTARY and with
PREEMPT and voila, the problems disappeared. kacpid stopped crashing
and 3d under q3 based games worked wonderfully with no apparent
performance hit to my setup.
I hope that if anyone else runs across this problem that this will help
them and that perhaps it could help lead to a bug fix for this.
-brian
2:07 p.m.
New subject: Kernel-2.6.7-1.494 and Nvidia Drivers
On Sunday 25 July 2004 03:45, Brian R Smith wrote:
Hi,
Regarding Kernel-2.6.7-1.494 and Nvidia Drivers,
I don't know if this has been mentioned before, but I've noticed some
nasty problems with this kernel release (the rpm) and the Nvidia drivers
while running Quake3 based games.
First of all, performance is terrible. I could barely get Return to
Castle Wolfenstein to run acceptably at 800x600x32 despite the fact that
normally, it runs flawlessly on my Geforce2go at 1024x768x32 under
normal circumstances. Secondly, it seems that some of the hardware
lighting instructions break under this kernel.
After fooling around with some things to try to fix this problem, I
noticed that the kacpid process crashes for some reason, causing it to
race and use >50% cpu.
I did some looking around and noticed that some people have had issues
with the PREEMPT_VOLUNTARY patch that was applied to this kernel and had
a hunch that perhaps this patch was in some way screwing up the ACPI
subsystem in the kernel.
What is the purpose of "PREEMPT_VOLUNTARY" ?
Rather than follow the same old mantra of
adding an acpi=off line to grub (especially since this machine is a
laptop), I rebuilt the kernel _without_ PREEMPT_VOLUNTARY and with
PREEMPT and voila, the problems disappeared. kacpid stopped crashing
and 3d under q3 based games worked wonderfully with no apparent
performance hit to my setup.
Would be nice if we can get "preempt=on/off" on the grub line, eh?
I hope that if anyone else runs across this problem that this will help
them and that perhaps it could help lead to a bug fix for this.
Maybe, I should try the NVIDIA again. I have not been able to get NVIDIA 3D
support going since the "2.6.6-1.368" kernel, I think.
-brian
--
Ernest L. Williams Jr.
SNS Control Systems Group
(865) 591-0183
ORNL
7:20 p.m.
New subject: Kernel-2.6.7-1.494 and Nvidia Drivers
On Sun, 2004-07-25 at 03:45 -0400, Brian R Smith wrote:
Hi,
Regarding Kernel-2.6.7-1.494 and Nvidia Drivers,
I don't know if this has been mentioned before, but I've noticed some
nasty problems with this kernel release (the rpm) and the Nvidia drivers
while running Quake3 based games.
Then consult nVidia? What version of the drivers are you using?
I'm currently using NVIDIA-Linux-x86-1.0-6106-pkg1.run with 2.6.7-1.476
without issue.
First of all, performance is terrible. I could barely get Return to
Castle Wolfenstein to run acceptably at 800x600x32 despite the fact that
normally, it runs flawlessly on my Geforce2go at 1024x768x32 under
normal circumstances. Secondly, it seems that some of the hardware
lighting instructions break under this kernel.
This seems like it would be a driver problem...
After fooling around with some things to try to fix this problem, I
noticed that the kacpid process crashes for some reason, causing it to
race and use >50% cpu.
Then wouldn't one assume ACPI might be the prob? There have been
numerous ACPI in the 2.6.8rcX kernels so this will prolly go away with
the next kernel RPM release...
I did some looking around and noticed that some people have had
issues
with the PREEMPT_VOLUNTARY patch that was applied to this kernel and had
a hunch that perhaps this patch was in some way screwing up the ACPI
How about ACPI is screwing up because of ACPI bugs? Preemt Voluntary
has some issues here, but none are related to video and none are fatal.
Seems to work GREAT 90% of the time.
subsystem in the kernel. Rather than follow the same old mantra of
adding an acpi=off line to grub (especially since this machine is a
laptop), I rebuilt the kernel _without_ PREEMPT_VOLUNTARY and with
Are you sure your laptop's ACPI implementation is sane? Speaking of
which you don't mention the laptop brand or hardware at all...
PREEMPT and voila, the problems disappeared. kacpid stopped
crashing
and 3d under q3 based games worked wonderfully with no apparent
performance hit to my setup.
There is a newer preempt voluntary in later 2.6.8rcX kernels which fix
many issues according to Igno, so...whatever just stick to preempt I
guess the whole point of preempt voluntary is to improve desktop
performance...
I hope that if anyone else runs across this problem that this will
help
them and that perhaps it could help lead to a bug fix for this.
It's probably already been fixed.
-brian
-sb
--
Stan Bubrouski <stan(a)ccs.neu.edu>
5:04 p.m.
New subject: Kernel-2.6.7-1.494 and Nvidia Drivers
Hey Stan,
Then consult nVidia? What version of the drivers are you using?
I'm currently using NVIDIA-Linux-x86-1.0-6106-pkg1.run with
2.6.7-1.476 without issue.
NVIDIA-Linux-x86-1.0-6106-pkg1.run with the same kernel as you. Are you
relying heavily on ACPI? And of course I initially thought it could be
the problem, but:
Rather than follow the same old mantra of
adding an acpi=off line to grub (especially since this machine is a
laptop), I rebuilt the kernel _without_ PREEMPT_VOLUNTARY...
At the end of my post, I said that I rebuilt the kernel _without_
PREEMPT_VOLUNTARY and that afterward, everything worked beautifully, the
NVIDIA Drivers, ACPI and all. It was strictly a hunch that
PREEMPT_VOLUNTARY was causing problems with ACPI (possibly indirectly?)
and causing that subsystem to enter some race condition, chewing up my
CPU cycles.
My laptop's ACPI implementation shouldn't be broken, especially since
FC2 supported it quite well as does FreeBSD 5.x, in fact, if there are
kernel devs around, do you know if there are any differences between
linux's ACPI system and FreeBSD 5.x's? It seems the BSD one works
better (of course, my mileage has varied), at least on my Dell Inspiron
2650.
Asside from the newer kernel releases with PREEMPT_VOLUNTARY being
"fixed", I never noticed any performance gain while using it nor any
benefit so I may not even upgrade later. But who knows? I'm always
game for an upgrade.
-brian
On Sun, 2004-07-25 at 12:20, Stan Bubrouski wrote:
On Sun, 2004-07-25 at 03:45 -0400, Brian R Smith wrote:
> Hi,
>
> Regarding Kernel-2.6.7-1.494 and Nvidia Drivers,
>
> I don't know if this has been mentioned before, but I've noticed some
> nasty problems with this kernel release (the rpm) and the Nvidia drivers
> while running Quake3 based games.
>
Then consult nVidia? What version of the drivers are you using?
I'm currently using NVIDIA-Linux-x86-1.0-6106-pkg1.run with 2.6.7-1.476
without issue.
> First of all, performance is terrible. I could barely get Return to
> Castle Wolfenstein to run acceptably at 800x600x32 despite the fact that
> normally, it runs flawlessly on my Geforce2go at 1024x768x32 under
> normal circumstances. Secondly, it seems that some of the hardware
> lighting instructions break under this kernel.
>
This seems like it would be a driver problem...
> After fooling around with some things to try to fix this problem, I
> noticed that the kacpid process crashes for some reason, causing it to
> race and use >50% cpu.
>
Then wouldn't one assume ACPI might be the prob? There have been
numerous ACPI in the 2.6.8rcX kernels so this will prolly go away with
the next kernel RPM release...
> I did some looking around and noticed that some people have had issues
> with the PREEMPT_VOLUNTARY patch that was applied to this kernel and had
> a hunch that perhaps this patch was in some way screwing up the ACPI
How about ACPI is screwing up because of ACPI bugs? Preemt Voluntary
has some issues here, but none are related to video and none are fatal.
Seems to work GREAT 90% of the time.
> subsystem in the kernel. Rather than follow the same old mantra of
> adding an acpi=off line to grub (especially since this machine is a
> laptop), I rebuilt the kernel _without_ PREEMPT_VOLUNTARY and with
Are you sure your laptop's ACPI implementation is sane? Speaking of
which you don't mention the laptop brand or hardware at all...
> PREEMPT and voila, the problems disappeared. kacpid stopped crashing
> and 3d under q3 based games worked wonderfully with no apparent
> performance hit to my setup.
>
There is a newer preempt voluntary in later 2.6.8rcX kernels which fix
many issues according to Igno, so...whatever just stick to preempt I
guess the whole point of preempt voluntary is to improve desktop
performance...
> I hope that if anyone else runs across this problem that this will help
> them and that perhaps it could help lead to a bug fix for this.
>
It's probably already been fixed.
>
> -brian
>
>
-sb
--
Stan Bubrouski <stan(a)ccs.neu.edu>
5:19 p.m.
New subject: Kernel-2.6.7-1.494 and Nvidia Drivers
unfortionately your report is useless unless you can reproduce
without nvidia.
Unless you are running Kernel-2.6.7-1.494 with the Nvidia drivers and
have problems. There aren't a whole lot of people running
Kernel-2.6.7-1.494 so posting this report to Nvidia would have been
useless. I posted it here in case people who are running
Kernel-2.6.7-1.494, likely FC-devel people, run into the same problem.
As well, if I were like some people and had 4 or 5 machines laying
around with different hardware, I'd have already tested this theory
without "nvidia", but some of us are not that lucky. Laptops don't
surrender their video cards for replacement easily. I could try using
the "nv" driver, but it certainly wouldn't help in testing 3d. I could
try to see if the kacpid process races without the "nvidia" driver on my
machine???
I know that you guys do not tailor the kernel to run with the nvidia
drivers, that its nvidia's responsibility to produce a driver that will
run on their customers machine. I just figured there might be _someone_
on here that would benefit from my encounter.
-brian
On Wed, 2004-07-28 at 04:17, Arjan van de Ven wrote:
On Sun, 2004-07-25 at 03:45, Brian R Smith wrote:
> Hi,
>
> Regarding Kernel-2.6.7-1.494 and Nvidia Drivers,
unfortionately your report is useless unless you can reproduce without
nvidia.
______________________________________________________________________
--
fedora-test-list mailing list
fedora-test-list(a)redhat.com
To unsubscribe:
http://www.redhat.com/mailman/listinfo/fedora-test-list
6:55 p.m.
New subject: Kernel-2.6.7-1.494 and Nvidia Drivers
On Wed, 28 Jul 2004 10:19:25 -0400, Brian R Smith
<brian(a)cypher.acomp.usf.edu> wrote:
I just figured there might be _someone_
on here that would benefit from my encounter.
I'm sure that some user out there will end up eventually googling and
finding your report.
So in the most general sense, you are probably right.. someone will
end up finding your report not unuseful. But certaintly, a report like
this is unuseful to developers since any problems that only happen
when nvidia or other proprietary kernel module take an immense amount
of effort to debug without access to the code. And even if the kernel
developers could diagnose this problem after considerable effort, they
can't necessarily fix the problem if its nvidia driver specific
becuase they don't have access to nvidia's codebase.
Useful reports to developers, whether it be in this mailinglist or
bugzilla or the irc chat, need to be situations that developers can
attempt to reproduce AND diagnose via code review. There must be a
path towards achievable resolution for it to be worth their time, and
to be useful to them. So please be considerate the audience you are
trying to reach and use the appropriate forum. If you want to make
other testers aware of your problems and compare notes with other
testers use fedora-test-list.
-jef
8:47 p.m.
New subject: Kernel-2.6.7-1.494 and Nvidia Drivers
If you want to make other testers aware of your problems and
compare notes with other testers use fedora-test-list
For testers of Fedora Core development releases...
That's what I've been using... is there another fedora-test-list I
should be aware of?
Quoting myself from the message you quoted:
> I know that you guys do not tailor the kernel to run
> with the nvidia drivers, that its nvidia's responsibility
> to produce a driver that will run on their customers machine.
Never mind then. I know you guys can't do anything about the nvidia
drivers because you don't have access to the source, as I stated in the
same post that you quoted.
That said, I only posted to assist users who may run into the same
problem, fully aware of how the linux development process goes as far as
proprietary drivers are concerned: avoid them like the plague and keep
them as far from the tree as possible. If FC3 or kernel-2.6.8
w/PREEMPT_VOLUNTARY is released and this problem still exists for people
like me, then we will go to nvidia for a fix, because it is their
problem, not yours.
-brian
On Wed, 2004-07-28 at 11:55, Jeff Spaleta wrote:
On Wed, 28 Jul 2004 10:19:25 -0400, Brian R Smith
<brian(a)cypher.acomp.usf.edu> wrote:
> I just figured there might be _someone_
> on here that would benefit from my encounter.
I'm sure that some user out there will end up eventually googling and
finding your report.
So in the most general sense, you are probably right.. someone will
end up finding your report not unuseful. But certaintly, a report like
this is unuseful to developers since any problems that only happen
when nvidia or other proprietary kernel module take an immense amount
of effort to debug without access to the code. And even if the kernel
developers could diagnose this problem after considerable effort, they
can't necessarily fix the problem if its nvidia driver specific
becuase they don't have access to nvidia's codebase.
Useful reports to developers, whether it be in this mailinglist or
bugzilla or the irc chat, need to be situations that developers can
attempt to reproduce AND diagnose via code review. There must be a
path towards achievable resolution for it to be worth their time, and
to be useful to them. So please be considerate the audience you are
trying to reach and use the appropriate forum. If you want to make
other testers aware of your problems and compare notes with other
testers use fedora-test-list.
-jef
9:16 p.m.
New subject: Kernel-2.6.7-1.494 and Nvidia Drivers
On Wed, 28 Jul 2004 13:47:59 -0400, Brian R Smith
<brian(a)cypher.acomp.usf.edu> wrote:
> If you want to make other testers aware of your problems and
> compare notes with other testers use fedora-test-list
For testers of Fedora Core development releases...
You know what... im an idiot... I apologize.
Luckily i did say please this time, so at least i get points for being
a civil idiot.
-jef"will gladly accept his rightfuly deserved egg on his face,
becuase well I've never been really keen on using eating utensils and
egg tastes good"spaleta
10:26 p.m.
New subject: Kernel-2.6.7-1.494 and Nvidia Drivers
thanks for having a sense of humor about it and being so polite by
saying please. your sigs are famous.
-brian
On Wed, 2004-07-28 at 14:16, Jeff Spaleta wrote:
On Wed, 28 Jul 2004 13:47:59 -0400, Brian R Smith
<brian(a)cypher.acomp.usf.edu> wrote:
> > If you want to make other testers aware of your problems and
> > compare notes with other testers use fedora-test-list
>
> For testers of Fedora Core development releases...
You know what... im an idiot... I apologize.
Luckily i did say please this time, so at least i get points for being
a civil idiot.
-jef"will gladly accept his rightfuly deserved egg on his face,
becuase well I've never been really keen on using eating utensils and
egg tastes good"spaleta
7:33 p.m.
On Sat, Jul 24, 2004 at 05:59:08PM -0600, Reg Clemens wrote:
Here is something we have all needed for some time.
Getting all the information is going to take some time, but
it will be worth it...
ALL Programs in FC3 should have a new section in their MAN
pages listing the ports they use.
That isn't really something Fedora can solve directly. I agree with your
comment - in the network world it is as relevant as "FILES". Such fixes need
to happen upstream in the various packages. You might want to submit the
needed fixes to a few packages and see what the general community view is.
7210
days inactive
7214
days old
23 comments
14 participants
participants (14)
-
Alan Cox -
Arjan van de Ven -
Brian R Smith -
Chuck Anderson -
Ernest L. Williams Jr. -
Harry Putnam -
Jef Spaleta -
Michel Salim -
Mike Klinke -
Reg Clemens -
richard mullens -
Robert G. (Doc) Savage -
shrek-m＠gmx.de -
Stan Bubrouski