ethtool dies with a segmentation fault when run without any parameters against a gigabit interface on an IBM HS20 blade (but other forms of the command work): ------------------------------------------------------------- # ethtool eth0 Settings for eth0: Supported ports: [ FIBRE ] Supported link modes: 1000baseT/Half 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 1000baseT/Half 1000baseT/Full Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full 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 Segmentation fault # ethtool -i eth0 driver: tg3 version: 1.2e4 firmware-version: bus-info: 01:01.0 # ethtool -s etho speed 1000 duplex full autoneg off # ------------------------------------------------------------- Also, in the last example, note that ethtool is able to set the speed/duplex of the interface with no problems (despite other bug reports I see about problems doing so with the tg3 driver). It's only the "ethtool ethX" format that seems not to be working on the HS20 blades; on all the gigabit interfaces on all the HS20 blades on which I've tried it, it acts exactly as it did above, printing out all the relevant information and then hitting a segmentation fault. A side note: redirecting the output of "ethtool eth0" into a file results in the same segmentation violation, but the output file is empty. E.g.: # ethtool eth1 > ethout Segmentation fault # cat ethout #
Sorry, typo in the "ethtool -s etho speed 1000 duplex full autoneg off " command (it should have said eth0, not etho). In any case, it works without a problem.
So... this is not actually a bug, then? If I'm interpreting your comment incorrectly, please reopen.
The intention of my second note was solely to correct a typo. When I said "it works without a problem", I meant that the command "ethtool - s eth0 speed 1000 duplex full autoneg off" works without a problem (whereas obviously putting etho instead of eth0 wouldn't have). Yes, it is most definitely a live bug, reproducible every single time.
And to preempt any further confusion: when I said "it is most definitely a live bug" in the above note, I meant that the original bug report still obtains: that if you do "ethtool ethX" for any interface on an IBM HS20 blade, it will print the information and then die with a segmentation fault.
Is there any progress on this bug? Do you need any more info from me? It's certainly easy to reproduce.
I'm starting to think that this bug report was "tainted" by being prematurely closed, and so I should just close it and open a new one (since this one seems to have been orphaned). If not, let me know.
It should indeed be closed, as it should be fixed in the latest update. If it is not, please do open a new bug.
It should not have been closed on 2/24/2004, regardless of what's been done about it since. If it's actually fixed now, please clarify which level of the ethtool RPM fixes the problem. Thanks.
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. Please See https://access.redhat.com/support/policy/updates/errata/ If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.