All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiner Kallweit <hkallweit1@gmail.com>
To: Petr Tesarik <ptesarik@suse.cz>
Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>,
	netdev@vger.kernel.org
Subject: Re: RTL8402 stops working after hibernate/resume
Date: Wed, 30 Sep 2020 22:11:02 +0200	[thread overview]
Message-ID: <2e91f3b7-b675-e117-2200-e97b089e9996@gmail.com> (raw)
In-Reply-To: <20200930200027.3b512633@ezekiel.suse.cz>

On 30.09.2020 20:00, Petr Tesarik wrote:
> Hi Heiner again,
> 
> On Wed, 30 Sep 2020 19:32:59 +0200
> Petr Tesarik <ptesarik@suse.cz> wrote:
> 
>> Hi Heiner,
>>
>> On Wed, 30 Sep 2020 18:41:24 +0200
>> Petr Tesarik <ptesarik@suse.cz> wrote:
>>
>>> HI Heiner,
>>>
>>> On Wed, 30 Sep 2020 17:47:15 +0200
>>> Heiner Kallweit <hkallweit1@gmail.com> wrote:
>>> [...]  
>>>> Petr,
>>>> in the following I send two patches. First one is supposed to fix the freeze.
>>>> It also fixes another issue that existed before my ether_clk change:
>>>> ether_clk was disabled on suspend even if WoL is enabled. And the network
>>>> chip most likely needs the clock to check for WoL packets.    
>>>
>>> Should I also check whether WoL works? Plus, it would be probably good
>>> if I could check whether it indeed didn't work before the change. ;-)
>>>   
>>>> Please let me know whether it fixes the freeze, then I'll add your
>>>>   Tested-by.    
>>>
>>> Will do.  
>>
>> Here are the results:
>>
>> - WoL does not work without your patch; this was tested with 5.8.4,
>>   because master freezes hard on load.
>>
>> - I got a kernel crash when I woke up the laptop through keyboard; I am
>>   not sure if it is related, although I could spend some time looking
>>   at the resulting crash dump if you think it's worth the time.
>>

This may be caused by the following code in the resume path in 5.8.
The chip is accessed before the clock gets enabled.

rtl_rar_set(tp, tp->dev->dev_addr);
clk_prepare_enable(tp->clk);


>> - After applying your first patch on top of v5.9-rc6, the driver can be
>>   loaded, but stops working properly on suspend/resume.
>>
>> - WoL still does not work, but I'm no longer getting a kernel crash at
>>   least. ;-)
>>
>> Tested-by: Petr Tesarik <ptesarik@suse.com>
>>
>>>> Second patch is a re-send of the one I sent before, it should fix
>>>> the rx issues after resume from suspend for you.    
>>>
>>> All right, going to rebuild the kernel and see how it goes.  
>>
>> This second patch does not fix suspend/resume for me, unfortunately. The
>> receive is still erratic, but the behaviour is now different: some
>> packets are truncated, other packets are delayed by approx. 1024 ms.
>> Yes, 1024 may ring a bell, but I've no idea which.
> 
> I'm sorry, I added some debugging message, and as I was wondering why
> the resume path is not run, I found out I was not properly reloading the
> modified module. So, after fixing my build, your patch also fixes the
> Rx queue on resume! Both with and without NetworkManager.
> 
> So, you can also add to the second patch:
> 
> Tested-by: Petr Tesarik <ptesarik@suse.com>
> 
Thanks a lot for all your efforts!

