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:
mii-tool can be used as a workaround, ie mii-tool --force=100baseTx-FD
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.
*** Bug 113982 has been marked as a duplicate of this bug. ***
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
This is for RHEL 2.1, not 3.0 so no it's not resolved (AFAIK).
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
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?
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.
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
It is the same exact bug, closing this.
*** This bug has been marked as a duplicate of 106004 ***