From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.4) Gecko/20030922 Description of problem: After installation RHEL3 the (NET 3C59X) 3c905B, 3c905 does not work correct. Also at every reboot. I know different 10/100 PCI 3COM-cards. 3c905 (Boomerang, build in 1996) and 3c905B (Cyclon, build in 1997) works only correct if kudzu do not running at boot time. The 3c905C (Tornado build in 1999) card do not have this problem! Please see Bugzilla Bug #102685 for all details I have reported. This is not a kernel module problem. In Additional Comment #8 - #11 you can find informationen from other peoples an me that this problem is a result of running "kudzu" at boot time. This is also the reason, that installation works with all cards correct. Version-Release number of selected component (if applicable): kudzu-1.1.22-1.1 in Update 1 How reproducible: Always Steps to Reproduce: 1.Install RHEL3 Update 1 2.Boot system with running kudzu (default) 3. Actual Results: - only new cards (Tornado build 1999 and newer) works - unable to use network Expected Results: All cards should work after kudzu checks for new or change hardware at boot time Additional info:
*** This bug has been marked as a duplicate of 107389 ***
Red Hat Enterprise 3 Update 1 kudzu-1.1.22-1.1.i386.rpm. . . . Jan 11 05:50 338921 Fedora Core 1 kudzu-1.1.36-1.i386.rpm. . . . . Nov 02 19:27 336k This two rpms are identical? My report is for Red Hat Enterprise 3 and Red Hat Enterprise 3 Update 1. I do not set any options in /etc/modules.conf. If kudzu was not running at boot time autonegotiation works correct and it is possible to work in 10 MB half and also in 100 MB half or full mode with full throughput.
It's the exact same symptoms, the same code is in kudzu that could trigger it in both versions, so it is presumably the exact same problem. kudzu's call to the ethtool ioctl() seems to confuse the 3c59x hardware in some way.
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.