> WoL still does not work on my laptop, but this might be an unrelated
> issue, and I can even imagine the BIOS is buggy in this regard.
> 
A simple further check you could do:
After sending the WoL packet (that doesn't wake the system) you wake
the system by e.g. a keystroke. Then check in /proc/interrupts for
a PCIe PME interrupt. If there's a PME interrupt, then the network
chip successfully detected the WoL packet, and it seems we have to
blame the BIOS.

> Petr T
> 
>> HTH,
>> Petr T
>>
>>> Stay tuned,
>>> Petr T
>>>
>>>   
>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c
>>>>   b/drivers/net/ethernet/realtek/r8169_main.c index
>>>>   6c7c004c2..72351c5b0 100644 ---
>>>>   a/drivers/net/ethernet/realtek/r8169_main.c +++
>>>>   b/drivers/net/ethernet/realtek/r8169_main.c @@ -2236,14 +2236,10
>>>>   @@ static void rtl_pll_power_down(struct rtl8169_private *tp)
>>>>   default: break;
>>>>  	}
>>>> -
>>>> -	clk_disable_unprepare(tp->clk);
>>>>  }
>>>>  
>>>>  static void rtl_pll_power_up(struct rtl8169_private *tp)
>>>>  {
>>>> -	clk_prepare_enable(tp->clk);
>>>> -
>>>>  	switch (tp->mac_version) {
>>>>  	case RTL_GIGA_MAC_VER_25 ... RTL_GIGA_MAC_VER_33:
>>>>  	case RTL_GIGA_MAC_VER_37:
>>>> @@ -4820,29 +4816,39 @@ static void rtl8169_net_suspend(struct
>>>>   rtl8169_private *tp) 
>>>>  #ifdef CONFIG_PM
>>>>  
>>>> +static int rtl8169_net_resume(struct rtl8169_private *tp)
>>>> +{
>>>> +	rtl_rar_set(tp, tp->dev->dev_addr);
>>>> +
>>>> +	if (tp->TxDescArray)
>>>> +		rtl8169_up(tp);
>>>> +
>>>> +	netif_device_attach(tp->dev);
>>>> +
>>>> +	return 0;
>>>> +}
>>>> +
>>>>  static int __maybe_unused rtl8169_suspend(struct device *device)
>>>>  {
>>>>  	struct rtl8169_private *tp = dev_get_drvdata(device);
>>>>  
>>>>  	rtnl_lock();
>>>>  	rtl8169_net_suspend(tp);
>>>> +	if (!device_may_wakeup(tp_to_dev(tp)))
>>>> +		clk_disable_unprepare(tp->clk);
>>>>  	rtnl_unlock();
>>>>  
>>>>  	return 0;
>>>>  }
>>>>  
>>>> -static int rtl8169_resume(struct device *device)
>>>> +static int __maybe_unused rtl8169_resume(struct device *device)
>>>>  {
>>>>  	struct rtl8169_private *tp = dev_get_drvdata(device);
>>>>  
>>>> -	rtl_rar_set(tp, tp->dev->dev_addr);
>>>> -
>>>> -	if (tp->TxDescArray)
>>>> -		rtl8169_up(tp);
>>>> +	if (!device_may_wakeup(tp_to_dev(tp)))
>>>> +		clk_prepare_enable(tp->clk);
>>>>  
>>>> -	netif_device_attach(tp->dev);
>>>> -
>>>> -	return 0;
>>>> +	return rtl8169_net_resume(tp);
>>>>  }
>>>>  
>>>>  static int rtl8169_runtime_suspend(struct device *device)
>>>> @@ -4868,7 +4874,7 @@ static int rtl8169_runtime_resume(struct
>>>>   device *device) 
>>>>  	__rtl8169_set_wol(tp, tp->saved_wolopts);
>>>>  
>>>> -	return rtl8169_resume(device);
>>>> +	return rtl8169_net_resume(tp);
>>>>  }
>>>>  
>>>>  static int rtl8169_runtime_idle(struct device *device)    
>>>   
>>
> 
Heiner

  reply	other threads:[~2020-09-30 20:11 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-15  8:28 RTL8402 stops working after hibernate/resume Petr Tesarik
2020-07-15 15:22 ` Heiner Kallweit
2020-07-16  8:58   ` Petr Tesarik
2020-07-18 12:07     ` Heiner Kallweit
2020-09-03  8:41       ` Petr Tesarik
2020-09-17 14:10         ` Petr Tesarik
2020-09-23  9:57         ` Heiner Kallweit
2020-09-24 19:14           ` Petr Tesarik
2020-09-24 19:37             ` Heiner Kallweit
2020-09-24 20:12             ` Heiner Kallweit
2020-09-25  7:30               ` Petr Tesarik
2020-09-25  8:54                 ` Petr Tesarik
2020-09-25  9:44                   ` Heiner Kallweit
2020-09-25  9:52                     ` Petr Tesarik
2020-09-25 12:56                       ` Petr Tesarik
2020-09-25 14:47                         ` Heiner Kallweit
2020-09-29 19:07                           ` Petr Tesarik
2020-09-29 19:41                             ` Heiner Kallweit
2020-09-29 20:08                             ` Hans de Goede
2020-09-29 20:29                               ` Hans de Goede
2020-09-29 20:35                               ` Heiner Kallweit
2020-09-29 20:42                                 ` Heiner Kallweit
2020-09-30  9:04                                 ` Hans de Goede
2020-09-30 15:47                                   ` Heiner Kallweit
2020-09-30 16:41                                     ` Petr Tesarik
2020-09-30 17:13                                       ` Heiner Kallweit
2020-09-30 17:32                                       ` Petr Tesarik
2020-09-30 18:00                                         ` Petr Tesarik
2020-09-30 20:11                                           ` Heiner Kallweit [this message]
2020-09-30 21:44                                             ` Petr Tesarik
2020-10-01  6:14                                               ` Heiner Kallweit
2020-09-30 18:10                                     ` Petr Tesarik
2020-09-29 21:17                               ` Petr Tesarik
2020-07-15 15:25 ` Heiner Kallweit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2e91f3b7-b675-e117-2200-e97b089e9996@gmail.com \
    --to=hkallweit1@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=nic_swsd@realtek.com \
    --cc=ptesarik@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.