When setting up 1.4_rc2 earlier this morning I could not get networking to work. After issuing ifconfig eth0 192.168.1.11 broadcast 192.168.1.255 netmask 255.255.255.0 route add default gw 192.168.1.10 netmask 0.0.0.0 metric 1 It appeared that my network was up and running (ifconfig output was correct). But all traffic (eg ping requests to my LAN gateway or domains) did not appear to find a valid path through eth0. Instead the actaul traffic values seemed to be registering on lo (the localhost device). I now have rc2 installed but I had to boot from an old 1.2 CD and then use the 1.4_rc2 stage 1 tar ball instead of the 1.2 tar ball. Networking worked perfectly from the 1.2 CD I am using the 8139too driver for a SMC Ultra EX NIC which is working (as I am writting this from rc2). This problem also exists on 1.4_rc1 LiveCD's (for i686) as I first went back to it before the 1.2 CD. I am waiting for a few things to finish emerging and then I will be testing this with a few other cards (tulip driver's) and see if the problem exists there aswell.
OK, we'll be awaiting the results of your additional testing.
Sorry for the delay, my machine became LAN mission critical for a while but now I have had some time to do some futher tests and have found the same problem using the following drivers... 8139too (original) tulip 8139c smc-ultra 3c501 All cards work under installed systems with the above drivers and still function at maximum speed after being moved between test machines.
Hmm..that's strange as it happens with a wide range of drivers.. maybe have a look at bug #8495..it's a similar situation. Which kernels do you run on your installed systems?
Installed systems (I have three, two gentoo's and one debian). The first Gentoo is running 2.4.18 (vanilla-sources) no patches whatsoever contains the 3Com card. The second Gentoo is 1.4_rc2 running the latest gentoo-source from the 2.4 tree (19-r10) and that machine (this one) runs the 8139too card. I also tried a different Realtek card on this machine for the 8139c driver. The debian box, which I tried booting with the x86 stage1 liveCD has two Netgear cards (tulip drivers) and a SMC Ultra card -- LAN gateway for two subnets. The debian box runs a kernel.org download of the 2.4.20 kernel. That bug #8495 seems fairly similar, am going to reboot now and see if the noapci options work, will post reply in another few minutes to resolve that issue.
OK ive just been playing around passing noapic or acpi=no to the kernel, on both my 1.4_rc2 machine and the Debian machine and in both cases the results were still the same. I did some log reading and found that there was this message reported on both machines aswell, only after I tried pinging a network machine. NETDEV WATCHDOG: eth0: Transmit Timeout. Possible thoughts on the issue are http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.0/1613.html
have you tried the newest stages?
Finally found the problem and the solution. The 1.4_rc2 candidate CD actually needs acpi=off passed to it, not acpi=no this disables acpi during the install, and the networking actually works. Bug can be CLOSED now I think, it works with all the previousl;y listed cards and drivers with acpi=off passed to the kernel. NOTE: In the future, the acpi=X option may change, if off does NOT work then maybe you should try no :)
db fix
Moving these so we can remove the "Install CD" component from "Gentoo Linux". I apologize to everyone for this spam, but according to the bugzilla developers, this is the only reasonable way to do this.
