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.
Steps to Reproduce:
1. Install Fedora 9
The default MTU for the ethernet device is wrong, thus downloading data over
network fails with 99% of cases.
The default MTU for the ethernet device is correct and downloading data over
No idea under which "component" this belongs to really.
Created attachment 303052 [details]
lspci -vvv output
Created attachment 303053 [details]
Created attachment 303054 [details]
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
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.