I am currently working with an Intel Pro/1000 PT in a Kontron KISS 2U (Motherboard Kontron PCI760). OS is Linux if that matters.
Upon connecting the power to the system a physical link is established to the next switch on the topmost ethernet port even though the computer has not even been powered up.
Under linux I cannot switch this PHY to complete suspend; the driver insists on the NIC having Wake on Lan activated so that I cannot shut down the (physical) link.
I would like to change the behavior such that the physical link is only present when really activated.
I have disabled all AMT related settings in the BIOS. The IBAUtil tells me that the respective port does not support Wake-on-Lan (but another port would do which I have disabled): I have however not been able to change the behavior.
Any ideas on how to completely disable the PHY?
I just tried: it does not help.
IBAUtil now reports "FLASH disabled". I however still get the physical link as soon as the power cable is plugged in and before the power button is pressed and the system starts up.
hmm strange, i have one here the phy link on the 1st port is on but system never auto-power up, have you tried the ethtool -wol d ethx (x refers to the 1st port of your quad port).
or have you tried connecting to another switch, the machine/switch you're connecting to might be broadcasting magic packet
looking into Intel adapter file, the only port that supports WOL for quad port is port# 1
I could perform "ethtool eth0 -s wol d" which actually switched the ethtool output from "g" to "d".
After performing this change the respective port can be completely shut down (and back up again) in this session.
After a power cycle the respective flag however is back at "g" again.
So this would be one part of the solution.
Any idea on how to make this persistant? I actually want to make sure that if the system is down (powered off and will not be powered up as wake-on-lan is not supported) other network components will report "link down".
Having this said: the other components I am using for test purposes are "really stupid" and/or full under my own control.
looks like when system restarted it went back to enabling the wol feature, another suggestion if it's not too inconvenient, try running ibautil -nic=all -fe to enable the pxe then run another command ibautil -nic=all -wold to disable the wol from the chip then went to the OS and run the ethtool -wol d again.
Whatever I do, it seems that the card goes back to WOL. I have tried the sequence you proposed with several variations. Nevertheless after a reboot (with or without shutting down the power supply) the WOL flags is back...
ethtool would offer me a hexdump of the respective flash block (and the option to edit it, for what its worth), but I rather would not play around in undocumented bits...
A DOS utility, IBAUtil.exe, is available to disable the Wake on LAN in the adapters flash memory. That should take care of any Wake on LAN issues across reboots. You can use the -WOLDISABLE to disable Wake on LAN.
If you have the CD that came with your adapter, you can find IBAUtil.exe in /APPS/BOOTAGNT. If you do not have the CD, then download http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=8242&lang=eng Intel® Boot Agent for Intel® Network Adapters.
See ibautil.txt for information about the utility.
I hope this helps.
I have indeed used the IBAUtil (under freedos) which shows 5 Intel Ethernet Ports: one on board and four on the quad card.
For both the on-board NIC and the first port of the quad card it shows "NO" in the WOL column (the other ports show N/A).
Nevertheless as soon as the system is booted (before even the Linux kernel is loaded) a link comes up.
Could this be a question of the BIOS (AMIBIOS if that matters) rather than of the card itself??
IBAUtil reports version 4.12.02.24
Sorry I did not take the time to read the whole thread yesterday. I would have seen that you already tried using the utility.
I suspect that there is no way to keep the physical layer link from coming up because the adapter receives power as soon as you power on the computer. I do not know of any way to stop this from happening.
Since I posted yesterday, I kept thinking about this issue wondering why you could not disable the link on the top port of your adapter. Today, I put an Intel(R) PRO/1000 PT Quad Port Server Adapter in my desktop PC. Like you, I observed link on the top port as soon as the cable was plugged in.
Then I booted to DOS and ran ibautil.exe. WOL for the top port, NIC 2 in my desktop, showed Yes. I ran ibautil -NIC=02 -WOLD. The WOL status changed to No. Now I do not show any link until I power on the computer. I used IBAUtil version 4.12.02.24. This is the same version of the utility that you reported using.
Alll of the behavior I described above is what I expected to happen. As you pointed out, your experience is different. Could we be using different versions of the adapter?
Would you give me some part number information from your adapter so I can check for differences? On the component side of the board is a label with a MAC address, manufacturing code, and part number. The part number will be something like D47316-003. What is the part number on your adapter?
On the back side of the board is a label with the board name and 2 other numbers. On my board those numbers are 882125 and EXPI9494PTBLK. What are the numbers on your board?
The part number on the top side is D47316-004, back side shows EXPI9404PTBLK/882125. It hence may be of a slightly later revision.
Unfortunately the behavior still persists: Even though WOL is disabled according to IBAUtil, the link comes up as soon as the power cable is plugged in before actually powering up the system.
What I find even more disturbing is that after boot into Linux the respective ethtool and driver both are of the opinion that Wake-on-Lan would be enabled as "WAKE_MAGIC" or "WUFC_MAG". (Well, actually it is the driver's opinion, ethtool just reports the driver's point of view :-)
So much the code in the driver seems to be consistent in quering the configuration bits in the NVRAM.
Ok, after a respective search through the download area it seems that the respective manuals are not under NDA, yet quite some pages of documentation and some source code has to be read to understand what is actually going on.