Hello, I revamp this thread, as I tested all combinations of cables
and duplex mode getting again the problem without any difference.
Resuming: after starting a large transfer, I soon get this in /var/log/messages
Feb 9 15:40:14 tekkaman kernel: tg3: eth0: Link is down.
Feb 9 15:40:14 tekkaman N
On Tue Jan 26 17:24:38 UTC 2010 Rick Stevens wrote:
> I'd first try a new cable from your system to your wallplate (if you're
> wired like that). If there's no improvement, I'd have your IT people
> check the wiring in the wall and on your wallplate. If it's a typical
> 66-type punchdown wallplat
On 01/26/2010 02:13 AM, Gianluca Cecchi wrote:
> On Fri Jan 22 17:48:03 UTC 2010 Rick Stevens wrote:
>> It's NetworkManager doing that to you.
> Ok, as I supposed.
>
>> Is there a reason they've set that up as fixed? Is there an autoneg
>> issue with the switch (some don't do autonegotiation corre
On Fri Jan 22 17:48:03 UTC 2010 Rick Stevens wrote:
> It's NetworkManager doing that to you.
Ok, as I supposed.
> Is there a reason they've set that up as fixed? Is there an autoneg
> issue with the switch (some don't do autonegotiation correctly).
There was a problem on older gigabit switches a
On 01/22/2010 04:08 AM, Gianluca Cecchi wrote:
> Hello,
> in f11 I had a line into /etc/rc.d/rc.local to force speed/duplex/autoneg:
> /sbin/ethtool -s eth0 speed 100 duplex full autoneg off>> /tmp/ethtool.log
> 2>&1
>
> In F12 I see that this setting is not maintained.
> After I log in in Gnome
Hello,
in f11 I had a line into /etc/rc.d/rc.local to force speed/duplex/autoneg:
/sbin/ethtool -s eth0 speed 100 duplex full autoneg off >> /tmp/ethtool.log 2>&1
In F12 I see that this setting is not maintained.
After I log in in Gnome I see that:
[r...@tekkaman ~]# ethtool eth0
Settings for eth0
