Description of problem: The MTU value selected by default for Silicon Integrated Systems [SiS] 190 Gigabit Ethernet Adapter is wrong and has to be manually changed to fix networking. Fixed by adding the following line to /etc/rc.local ifconfig eth0 mtu 1492 Version-Release number of selected component (if applicable): Figured this out with 9-Preview installed from CDs, propably caused my problems with trying to do a netinstall for 9-Beta and rawhide earlier. How reproducible: Always Steps to Reproduce: 1. Install Fedora 9 2. 3. Actual results: The default MTU for the ethernet device is wrong, thus downloading data over network fails with 99% of cases. Expected results: The default MTU for the ethernet device is correct and downloading data over network works. Additional info: No idea under which "component" this belongs to really.
Created attachment 303052 [details] lspci -vvv output
Created attachment 303053 [details] lsmod output
Created attachment 303054 [details] dmesg output
Janne: you should probably put MTU=1492 into your /etc/sysconfig/network-scripts/ifcfg-eth0 file. This is probably a situation unique to your network; an MTU of 1492 is usually seen in VPN setups or other cases where the traffic is again wrapped by VPN or 802.1x or whatever.
Thanks for telling me the correct place for setting the MTU.. Anyways, this is not a VPN setup or anything similar. Just a "normal" lan behind a nat router. I have never had to set MTU on any of the other boxes I have in here, no matter if they were running linux, freebsd, openbsd, macosx, windows, skyos or anything else. Also the same NIC worked fine with xp and kubuntu without any MTU settings. Considering the above this is most propably a bug with the kernel module, but since I only have a slight idea of what MTU is and none about how to track the bug, I cannot be certain of the source. Also since I found the MTU fix from google by searching for 'linux "Silicon Integrated Systems [SiS] 190 Gigabit Ethernet Adapter"' and several other people were having problems with it, I doubt this is in any way related to my network.
could be path MTU discovery not working or something like that? that's more of a TCP stack issue though.
Just checked and the other linux boxes atleast use MTU 1500 in the network, why this one now requires 1492 is beyond my ability to comprehend. Also as I stated in the initial additional info, I don't really have a clue of under which "component" this should've been reported under.