Hide Forgot
Description of problem: On a PRIMERGY RX300S7 (Romley/Patsburg system with onboard Powerville NIC), wake-on-lan can't be activated with the RHEL6.1 native igb driver 3.0.6-k2. Version-Release number of selected component (if applicable): 2.6.32-131.0.15.el6.x86_64, igb 3.0.6-k2 How reproducible: always Steps to Reproduce: 1. run "ethtool eth2" Actual results: Supports Wake-on: d Expected results: Supports Wake-on: pumbg Additional info: The driver igb 3.0.19 from e1000.sourceforge.net enables WOL on this port successfully.
Created attachment 510903 [details] sosreport
The weird thing is that I can see no difference in the WOL logic between igb 3.0.6-k2 and igb 3.0.19. Mainly the driver looks at certain bit in the EEPROM (NVM_INIT_CONTROL3_PORT_A = 24 for Port A and NVM_INIT_CONTROL3_PORT_B = 14 for port B, bitmask 0x400). The eeprom registers are 16bit wide and indexing is also by 16-but words. I checked the eeprom settings and they are the same for both drivers. 0x0000 00 19 99 7e fc 63 00 08 ff ff 30 09 ff ff ff ff 0x0010 31 31 35 30 2f 60 ce 11 34 17 21 15 86 80 a7 b3 0x0020 ff ff ff ff 80 60 81 00 6d eb 50 00 00 4c 17 0a 0x0030 bf 3d 00 70 0a 1a 26 34 83 07 a6 10 00 02 02 06 0x0040 04 00 47 25 00 00 ff ff 81 04 f1 01 20 15 79 0f 0x0050 80 1c 1c 00 00 00 04 14 00 00 00 00 00 10 ff ff register 14 (offset 28, control port B) is eb6d -> WOL off ! register 24 (offset 48, control port A) is 0481 -> WOL on ! This would suggest that the 3.0.19 driver somehow enables WOL on port B although it is disabled in the FW. But perhaps I got something wrong with the registers offsets. I need to check this again.
Please have Intel engineers check this problem and my assessment.
Created attachment 511175 [details] proposed patch I think I found the difference between the OEM and upstream drivers. It's a trivial patch. Intel, please verify.
Verified that the patch in comment #5 indeed solves the problem.
We request a 6.1.z errata with the patch from comment #5. I also just posted this patch upstream to netdev.org.
Upstream submission here: http://marc.info/?l=linux-netdev&m=130978970530745&w=2
Yes, I agree with the fix. Thanks for the catch. Will ack the upstream patch.
Stefan, please initiate a 6.1.z release. Given Carolyn's ACK and the simplicity of the patch, that shouldn't be a big problem any more.
The patch needs to go into 6.2 first and can be backported to 6.1.z afterwards.
OK, add it to 6.2, please. Do you expect me to open a new BZ?
No, I'll make sure it is proposed for 6.1.z. Thanks for your work Martin.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
The fix will be provided as part of the RHEl6.2 igb driver update (#694211).
Opening Stefan's comment above to Martin. So do we use this bug for the 6.1.z stream request or clone it first and close this bug as a DUP of bug 694211?
As noted elsewhere, we agree with Stefan that backporting the 6.2 driver into 6.1.z is not a good idea. We'd rather propose to release a 6.1.z with just the patch from comment #8 applied.
Larry, for the sake of trackability please clone and mark this as DUP. Thanks!
Hmm, there's a test kernel for 5.8 available now on bug #718988. I'd rather retest for RHEL6.x because that's where the bug was originally reported.
*** This bug has been marked as a duplicate of bug 694211 ***
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Some system vendors desired the Wake-on-Lan capability to be accessible on more than the first on-board port of an Intel i350 network adapter. Due to a bug in the igb driver, this was not possible. This bug has been fixed and igb now honors the EEPROM setting for the second port.