* WoL broken in r8169.c since kernel 4.19
@ 2019-01-12 20:08 Marc Haber
2019-01-12 20:28 ` Heiner Kallweit
0 siblings, 1 reply; 36+ messages in thread
From: Marc Haber @ 2019-01-12 20:08 UTC (permalink / raw)
To: Alex Xu, Anthony Wong, Azat Khuzhin, David S. Miller,
Hans de Goede, Heiner Kallweit, Jian-Hong Pan, Kai-Heng Feng,
Maciej S. Szmigiero
Hi,
I am writing to all people who have commits in r8169.c between the v4.18
and v4.19 tags in the Linux kernel. Please ignore as appropriate. If
you'd prefer that to be on a mailing list, please indicate on which list
you want to have that, and I'll resend.
My desktop copmuter has the following network interface:
06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
Subsystem: ASUSTeK Computer Inc. P8P67 and other motherboards
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 17
NUMA node: 0
Region 0: I/O ports at e800 [size=256]
Region 2: Memory at fdfff000 (64-bit, prefetchable) [size=4K]
Region 4: Memory at fdff8000 (64-bit, prefetchable) [size=16K]
Capabilities: <access denied>
Kernel driver in use: r8169
Kernel modules: r8169
I regularly buíld a VPN tunnel to my local network from 'on the road'
and use WoL to wake up the desktop box when I need it.
Since kernel 4.19, that does not work any more, the desktop remains
suspended when I send it a magic packet. This still applies to 4.20.1,
and it still works with any 4.18 kernel.
I transplanted the 4.18 r8169.c into 4.20.1, and then WoL worked again.
Thus, the issue must have been introduced between 4.18 and 4.19.
Does anybody of you have an idea how to find the issue in the 4.20 code?
I have seen 648458fe97b5c0630435fa2b2cd65ba57ceb18e0 in 4.19.14 and
tried applying it to 4.20.1 (was necessary to do it manually because the
patch wouldn't apply), but that one didn't help.
4.19.14, which has a WoL-related patch applied, doesn't wake on LAN as
well.
I tried bisecting for r8169.c between v4.18 and v4.19, but right the
first step didn't even boot far enough for the disk password prompt, so
I am at a loss here.
Any ideas?
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-01-12 20:08 WoL broken in r8169.c since kernel 4.19 Marc Haber
@ 2019-01-12 20:28 ` Heiner Kallweit
2019-01-12 20:44 ` Heiner Kallweit
2019-01-13 16:01 ` Marc Haber
0 siblings, 2 replies; 36+ messages in thread
From: Heiner Kallweit @ 2019-01-12 20:28 UTC (permalink / raw)
To: Marc Haber, Alex Xu, Anthony Wong, Azat Khuzhin, David S. Miller,
Hans de Goede, Jian-Hong Pan, Kai-Heng Feng, Maciej S. Szmigiero
Cc: netdev
On 12.01.2019 21:08, Marc Haber wrote:
> Hi,
>
> I am writing to all people who have commits in r8169.c between the v4.18
> and v4.19 tags in the Linux kernel. Please ignore as appropriate. If
> you'd prefer that to be on a mailing list, please indicate on which list
> you want to have that, and I'll resend.
>
It should be cc'ed to the netdev mailing list, as listed in MAINTAINERS.
> My desktop copmuter has the following network interface:
>
> 06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
> Subsystem: ASUSTeK Computer Inc. P8P67 and other motherboards
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0, Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 17
> NUMA node: 0
> Region 0: I/O ports at e800 [size=256]
> Region 2: Memory at fdfff000 (64-bit, prefetchable) [size=4K]
> Region 4: Memory at fdff8000 (64-bit, prefetchable) [size=16K]
> Capabilities: <access denied>
> Kernel driver in use: r8169
> Kernel modules: r8169
>
Unfortunately there's different chip versions with the same description.
Please provide the result of "dmesg | grep XID".
> I regularly buíld a VPN tunnel to my local network from 'on the road'
> and use WoL to wake up the desktop box when I need it.
>
> Since kernel 4.19, that does not work any more, the desktop remains
> suspended when I send it a magic packet. This still applies to 4.20.1,
> and it still works with any 4.18 kernel.
>
WoL works perfectly fine here with r8169 from runtime-suspend and
from S3. How do you enable WoL? And which WoL method do you use
(magic packet or ..) ?
Please provide a register dump (ethtool -d <if>).
> I transplanted the 4.18 r8169.c into 4.20.1, and then WoL worked again.
> Thus, the issue must have been introduced between 4.18 and 4.19.
>
> Does anybody of you have an idea how to find the issue in the 4.20 code?
>
> I have seen 648458fe97b5c0630435fa2b2cd65ba57ceb18e0 in 4.19.14 and
> tried applying it to 4.20.1 (was necessary to do it manually because the
> patch wouldn't apply), but that one didn't help.
>
> 4.19.14, which has a WoL-related patch applied, doesn't wake on LAN as
> well.
>
> I tried bisecting for r8169.c between v4.18 and v4.19, but right the
> first step didn't even boot far enough for the disk password prompt, so
> I am at a loss here.
>
> Any ideas?
>
> Greetings
> Marc
>
>
Heiner
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-01-12 20:28 ` Heiner Kallweit
@ 2019-01-12 20:44 ` Heiner Kallweit
2019-01-13 16:01 ` Marc Haber
1 sibling, 0 replies; 36+ messages in thread
From: Heiner Kallweit @ 2019-01-12 20:44 UTC (permalink / raw)
To: Marc Haber; +Cc: netdev
On 12.01.2019 21:28, Heiner Kallweit wrote:
> On 12.01.2019 21:08, Marc Haber wrote:
>> Hi,
>>
>> I am writing to all people who have commits in r8169.c between the v4.18
>> and v4.19 tags in the Linux kernel. Please ignore as appropriate. If
>> you'd prefer that to be on a mailing list, please indicate on which list
>> you want to have that, and I'll resend.
>>
> It should be cc'ed to the netdev mailing list, as listed in MAINTAINERS.
>
>> My desktop copmuter has the following network interface:
>>
>> 06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
>> Subsystem: ASUSTeK Computer Inc. P8P67 and other motherboards
>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>> Latency: 0, Cache Line Size: 64 bytes
>> Interrupt: pin A routed to IRQ 17
>> NUMA node: 0
>> Region 0: I/O ports at e800 [size=256]
>> Region 2: Memory at fdfff000 (64-bit, prefetchable) [size=4K]
>> Region 4: Memory at fdff8000 (64-bit, prefetchable) [size=16K]
>> Capabilities: <access denied>
>> Kernel driver in use: r8169
>> Kernel modules: r8169
>>
> Unfortunately there's different chip versions with the same description.
> Please provide the result of "dmesg | grep XID".
>
>> I regularly buíld a VPN tunnel to my local network from 'on the road'
>> and use WoL to wake up the desktop box when I need it.
>>
>> Since kernel 4.19, that does not work any more, the desktop remains
>> suspended when I send it a magic packet. This still applies to 4.20.1,
>> and it still works with any 4.18 kernel.
>>
> WoL works perfectly fine here with r8169 from runtime-suspend and
> from S3. How do you enable WoL? And which WoL method do you use
> (magic packet or ..) ?
> Please provide a register dump (ethtool -d <if>).
>
Sorry, missed that you mentioned "magic packet". So one question is
answered.
Do you want to wake the system from S3 or S5? If waking from S5 fails,
does waking from S3 work?
>> I transplanted the 4.18 r8169.c into 4.20.1, and then WoL worked again.
>> Thus, the issue must have been introduced between 4.18 and 4.19.
>>
>> Does anybody of you have an idea how to find the issue in the 4.20 code?
>>
>> I have seen 648458fe97b5c0630435fa2b2cd65ba57ceb18e0 in 4.19.14 and
>> tried applying it to 4.20.1 (was necessary to do it manually because the
>> patch wouldn't apply), but that one didn't help.
>>
>> 4.19.14, which has a WoL-related patch applied, doesn't wake on LAN as
>> well.
>>
>> I tried bisecting for r8169.c between v4.18 and v4.19, but right the
>> first step didn't even boot far enough for the disk password prompt, so
>> I am at a loss here.
>>
>> Any ideas?
>>
>> Greetings
>> Marc
>>
>>
> Heiner
>
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-01-12 20:28 ` Heiner Kallweit
2019-01-12 20:44 ` Heiner Kallweit
@ 2019-01-13 16:01 ` Marc Haber
2019-01-13 16:19 ` Heiner Kallweit
2019-01-26 14:08 ` Heiner Kallweit
1 sibling, 2 replies; 36+ messages in thread
From: Marc Haber @ 2019-01-13 16:01 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Alex Xu, Anthony Wong, Azat Khuzhin, David S. Miller,
Hans de Goede, Jian-Hong Pan, Kai-Heng Feng, Maciej S. Szmigiero,
netdev
On Sat, Jan 12, 2019 at 09:28:48PM +0100, Heiner Kallweit wrote:
> On 12.01.2019 21:08, Marc Haber wrote:
> > I am writing to all people who have commits in r8169.c between the v4.18
> > and v4.19 tags in the Linux kernel. Please ignore as appropriate. If
> > you'd prefer that to be on a mailing list, please indicate on which list
> > you want to have that, and I'll resend.
> >
> It should be cc'ed to the netdev mailing list, as listed in MAINTAINERS.
I have bounced the original message there. Sorry for missing that, I was
not aware that the MAINTAINERS file goes down on a single driver level.
> > My desktop copmuter has the following network interface:
> >
> > 06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
> > Subsystem: ASUSTeK Computer Inc. P8P67 and other motherboards
> > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
> > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> > Latency: 0, Cache Line Size: 64 bytes
> > Interrupt: pin A routed to IRQ 17
> > NUMA node: 0
> > Region 0: I/O ports at e800 [size=256]
> > Region 2: Memory at fdfff000 (64-bit, prefetchable) [size=4K]
> > Region 4: Memory at fdff8000 (64-bit, prefetchable) [size=16K]
> > Capabilities: <access denied>
> > Kernel driver in use: r8169
> > Kernel modules: r8169
> >
> Unfortunately there's different chip versions with the same description.
> Please provide the result of "dmesg | grep XID".
[1/5004]mh@fan:~ $ dmesg | grep XID
[ 2.671004] r8169 0000:06:00.0 eth0: RTL8168evl/8111evl, 54:04:a6:82:21:00, XID 2c900800, IRQ 29
> > I regularly buíld a VPN tunnel to my local network from 'on the road'
> > and use WoL to wake up the desktop box when I need it.
> >
> > Since kernel 4.19, that does not work any more, the desktop remains
> > suspended when I send it a magic packet. This still applies to 4.20.1,
> > and it still works with any 4.18 kernel.
> >
> WoL works perfectly fine here with r8169 from runtime-suspend and
> from S3. How do you enable WoL? And which WoL method do you use
> (magic packet or ..) ?
I do enable WOL via systemd-networkd:
[7/5009]mh@fan:~ $ cat /etc/systemd/network/10-lanc0.link
[Match]
MACAddress=54:04:a6:82:21:00
[Link]
Name=lanc0
WakeOnLan=magic
and I wake up the box by calling
sudo etherwake -i int182 54:04:a6:82:21:00
on the router. int182 is the interface name of the correct interface,
this is proven correct by the fact that the box wakes up just fine with
older version of the driver.
> Please provide a register dump (ethtool -d <if>).
The register dump is here (obtained with 4.20.1 with the r8169.c from
4.18):
[5/5008]mh@fan:~ $ sudo ethtool -d lanc0
RealTek RTL8168evl/8111evl registers:
--------------------------------------------------------
0x00: MAC Address 54:04:a6:82:21:00
0x08: Multicast Address Filter 0xffffffff 0xffffffff
0x10: Dump Tally Counter Command 0x20f36000 0x00000004
0x20: Tx Normal Priority Ring Addr 0x14994000 0x00000004
0x28: Tx High Priority Ring Addr 0x00000000 0x00000000
0x30: Flash memory read/write 0x00000000
0x34: Early Rx Byte Count 0
0x36: Early Rx Status 0x00
0x37: Command 0x0c
Rx on, Tx on
0x3C: Interrupt Mask 0x803f
SERR LinkChg RxNoBuf TxErr TxOK RxErr RxOK
0x3E: Interrupt Status 0x0000
0x40: Tx Configuration 0x2f900f80
0x44: Rx Configuration 0x0002c70f
0x48: Timer count 0x00000000
0x4C: Missed packet counter 0x000000
0x50: EEPROM Command 0x10
0x51: Config 0 0x00
0x52: Config 1 0xcf
0x53: Config 2 0xbd
0x54: Config 3 0x60
0x55: Config 4 0x51
0x56: Config 5 0x02
0x58: Timer interrupt 0x00000000
0x5C: Multiple Interrupt Select 0x0000
0x60: PHY access 0x8005c1e1
0x64: TBI control and status 0x84321043
0x68: TBI Autonegotiation advertisement (ANAR) 0xf02c
0x6A: TBI Link partner ability (LPAR) 0x0000
0x6C: PHY status 0x93
0x84: PM wakeup frame 0 0x00000000 0x00000000
0x8C: PM wakeup frame 1 0x00000000 0x02fcb1e5
0x94: PM wakeup frame 2 (low) 0x6603216b 0xaab879be
0x9C: PM wakeup frame 2 (high) 0x41bee65e 0x800a2260
0xA4: PM wakeup frame 3 (low) 0x05280748 0x187ea050
0xAC: PM wakeup frame 3 (high) 0x8463e510 0x84630000
0xB4: PM wakeup frame 4 (low) 0xffffffff 0xffffffff
0xBC: PM wakeup frame 4 (high) 0x00000000 0x00000000
0xC4: Wakeup frame 0 CRC 0x0000
0xC6: Wakeup frame 1 CRC 0x0000
0xC8: Wakeup frame 2 CRC 0x0000
0xCA: Wakeup frame 3 CRC 0x0000
0xCC: Wakeup frame 4 CRC 0x0000
0xDA: RX packet maximum size 0x4000
0xE0: C+ Command 0x20e1
VLAN de-tagging
RX checksumming
0xE2: Interrupt Mitigation 0x5151
TxTimer: 5
TxPackets: 1
RxTimer: 5
RxPackets: 1
0xE4: Rx Ring Addr 0x14995000 0x00000004
0xEC: Early Tx threshold 0x27
0xF0: Func Event 0x00400030
0xF4: Func Event Mask 0x00000000
0xF8: Func Preset State 0x000303ff
0xFC: Func Force Event 0x00000000
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-01-13 16:01 ` Marc Haber
@ 2019-01-13 16:19 ` Heiner Kallweit
2019-01-22 16:10 ` Marc Haber
2019-01-26 14:08 ` Heiner Kallweit
1 sibling, 1 reply; 36+ messages in thread
From: Heiner Kallweit @ 2019-01-13 16:19 UTC (permalink / raw)
To: Marc Haber; +Cc: netdev
On 13.01.2019 17:01, Marc Haber wrote:
> On Sat, Jan 12, 2019 at 09:28:48PM +0100, Heiner Kallweit wrote:
>> On 12.01.2019 21:08, Marc Haber wrote:
>>> I am writing to all people who have commits in r8169.c between the v4.18
>>> and v4.19 tags in the Linux kernel. Please ignore as appropriate. If
>>> you'd prefer that to be on a mailing list, please indicate on which list
>>> you want to have that, and I'll resend.
>>>
>> It should be cc'ed to the netdev mailing list, as listed in MAINTAINERS.
>
> I have bounced the original message there. Sorry for missing that, I was
> not aware that the MAINTAINERS file goes down on a single driver level.
>
The netdev mailing list is used for everything in the network subsystem.
>>> My desktop copmuter has the following network interface:
>>>
>>>
>> Unfortunately there's different chip versions with the same description.
>> Please provide the result of "dmesg | grep XID".
>
> [1/5004]mh@fan:~ $ dmesg | grep XID
> [ 2.671004] r8169 0000:06:00.0 eth0: RTL8168evl/8111evl, 54:04:a6:82:21:00, XID 2c900800, IRQ 29
>
>>> I regularly buíld a VPN tunnel to my local network from 'on the road'
>>> and use WoL to wake up the desktop box when I need it.
>>>
>>> Since kernel 4.19, that does not work any more, the desktop remains
>>> suspended when I send it a magic packet. This still applies to 4.20.1,
>>> and it still works with any 4.18 kernel.
>>>
>> WoL works perfectly fine here with r8169 from runtime-suspend and
>> from S3. How do you enable WoL? And which WoL method do you use
>> (magic packet or ..) ?
>
> I do enable WOL via systemd-networkd:
> [7/5009]mh@fan:~ $ cat /etc/systemd/network/10-lanc0.link
> [Match]
> MACAddress=54:04:a6:82:21:00
>
> [Link]
> Name=lanc0
> WakeOnLan=magic
>
> and I wake up the box by calling
>
> sudo etherwake -i int182 54:04:a6:82:21:00
>
> on the router. int182 is the interface name of the correct interface,
> this is proven correct by the fact that the box wakes up just fine with
> older version of the driver.
>
>> Please provide a register dump (ethtool -d <if>).
>
> The register dump is here (obtained with 4.20.1 with the r8169.c from
> 4.18):
> [5/5008]mh@fan:~ $ sudo ethtool -d lanc0
> RealTek RTL8168evl/8111evl registers:
> --------------------------------------------------------
> [..]
>
> Greetings
> Marc
>
I removed most people from To/Cc because I think for now they aren't needed
and our conversation would just bother them.
I assume you want to wake the system from S5 (poweroff).
Does is wake from S3 (suspend-to-RAM) ? You can trigger this with
"systemctl suspend".
Any difference if you enable WoL manually via ethtool "ethtool -s <if> wol g" ?
And a basic question: Once you have powered off your system, is network
LED on PC and router on?
Heiner
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-01-13 16:19 ` Heiner Kallweit
@ 2019-01-22 16:10 ` Marc Haber
2019-01-22 18:47 ` Heiner Kallweit
0 siblings, 1 reply; 36+ messages in thread
From: Marc Haber @ 2019-01-22 16:10 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: netdev
On Sun, Jan 13, 2019 at 05:19:41PM +0100, Heiner Kallweit wrote:
> I assume you want to wake the system from S5 (poweroff).
No. The machine is almost never completely powered down.
> Does is wake from S3 (suspend-to-RAM) ? You can trigger this with
> "systemctl suspend".
That's what I am doing, with the behavior I reported: No reaction to
magic packet with the 4.20 driver, waking up from suspend to ram with a
current kernel with 4.18's r8169.c transplanted.
> Any difference if you enable WoL manually via ethtool "ethtool -s <if> wol g" ?
Would that make any difference if ethtool already says "Wake-on: g"? Why
would that make a difference with the 4.20 driver, but not with the
older one?
And yes, I remember this being one of the very first attempts after
noticing the issue, and I frankly would consider it at least a
regression if the 4.20 driver needs manual intervention while the 4.18
driver works fine with the appropriate setting in systemd-networkd
configuration.
Let me repeat, the issue does immediately vanish once I replace the
r8169 driver in the kernel with an older version, and re-establishes
itself immediately once I use a current driver version. No other parts
of the system or the network do not even get touched.
> And a basic question: Once you have powered off your system, is network
> LED on PC and router on?
When the system is in suspend, the manageable TP-Link 52 Port Gigabit
Switch reports the link on port 41 going down for a second and then
coming up again with 10 Mbit/s Full-Duplex. The Link LED on the system
board is _off_ in this case, even with the older driver and working Wake
on LAN. After receiving the magic packet, the system wakes up from
suspend to RAM, the link LED on the system board lights up again, the
switch reports the link going down again for a second and then
re-establishes as 1000 Mbit/s Full-Duplex.
The router's link to the same switch, different port, stays up with 1000
Mbit/s Full-Duplex, as expected, and frankly I do not see why the
totally unrelated network link between switch and router plays a role
here.
All those tests were done with Linux 4.20.3 with the driver from 4.18
transplanted and WoL working. I guess you want me to retry with the
broken driver?
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-01-22 16:10 ` Marc Haber
@ 2019-01-22 18:47 ` Heiner Kallweit
2019-01-25 5:59 ` Marc Haber
0 siblings, 1 reply; 36+ messages in thread
From: Heiner Kallweit @ 2019-01-22 18:47 UTC (permalink / raw)
To: Marc Haber; +Cc: netdev
On 22.01.2019 17:10, Marc Haber wrote:
> On Sun, Jan 13, 2019 at 05:19:41PM +0100, Heiner Kallweit wrote:
>> I assume you want to wake the system from S5 (poweroff).
>
> No. The machine is almost never completely powered down.
>
>> Does is wake from S3 (suspend-to-RAM) ? You can trigger this with
>> "systemctl suspend".
>
> That's what I am doing, with the behavior I reported: No reaction to
> magic packet with the 4.20 driver, waking up from suspend to ram with a
> current kernel with 4.18's r8169.c transplanted.
>
OK, good to know. I was asking because once there was an issue
with S5 only.
>> Any difference if you enable WoL manually via ethtool "ethtool -s <if> wol g" ?
>
> Would that make any difference if ethtool already says "Wake-on: g"? Why
> would that make a difference with the 4.20 driver, but not with the
> older one?
>
ethtool only reports the chip settings, it doesn't consider whether
wake-up is enabled on system level.
As an additional note: When setting WoL ethtool first queries the settings
and it only does something if it finds the new settings are different.
For wake-up basically three things are involved:
1. physical network, so that wakeup packet can reach NIC
2. chip must be programmed to detect WoL packet and generate PME
3. system must be programmed to detect PME from this source
Point 2 seems to be ok based on the register dump you provided.
Point 1 we should check, therefore answer to your last question is: yes.
Point 3 we still have to check.
Which version of 4.18 are you running that is ok? To check the code ..
Based on what I wrote above, could you try the following sequence and
check whether wake from S3 works then?
ethtool -s <if> wol d
ethtool -s <if> wol g
> And yes, I remember this being one of the very first attempts after
> noticing the issue, and I frankly would consider it at least a
> regression if the 4.20 driver needs manual intervention while the 4.18
> driver works fine with the appropriate setting in systemd-networkd
> configuration.
>
> Let me repeat, the issue does immediately vanish once I replace the
> r8169 driver in the kernel with an older version, and re-establishes
> itself immediately once I use a current driver version. No other parts
> of the system or the network do not even get touched.
>
>> And a basic question: Once you have powered off your system, is network
>> LED on PC and router on?
>
> When the system is in suspend, the manageable TP-Link 52 Port Gigabit
> Switch reports the link on port 41 going down for a second and then
> coming up again with 10 Mbit/s Full-Duplex. The Link LED on the system
> board is _off_ in this case, even with the older driver and working Wake
> on LAN. After receiving the magic packet, the system wakes up from
> suspend to RAM, the link LED on the system board lights up again, the
> switch reports the link going down again for a second and then
> re-establishes as 1000 Mbit/s Full-Duplex.
>
> The router's link to the same switch, different port, stays up with 1000
> Mbit/s Full-Duplex, as expected, and frankly I do not see why the
> totally unrelated network link between switch and router plays a role
> here.
>
I asked for the router because I assumed that your system is connected
to the router directly.
> All those tests were done with Linux 4.20.3 with the driver from 4.18
> transplanted and WoL working. I guess you want me to retry with the
> broken driver?
>
> Greetings
> Marc
>
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-01-22 18:47 ` Heiner Kallweit
@ 2019-01-25 5:59 ` Marc Haber
2019-01-25 6:49 ` Heiner Kallweit
0 siblings, 1 reply; 36+ messages in thread
From: Marc Haber @ 2019-01-25 5:59 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: netdev
Hi Heiner,
On Tue, Jan 22, 2019 at 07:47:45PM +0100, Heiner Kallweit wrote:
> Which version of 4.18 are you running that is ok? To check the code ..
I pull over drivers/net/ethernet/realtek/r8169.c from an unpacked
4.18.16 source tree. It sets RTL8169_VERSION "2.3LK-NAPI". The last
commit in this file's history is
commit 241e5a13a5ad75fd0b5a47b583e098fa08917d5c
Author: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Date: Thu Oct 11 16:02:10 2018 +0200
r8169: set RX_MULTI_EN bit in RxConfig for 8168F-family chips
Unfortunately, very different r8169.c in 4.20.3 also sets RTL8169_VERSION "2.3LK-NAPI", so we cannot use this as identification.
> Based on what I wrote above, could you try the following sequence and
> check whether wake from S3 works then?
>
> ethtool -s <if> wol d
> ethtool -s <if> wol g
This test was done with the Debian kernel package 4.20.0-trunk-amd64,
which contains a kernel 4.20.1 compiled on 2018-12-24, from Debian's
experimental repository.
This are my steps:
(1) ethtool -s lanc0 wol d
(2) ethtool -s lanc0 wol g
(3) systemctl suspend
(4) system gows down into Suspend to RAM, an audible *click* from a
relay, power LED blinking, Switch reporting that the ethernet link state
changed from 1000Full to down and then to 10Full.
(5) sent a magic packet
(6) *click* system up again. This is good.
(7) switch reported link state change from 10Full to down and then to
1000Full
(8) system and network operational
(9) shut down the system completely, remove power. all LEDs off, link
down
(10) re-plug power, all LEDs off, link 10Full
(11) push power button, bring system up again with Debian's 4.20 kernel
(12) link up at 1000Full
(12a) take register dump, exhibit 12a
(13) systemctl suspend
(14) system gows down into Suspend to RAM, an audible *click* from a
relay, power LED blinking, Switch reporting that the ethernet link state
changed from 1000Full to down and then to 10Full.
(15) send magic packet identical to step (5)
(16) system remains suspended, blinking LED; link 10Full
(17) push any key on keyboard
(18) *click* system up again. This is good.
(19) switch reported link state change from 10Full to down and then to
1000Full
(19a) take register dump, exhibit 19a
(20) system and network operational
(21) repeat steps (1) through (5)
(22) system reacts to magic packet and wakes up
(23) ethtool -s lanc0 wol d
(24) ethtool -s lanc0 wol g
(25) take register dump, exhibit 25
(26) systemctl suspend
(27) system gows down into Suspend to RAM, an audible *click* from a
relay, power LED blinking, Switch reporting that the ethernet link state
changed from 1000Full to down and then to 10Full.
(28) sent a magic packet
(29) *click* system up again. This is good.
(30) switch reported link state change from 10Full to down and then to
1000Full
(31) take register dump, exhibit 31
(32) system and network operational
So, our hypothesis is now that the older driver does "something" that
the new driver doesn't, but what is needed for my machine to wake up on
magic packet from suspend to RAM. the two ethtool calls do seem to fix
that.
Unfortunately, exhibits 19a, 25 and 31 are identical, and exhibit 12a
only differs in a single line, PHY access holding 0x8001796d instead of
0x80040de1. So, whatever the two ethtools do, it is not visible in the
register dump.
I repaeted the experiment with stock 4.20.4, with the same results, and
4.20.4 with a r8169.c transplant from 4.18.16, with the result of
ethtool not needed.
Exhibits from the stock 4.20.4 experiments:
exhibit-4.20.4-preeth-presleep - direct after boot
exhibit-4.20.4-preeth-postsleep - after suspend with manual wakeup needed
exhibit-4.20.4-posteth-presleep - after the two ethtool calls
exhibit-4.20.4-posteth-postsleep - after successful wake on lan
Exhibits from the 4.20.4+transplant experiments:
exhibit-4.18-presleep - direct after boot
exhibit-4.18-postsleep - after successful wake on LAN.
I hope this helps. Let me know if additional data is helpful.
Greetings
Marc
Exhibits:
==> exhibit-12a <==
RealTek RTL8168evl/8111evl registers:
--------------------------------------------------------
0x00: MAC Address 54:04:a6:82:21:00
0x08: Multicast Address Filter 0x024a0040 0x80c14082
0x10: Dump Tally Counter Command 0x1ab90000 0x00000004
0x20: Tx Normal Priority Ring Addr 0x1f153000 0x00000004
0x28: Tx High Priority Ring Addr 0x00000000 0x00000000
0x30: Flash memory read/write 0x00000000
0x34: Early Rx Byte Count 0
0x36: Early Rx Status 0x00
0x37: Command 0x0c
Rx on, Tx on
0x3C: Interrupt Mask 0x803f
SERR LinkChg RxNoBuf TxErr TxOK RxErr RxOK
0x3E: Interrupt Status 0x0000
0x40: Tx Configuration 0x2f900f80
0x44: Rx Configuration 0x0002c70e
0x48: Timer count 0x00000000
0x4C: Missed packet counter 0x000000
0x50: EEPROM Command 0x10
0x51: Config 0 0x00
0x52: Config 1 0xcf
0x53: Config 2 0xbd
0x54: Config 3 0x60
0x55: Config 4 0x51
0x56: Config 5 0x03
0x58: Timer interrupt 0x00000000
0x5C: Multiple Interrupt Select 0x0000
0x60: PHY access 0x8001796d
0x64: TBI control and status 0x84321043
0x68: TBI Autonegotiation advertisement (ANAR) 0xf02c
0x6A: TBI Link partner ability (LPAR) 0x0000
0x6C: PHY status 0x93
0x84: PM wakeup frame 0 0x00000000 0x00000000
0x8C: PM wakeup frame 1 0x00000000 0x4af63565
0x94: PM wakeup frame 2 (low) 0x6202016b 0x8ab829be
0x9C: PM wakeup frame 2 (high) 0x40bee65e 0x800e2860
0xA4: PM wakeup frame 3 (low) 0x44280748 0x1ceea050
0xAC: PM wakeup frame 3 (high) 0xc465e124 0xc4650000
0xB4: PM wakeup frame 4 (low) 0xffffffff 0xffffffff
0xBC: PM wakeup frame 4 (high) 0x00000000 0x00000000
0xC4: Wakeup frame 0 CRC 0x0000
0xC6: Wakeup frame 1 CRC 0x0000
0xC8: Wakeup frame 2 CRC 0x0000
0xCA: Wakeup frame 3 CRC 0x0000
0xCC: Wakeup frame 4 CRC 0x0000
0xDA: RX packet maximum size 0x4000
0xE0: C+ Command 0x20e1
VLAN de-tagging
RX checksumming
0xE2: Interrupt Mitigation 0x5151
TxTimer: 5
TxPackets: 1
RxTimer: 5
RxPackets: 1
0xE4: Rx Ring Addr 0x1f152000 0x00000004
0xEC: Early Tx threshold 0x27
0xF0: Func Event 0x00400030
0xF4: Func Event Mask 0x00000000
0xF8: Func Preset State 0x000303ff
0xFC: Func Force Event 0x00000000
==> exhibit-19a <==
RealTek RTL8168evl/8111evl registers:
--------------------------------------------------------
0x00: MAC Address 54:04:a6:82:21:00
0x08: Multicast Address Filter 0x024a0040 0x80c14082
0x10: Dump Tally Counter Command 0x1ab90000 0x00000004
0x20: Tx Normal Priority Ring Addr 0x1f153000 0x00000004
0x28: Tx High Priority Ring Addr 0x00000000 0x00000000
0x30: Flash memory read/write 0x00000000
0x34: Early Rx Byte Count 0
0x36: Early Rx Status 0x00
0x37: Command 0x0c
Rx on, Tx on
0x3C: Interrupt Mask 0x803f
SERR LinkChg RxNoBuf TxErr TxOK RxErr RxOK
0x3E: Interrupt Status 0x0000
0x40: Tx Configuration 0x2f900f80
0x44: Rx Configuration 0x0002c70e
0x48: Timer count 0x00000000
0x4C: Missed packet counter 0x000000
0x50: EEPROM Command 0x10
0x51: Config 0 0x00
0x52: Config 1 0xcf
0x53: Config 2 0xbd
0x54: Config 3 0x60
0x55: Config 4 0x51
0x56: Config 5 0x03
0x58: Timer interrupt 0x00000000
0x5C: Multiple Interrupt Select 0x0000
0x60: PHY access 0x80040de1
0x64: TBI control and status 0x84321043
0x68: TBI Autonegotiation advertisement (ANAR) 0xf02c
0x6A: TBI Link partner ability (LPAR) 0x0000
0x6C: PHY status 0x93
0x84: PM wakeup frame 0 0x00000000 0x00000000
0x8C: PM wakeup frame 1 0x00000000 0x4af63565
0x94: PM wakeup frame 2 (low) 0x6202016b 0x8ab829be
0x9C: PM wakeup frame 2 (high) 0x40bee65e 0x800e2860
0xA4: PM wakeup frame 3 (low) 0x44280748 0x1ceea050
0xAC: PM wakeup frame 3 (high) 0xc465e124 0xc4650000
0xB4: PM wakeup frame 4 (low) 0xffffffff 0xffffffff
0xBC: PM wakeup frame 4 (high) 0x00000000 0x00000000
0xC4: Wakeup frame 0 CRC 0x0000
0xC6: Wakeup frame 1 CRC 0x0000
0xC8: Wakeup frame 2 CRC 0x0000
0xCA: Wakeup frame 3 CRC 0x0000
0xCC: Wakeup frame 4 CRC 0x0000
0xDA: RX packet maximum size 0x4000
0xE0: C+ Command 0x20e1
VLAN de-tagging
RX checksumming
0xE2: Interrupt Mitigation 0x5151
TxTimer: 5
TxPackets: 1
RxTimer: 5
RxPackets: 1
0xE4: Rx Ring Addr 0x1f152000 0x00000004
0xEC: Early Tx threshold 0x27
0xF0: Func Event 0x00400030
0xF4: Func Event Mask 0x00000000
0xF8: Func Preset State 0x000303ff
0xFC: Func Force Event 0x00000000
==> exhibit-25 <==
RealTek RTL8168evl/8111evl registers:
--------------------------------------------------------
0x00: MAC Address 54:04:a6:82:21:00
0x08: Multicast Address Filter 0x024a0040 0x80c14082
0x10: Dump Tally Counter Command 0x1ab90000 0x00000004
0x20: Tx Normal Priority Ring Addr 0x1f153000 0x00000004
0x28: Tx High Priority Ring Addr 0x00000000 0x00000000
0x30: Flash memory read/write 0x00000000
0x34: Early Rx Byte Count 0
0x36: Early Rx Status 0x00
0x37: Command 0x0c
Rx on, Tx on
0x3C: Interrupt Mask 0x803f
SERR LinkChg RxNoBuf TxErr TxOK RxErr RxOK
0x3E: Interrupt Status 0x0000
0x40: Tx Configuration 0x2f900f80
0x44: Rx Configuration 0x0002c70e
0x48: Timer count 0x00000000
0x4C: Missed packet counter 0x000000
0x50: EEPROM Command 0x10
0x51: Config 0 0x00
0x52: Config 1 0xcf
0x53: Config 2 0xbd
0x54: Config 3 0x60
0x55: Config 4 0x51
0x56: Config 5 0x03
0x58: Timer interrupt 0x00000000
0x5C: Multiple Interrupt Select 0x0000
0x60: PHY access 0x80040de1
0x64: TBI control and status 0x84321043
0x68: TBI Autonegotiation advertisement (ANAR) 0xf02c
0x6A: TBI Link partner ability (LPAR) 0x0000
0x6C: PHY status 0x93
0x84: PM wakeup frame 0 0x00000000 0x00000000
0x8C: PM wakeup frame 1 0x00000000 0x4af63565
0x94: PM wakeup frame 2 (low) 0x6202016b 0x8ab829be
0x9C: PM wakeup frame 2 (high) 0x40bee65e 0x800e2860
0xA4: PM wakeup frame 3 (low) 0x44280748 0x1ceea050
0xAC: PM wakeup frame 3 (high) 0xc465e124 0xc4650000
0xB4: PM wakeup frame 4 (low) 0xffffffff 0xffffffff
0xBC: PM wakeup frame 4 (high) 0x00000000 0x00000000
0xC4: Wakeup frame 0 CRC 0x0000
0xC6: Wakeup frame 1 CRC 0x0000
0xC8: Wakeup frame 2 CRC 0x0000
0xCA: Wakeup frame 3 CRC 0x0000
0xCC: Wakeup frame 4 CRC 0x0000
0xDA: RX packet maximum size 0x4000
0xE0: C+ Command 0x20e1
VLAN de-tagging
RX checksumming
0xE2: Interrupt Mitigation 0x5151
TxTimer: 5
TxPackets: 1
RxTimer: 5
RxPackets: 1
0xE4: Rx Ring Addr 0x1f152000 0x00000004
0xEC: Early Tx threshold 0x27
0xF0: Func Event 0x00400030
0xF4: Func Event Mask 0x00000000
0xF8: Func Preset State 0x000303ff
0xFC: Func Force Event 0x00000000
==> exhibit-31 <==
RealTek RTL8168evl/8111evl registers:
--------------------------------------------------------
0x00: MAC Address 54:04:a6:82:21:00
0x08: Multicast Address Filter 0x024a0040 0x80c14082
0x10: Dump Tally Counter Command 0x1ab90000 0x00000004
0x20: Tx Normal Priority Ring Addr 0x1f153000 0x00000004
0x28: Tx High Priority Ring Addr 0x00000000 0x00000000
0x30: Flash memory read/write 0x00000000
0x34: Early Rx Byte Count 0
0x36: Early Rx Status 0x00
0x37: Command 0x0c
Rx on, Tx on
0x3C: Interrupt Mask 0x803f
SERR LinkChg RxNoBuf TxErr TxOK RxErr RxOK
0x3E: Interrupt Status 0x0000
0x40: Tx Configuration 0x2f900f80
0x44: Rx Configuration 0x0002c70e
0x48: Timer count 0x00000000
0x4C: Missed packet counter 0x000000
0x50: EEPROM Command 0x10
0x51: Config 0 0x00
0x52: Config 1 0xcf
0x53: Config 2 0xbd
0x54: Config 3 0x60
0x55: Config 4 0x51
0x56: Config 5 0x03
0x58: Timer interrupt 0x00000000
0x5C: Multiple Interrupt Select 0x0000
0x60: PHY access 0x80040de1
0x64: TBI control and status 0x84321043
0x68: TBI Autonegotiation advertisement (ANAR) 0xf02c
0x6A: TBI Link partner ability (LPAR) 0x0000
0x6C: PHY status 0x93
0x84: PM wakeup frame 0 0x00000000 0x00000000
0x8C: PM wakeup frame 1 0x00000000 0x4af63565
0x94: PM wakeup frame 2 (low) 0x6202016b 0x8ab829be
0x9C: PM wakeup frame 2 (high) 0x40bee65e 0x800e2860
0xA4: PM wakeup frame 3 (low) 0x44280748 0x1ceea050
0xAC: PM wakeup frame 3 (high) 0xc465e124 0xc4650000
0xB4: PM wakeup frame 4 (low) 0xffffffff 0xffffffff
0xBC: PM wakeup frame 4 (high) 0x00000000 0x00000000
0xC4: Wakeup frame 0 CRC 0x0000
0xC6: Wakeup frame 1 CRC 0x0000
0xC8: Wakeup frame 2 CRC 0x0000
0xCA: Wakeup frame 3 CRC 0x0000
0xCC: Wakeup frame 4 CRC 0x0000
0xDA: RX packet maximum size 0x4000
0xE0: C+ Command 0x20e1
VLAN de-tagging
RX checksumming
0xE2: Interrupt Mitigation 0x5151
TxTimer: 5
TxPackets: 1
RxTimer: 5
RxPackets: 1
0xE4: Rx Ring Addr 0x1f152000 0x00000004
0xEC: Early Tx threshold 0x27
0xF0: Func Event 0x00400030
0xF4: Func Event Mask 0x00000000
0xF8: Func Preset State 0x000303ff
0xFC: Func Force Event 0x00000000
==> exhibit-4.20.4-preeth-presleep <==
RealTek RTL8168evl/8111evl registers:
--------------------------------------------------------
0x00: MAC Address 54:04:a6:82:21:00
0x08: Multicast Address Filter 0x024a0040 0x80c14082
0x10: Dump Tally Counter Command 0x1f7c2000 0x00000004
0x20: Tx Normal Priority Ring Addr 0x0ce91000 0x00000004
0x28: Tx High Priority Ring Addr 0x00000000 0x00000000
0x30: Flash memory read/write 0x00000000
0x34: Early Rx Byte Count 0
0x36: Early Rx Status 0x00
0x37: Command 0x0c
Rx on, Tx on
0x3C: Interrupt Mask 0x803f
SERR LinkChg RxNoBuf TxErr TxOK RxErr RxOK
0x3E: Interrupt Status 0x0000
0x40: Tx Configuration 0x2f900f80
0x44: Rx Configuration 0x0002c70e
0x48: Timer count 0x00000000
0x4C: Missed packet counter 0x000000
0x50: EEPROM Command 0x10
0x51: Config 0 0x00
0x52: Config 1 0xcf
0x53: Config 2 0xbd
0x54: Config 3 0x60
0x55: Config 4 0x51
0x56: Config 5 0x03
0x58: Timer interrupt 0x00000000
0x5C: Multiple Interrupt Select 0x0000
0x60: PHY access 0x8001796d
0x64: TBI control and status 0x84321043
0x68: TBI Autonegotiation advertisement (ANAR) 0xf02c
0x6A: TBI Link partner ability (LPAR) 0x0000
0x6C: PHY status 0x93
0x84: PM wakeup frame 0 0x00000000 0x00000000
0x8C: PM wakeup frame 1 0x00000000 0x4af63565
0x94: PM wakeup frame 2 (low) 0x6202016b 0x8ab829be
0x9C: PM wakeup frame 2 (high) 0x40bee65e 0x800e2860
0xA4: PM wakeup frame 3 (low) 0x44280748 0x1ceea050
0xAC: PM wakeup frame 3 (high) 0xc465e124 0xc4650000
0xB4: PM wakeup frame 4 (low) 0xffffffff 0xffffffff
0xBC: PM wakeup frame 4 (high) 0x00000000 0x00000000
0xC4: Wakeup frame 0 CRC 0x0000
0xC6: Wakeup frame 1 CRC 0x0000
0xC8: Wakeup frame 2 CRC 0x0000
0xCA: Wakeup frame 3 CRC 0x0000
0xCC: Wakeup frame 4 CRC 0x0000
0xDA: RX packet maximum size 0x4000
0xE0: C+ Command 0x20e1
VLAN de-tagging
RX checksumming
0xE2: Interrupt Mitigation 0x5151
TxTimer: 5
TxPackets: 1
RxTimer: 5
RxPackets: 1
0xE4: Rx Ring Addr 0x0ce8e000 0x00000004
0xEC: Early Tx threshold 0x27
0xF0: Func Event 0x00400030
0xF4: Func Event Mask 0x00000000
0xF8: Func Preset State 0x000303ff
0xFC: Func Force Event 0x00000000
==> exhibit-4.20.4-preeth-postsleep <==
RealTek RTL8168evl/8111evl registers:
--------------------------------------------------------
0x00: MAC Address 54:04:a6:82:21:00
0x08: Multicast Address Filter 0x024a0040 0x80c14082
0x10: Dump Tally Counter Command 0x1f7c2000 0x00000004
0x20: Tx Normal Priority Ring Addr 0x0ce91000 0x00000004
0x28: Tx High Priority Ring Addr 0x00000000 0x00000000
0x30: Flash memory read/write 0x00000000
0x34: Early Rx Byte Count 0
0x36: Early Rx Status 0x00
0x37: Command 0x0c
Rx on, Tx on
0x3C: Interrupt Mask 0x803f
SERR LinkChg RxNoBuf TxErr TxOK RxErr RxOK
0x3E: Interrupt Status 0x0000
0x40: Tx Configuration 0x2f900f80
0x44: Rx Configuration 0x0002c70e
0x48: Timer count 0x00000000
0x4C: Missed packet counter 0x000000
0x50: EEPROM Command 0x10
0x51: Config 0 0x00
0x52: Config 1 0xcf
0x53: Config 2 0xbd
0x54: Config 3 0x60
0x55: Config 4 0x51
0x56: Config 5 0x03
0x58: Timer interrupt 0x00000000
0x5C: Multiple Interrupt Select 0x0000
0x60: PHY access 0x80040de1
0x64: TBI control and status 0x84321043
0x68: TBI Autonegotiation advertisement (ANAR) 0xf02c
0x6A: TBI Link partner ability (LPAR) 0x0000
0x6C: PHY status 0x93
0x84: PM wakeup frame 0 0x00000000 0x00000000
0x8C: PM wakeup frame 1 0x00000000 0x4af63565
0x94: PM wakeup frame 2 (low) 0x6202016b 0x8ab829be
0x9C: PM wakeup frame 2 (high) 0x40bee65e 0x800e2860
0xA4: PM wakeup frame 3 (low) 0x44280748 0x1ceea050
0xAC: PM wakeup frame 3 (high) 0xc465e124 0xc4650000
0xB4: PM wakeup frame 4 (low) 0xffffffff 0xffffffff
0xBC: PM wakeup frame 4 (high) 0x00000000 0x00000000
0xC4: Wakeup frame 0 CRC 0x0000
0xC6: Wakeup frame 1 CRC 0x0000
0xC8: Wakeup frame 2 CRC 0x0000
0xCA: Wakeup frame 3 CRC 0x0000
0xCC: Wakeup frame 4 CRC 0x0000
0xDA: RX packet maximum size 0x4000
0xE0: C+ Command 0x20e1
VLAN de-tagging
RX checksumming
0xE2: Interrupt Mitigation 0x5151
TxTimer: 5
TxPackets: 1
RxTimer: 5
RxPackets: 1
0xE4: Rx Ring Addr 0x0ce8e000 0x00000004
0xEC: Early Tx threshold 0x27
0xF0: Func Event 0x00400030
0xF4: Func Event Mask 0x00000000
0xF8: Func Preset State 0x000303ff
0xFC: Func Force Event 0x00000000
==> exhibit-4.20.4-posteth-presleep <==
RealTek RTL8168evl/8111evl registers:
--------------------------------------------------------
0x00: MAC Address 54:04:a6:82:21:00
0x08: Multicast Address Filter 0x024a0040 0x80c14082
0x10: Dump Tally Counter Command 0x1f7c2000 0x00000004
0x20: Tx Normal Priority Ring Addr 0x0ce91000 0x00000004
0x28: Tx High Priority Ring Addr 0x00000000 0x00000000
0x30: Flash memory read/write 0x00000000
0x34: Early Rx Byte Count 0
0x36: Early Rx Status 0x00
0x37: Command 0x0c
Rx on, Tx on
0x3C: Interrupt Mask 0x803f
SERR LinkChg RxNoBuf TxErr TxOK RxErr RxOK
0x3E: Interrupt Status 0x0000
0x40: Tx Configuration 0x2f900f80
0x44: Rx Configuration 0x0002c70e
0x48: Timer count 0x00000000
0x4C: Missed packet counter 0x000000
0x50: EEPROM Command 0x10
0x51: Config 0 0x00
0x52: Config 1 0xcf
0x53: Config 2 0xbd
0x54: Config 3 0x60
0x55: Config 4 0x51
0x56: Config 5 0x03
0x58: Timer interrupt 0x00000000
0x5C: Multiple Interrupt Select 0x0000
0x60: PHY access 0x80040de1
0x64: TBI control and status 0x84321043
0x68: TBI Autonegotiation advertisement (ANAR) 0xf02c
0x6A: TBI Link partner ability (LPAR) 0x0000
0x6C: PHY status 0x93
0x84: PM wakeup frame 0 0x00000000 0x00000000
0x8C: PM wakeup frame 1 0x00000000 0x4af63565
0x94: PM wakeup frame 2 (low) 0x6202016b 0x8ab829be
0x9C: PM wakeup frame 2 (high) 0x40bee65e 0x800e2860
0xA4: PM wakeup frame 3 (low) 0x44280748 0x1ceea050
0xAC: PM wakeup frame 3 (high) 0xc465e124 0xc4650000
0xB4: PM wakeup frame 4 (low) 0xffffffff 0xffffffff
0xBC: PM wakeup frame 4 (high) 0x00000000 0x00000000
0xC4: Wakeup frame 0 CRC 0x0000
0xC6: Wakeup frame 1 CRC 0x0000
0xC8: Wakeup frame 2 CRC 0x0000
0xCA: Wakeup frame 3 CRC 0x0000
0xCC: Wakeup frame 4 CRC 0x0000
0xDA: RX packet maximum size 0x4000
0xE0: C+ Command 0x20e1
VLAN de-tagging
RX checksumming
0xE2: Interrupt Mitigation 0x5151
TxTimer: 5
TxPackets: 1
RxTimer: 5
RxPackets: 1
0xE4: Rx Ring Addr 0x0ce8e000 0x00000004
0xEC: Early Tx threshold 0x27
0xF0: Func Event 0x00400030
0xF4: Func Event Mask 0x00000000
0xF8: Func Preset State 0x000303ff
0xFC: Func Force Event 0x00000000
==> exhibit-4.20.4-posteth-postsleep <==
RealTek RTL8168evl/8111evl registers:
--------------------------------------------------------
0x00: MAC Address 54:04:a6:82:21:00
0x08: Multicast Address Filter 0x024a0040 0x80c14082
0x10: Dump Tally Counter Command 0x1f7c2000 0x00000004
0x20: Tx Normal Priority Ring Addr 0x0ce91000 0x00000004
0x28: Tx High Priority Ring Addr 0x00000000 0x00000000
0x30: Flash memory read/write 0x00000000
0x34: Early Rx Byte Count 0
0x36: Early Rx Status 0x00
0x37: Command 0x0c
Rx on, Tx on
0x3C: Interrupt Mask 0x803f
SERR LinkChg RxNoBuf TxErr TxOK RxErr RxOK
0x3E: Interrupt Status 0x0000
0x40: Tx Configuration 0x2f900f80
0x44: Rx Configuration 0x0002c70e
0x48: Timer count 0x00000000
0x4C: Missed packet counter 0x000000
0x50: EEPROM Command 0x10
0x51: Config 0 0x00
0x52: Config 1 0xcf
0x53: Config 2 0xbd
0x54: Config 3 0x60
0x55: fig 4 0x51
0x56: Config 5 0x03
0x58: Timer interrupt 0x00000000
0x5C: Multiple Interrupt Select 0x0000
0x60: PHY access 0x80040de1
0x64: TBI control and status 0x84321043
0x68: TBI Autonegotiation advertisement (ANAR) 0xf02c
0x6A: TBI Link partner ability (LPAR) 0x0000
0x6C: PHY status 0x93
0x84: PM wakeup frame 0 0x00000000 0x00000000
0x8C: PM wakeup frame 1 0x00000000 0x4af63565
0x94: PM wakeup frame 2 (low) 0x6202016b 0x8ab829be
0x9C: PM wakeup frame 2 (high) 0x40bee65e 0x800e2860
0xA4: PM wakeup frame 3 (low) 0x44280748 0x1ceea050
0xAC: PM wakeup frame 3 (high) 0xc465e124 0xc4650000
0xB4: PM wakeup frame 4 (low) 0xffffffff 0xffffffff
0xBC: PM wakeup frame 4 (high) 0x00000000 0x00000000
0xC4: Wakeup frame 0 CRC 0x0000
0xC6: Wakeup frame 1 CRC 0x0000
0xC8: Wakeup frame 2 CRC 0x0000
0xCA: Wakeup frame 3 CRC 0x0000
0xCC: Wakeup frame 4 CRC 0x0000
0xDA: RX packet maximum size 0x4000
0xE0: C+ Command 0x20e1
VLAN de-tagging
RX checksumming
0xE2: Interrupt Mitigation 0x5151
TxTimer: 5
TxPackets: 1
RxTimer: 5
RxPackets: 1
0xE4: Rx Ring Addr 0x0ce8e000 0x00000004
0xEC: Early Tx threshold 0x27
0xF0: Func Event 0x00400030
0xF4: Func Event Mask 0x00000000
0xF8: Func Preset State 0x000303ff
0xFC: Func Force Event 0x00000000
==> exhibit-4.18-presleep <==
RealTek RTL8168evl/8111evl registers:
--------------------------------------------------------
0x00: MAC Address 54:04:a6:82:21:00
0x08: Multicast Address Filter 0x024a0040 0x80c14082
0x10: Dump Tally Counter Command 0x20651000 0x00000004
0x20: Tx Normal Priority Ring Addr 0x0e02c000 0x00000004
0x28: Tx High Priority Ring Addr 0x00000000 0x00000000
0x30: Flash memory read/write 0x00000000
0x34: Early Rx Byte Count 0
0x36: Early Rx Status 0x00
0x37: Command 0x0c
Rx on, Tx on
0x3C: Interrupt Mask 0x803f
SERR LinkChg RxNoBuf TxErr TxOK RxErr RxOK
0x3E: Interrupt Status 0x0000
0x40: Tx Configuration 0x2f900f80
0x44: Rx Configuration 0x0002c70e
0x48: Timer count 0x00000000
0x4C: Missed packet counter 0x000000
0x50: EEPROM Command 0x10
0x51: Config 0 0x00
0x52: Config 1 0xcf
0x53: Config 2 0xbd
0x54: Config 3 0x60
0x55: Config 4 0x51
0x56: Config 5 0x02
0x58: Timer interrupt 0x00000000
0x5C: Multiple Interrupt Select 0x0000
0x60: PHY access 0x8005c1e1
0x64: TBI control and status 0x84321043
0x68: I Autonegotiation advertisement (ANAR) 0xf02c
0x6A: TBI Link partner ability (LPAR) 0x0000
0x6C: PHY status 0x93
0x84: PM wakeup frame 0 0x00000000 0x00000000
0x8C: PM wakeup frame 1 0x00000000 0x4af63565
0x94: PM wakeup frame 2 (low) 0x6202016b 0x8ab829be
0x9C: PM wakeup frame 2 (high) 0x40bee65e 0x800e2860
0xA4: PM wakeup frame 3 (low) 0x44280748 0x1ceea050
0xAC: PM wakeup frame 3 (high) 0xc465e124 0xc4650000
0xB4: PM wakeup frame 4 (low) 0xffffffff 0xffffffff
0xBC: PM wakeup frame 4 (high) 0x00000000 0x00000000
0xC4: Wakeup frame 0 CRC 0x0000
0xC6: Wakeup frame 1 CRC 0x0000
0xC8: Wakeup frame 2 CRC 0x0000
0xCA: Wakeup frame 3 CRC 0x0000
0xCC: Wakeup frame 4 CRC 0x0000
0xDA: RX packet maximum size 0x4000
0xE0: C+ Command 0x20e1
VLAN de-tagging
RX checksumming
0xE2: Interrupt Mitigation 0x5151
TxTimer: 5
TxPackets: 1
RxTimer: 5
RxPackets: 1
0xE4: Rx Ring Addr 0x0e02d000 0x00000004
0xEC: Early Tx threshold 0x27
0xF0: Func Event 0x00400030
0xF4: Func Event Mask 0x00000000
0xF8: Func Preset State 0x000303ff
0xFC: Func Force Event 0x00000000
==> exhibit-4.18-postsleep <==
RealTek RTL8168evl/8111evl registers:
--------------------------------------------------------
0x00: MAC Address 54:04:a6:82:21:00
0x08: Multicast Address Filter 0x024a0040 0x80c14082
0x10: Dump Tally Counter Command 0x20651000 0x00000004
0x20: Tx Normal Priority Ring Addr 0x0e02c000 0x00000004
0x28: Tx High Priority Ring Addr 0x00000000 0x00000000
0x30: Flash memory read/write 0x00000000
0x34: Early Rx Byte Count 0
0x36: Early Rx Status 0x00
0x37: Command 0x0c
Rx on, Tx on
0x3C: Interrupt Mask 0x803f
SERR LinkChg RxNoBuf TxErr TxOK RxErr RxOK
0x3E: Interrupt Status 0x0000
0x40: Tx Configuration 0x2f900f80
0x44: Rx Configuration 0x0002c70e
0x48: Timer count 0x00000000
0x4C: Missed packet counter 0x000000
0x50: EEPROM Command 0x10
0x51: Config 0 0x00
0x52: Config 1 0xcf
0x53: Config 2 0xbd
0x54: Config 3 0x60
0x55: Config 4 0x51
0x56: Config 5 0x02
0x58: Timer interrupt 0x00000000
0x5C: Multiple Interrupt Select 0x0000
0x60: PHY access 0x80040de1
0x64: TBI control and status 0x84321043
0x68: TBI Autonegotiation advertisement (ANAR) 0xf02c
0x6A: TBI Link partner ability (LPAR) 0x0000
0x6C: PHY status 0x93
0x84: PM wakeup frame 0 0x00000000 0x00000000
0x8C: PM wakeup frame 1 0x00000000 0x4af63565
0x94: PM wakeup frame 2 (low) 0x6202016b 0x8ab829be
0x9CM wakeup frame 2 (high) 0x40bee65e 0x800e2860
0xA4: PM wakeup frame 3 (low) 0x44280748 0x1ceea050
0xAC: PM wakeup frame 3 (high) 0xc465e124 0xc4650000
0xB4: PM wakeup frame 4 (low) 0xffffffff 0xffffffff
0xBC: PM wakeup frame 4 (high) 0x00000000 0x00000000
0xC4: Wakeup frame 0 CRC 0x0000
0xC6: Wakeup frame 1 CRC 0x0000
0xC8: Wakeup frame 2 CRC 0x0000
0xCA: Wakeup frame 3 CRC 0x0000
0xCC: Wakeup frame 4 CRC 0x0000
0xDA: RX packet maximum size 0x4000
0xE0: C+ Command 0x20e1
VLAN de-tagging
RX checksumming
0xE2: Interrupt Mitigation 0x5151
TxTimer: 5
TxPackets: 1
RxTimer: 5
RxPackets: 1
0xE4: Rx Ring Addr 0x0e02d000 0x00000004
0xEC: Early Tx threshold 0x27
0xF0: Func Event 0x00400030
0xF4: Func Event Mask 0x00000000
0xF8: Func Preset State 0x000303ff
0xFC: Func Force Event 0x00000000
-
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-01-25 5:59 ` Marc Haber
@ 2019-01-25 6:49 ` Heiner Kallweit
2019-01-25 12:02 ` Marc Haber
0 siblings, 1 reply; 36+ messages in thread
From: Heiner Kallweit @ 2019-01-25 6:49 UTC (permalink / raw)
To: Marc Haber; +Cc: netdev
Hi Marc,
thanks a lot for the detailed analysis. That this ethtool sequence
ethtool -s <if> wol d
ethtool -s <if> wol g
helps makes me think that the following patch should help too.
Could you please test?
There's an old story why this call is missing. Certain notebooks immediately
woke up again if WoL was enabled and they were suspended. I think they
should disable WoL instead of having this hack in the driver.
Heiner
---
drivers/net/ethernet/realtek/r8169.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 04c403539..1d101659f 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -7423,6 +7423,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
}
tp->saved_wolopts = __rtl8169_get_wol(tp);
+ device_set_wakeup_enable(&pdev->dev, tp->saved_wolopts);
mutex_init(&tp->wk.mutex);
INIT_WORK(&tp->wk.work, rtl_task);
--
2.20.1
On 25.01.2019 06:59, Marc Haber wrote:
> Hi Heiner,
>
> On Tue, Jan 22, 2019 at 07:47:45PM +0100, Heiner Kallweit wrote:
>> Which version of 4.18 are you running that is ok? To check the code ..
>
> I pull over drivers/net/ethernet/realtek/r8169.c from an unpacked
> 4.18.16 source tree. It sets RTL8169_VERSION "2.3LK-NAPI". The last
> commit in this file's history is
>
> commit 241e5a13a5ad75fd0b5a47b583e098fa08917d5c
> Author: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
> Date: Thu Oct 11 16:02:10 2018 +0200
>
> r8169: set RX_MULTI_EN bit in RxConfig for 8168F-family chips
>
> Unfortunately, very different r8169.c in 4.20.3 also sets RTL8169_VERSION "2.3LK-NAPI", so we cannot use this as identification.
>
>> Based on what I wrote above, could you try the following sequence and
>> check whether wake from S3 works then?
>>
>> ethtool -s <if> wol d
>> ethtool -s <if> wol g
>
> This test was done with the Debian kernel package 4.20.0-trunk-amd64,
> which contains a kernel 4.20.1 compiled on 2018-12-24, from Debian's
> experimental repository.
>
> This are my steps:
> (1) ethtool -s lanc0 wol d
> (2) ethtool -s lanc0 wol g
> (3) systemctl suspend
> (4) system gows down into Suspend to RAM, an audible *click* from a
> relay, power LED blinking, Switch reporting that the ethernet link state
> changed from 1000Full to down and then to 10Full.
> (5) sent a magic packet
> (6) *click* system up again. This is good.
> (7) switch reported link state change from 10Full to down and then to
> 1000Full
> (8) system and network operational
> (9) shut down the system completely, remove power. all LEDs off, link
> down
> (10) re-plug power, all LEDs off, link 10Full
> (11) push power button, bring system up again with Debian's 4.20 kernel
> (12) link up at 1000Full
> (12a) take register dump, exhibit 12a
> (13) systemctl suspend
> (14) system gows down into Suspend to RAM, an audible *click* from a
> relay, power LED blinking, Switch reporting that the ethernet link state
> changed from 1000Full to down and then to 10Full.
> (15) send magic packet identical to step (5)
> (16) system remains suspended, blinking LED; link 10Full
> (17) push any key on keyboard
> (18) *click* system up again. This is good.
> (19) switch reported link state change from 10Full to down and then to
> 1000Full
> (19a) take register dump, exhibit 19a
> (20) system and network operational
> (21) repeat steps (1) through (5)
> (22) system reacts to magic packet and wakes up
> (23) ethtool -s lanc0 wol d
> (24) ethtool -s lanc0 wol g
> (25) take register dump, exhibit 25
> (26) systemctl suspend
> (27) system gows down into Suspend to RAM, an audible *click* from a
> relay, power LED blinking, Switch reporting that the ethernet link state
> changed from 1000Full to down and then to 10Full.
> (28) sent a magic packet
> (29) *click* system up again. This is good.
> (30) switch reported link state change from 10Full to down and then to
> 1000Full
> (31) take register dump, exhibit 31
> (32) system and network operational
>
> So, our hypothesis is now that the older driver does "something" that
> the new driver doesn't, but what is needed for my machine to wake up on
> magic packet from suspend to RAM. the two ethtool calls do seem to fix
> that.
>
> Unfortunately, exhibits 19a, 25 and 31 are identical, and exhibit 12a
> only differs in a single line, PHY access holding 0x8001796d instead of
> 0x80040de1. So, whatever the two ethtools do, it is not visible in the
> register dump.
>
> I repaeted the experiment with stock 4.20.4, with the same results, and
> 4.20.4 with a r8169.c transplant from 4.18.16, with the result of
> ethtool not needed.
>
> Exhibits from the stock 4.20.4 experiments:
> exhibit-4.20.4-preeth-presleep - direct after boot
> exhibit-4.20.4-preeth-postsleep - after suspend with manual wakeup needed
> exhibit-4.20.4-posteth-presleep - after the two ethtool calls
> exhibit-4.20.4-posteth-postsleep - after successful wake on lan
>
> Exhibits from the 4.20.4+transplant experiments:
> exhibit-4.18-presleep - direct after boot
> exhibit-4.18-postsleep - after successful wake on LAN.
>
> I hope this helps. Let me know if additional data is helpful.
>
> Greetings
> Marc
>
^ permalink raw reply related [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-01-25 6:49 ` Heiner Kallweit
@ 2019-01-25 12:02 ` Marc Haber
2019-01-25 18:22 ` Heiner Kallweit
0 siblings, 1 reply; 36+ messages in thread
From: Marc Haber @ 2019-01-25 12:02 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: netdev
On Fri, Jan 25, 2019 at 07:49:56AM +0100, Heiner Kallweit wrote:
> thanks a lot for the detailed analysis. That this ethtool sequence
>
> ethtool -s <if> wol d
> ethtool -s <if> wol g
>
> helps makes me think that the following patch should help too.
> Could you please test?
That patch didn't apply cleanly because the rtl_init_one in kernel
4.20.4 is missing the INIT_WORK call at this place.
And it doesn't change the behavior, the two ethtool calls are needed so
that the host wakes up from suspend to ram on a magic packet.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-01-25 12:02 ` Marc Haber
@ 2019-01-25 18:22 ` Heiner Kallweit
2019-01-26 13:56 ` Marc Haber
0 siblings, 1 reply; 36+ messages in thread
From: Heiner Kallweit @ 2019-01-25 18:22 UTC (permalink / raw)
To: Marc Haber; +Cc: netdev
On 25.01.2019 13:02, Marc Haber wrote:
> On Fri, Jan 25, 2019 at 07:49:56AM +0100, Heiner Kallweit wrote:
>> thanks a lot for the detailed analysis. That this ethtool sequence
>>
>> ethtool -s <if> wol d
>> ethtool -s <if> wol g
>>
>> helps makes me think that the following patch should help too.
>> Could you please test?
>
> That patch didn't apply cleanly because the rtl_init_one in kernel
> 4.20.4 is missing the INIT_WORK call at this place.
>
> And it doesn't change the behavior, the two ethtool calls are needed so
> that the host wakes up from suspend to ram on a magic packet.
>
Then I'm slowly running out of ideas. New in 4.19 is a check for invalid
WoL flags, but usually the caller should warn if -EINVAL is returned.
Nevertheless, could you try the following and check whether the warning
is triggered?
---
drivers/net/ethernet/realtek/r8169.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 04c403539..a27cfc6e7 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -1491,8 +1491,10 @@ static int rtl8169_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
struct rtl8169_private *tp = netdev_priv(dev);
struct device *d = tp_to_dev(tp);
- if (wol->wolopts & ~WAKE_ANY)
+ if (wol->wolopts & ~WAKE_ANY) {
+ pr_warn("invalid WoL value: 0x%08x\n", wol->wolopts);
return -EINVAL;
+ }
pm_runtime_get_noresume(d);
--
2.20.1
> Greetings
> Marc
>
Heiner
^ permalink raw reply related [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-01-25 18:22 ` Heiner Kallweit
@ 2019-01-26 13:56 ` Marc Haber
2019-01-26 14:04 ` Heiner Kallweit
0 siblings, 1 reply; 36+ messages in thread
From: Marc Haber @ 2019-01-26 13:56 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: netdev
On Fri, Jan 25, 2019 at 07:22:36PM +0100, Heiner Kallweit wrote:
> Then I'm slowly running out of ideas. New in 4.19 is a check for invalid
> WoL flags, but usually the caller should warn if -EINVAL is returned.
> Nevertheless, could you try the following and check whether the warning
> is triggered?
Compiled the kernel, went through the motions:
- boot
- suspend
- try unsuccessful WoL
- wake up manually
- do ethtool gymnastics
- suspend
- try successful WoL
- grep syslog for "WoL", nothing found.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-01-26 13:56 ` Marc Haber
@ 2019-01-26 14:04 ` Heiner Kallweit
2019-01-26 17:07 ` Marc Haber
0 siblings, 1 reply; 36+ messages in thread
From: Heiner Kallweit @ 2019-01-26 14:04 UTC (permalink / raw)
To: Marc Haber; +Cc: netdev
On 26.01.2019 14:56, Marc Haber wrote:
> On Fri, Jan 25, 2019 at 07:22:36PM +0100, Heiner Kallweit wrote:
>> Then I'm slowly running out of ideas. New in 4.19 is a check for invalid
>> WoL flags, but usually the caller should warn if -EINVAL is returned.
>> Nevertheless, could you try the following and check whether the warning
>> is triggered?
>
> Compiled the kernel, went through the motions:
>
> - boot
> - suspend
> - try unsuccessful WoL
> - wake up manually
> - do ethtool gymnastics
> - suspend
> - try successful WoL
> - grep syslog for "WoL", nothing found.
>
Thanks for testing. Then the only way to find the offending commit is bisecting.
Let me know if you need support.
I can't reproduce the issue on latest kernels even though RTL8168evl and RTL8168g
use the same WoL code path.
> Greetings
> Marc
>
Heiner
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-01-13 16:01 ` Marc Haber
2019-01-13 16:19 ` Heiner Kallweit
@ 2019-01-26 14:08 ` Heiner Kallweit
2019-01-26 14:09 ` Heiner Kallweit
1 sibling, 1 reply; 36+ messages in thread
From: Heiner Kallweit @ 2019-01-26 14:08 UTC (permalink / raw)
To: Marc Haber; +Cc: netdev
On 13.01.2019 17:01, Marc Haber wrote:
> On Sat, Jan 12, 2019 at 09:28:48PM +0100, Heiner Kallweit wrote:
>> On 12.01.2019 21:08, Marc Haber wrote:
>>> I am writing to all people who have commits in r8169.c between the v4.18
>>> and v4.19 tags in the Linux kernel. Please ignore as appropriate. If
>>> you'd prefer that to be on a mailing list, please indicate on which list
>>> you want to have that, and I'll resend.
>>>
>> It should be cc'ed to the netdev mailing list, as listed in MAINTAINERS.
>
> I have bounced the original message there. Sorry for missing that, I was
> not aware that the MAINTAINERS file goes down on a single driver level.
>
>>> My desktop copmuter has the following network interface:
>>>
>>> 06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
>>> Subsystem: ASUSTeK Computer Inc. P8P67 and other motherboards
>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>>> Latency: 0, Cache Line Size: 64 bytes
>>> Interrupt: pin A routed to IRQ 17
>>> NUMA node: 0
>>> Region 0: I/O ports at e800 [size=256]
>>> Region 2: Memory at fdfff000 (64-bit, prefetchable) [size=4K]
>>> Region 4: Memory at fdff8000 (64-bit, prefetchable) [size=16K]
>>> Capabilities: <access denied>
>>> Kernel driver in use: r8169
>>> Kernel modules: r8169
>>>
>> Unfortunately there's different chip versions with the same description.
>> Please provide the result of "dmesg | grep XID".
>
> [1/5004]mh@fan:~ $ dmesg | grep XID
> [ 2.671004] r8169 0000:06:00.0 eth0: RTL8168evl/8111evl, 54:04:a6:82:21:00, XID 2c900800, IRQ 29
>
>>> I regularly buíld a VPN tunnel to my local network from 'on the road'
>>> and use WoL to wake up the desktop box when I need it.
>>>
>>> Since kernel 4.19, that does not work any more, the desktop remains
>>> suspended when I send it a magic packet. This still applies to 4.20.1,
>>> and it still works with any 4.18 kernel.
>>>
>> WoL works perfectly fine here with r8169 from runtime-suspend and
>> from S3. How do you enable WoL? And which WoL method do you use
>> (magic packet or ..) ?
>
> I do enable WOL via systemd-networkd:
> [7/5009]mh@fan:~ $ cat /etc/systemd/network/10-lanc0.link
> [Match]
> MACAddress=54:04:a6:82:21:00
>
> [Link]
> Name=lanc0
> WakeOnLan=magic
>
> and I wake up the box by calling
>
> sudo etherwake -i int182 54:04:a6:82:21:00
>
> on the router. int182 is the interface name of the correct interface,
> this is proven correct by the fact that the box wakes up just fine with
> older version of the driver.
>
>> Please provide a register dump (ethtool -d <if>).
>
> The register dump is here (obtained with 4.20.1 with the r8169.c from
> 4.18):
> [5/5008]mh@fan:~ $ sudo ethtool -d lanc0
Just one more thing because this register dump was with the r8169 driver
from 4.18 which is known to work.
Can you provide a register dump from a 4.20 r8169 which suffers from the issue?
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-01-26 14:08 ` Heiner Kallweit
@ 2019-01-26 14:09 ` Heiner Kallweit
0 siblings, 0 replies; 36+ messages in thread
From: Heiner Kallweit @ 2019-01-26 14:09 UTC (permalink / raw)
To: Marc Haber; +Cc: netdev
On 26.01.2019 15:08, Heiner Kallweit wrote:
> On 13.01.2019 17:01, Marc Haber wrote:
>> On Sat, Jan 12, 2019 at 09:28:48PM +0100, Heiner Kallweit wrote:
>>> On 12.01.2019 21:08, Marc Haber wrote:
>>>> I am writing to all people who have commits in r8169.c between the v4.18
>>>> and v4.19 tags in the Linux kernel. Please ignore as appropriate. If
>>>> you'd prefer that to be on a mailing list, please indicate on which list
>>>> you want to have that, and I'll resend.
>>>>
>>> It should be cc'ed to the netdev mailing list, as listed in MAINTAINERS.
>>
>> I have bounced the original message there. Sorry for missing that, I was
>> not aware that the MAINTAINERS file goes down on a single driver level.
>>
>>>> My desktop copmuter has the following network interface:
>>>>
>>>> 06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
>>>> Subsystem: ASUSTeK Computer Inc. P8P67 and other motherboards
>>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
>>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>>>> Latency: 0, Cache Line Size: 64 bytes
>>>> Interrupt: pin A routed to IRQ 17
>>>> NUMA node: 0
>>>> Region 0: I/O ports at e800 [size=256]
>>>> Region 2: Memory at fdfff000 (64-bit, prefetchable) [size=4K]
>>>> Region 4: Memory at fdff8000 (64-bit, prefetchable) [size=16K]
>>>> Capabilities: <access denied>
>>>> Kernel driver in use: r8169
>>>> Kernel modules: r8169
>>>>
>>> Unfortunately there's different chip versions with the same description.
>>> Please provide the result of "dmesg | grep XID".
>>
>> [1/5004]mh@fan:~ $ dmesg | grep XID
>> [ 2.671004] r8169 0000:06:00.0 eth0: RTL8168evl/8111evl, 54:04:a6:82:21:00, XID 2c900800, IRQ 29
>>
>>>> I regularly buíld a VPN tunnel to my local network from 'on the road'
>>>> and use WoL to wake up the desktop box when I need it.
>>>>
>>>> Since kernel 4.19, that does not work any more, the desktop remains
>>>> suspended when I send it a magic packet. This still applies to 4.20.1,
>>>> and it still works with any 4.18 kernel.
>>>>
>>> WoL works perfectly fine here with r8169 from runtime-suspend and
>>> from S3. How do you enable WoL? And which WoL method do you use
>>> (magic packet or ..) ?
>>
>> I do enable WOL via systemd-networkd:
>> [7/5009]mh@fan:~ $ cat /etc/systemd/network/10-lanc0.link
>> [Match]
>> MACAddress=54:04:a6:82:21:00
>>
>> [Link]
>> Name=lanc0
>> WakeOnLan=magic
>>
>> and I wake up the box by calling
>>
>> sudo etherwake -i int182 54:04:a6:82:21:00
>>
>> on the router. int182 is the interface name of the correct interface,
>> this is proven correct by the fact that the box wakes up just fine with
>> older version of the driver.
>>
>>> Please provide a register dump (ethtool -d <if>).
>>
>> The register dump is here (obtained with 4.20.1 with the r8169.c from
>> 4.18):
>> [5/5008]mh@fan:~ $ sudo ethtool -d lanc0
>
> Just one more thing because this register dump was with the r8169 driver
> from 4.18 which is known to work.
> Can you provide a register dump from a 4.20 r8169 which suffers from the issue?
>
Sorry, just saw that you did so already.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-01-26 14:04 ` Heiner Kallweit
@ 2019-01-26 17:07 ` Marc Haber
2019-01-26 19:22 ` Heiner Kallweit
0 siblings, 1 reply; 36+ messages in thread
From: Marc Haber @ 2019-01-26 17:07 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: netdev
On Sat, Jan 26, 2019 at 03:04:34PM +0100, Heiner Kallweit wrote:
> Thanks for testing. Then the only way to find the offending commit is bisecting.
:-(
Bisecting between which tags?
Greetings
Ma "at least this issue is readily reproducible" rc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-01-26 17:07 ` Marc Haber
@ 2019-01-26 19:22 ` Heiner Kallweit
2019-01-27 20:55 ` Marc Haber
0 siblings, 1 reply; 36+ messages in thread
From: Heiner Kallweit @ 2019-01-26 19:22 UTC (permalink / raw)
To: Marc Haber; +Cc: netdev
On 26.01.2019 18:07, Marc Haber wrote:
> On Sat, Jan 26, 2019 at 03:04:34PM +0100, Heiner Kallweit wrote:
>> Thanks for testing. Then the only way to find the offending commit is bisecting.
>
> :-(
>
> Bisecting between which tags?
>
You could go with this range:
from 4ff364662814 ("r8169: replace get_protocol with vlan_get_protocol")
to 649f0837a8cc ("r8169: fix broken Wake-on-LAN from S5 (poweroff)")
> Greetings
> Ma "at least this issue is readily reproducible" rc
>
Heiner
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-01-26 19:22 ` Heiner Kallweit
@ 2019-01-27 20:55 ` Marc Haber
2019-01-27 21:09 ` Heiner Kallweit
0 siblings, 1 reply; 36+ messages in thread
From: Marc Haber @ 2019-01-27 20:55 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: netdev
On Sat, Jan 26, 2019 at 08:22:33PM +0100, Heiner Kallweit wrote:
> You could go with this range:
> from 4ff364662814 ("r8169: replace get_protocol with vlan_get_protocol")
> to 649f0837a8cc ("r8169: fix broken Wake-on-LAN from S5 (poweroff)")
I am quite inexperienced with bisecting and am therefore giving a better
account of my actions here.
[2/4994]mh@fan:~/linux/git/linux ((v4.18.16) %) $ git pull
remote: Counting objects: 786, done.
remote: Compressing objects: 100% (197/197), done.
remote: Total 786 (delta 659), reused 697 (delta 589)
Receiving objects: 100% (786/786), 146.00 KiB | 1.20 MiB/s, done.
Resolving deltas: 100% (659/659), completed with 237 local objects.
From git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux
ba6069759381..1fc7f56db7a7 master -> origin/master
You are not currently on a branch.
1 [3/4995]mh@fan:~/linux/git/linux ((v4.18.16) %) $ git checkout 4ff364662814
Checking out files: 100% (13994/13994), done.
Previous HEAD position was 6b3252287aa2 Linux 4.18.16
HEAD is now at 4ff364662814 r8169: replace get_protocol with vlan_get_protocol
[4/4996]mh@fan:~/linux/git/linux ((4ff364662814...) %) $ git bisect start drivers/net/ethernet/realtek/r8169.c
[5/4997]mh@fan:~/linux/git/linux ((4ff364662814...) %|BISECTING) $
(copy 4.20 config, make oldconfig, say no to everything, make deb-pkg, install and try)
this boots and wakes up on magic packet from suspend to ram
[2/4994]mh@fan:~/linux/git/linux ((4ff364662814...) *%|BISECTING) $ git bisect good
[3/4995]mh@fan:~/linux/git/linux ((4ff364662814...) *%|BISECTING) $ git checkout 649f0837a8cc
Checking out files: 100% (21794/21794), done.
M scripts/package/Makefile
Previous HEAD position was 4ff364662814 r8169: replace get_protocol with vlan_get_protocol
HEAD is now at 649f0837a8cc r8169: fix broken Wake-on-LAN from S5 (poweroff)
[4/4996]mh@fan:~/linux/git/linux ((649f0837a8cc...) *%|BISECTING) $
(copy 4.20 config, make oldconfig, say no to everything, make deb-pkg, install and try)
this boots and does not wake up from StR on magic packet, after
waking up with any key on the keyboard I had an amdgpu issue on the console
and a dead console, but was able to ssh in and reboot.
[2/4994]mh@fan:~/linux/git/linux ((649f0837a8cc...) *%|BISECTING) $ git
bisect bad
Bisecting: 33 revisions left to test after this (roughly 5 steps)
[098b01ad9837b4d4d0022f407300f069a999e55a] r8169: don't include asm
headers directly
[3/4995]mh@fan:~/linux/git/linux ((098b01ad9837...) *%|BISECTING) $
I think I am on the right way here, am I?
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-01-27 20:55 ` Marc Haber
@ 2019-01-27 21:09 ` Heiner Kallweit
2019-01-28 7:30 ` Marc Haber
0 siblings, 1 reply; 36+ messages in thread
From: Heiner Kallweit @ 2019-01-27 21:09 UTC (permalink / raw)
To: Marc Haber; +Cc: netdev
On 27.01.2019 21:55, Marc Haber wrote:
> On Sat, Jan 26, 2019 at 08:22:33PM +0100, Heiner Kallweit wrote:
>> You could go with this range:
>> from 4ff364662814 ("r8169: replace get_protocol with vlan_get_protocol")
>> to 649f0837a8cc ("r8169: fix broken Wake-on-LAN from S5 (poweroff)")
>
> I am quite inexperienced with bisecting and am therefore giving a better
> account of my actions here.
>
> [2/4994]mh@fan:~/linux/git/linux ((v4.18.16) %) $ git pull
> remote: Counting objects: 786, done.
> remote: Compressing objects: 100% (197/197), done.
> remote: Total 786 (delta 659), reused 697 (delta 589)
> Receiving objects: 100% (786/786), 146.00 KiB | 1.20 MiB/s, done.
> Resolving deltas: 100% (659/659), completed with 237 local objects.
>>From git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux
> ba6069759381..1fc7f56db7a7 master -> origin/master
> You are not currently on a branch.
> 1 [3/4995]mh@fan:~/linux/git/linux ((v4.18.16) %) $ git checkout 4ff364662814
> Checking out files: 100% (13994/13994), done.
> Previous HEAD position was 6b3252287aa2 Linux 4.18.16
> HEAD is now at 4ff364662814 r8169: replace get_protocol with vlan_get_protocol
> [4/4996]mh@fan:~/linux/git/linux ((4ff364662814...) %) $ git bisect start drivers/net/ethernet/realtek/r8169.c
> [5/4997]mh@fan:~/linux/git/linux ((4ff364662814...) %|BISECTING) $
> (copy 4.20 config, make oldconfig, say no to everything, make deb-pkg, install and try)
> this boots and wakes up on magic packet from suspend to ram
> [2/4994]mh@fan:~/linux/git/linux ((4ff364662814...) *%|BISECTING) $ git bisect good
> [3/4995]mh@fan:~/linux/git/linux ((4ff364662814...) *%|BISECTING) $ git checkout 649f0837a8cc
> Checking out files: 100% (21794/21794), done.
> M scripts/package/Makefile
> Previous HEAD position was 4ff364662814 r8169: replace get_protocol with vlan_get_protocol
> HEAD is now at 649f0837a8cc r8169: fix broken Wake-on-LAN from S5 (poweroff)
> [4/4996]mh@fan:~/linux/git/linux ((649f0837a8cc...) *%|BISECTING) $
> (copy 4.20 config, make oldconfig, say no to everything, make deb-pkg, install and try)
> this boots and does not wake up from StR on magic packet, after
> waking up with any key on the keyboard I had an amdgpu issue on the console
> and a dead console, but was able to ssh in and reboot.
>
> [2/4994]mh@fan:~/linux/git/linux ((649f0837a8cc...) *%|BISECTING) $ git
> bisect bad
> Bisecting: 33 revisions left to test after this (roughly 5 steps)
> [098b01ad9837b4d4d0022f407300f069a999e55a] r8169: don't include asm
> headers directly
> [3/4995]mh@fan:~/linux/git/linux ((098b01ad9837...) *%|BISECTING) $
>
> I think I am on the right way here, am I?
>
> Greetings
> Marc
>
Yes. All you have to do after each "git bisect good/bad" is build again,
test, and make current build as good or bad.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-01-27 21:09 ` Heiner Kallweit
@ 2019-01-28 7:30 ` Marc Haber
2019-01-28 19:02 ` Heiner Kallweit
2019-01-28 20:22 ` Marc Haber
0 siblings, 2 replies; 36+ messages in thread
From: Marc Haber @ 2019-01-28 7:30 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: netdev
On Sun, Jan 27, 2019 at 10:09:51PM +0100, Heiner Kallweit wrote:
> Yes. All you have to do after each "git bisect good/bad" is build again,
> test, and make current build as good or bad.
Will report back if I get any results. When I bisected last time, I
ended up with a kernel that didn't even boot, but with 5 steps this is
probably manageable. Will take most of the week though.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-01-28 7:30 ` Marc Haber
@ 2019-01-28 19:02 ` Heiner Kallweit
2019-01-28 20:59 ` Marc Haber
2019-01-28 20:22 ` Marc Haber
1 sibling, 1 reply; 36+ messages in thread
From: Heiner Kallweit @ 2019-01-28 19:02 UTC (permalink / raw)
To: Marc Haber; +Cc: netdev
On 28.01.2019 08:30, Marc Haber wrote:
> On Sun, Jan 27, 2019 at 10:09:51PM +0100, Heiner Kallweit wrote:
>> Yes. All you have to do after each "git bisect good/bad" is build again,
>> test, and make current build as good or bad.
>
> Will report back if I get any results. When I bisected last time, I
> ended up with a kernel that didn't even boot, but with 5 steps this is
> probably manageable. Will take most of the week though.
>
> Greetings
> Marc
>
One more test .. Can you provide the output of the following under 4.18 and under 4.19?
It may not apply cleanly, but you get the idea. The message is written when suspending.
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 3e650bd9e..3a8b4b1b1 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -6927,6 +6927,8 @@ static int rtl8169_suspend(struct device *device)
rtl8169_net_suspend(dev);
clk_disable_unprepare(tp->clk);
+ pr_info("may wakeup? %d\n", device_may_wakeup(device));
+
return 0;
}
--
2.20.1
^ permalink raw reply related [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-01-28 7:30 ` Marc Haber
2019-01-28 19:02 ` Heiner Kallweit
@ 2019-01-28 20:22 ` Marc Haber
2019-01-28 20:28 ` Heiner Kallweit
1 sibling, 1 reply; 36+ messages in thread
From: Marc Haber @ 2019-01-28 20:22 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: netdev
On Mon, Jan 28, 2019 at 08:30:10AM +0100, Marc Haber wrote:
> On Sun, Jan 27, 2019 at 10:09:51PM +0100, Heiner Kallweit wrote:
> > Yes. All you have to do after each "git bisect good/bad" is build again,
> > test, and make current build as good or bad.
>
> Will report back if I get any results. When I bisected last time, I
> ended up with a kernel that didn't even boot, but with 5 steps this is
> probably manageable. Will take most of the week though.
[3/4995]mh@fan:~/linux/git/linux ((6fcf9b1d4d6c...) *%|BISECTING) $ git bislog
git bisect start 'drivers/net/ethernet/realtek/r8169.c'
# good: [4ff36466281428734791d3cc6331b8cca7c76019] r8169: replace get_protocol with vlan_get_protocol
git bisect good 4ff36466281428734791d3cc6331b8cca7c76019
# bad: [649f0837a8cc2b39329f2de00fa0d04b029291c5] r8169: fix broken Wake-on-LAN from S5 (poweroff)
git bisect bad 649f0837a8cc2b39329f2de00fa0d04b029291c5
# bad: [098b01ad9837b4d4d0022f407300f069a999e55a] r8169: don't include asm headers directly
git bisect bad 098b01ad9837b4d4d0022f407300f069a999e55a
[4/4996]mh@fan:~/linux/git/linux ((6fcf9b1d4d6c...) *%|BISECTING) $
The kernel that I now have is 6fcf9b1d4d6cd38202247de5c0ac7d85c4483abb and
that one throws oopses on booting and won't suspend at all.
Can I continue from here while still making sense?
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-01-28 20:22 ` Marc Haber
@ 2019-01-28 20:28 ` Heiner Kallweit
2019-01-29 7:32 ` Marc Haber
0 siblings, 1 reply; 36+ messages in thread
From: Heiner Kallweit @ 2019-01-28 20:28 UTC (permalink / raw)
To: Marc Haber; +Cc: netdev
On 28.01.2019 21:22, Marc Haber wrote:
> On Mon, Jan 28, 2019 at 08:30:10AM +0100, Marc Haber wrote:
>> On Sun, Jan 27, 2019 at 10:09:51PM +0100, Heiner Kallweit wrote:
>>> Yes. All you have to do after each "git bisect good/bad" is build again,
>>> test, and make current build as good or bad.
>>
>> Will report back if I get any results. When I bisected last time, I
>> ended up with a kernel that didn't even boot, but with 5 steps this is
>> probably manageable. Will take most of the week though.
>
> [3/4995]mh@fan:~/linux/git/linux ((6fcf9b1d4d6c...) *%|BISECTING) $ git bislog
> git bisect start 'drivers/net/ethernet/realtek/r8169.c'
> # good: [4ff36466281428734791d3cc6331b8cca7c76019] r8169: replace get_protocol with vlan_get_protocol
> git bisect good 4ff36466281428734791d3cc6331b8cca7c76019
> # bad: [649f0837a8cc2b39329f2de00fa0d04b029291c5] r8169: fix broken Wake-on-LAN from S5 (poweroff)
> git bisect bad 649f0837a8cc2b39329f2de00fa0d04b029291c5
> # bad: [098b01ad9837b4d4d0022f407300f069a999e55a] r8169: don't include asm headers directly
> git bisect bad 098b01ad9837b4d4d0022f407300f069a999e55a
> [4/4996]mh@fan:~/linux/git/linux ((6fcf9b1d4d6c...) *%|BISECTING) $
>
> The kernel that I now have is 6fcf9b1d4d6cd38202247de5c0ac7d85c4483abb and
> that one throws oopses on booting and won't suspend at all.
>
> Can I continue from here while still making sense?
>
Not w/o knowing whether this version is good or bad.
Because we're interested in file r8169.c only, you could test r8169.c from the
oops-ing kernel on top of a working kernel version.
> Greetings
> Marc
>
Heiner
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-01-28 19:02 ` Heiner Kallweit
@ 2019-01-28 20:59 ` Marc Haber
2019-01-28 21:21 ` Heiner Kallweit
0 siblings, 1 reply; 36+ messages in thread
From: Marc Haber @ 2019-01-28 20:59 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: netdev
On Mon, Jan 28, 2019 at 08:02:47PM +0100, Heiner Kallweit wrote:
> One more test .. Can you provide the output of the following under 4.18 and under 4.19?
> It may not apply cleanly, but you get the idea. The message is written when suspending.
I booted, suspeneded, sent a magic packet that got ignored. I then woke
the box up with the any key, went through the ethtool motions, suspended
again, sent a magic paket that the machine acted on and woke up
Log says:
1 [1/4994]mh@fan:~ $ grep 'may wakeup' /var/log/syslog/syslog
Jan 28 21:51:44 fan kernel: [ 77.571211] may wakeup? 0
Jan 28 21:54:11 fan kernel: [ 183.994131] may wakeup? 1
[2/4995]mh@fan:~ $
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-01-28 20:59 ` Marc Haber
@ 2019-01-28 21:21 ` Heiner Kallweit
2019-01-29 11:52 ` Marc Haber
0 siblings, 1 reply; 36+ messages in thread
From: Heiner Kallweit @ 2019-01-28 21:21 UTC (permalink / raw)
To: Marc Haber; +Cc: netdev
On 28.01.2019 21:59, Marc Haber wrote:
> On Mon, Jan 28, 2019 at 08:02:47PM +0100, Heiner Kallweit wrote:
>> One more test .. Can you provide the output of the following under 4.18 and under 4.19?
>> It may not apply cleanly, but you get the idea. The message is written when suspending.
>
> I booted, suspeneded, sent a magic packet that got ignored. I then woke
> the box up with the any key, went through the ethtool motions, suspended
> again, sent a magic paket that the machine acted on and woke up
>
> Log says:
> 1 [1/4994]mh@fan:~ $ grep 'may wakeup' /var/log/syslog/syslog
> Jan 28 21:51:44 fan kernel: [ 77.571211] may wakeup? 0
> Jan 28 21:54:11 fan kernel: [ 183.994131] may wakeup? 1
> [2/4995]mh@fan:~ $
>
> Greetings
> Marc
>
Thanks, this makes clearer what's going on.
This change to r8169
bde135a672bf ("r8169: only enable PCI wakeups when WOL is active")
removed marking the device as wakeup-enabled to work around an
issue on certain notebooks (see commit message for details).
ethtool doesn't care about the current settings and sets the new ones
(wakeup-enabling the device). systemd however checks the current settings
and writes new ones only if there's a change. Therefore in your case
systemd does nothing and device doesn't get wakeup-enabled.
Not totally clear to me is why it works under 4.18.
And I wonder why the following didn't work for you, you said it makes
no difference. Could you try again the following in addition to the
latest debug output statement?
drivers/net/ethernet/realtek/r8169.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 3e650bd9e..bd26d3f2e 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -7442,6 +7442,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
}
tp->saved_wolopts = __rtl8169_get_wol(tp);
+ device_set_wakeup_enable(&pdev->dev, tp->saved_wolopts);
mutex_init(&tp->wk.mutex);
INIT_WORK(&tp->wk.work, rtl_task);
--
^ permalink raw reply related [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-01-28 20:28 ` Heiner Kallweit
@ 2019-01-29 7:32 ` Marc Haber
2019-01-29 15:35 ` Marc Haber
0 siblings, 1 reply; 36+ messages in thread
From: Marc Haber @ 2019-01-29 7:32 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: netdev
On Mon, Jan 28, 2019 at 09:28:13PM +0100, Heiner Kallweit wrote:
> Because we're interested in file r8169.c only, you could test r8169.c
> from the oops-ing kernel on top of a working kernel version.
That's a really nice idea, and so obvious once one thinks about it.
According to bisect, the first bad commit is
19725496da5602b401eae389736ab00d1817e264
commit 19725496da5602b401eae389736ab00d1817e264
Merge: aea5f654e6b7 9981b4fb8684
Author: David S. Miller <davem@davemloft.net>
Date: Tue Jul 24 19:21:58 2018 -0700
Merge ra.kernel.org:/pub/scm/linux/kernel/git/davem/net
diff --cc drivers/net/ethernet/realtek/r8169.c
index 49a6e25ddc2b,eaedc11ed686..8ea1fa36ca43
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@@ -7396,9 -7734,24 +7396,8 @@@ static int rtl_init_one(struct pci_dev
return rc;
}
- /* override BIOS settings, use userspace tools to enable WOL */
- __rtl8169_set_wol(tp, 0);
+ tp->saved_wolopts = __rtl8169_get_wol(tp);
- if (rtl_tbi_enabled(tp)) {
- tp->set_speed = rtl8169_set_speed_tbi;
- tp->get_link_ksettings = rtl8169_get_link_ksettings_tbi;
- tp->phy_reset_enable = rtl8169_tbi_reset_enable;
- tp->phy_reset_pending = rtl8169_tbi_reset_pending;
- tp->link_ok = rtl8169_tbi_link_ok;
- tp->do_ioctl = rtl_tbi_ioctl;
- } else {
- tp->set_speed = rtl8169_set_speed_xmii;
- tp->get_link_ksettings = rtl8169_get_link_ksettings_xmii;
- tp->phy_reset_enable = rtl8169_xmii_reset_enable;
- tp->phy_reset_pending = rtl8169_xmii_reset_pending;
- tp->link_ok = rtl8169_xmii_link_ok;
- tp->do_ioctl = rtl_xmii_ioctl;
- }
-
mutex_init(&tp->wk.mutex);
u64_stats_init(&tp->rx_stats.syncp);
u64_stats_init(&tp->tx_stats.syncp);
What confuses me here is the big part where the "-" is not in column 1, and
patch -R calls it garbage.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-01-28 21:21 ` Heiner Kallweit
@ 2019-01-29 11:52 ` Marc Haber
0 siblings, 0 replies; 36+ messages in thread
From: Marc Haber @ 2019-01-29 11:52 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: netdev
On Mon, Jan 28, 2019 at 10:21:50PM +0100, Heiner Kallweit wrote:
> And I wonder why the following didn't work for you, you said it makes
> no difference. Could you try again the following in addition to the
> latest debug output statement?
This time it says
Jan 29 12:34:59 fan kernel: [ 141.397307] may wakeup? 1
Jan 29 12:46:39 fan kernel: [ 819.665683] may wakeup? 1
while the machine needed a manual wakeup at 12:34 as usual. The log
entry is only written after resume, first suspend was at 09:05 and the
machine was sleeping for three hours.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-01-29 7:32 ` Marc Haber
@ 2019-01-29 15:35 ` Marc Haber
2019-01-29 19:01 ` Heiner Kallweit
2019-01-29 21:20 ` Heiner Kallweit
0 siblings, 2 replies; 36+ messages in thread
From: Marc Haber @ 2019-01-29 15:35 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: netdev
Hi,
after having a good night's sleep over that, it's obviously a merge
commit which cannot easily be reverted. How would I continue after
identifying a merge commit as the culprit?
On Tue, Jan 29, 2019 at 08:32:53AM +0100, Marc Haber wrote:
> According to bisect, the first bad commit is
> 19725496da5602b401eae389736ab00d1817e264
>
> commit 19725496da5602b401eae389736ab00d1817e264
> Merge: aea5f654e6b7 9981b4fb8684
git diff aea5f654e6b7..19725496da5602b401eae389736ab00d1817e264,
filtered for r8169 looks manageable:
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -7396,8 +7396,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struc
return rc;
}
- /* override BIOS settings, use userspace tools to enable WOL */
- __rtl8169_set_wol(tp, 0);
+ tp->saved_wolopts = __rtl8169_get_wol(tp);
mutex_init(&tp->wk.mutex);
u64_stats_init(&tp->rx_stats.syncp);
but the other one seems unmanageably big:
[18/5009]mh@fan:~/linux/git/linux (master % u=) $ git diff 9981b4fb8684..19725496da5602b401eae389736ab00d1817e264 -- drivers/net/ethernet/realtek/r8169.c | diffstat
r8169.c | 815 ++++++++++++++++++----------------------------------------------
1 file changed, 234 insertions(+), 581 deletions(-)
[19/5009]mh@fan:~/linux/git/linux (master % u=) $
-------
But, indeed, adding the call to __rtl8169_set_wol(tp, 0) fixes the issue
for me and the machine now wakes up from StR on a magic packet without
having to go through strange ethtool motions.
-------
Would that code change be suitable for the official kernel cod?
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-01-29 15:35 ` Marc Haber
@ 2019-01-29 19:01 ` Heiner Kallweit
2019-01-30 8:46 ` Marc Haber
2019-01-29 21:20 ` Heiner Kallweit
1 sibling, 1 reply; 36+ messages in thread
From: Heiner Kallweit @ 2019-01-29 19:01 UTC (permalink / raw)
To: Marc Haber; +Cc: netdev
Hi Marc,
the change to replace __rtl8169_set_wol(tp, 0) doesn't seem to be the right commit
because it was included in 4.18 already. And if you read the commit description you'll
see that it was replaced because it caused issues with certain boards. Having said that
it's not an option for us.
Still I'm struggling to see where the relevant difference between 4.18 and 4.19 is.
Especially as 4.19 and also later versions work perfectly fine here.
Can you in addition apply the following (again it may not apply cleanly) and provide
the results for 4.18 and 4.19?
And from today's run, can you provide the full dmesg output? I'd like to check
why the message was written on resume only.
Heiner
---
drivers/net/ethernet/realtek/r8169.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index bd26d3f2e..e9c37f10c 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -1414,6 +1414,8 @@ static void rtl8169_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
wol->supported = WAKE_ANY;
wol->wolopts = tp->saved_wolopts;
rtl_unlock_work(tp);
+
+ pr_info("get_wol: 0x%08x\n", wol->wolopts);
}
static void __rtl8169_set_wol(struct rtl8169_private *tp, u32 wolopts)
@@ -1491,6 +1493,8 @@ static int rtl8169_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
struct rtl8169_private *tp = netdev_priv(dev);
struct device *d = tp_to_dev(tp);
+ pr_info("set_wol: 0x%08x\n", wol->wolopts);
+
if (wol->wolopts & ~WAKE_ANY)
return -EINVAL;
--
2.20.1
On 29.01.2019 16:35, Marc Haber wrote:
> Hi,
>
> after having a good night's sleep over that, it's obviously a merge
> commit which cannot easily be reverted. How would I continue after
> identifying a merge commit as the culprit?
>
> On Tue, Jan 29, 2019 at 08:32:53AM +0100, Marc Haber wrote:
>> According to bisect, the first bad commit is
>> 19725496da5602b401eae389736ab00d1817e264
>>
>> commit 19725496da5602b401eae389736ab00d1817e264
>> Merge: aea5f654e6b7 9981b4fb8684
>
> git diff aea5f654e6b7..19725496da5602b401eae389736ab00d1817e264,
> filtered for r8169 looks manageable:
>
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
> @@ -7396,8 +7396,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struc
> return rc;
> }
>
> - /* override BIOS settings, use userspace tools to enable WOL */
> - __rtl8169_set_wol(tp, 0);
> + tp->saved_wolopts = __rtl8169_get_wol(tp);
>
> mutex_init(&tp->wk.mutex);
> u64_stats_init(&tp->rx_stats.syncp);
>
> but the other one seems unmanageably big:
>
> [18/5009]mh@fan:~/linux/git/linux (master % u=) $ git diff 9981b4fb8684..19725496da5602b401eae389736ab00d1817e264 -- drivers/net/ethernet/realtek/r8169.c | diffstat
> r8169.c | 815 ++++++++++++++++++----------------------------------------------
> 1 file changed, 234 insertions(+), 581 deletions(-)
> [19/5009]mh@fan:~/linux/git/linux (master % u=) $
>
> -------
> But, indeed, adding the call to __rtl8169_set_wol(tp, 0) fixes the issue
> for me and the machine now wakes up from StR on a magic packet without
> having to go through strange ethtool motions.
> -------
>
> Would that code change be suitable for the official kernel cod?
>
> Greetings
> Marc
>
^ permalink raw reply related [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-01-29 15:35 ` Marc Haber
2019-01-29 19:01 ` Heiner Kallweit
@ 2019-01-29 21:20 ` Heiner Kallweit
2019-01-30 15:37 ` Marc Haber
1 sibling, 1 reply; 36+ messages in thread
From: Heiner Kallweit @ 2019-01-29 21:20 UTC (permalink / raw)
To: Marc Haber; +Cc: netdev
Hi Marc,
one more attempt, could you please test the following with 4.19 or 4.20
(w/o the other debug patches) ?
Rgds, Heiner
---
drivers/net/ethernet/realtek/r8169.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 3e650bd9e..2dab28115 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -1371,6 +1371,8 @@ static void rtl_link_chg_patch(struct rtl8169_private *tp)
#define WAKE_ANY (WAKE_PHY | WAKE_MAGIC | WAKE_UCAST | WAKE_BCAST | WAKE_MCAST)
+/* Don't delete it completely, in case we need to re-enable it */
+#if 0
static u32 __rtl8169_get_wol(struct rtl8169_private *tp)
{
u8 options;
@@ -1405,6 +1407,7 @@ static u32 __rtl8169_get_wol(struct rtl8169_private *tp)
return wolopts;
}
+#endif
static void rtl8169_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
{
@@ -4284,7 +4287,7 @@ static void rtl_wol_suspend_quirk(struct rtl8169_private *tp)
static bool rtl_wol_pll_power_down(struct rtl8169_private *tp)
{
- if (!__rtl8169_get_wol(tp))
+ if (!device_may_wakeup(tp_to_dev(tp)))
return false;
phy_speed_down(tp->phydev, false);
@@ -7441,8 +7444,6 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
return rc;
}
- tp->saved_wolopts = __rtl8169_get_wol(tp);
-
mutex_init(&tp->wk.mutex);
INIT_WORK(&tp->wk.work, rtl_task);
u64_stats_init(&tp->rx_stats.syncp);
--
2.20.1
On 29.01.2019 16:35, Marc Haber wrote:
> Hi,
>
> after having a good night's sleep over that, it's obviously a merge
> commit which cannot easily be reverted. How would I continue after
> identifying a merge commit as the culprit?
>
> On Tue, Jan 29, 2019 at 08:32:53AM +0100, Marc Haber wrote:
>> According to bisect, the first bad commit is
>> 19725496da5602b401eae389736ab00d1817e264
>>
>> commit 19725496da5602b401eae389736ab00d1817e264
>> Merge: aea5f654e6b7 9981b4fb8684
>
> git diff aea5f654e6b7..19725496da5602b401eae389736ab00d1817e264,
> filtered for r8169 looks manageable:
>
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
> @@ -7396,8 +7396,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struc
> return rc;
> }
>
> - /* override BIOS settings, use userspace tools to enable WOL */
> - __rtl8169_set_wol(tp, 0);
> + tp->saved_wolopts = __rtl8169_get_wol(tp);
>
> mutex_init(&tp->wk.mutex);
> u64_stats_init(&tp->rx_stats.syncp);
>
> but the other one seems unmanageably big:
>
> [18/5009]mh@fan:~/linux/git/linux (master % u=) $ git diff 9981b4fb8684..19725496da5602b401eae389736ab00d1817e264 -- drivers/net/ethernet/realtek/r8169.c | diffstat
> r8169.c | 815 ++++++++++++++++++----------------------------------------------
> 1 file changed, 234 insertions(+), 581 deletions(-)
> [19/5009]mh@fan:~/linux/git/linux (master % u=) $
>
> -------
> But, indeed, adding the call to __rtl8169_set_wol(tp, 0) fixes the issue
> for me and the machine now wakes up from StR on a magic packet without
> having to go through strange ethtool motions.
> -------
>
> Would that code change be suitable for the official kernel cod?
>
> Greetings
> Marc
>
^ permalink raw reply related [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-01-29 19:01 ` Heiner Kallweit
@ 2019-01-30 8:46 ` Marc Haber
0 siblings, 0 replies; 36+ messages in thread
From: Marc Haber @ 2019-01-30 8:46 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: netdev
On Tue, Jan 29, 2019 at 08:01:14PM +0100, Heiner Kallweit wrote:
> the change to replace __rtl8169_set_wol(tp, 0) doesn't seem to be the right commit
> because it was included in 4.18 already. And if you read the commit description you'll
> see that it was replaced because it caused issues with certain boards. Having said that
> it's not an option for us.
:-(
> Can you in addition apply the following (again it may not apply cleanly) and provide
> the results for 4.18 and 4.19?
In addition to the debug output? Can I do that together with the other
patch you sent yesterday or does that need to be two different tests?
> And from today's run, can you provide the full dmesg output? I'd like to check
> why the message was written on resume only.
I guess that it just didn't find its way to syslog before resume and got
stuck in some buffer during suspend.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-01-29 21:20 ` Heiner Kallweit
@ 2019-01-30 15:37 ` Marc Haber
2019-02-01 6:49 ` Heiner Kallweit
0 siblings, 1 reply; 36+ messages in thread
From: Marc Haber @ 2019-01-30 15:37 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: netdev
On Tue, Jan 29, 2019 at 10:20:48PM +0100, Heiner Kallweit wrote:
> one more attempt, could you please test the following with 4.19 or 4.20
> (w/o the other debug patches) ?
With the following patch, the machine wakes up fine on a WoL magic
packet:
nux-4.20.5/drivers/net/ethernet/realtek/r8169.c 2019-01-30 16:03:00.090841076 +0100
+++ orig/linux-4.20.5/drivers/net/ethernet/realtek/r8169.c 2019-01-26 09:20:52.000000000 +0100
@@ -1418,7 +1418,6 @@
#define WAKE_ANY (WAKE_PHY | WAKE_MAGIC | WAKE_UCAST | WAKE_BCAST | WAKE_MCAST)
-#if 0
static u32 __rtl8169_get_wol(struct rtl8169_private *tp)
{
u8 options;
@@ -1453,7 +1452,6 @@
return wolopts;
}
-#endif
static void rtl8169_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
{
@@ -1463,8 +1461,6 @@
wol->supported = WAKE_ANY;
wol->wolopts = tp->saved_wolopts;
rtl_unlock_work(tp);
-
- pr_info("get_wol: 0x%08x\n", wol->wolopts);
}
static void __rtl8169_set_wol(struct rtl8169_private *tp, u32 wolopts)
@@ -1540,8 +1536,6 @@
struct rtl8169_private *tp = netdev_priv(dev);
struct device *d = tp_to_dev(tp);
- pr_info("set_wol: 0x%08x\n", wol->wolopts);
-
if (wol->wolopts & ~WAKE_ANY)
return -EINVAL;
@@ -4174,7 +4168,7 @@
{
struct phy_device *phydev;
- if (!device_may_wakeup(tp_to_dev(tp)))
+ if (!__rtl8169_get_wol(tp))
return false;
/* phydev may not be attached to netdevice */
@@ -7372,6 +7366,8 @@
return rc;
}
+ tp->saved_wolopts = __rtl8169_get_wol(tp);
+
mutex_init(&tp->wk.mutex);
u64_stats_init(&tp->rx_stats.syncp);
u64_stats_init(&tp->tx_stats.syncp);
1 [14/5006]mh@fan:~/linux/4.20.5 $
I'll send the dmesg output to you in private e-mail
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-01-30 15:37 ` Marc Haber
@ 2019-02-01 6:49 ` Heiner Kallweit
2019-02-01 17:19 ` Marc Haber
0 siblings, 1 reply; 36+ messages in thread
From: Heiner Kallweit @ 2019-02-01 6:49 UTC (permalink / raw)
To: Marc Haber; +Cc: netdev
Great, thanks. This patch has been applied and is part of latest linux-next kernel already:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/?h=next-20190201
Would be much appreciated if you could build and test this kernel version.
Heiner
On 30.01.2019 16:37, Marc Haber wrote:
> On Tue, Jan 29, 2019 at 10:20:48PM +0100, Heiner Kallweit wrote:
>> one more attempt, could you please test the following with 4.19 or 4.20
>> (w/o the other debug patches) ?
>
> With the following patch, the machine wakes up fine on a WoL magic
> packet:
>
> nux-4.20.5/drivers/net/ethernet/realtek/r8169.c 2019-01-30 16:03:00.090841076 +0100
> +++ orig/linux-4.20.5/drivers/net/ethernet/realtek/r8169.c 2019-01-26 09:20:52.000000000 +0100
> @@ -1418,7 +1418,6 @@
>
> #define WAKE_ANY (WAKE_PHY | WAKE_MAGIC | WAKE_UCAST | WAKE_BCAST | WAKE_MCAST)
>
> -#if 0
> static u32 __rtl8169_get_wol(struct rtl8169_private *tp)
> {
> u8 options;
> @@ -1453,7 +1452,6 @@
>
> return wolopts;
> }
> -#endif
>
> static void rtl8169_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
> {
> @@ -1463,8 +1461,6 @@
> wol->supported = WAKE_ANY;
> wol->wolopts = tp->saved_wolopts;
> rtl_unlock_work(tp);
> -
> - pr_info("get_wol: 0x%08x\n", wol->wolopts);
> }
>
> static void __rtl8169_set_wol(struct rtl8169_private *tp, u32 wolopts)
> @@ -1540,8 +1536,6 @@
> struct rtl8169_private *tp = netdev_priv(dev);
> struct device *d = tp_to_dev(tp);
>
> - pr_info("set_wol: 0x%08x\n", wol->wolopts);
> -
> if (wol->wolopts & ~WAKE_ANY)
> return -EINVAL;
>
> @@ -4174,7 +4168,7 @@
> {
> struct phy_device *phydev;
>
> - if (!device_may_wakeup(tp_to_dev(tp)))
> + if (!__rtl8169_get_wol(tp))
> return false;
>
> /* phydev may not be attached to netdevice */
> @@ -7372,6 +7366,8 @@
> return rc;
> }
>
> + tp->saved_wolopts = __rtl8169_get_wol(tp);
> +
> mutex_init(&tp->wk.mutex);
> u64_stats_init(&tp->rx_stats.syncp);
> u64_stats_init(&tp->tx_stats.syncp);
> 1 [14/5006]mh@fan:~/linux/4.20.5 $
>
> I'll send the dmesg output to you in private e-mail
>
> Greetings
> Marc
>
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-02-01 6:49 ` Heiner Kallweit
@ 2019-02-01 17:19 ` Marc Haber
2019-02-01 18:24 ` Heiner Kallweit
0 siblings, 1 reply; 36+ messages in thread
From: Marc Haber @ 2019-02-01 17:19 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: netdev
On Fri, Feb 01, 2019 at 07:49:09AM +0100, Heiner Kallweit wrote:
> Great, thanks. This patch has been applied and is part of latest linux-next kernel already:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/?h=next-20190201
> Would be much appreciated if you could build and test this kernel version.
I regret that I have not been able to get this through the compiler.
When I clone the linux-next repo and try to build with deb-pkg, some
process chokes on the weird version number of the linux-next kernel, and
transplanting the r8169.c from linux-next on to 4.20.6, compile aborts:
In file included from drivers/net/ethernet/realtek/r8169.c:13:
./include/linux/pci.h:830:12: error: ‘PCI_VENDOR_ID_USR’ undeclared here (not in a function); did you mean ‘PCI_VENDOR_ID_UMC’?
.vendor = PCI_VENDOR_ID_##vend, .device = (dev), \
^~~~~~~~~~~~~~
drivers/net/ethernet/realtek/r8169.c:222:4: note: in expansion of macro ‘PCI_VDEVICE’
{ PCI_VDEVICE(USR, 0x0116), RTL_CFG_0 },
^~~~~~~~~~~
drivers/net/ethernet/realtek/r8169.c: In function ‘rtl8169_start_xmit’:
drivers/net/ethernet/realtek/r8169.c:6261:6: error: implicit declaration of function ‘__netdev_sent_queue’; did you mean ‘netdev_sent_queue’? [-Werror=implicit-function-declaration]
if (__netdev_sent_queue(dev, skb->len, skb->xmit_more))
^~~~~~~~~~~~~~~~~~~
netdev_sent_queue
drivers/net/ethernet/realtek/r8169.c: In function ‘r8169_phy_connect’:
drivers/net/ethernet/realtek/r8169.c:6653:22: warning: passing argument 1 of ‘linkmode_copy’ makes pointer from integer without a cast [-Wint-conversion]
linkmode_copy(phydev->advertising, phydev->supported);
~~~~~~^~~~~~~~~~~~~
In file included from ./include/linux/phy.h:22,
from drivers/net/ethernet/realtek/r8169.c:19:
./include/linux/linkmode.h:13:49: note: expected ‘long unsigned int *’ but argument is of type ‘u32’ {aka ‘unsigned int’}
static inline void linkmode_copy(unsigned long *dst, const unsigned long *src)
~~~~~~~~~~~~~~~^~~
drivers/net/ethernet/realtek/r8169.c:6653:43: warning: passing argument 2 of ‘linkmode_copy’ makes pointer from integer without a cast [-Wint-conversion]
linkmode_copy(phydev->advertising, phydev->supported);
~~~~~~^~~~~~~~~~~
In file included from ./include/linux/phy.h:22,
from drivers/net/ethernet/realtek/r8169.c:19:
./include/linux/linkmode.h:13:75: note: expected ‘const long unsigned int *’ but argument is of type ‘u32’ {aka ‘unsigned int’}
static inline void linkmode_copy(unsigned long *dst, const unsigned long *src)
~~~~~~~~~~~~~~~~~~~~~^~~
cc1: some warnings being treated as errors
make[4]: *** [scripts/Makefile.build:297: drivers/net/ethernet/realtek/r8169.o] Error 1
Will it help if I transplant more files from linux-next to 4.20.6?
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-02-01 17:19 ` Marc Haber
@ 2019-02-01 18:24 ` Heiner Kallweit
2019-02-01 18:41 ` Marc Haber
0 siblings, 1 reply; 36+ messages in thread
From: Heiner Kallweit @ 2019-02-01 18:24 UTC (permalink / raw)
To: Marc Haber; +Cc: netdev
It's too much effort to make the current r8169 compile under an older kernel.
But thanks anyway for trying!
Heiner
On 01.02.2019 18:19, Marc Haber wrote:
> On Fri, Feb 01, 2019 at 07:49:09AM +0100, Heiner Kallweit wrote:
>> Great, thanks. This patch has been applied and is part of latest linux-next kernel already:
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/?h=next-20190201
>> Would be much appreciated if you could build and test this kernel version.
>
> I regret that I have not been able to get this through the compiler.
> When I clone the linux-next repo and try to build with deb-pkg, some
> process chokes on the weird version number of the linux-next kernel, and
> transplanting the r8169.c from linux-next on to 4.20.6, compile aborts:
>
> In file included from drivers/net/ethernet/realtek/r8169.c:13:
> ./include/linux/pci.h:830:12: error: ‘PCI_VENDOR_ID_USR’ undeclared here (not in a function); did you mean ‘PCI_VENDOR_ID_UMC’?
> .vendor = PCI_VENDOR_ID_##vend, .device = (dev), \
> ^~~~~~~~~~~~~~
> drivers/net/ethernet/realtek/r8169.c:222:4: note: in expansion of macro ‘PCI_VDEVICE’
> { PCI_VDEVICE(USR, 0x0116), RTL_CFG_0 },
> ^~~~~~~~~~~
> drivers/net/ethernet/realtek/r8169.c: In function ‘rtl8169_start_xmit’:
> drivers/net/ethernet/realtek/r8169.c:6261:6: error: implicit declaration of function ‘__netdev_sent_queue’; did you mean ‘netdev_sent_queue’? [-Werror=implicit-function-declaration]
> if (__netdev_sent_queue(dev, skb->len, skb->xmit_more))
> ^~~~~~~~~~~~~~~~~~~
> netdev_sent_queue
> drivers/net/ethernet/realtek/r8169.c: In function ‘r8169_phy_connect’:
> drivers/net/ethernet/realtek/r8169.c:6653:22: warning: passing argument 1 of ‘linkmode_copy’ makes pointer from integer without a cast [-Wint-conversion]
> linkmode_copy(phydev->advertising, phydev->supported);
> ~~~~~~^~~~~~~~~~~~~
> In file included from ./include/linux/phy.h:22,
> from drivers/net/ethernet/realtek/r8169.c:19:
> ./include/linux/linkmode.h:13:49: note: expected ‘long unsigned int *’ but argument is of type ‘u32’ {aka ‘unsigned int’}
> static inline void linkmode_copy(unsigned long *dst, const unsigned long *src)
> ~~~~~~~~~~~~~~~^~~
> drivers/net/ethernet/realtek/r8169.c:6653:43: warning: passing argument 2 of ‘linkmode_copy’ makes pointer from integer without a cast [-Wint-conversion]
> linkmode_copy(phydev->advertising, phydev->supported);
> ~~~~~~^~~~~~~~~~~
> In file included from ./include/linux/phy.h:22,
> from drivers/net/ethernet/realtek/r8169.c:19:
> ./include/linux/linkmode.h:13:75: note: expected ‘const long unsigned int *’ but argument is of type ‘u32’ {aka ‘unsigned int’}
> static inline void linkmode_copy(unsigned long *dst, const unsigned long *src)
> ~~~~~~~~~~~~~~~~~~~~~^~~
> cc1: some warnings being treated as errors
> make[4]: *** [scripts/Makefile.build:297: drivers/net/ethernet/realtek/r8169.o] Error 1
>
> Will it help if I transplant more files from linux-next to 4.20.6?
>
> Greetings
> Marc
>
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: WoL broken in r8169.c since kernel 4.19
2019-02-01 18:24 ` Heiner Kallweit
@ 2019-02-01 18:41 ` Marc Haber
0 siblings, 0 replies; 36+ messages in thread
From: Marc Haber @ 2019-02-01 18:41 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: netdev
On Fri, Feb 01, 2019 at 07:24:01PM +0100, Heiner Kallweit wrote:
> It's too much effort to make the current r8169 compile under an older kernel.
> But thanks anyway for trying!
Will the patch be in 5.0-rc5?
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2019-02-01 18:41 UTC | newest]
Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-12 20:08 WoL broken in r8169.c since kernel 4.19 Marc Haber
2019-01-12 20:28 ` Heiner Kallweit
2019-01-12 20:44 ` Heiner Kallweit
2019-01-13 16:01 ` Marc Haber
2019-01-13 16:19 ` Heiner Kallweit
2019-01-22 16:10 ` Marc Haber
2019-01-22 18:47 ` Heiner Kallweit
2019-01-25 5:59 ` Marc Haber
2019-01-25 6:49 ` Heiner Kallweit
2019-01-25 12:02 ` Marc Haber
2019-01-25 18:22 ` Heiner Kallweit
2019-01-26 13:56 ` Marc Haber
2019-01-26 14:04 ` Heiner Kallweit
2019-01-26 17:07 ` Marc Haber
2019-01-26 19:22 ` Heiner Kallweit
2019-01-27 20:55 ` Marc Haber
2019-01-27 21:09 ` Heiner Kallweit
2019-01-28 7:30 ` Marc Haber
2019-01-28 19:02 ` Heiner Kallweit
2019-01-28 20:59 ` Marc Haber
2019-01-28 21:21 ` Heiner Kallweit
2019-01-29 11:52 ` Marc Haber
2019-01-28 20:22 ` Marc Haber
2019-01-28 20:28 ` Heiner Kallweit
2019-01-29 7:32 ` Marc Haber
2019-01-29 15:35 ` Marc Haber
2019-01-29 19:01 ` Heiner Kallweit
2019-01-30 8:46 ` Marc Haber
2019-01-29 21:20 ` Heiner Kallweit
2019-01-30 15:37 ` Marc Haber
2019-02-01 6:49 ` Heiner Kallweit
2019-02-01 17:19 ` Marc Haber
2019-02-01 18:24 ` Heiner Kallweit
2019-02-01 18:41 ` Marc Haber
2019-01-26 14:08 ` Heiner Kallweit
2019-01-26 14:09 ` Heiner Kallweit
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).