From: Ben Hutchings <hidden> Date: 2012-10-19 01:30:24
Teodor MICU reported that:
On Broadcom NX II rev < 12 network interfaces it's not possible to activate
WoL using 'ethtool' (it can only be done from the MBA Configuration Menu).
However, even if "Pre-boot Wake On LAN" was enabled 'ethtool' doesn't
see this change:
Supports Wake-on: d
Wake-on: d
I've just tested that WoL works for this system.
He's been using Linux 2.6.32 and Linux 3.2, but there don't seem to have
been any later changes to WoL support in bnx2.
Is there any possibility that this could be fixed?
Ben.
--
Ben Hutchings
Anthony's Law of Force: Don't force it, get a larger hammer.
On Fri, 2012-10-19 at 02:30 +0100, Ben Hutchings wrote:
Teodor MICU reported that:
quoted
On Broadcom NX II rev < 12 network interfaces it's not possible to activate
WoL using 'ethtool' (it can only be done from the MBA Configuration Menu).
However, even if "Pre-boot Wake On LAN" was enabled 'ethtool' doesn't
see this change:
Supports Wake-on: d
Wake-on: d
I've just tested that WoL works for this system.
He's been using Linux 2.6.32 and Linux 3.2, but there don't seem to have
been any later changes to WoL support in bnx2.
Teodor MICU, please provide lspci -vvv and ethtool -i eth? on the
Broadcom bnx2 device. Thanks.
It is 5708 B1, and due to some hardware limitations, ethtool initiated
WoL is not supported. Here's the code fragment in bnx2.c:
if ((CHIP_ID(bp) == CHIP_ID_5708_A0) ||
(CHIP_ID(bp) == CHIP_ID_5708_B0) ||
(CHIP_ID(bp) == CHIP_ID_5708_B1) ||
!(REG_RD(bp, BNX2_PCI_CONFIG_3) & BNX2_PCI_CONFIG_3_VAUX_PRESET)) {
bp->flags |= BNX2_FLAG_NO_WOL;
bp->wol = 0;
}
It is 5708 B1, and due to some hardware limitations, ethtool initiated
WoL is not supported.
[...]
Well we knew that much! Is the problem that the system firmware 'owns'
the WoL control registers so the host can't safely change them? Is it
possible to *read* the WoL configuration, if not to change it?
(If even that is not possible, the correct thing to do might be for
ETHTOOL_GWOL to return 'don't know' (EOPNOTSUPP) for this device. But
since ethtool_ops::get_wol (and various other operations) can't return
an error, that would require you to define a separate instance of
ethtool_ops with get_wol = NULL. I should look at fixing that...)
Ben.
--
Ben Hutchings
Humour is the best antidote to reality.
On Tue, 2012-10-23 at 02:45 +0100, Ben Hutchings wrote:
Well we knew that much! Is the problem that the system firmware 'owns'
the WoL control registers so the host can't safely change them? Is it
possible to *read* the WoL configuration, if not to change it?
It's a hardware problem and I don't understand all the details. There
is an internal PCIX to PCIE bridge on this chip and it gates the NIC's
PME event. During S5 reset, the bridge gets reset by the BIOS and the
WoL setting done by the driver will no longer work. Newer chip revs
have fixed the problem in hardware.
The driver reads the pre-boot WoL setting from NVRAM and it becomes the
ethtool WoL default setting. Apparently, it is also not working in this
case. I know that it doesn't work on some LOM designs as the setting is
actually in BIOS NVRAM as opposed to NIC NVRAM.
From: Ben Hutchings <hidden> Date: 2012-10-24 14:23:20
On Mon, 2012-10-22 at 19:18 -0700, Michael Chan wrote:
On Tue, 2012-10-23 at 02:45 +0100, Ben Hutchings wrote:
quoted
Well we knew that much! Is the problem that the system firmware 'owns'
the WoL control registers so the host can't safely change them? Is it
possible to *read* the WoL configuration, if not to change it?
It's a hardware problem and I don't understand all the details. There
is an internal PCIX to PCIE bridge on this chip and it gates the NIC's
PME event. During S5 reset, the bridge gets reset by the BIOS and the
WoL setting done by the driver will no longer work. Newer chip revs
have fixed the problem in hardware.
The driver reads the pre-boot WoL setting from NVRAM and it becomes the
ethtool WoL default setting. Apparently, it is also not working in this
case. I know that it doesn't work on some LOM designs as the setting is
actually in BIOS NVRAM as opposed to NIC NVRAM.
Thanks for the explanation. This does seem to be unfixable, then,
unfortunately.
Ben.
--
Ben Hutchings
Never attribute to conspiracy what can adequately be explained by stupidity.