I have 2 Dell 2400's identically configured. One running RH 6.2 and one
running RH 7.0. Both are sitting side by side on the same network
(physical and logical). When I run an anaconda install from the RH 6.2
machine, the install completes in about 10 minutes. When I run the
install from the RH 7.0 server, it frequently stalls with "server stopped
responding still trying". The process completed after about 2.5 hours.
The target machine is the same machine in both cases (I'm installing to a
test machine). If I telnet to the RH 7.0 machine I don't have any
response time issues with the telnet session, so I don't think it's
network related. Both source machines are SMP machines 667 mhz for each
processor. The CPU is <5% utilized, and with 512 mb memory, there are
scads of available memory on both boxes. What else could be causing the
long delays? I'm suspecting the new NFS on a SMP machine. Any help would
The problem is definately related to SMP. After dropping the RH 7.0 box into
Uniprocessor mode by selecting the UP kernel option at startup. The RH 7 box
functions/loads at the same rate as the RH 6.2 SMP box.
There was an nfs race condition reported as fixed in kernel 2.2.17. I tested
the 2.2.17 kernel out, and it does resolve the issue. How do I package up my
new working kernel etc. to replace the broken kernel shipping in RH7.0? Or
would you like to release an errata kernel?
Hello, anyone home?
I have the same problem, I've created a NFS based kickstart installation, it
seems to work fine from my Workstation to the kickstart server. But when I try
to kickstart the Dell Precision 620 workstations, I have tons of NFS errors and
it's VERY slow.
I do believe that it's partly related to the 3com card that I have or definetly
a NFS error. I am running with a 3com 3c90x (rev 120) it's intergrated on the
motherboard so I don't have a known way to identify it.
[root@host /root] # cat /proc/pci | grep -i 3com
Ethernet controller: 3Com Unknown device (rev 120).
I don't seem to hear much of a response on bug reports does anyone respond to
Interesting spin, I hadn't thought of that. I think you're on to something.
I'm using the 3com 3c905C-TX card. Using RedHat's kernel, it's loading as a
3c90x card, and I get lots of timeouts. When I compile my own stock kernel, it
loads as a 3c59x, which is what was loading on my 6.2 system with the same
This is only my second major incident I've opened. My first incident went
quite well, this one has not been a positive experience. I'm wondering if the
$7 share price has anything to do with it. They definately seem to be ignoring
bug reports with this release, maybe they're waiting on a recount to see if the
number of bugs decreases.
I've had nothing but trouble with redhat kernels using the 3c90x kernels, if
that is your main problem download a standard 2.2.17 from ftp.us.kernel.org and
things will straighten up for you.
I have done this on the machines and everything works fine far as NFS and
ethernet issues. Unfortunately I haven't had enough time to attempt to build my
own installation disk yet, as this would fix my problem.
I just wish they would fix their ethernet driver, and NFS issues. Hoepfully
when 2.4 is released it will clean up most of the NFS issues that have plaqued
Hello, hello, hello, hello. This problem has been open since last October. Has
anyone looked at it yet? Is anyone still working here?
The 3c59x driver was not able to handle some cards when we released
7.0 that it is now able to handle. We did release a 2.2.17 errata