Bug 108115

Summary: Ethtool not working on tg3 driver
Product: Red Hat Enterprise Linux 3 Reporter: Brian Baggett <brian>
Component: ethtoolAssignee: David Miller <davem>
Status: CLOSED DUPLICATE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: ingvar, jacques.beja, jgarzik, pamadio, petrides, raimondi, tonybennett
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-03-06 07:29:49 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Brian Baggett 2003-10-27 18:45:52 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007

Description of problem:
Verified switch is hard-coded to 100 Mb / full-duplex autoneg off

Box boots...

tg3: eth0: Link is up at 100 Mbps, half duplex.
tg3: eth0: Flow control is off for TX and off for RX.

I run ...
ethtool -s eth0 autoneg off speed 100 duplex full

No effect:
tg3: eth0: Link is up at 100 Mbps, half duplex.
tg3: eth0: Flow control is off for TX and off for RX.

I strace it:
[root@elldns01 root]# strace ethtool -s eth0 speed 100 duplex full autoneg off
execve("/sbin/ethtool", ["ethtool", "-s", "eth0", "speed", "100", "duplex",
"full", "autoneg", "off"], [/* 23 vars */]) = 0
uname({sys="Linux", node="elldns01", ...}) = 0
brk(0)                                  = 0x805c644
open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=38441, ...}) = 0
old_mmap(NULL, 38441, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb75e1000
close(3)                                = 0
open("/lib/tls/libc.so.6", O_RDONLY)    = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000X\1\000"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1563240, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb75e0000
old_mmap(NULL, 1272460, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xb74a9000
old_mmap(0xb75da000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x130000) = 0xb75da000
old_mmap(0xb75dd000, 10892, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb75dd000
close(3)                                = 0
set_thread_area({entry_number:-1 -> 6, base_addr:0xb75e0740, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,
useable:1}) = 0
munmap(0xb75e1000, 38441)               = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
ioctl(3, 0x8946, 0xbfff9110)            = 0
ioctl(3, 0x8946, 0xbfff9110)            = 0
exit_group(0)                           = ?

[root@elldns01 root]# echo $?
0

Looks fine to me, except when I run dmesg:
tg3: eth0: Link is up at 100 Mbps, half duplex.
tg3: eth0: Flow control is off for TX and off for RX.

[root@elldns01 sys]# ethtool eth0
Settings for eth0:
        Supported ports: [ MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Advertised auto-negotiation: Yes
        Speed: 100Mb/s
        Duplex: Half
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: d
        Current message level: 0x000000ff (255)
        Link detected: yes

Any ideas on what I'm doing wrong here?

Version-Release number of selected component (if applicable):
ethtool-1.8-2

How reproducible:
Always

Steps to Reproduce:
See above.    

Additional info:

Comment 2 Anthony Bennett 2004-01-09 15:28:01 UTC
mii-tool can be used as a workaround, ie
mii-tool --force=100baseTx-FD

Comment 3 Brian Baggett 2004-01-12 15:11:03 UTC
I've found that mii-tool is not always reliable.  Sometimes it, like
ethtool, will not error out but simply won't work either.  I do
appreciate your mentioning it though.

Comment 5 Suzanne Hillman 2004-02-04 18:08:43 UTC
*** Bug 113982 has been marked as a duplicate of this bug. ***

Comment 7 Ingvar Hagelund 2004-02-04 21:16:33 UTC
Am I totally wrong, or is this not a duplicate of bug #106004,
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=106004 ?

Bug 106004 is not marked as resolved, but according to ES 3.0 Errata a
fix seems to be included in the latest enterprise kernel update,
RHSA-2004-017, https://rhn.redhat.com/errata/RHSA-2004-017.html

"Bugs fixed: (...) 106004 - Broadcom tg3 driver duplex won't set"

Am I missing something?

Ingvar



Comment 8 Brian Baggett 2004-02-04 21:24:52 UTC
This is for RHEL 2.1, not 3.0 so no it's not resolved (AFAIK).

Comment 9 Ingvar Hagelund 2004-02-05 13:38:11 UTC
Brian Bagget writes:

> This is for RHEL 2.1, not 3.0, so no it's not resolved (AFAIK).

When saying "this", what are your referring to? 

RHSA-2004-017 surely surely describes an update to RedHat Enterprise 3
("Updated kernel packages are now available as part of ongoing
support and maintenance of Red Hat Enterprise Linux version
3. This is the first regular update.")

Bug #108115 (this bug) is filed against RedHat Enterprise Linux
version 3. "my" bug, bug #113982 was filed against RedHat Enterprise
Linux version 3, and was marked a duplicate of this bug. The bug
marked as fixed in RHSA-2004-017, bug #106004, is filed against
taroon-beta2, the beta version of RedHat Enterprise Linux version 3.

Am I still missing something?

Ingvar


Comment 10 Brian Baggett 2004-02-05 14:01:04 UTC
This bug refers to the kernel in RHEL 2.1 *not* the kernel in RHEL
3.0.  These are two seperate kernels and the features / fixes in one
are *not* necessarily in the other.

The bug is likely fixed in RHEL3, but to my knowledge it's not fixed
in the kernel in this version of RHEL 2.1.  Follow?

Comment 11 Brian Baggett 2004-02-05 14:06:23 UTC
Ugh!  My bad.  Thought I filed this against 2.1, but it was really
3.0!  Sorry, nevermind!

We use both at my client.  Got confused.

Comment 13 Ingvar Hagelund 2004-03-04 08:37:52 UTC
Well, my question remains unanswered. I think this bug is a duplicate
of bug #106004, which seems unresolved, but is marked as resolved in
RHSA-2004-017. Am I wrong or am I right? And is it time to close bug
#106004?

Ingvar

Comment 14 David Miller 2004-03-06 07:29:49 UTC
It is the same exact bug, closing this.


Comment 15 Ernie Petrides 2005-10-06 02:15:46 UTC

*** This bug has been marked as a duplicate of 106004 ***