Hide Forgot
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 be appreciated. Thanks, Bill Stephens bill.stephens@fritolay.com
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. -Bill
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? Thanks, Bill Stephens
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). Any ideas?? I don't seem to hear much of a response on bug reports does anyone respond to these?
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 card. 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. -Bill
Bill, 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 2.2.x.
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 kernel recently.