Hi Robert,
On 29/08/16 14:32, [email protected] wrote:
> From: Robert Foss <[email protected]>
>
> From: Allan Chou <[email protected]>
>
> The change fixes AX88772x resume failure by
> - Restore incorrect AX88772A PHY registers when resetting
> - Need to stop MAC operation when suspending
> - Need to restart MII when restoring PHY
>
> Signed-off-by: Allan Chou <[email protected]>
> Signed-off-by: Robert Foss <[email protected]>
> Tested-by: Robert Foss <[email protected]>
After this commit, I have started seeing the following messages
during system suspend on various tegra boards using asix ethernet
dongles ...
[ 288.667010] PM: Syncing filesystems ... done.
[ 288.672223] Freezing user space processes ... (elapsed 0.001 seconds) done.
[ 288.680505] Double checking all user space processes after OOM killer disable... (elapsed 0.000 seconds)
[ 288.690193] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[ 288.698987] Suspending console(s) (use no_console_suspend to debug)
[ 288.706605] asix 1-1:1.0 eth0: Failed to read reg index 0x0000: -19
[ 288.706613] asix 1-1:1.0 eth0: Error reading Medium Status register: ffffffed
[ 288.706621] asix 1-1:1.0 eth0: Failed to write reg index 0x0000: -19
[ 288.706629] asix 1-1:1.0 eth0: Failed to write Medium Mode mode to 0xfeed: ffffffed
[ 288.759167] PM: suspend of devices complete after 52.772 msecs
Interestingly, it only seems to happen if the ethernet is in a
disconnected state when entering suspend. I have not had chance
to look at this any further, but wanted to see if you had any
thoughts.
Cheers
Jon
--
nvpublic
Hi Jon,
It seems the AX88772x dongle had been unexpectedly removed while running the
ax88772_suspend() routine. If yes, you might see these error messages
because the hardware had been absent.
---
Best regards,
Allan Chou
-----Original Message-----
From: Jon Hunter [mailto:[email protected]]
Sent: Thursday, November 10, 2016 8:01 PM
To: [email protected]; [email protected]; [email protected];
[email protected]; [email protected]; [email protected];
[email protected]; [email protected]; [email protected];
[email protected]; [email protected]; [email protected];
[email protected]; [email protected]; [email protected];
[email protected]; [email protected];
[email protected]; [email protected]
Subject: Re: [PATCH v3 3/5] net: asix: Fix AX88772x resume failures
Hi Robert,
On 29/08/16 14:32, [email protected] wrote:
> From: Robert Foss <[email protected]>
>
> From: Allan Chou <[email protected]>
>
> The change fixes AX88772x resume failure by
> - Restore incorrect AX88772A PHY registers when resetting
> - Need to stop MAC operation when suspending
> - Need to restart MII when restoring PHY
>
> Signed-off-by: Allan Chou <[email protected]>
> Signed-off-by: Robert Foss <[email protected]>
> Tested-by: Robert Foss <[email protected]>
After this commit, I have started seeing the following messages during
system suspend on various tegra boards using asix ethernet dongles ...
[ 288.667010] PM: Syncing filesystems ... done.
[ 288.672223] Freezing user space processes ... (elapsed 0.001 seconds)
done.
[ 288.680505] Double checking all user space processes after OOM killer
disable... (elapsed 0.000 seconds) [ 288.690193] Freezing remaining
freezable tasks ... (elapsed 0.001 seconds) done.
[ 288.698987] Suspending console(s) (use no_console_suspend to debug) [
288.706605] asix 1-1:1.0 eth0: Failed to read reg index 0x0000: -19 [
288.706613] asix 1-1:1.0 eth0: Error reading Medium Status register:
ffffffed [ 288.706621] asix 1-1:1.0 eth0: Failed to write reg index 0x0000:
-19 [ 288.706629] asix 1-1:1.0 eth0: Failed to write Medium Mode mode to
0xfeed: ffffffed [ 288.759167] PM: suspend of devices complete after 52.772
msecs
Interestingly, it only seems to happen if the ethernet is in a disconnected
state when entering suspend. I have not had chance to look at this any
further, but wanted to see if you had any thoughts.
Cheers
Jon
--
nvpublic
Hi Allan,
On 14/11/16 08:50, ASIX_Allan [Home] wrote:
> It seems the AX88772x dongle had been unexpectedly removed while running the
> ax88772_suspend() routine. If yes, you might see these error messages
> because the hardware had been absent.
In my case the hardware was never removed. The boards are in a test
fixture that are not touched. This is seen on more than one board. By
reverting this change I no longer see the error messages and appears to
be 100% reproducible.
Jon
--
nvpublic
Hi Jon,
Please help to double check if the USB host controller of your Terga
platform had been powered OFF while running the ax88772_suspend() routine or
not?
---
Best regards,
Allan Chou
-----Original Message-----
From: Jon Hunter [mailto:[email protected]]
Sent: Monday, November 14, 2016 5:34 PM
To: [email protected]; [email protected]; [email protected];
[email protected]; [email protected]; [email protected];
[email protected]; [email protected]; [email protected];
[email protected]; [email protected]; [email protected];
[email protected]; [email protected]; [email protected];
[email protected]; [email protected];
[email protected]; [email protected]
Subject: Re: [PATCH v3 3/5] net: asix: Fix AX88772x resume failures
Hi Allan,
On 14/11/16 08:50, ASIX_Allan [Home] wrote:
> It seems the AX88772x dongle had been unexpectedly removed while
> running the
> ax88772_suspend() routine. If yes, you might see these error messages
> because the hardware had been absent.
In my case the hardware was never removed. The boards are in a test fixture
that are not touched. This is seen on more than one board. By reverting this
change I no longer see the error messages and appears to be 100%
reproducible.
Jon
--
nvpublic
Hi Allan,
On 14/11/16 09:45, ASIX_Allan [Office] wrote:
> Hi Jon,
>
> Please help to double check if the USB host controller of your Terga
> platform had been powered OFF while running the ax88772_suspend() routine or
> not?
Sorry for the delay. Today I set up a local board to reproduce this on
and was able to recreate the same problem. The Tegra xhci driver does
not power off during suspend and simply calls xhci_suspend(). I also
checked vbus to see if it was turning off but it is not. Furthermore I
don't see a new USB device detected after the error and so I don't see
any evidence that it ever disconnects.
Cheers
Jon
--
nvpublic
Hi Allan,
On 18/11/16 15:09, Jon Hunter wrote:
> Hi Allan,
>
> On 14/11/16 09:45, ASIX_Allan [Office] wrote:
>> Hi Jon,
>>
>> Please help to double check if the USB host controller of your Terga
>> platform had been powered OFF while running the ax88772_suspend() routine or
>> not?
>
> Sorry for the delay. Today I set up a local board to reproduce this on
> and was able to recreate the same problem. The Tegra xhci driver does
> not power off during suspend and simply calls xhci_suspend(). I also
> checked vbus to see if it was turning off but it is not. Furthermore I
> don't see a new USB device detected after the error and so I don't see
> any evidence that it ever disconnects.
In an attempt to isolate if this is a Tegra issue or not, I recompiled
v4.9-rc6 for x86 and I was able to reproduce the problem on my desktop ...
[ 256.030060] PM: Syncing filesystems ... done.
[ 256.113925] PM: Preparing system for sleep (mem)
[ 256.114119] Freezing user space processes ... (elapsed 0.002 seconds) done.
[ 256.116701] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[ 256.118041] PM: Suspending system (mem)
[ 256.118058] Suspending console(s) (use no_console_suspend to debug)
[ 256.118324] asix 1-1.2:1.0 eth2: Failed to read reg index 0x0000: -19
[ 256.118327] asix 1-1.2:1.0 eth2: Error reading Medium Status register: ffffffed
[ 256.118329] asix 1-1.2:1.0 eth2: Failed to write reg index 0x0000: -19
[ 256.118332] asix 1-1.2:1.0 eth2: Failed to write Medium Mode mode to 0xfeed: ffffffed
[ 256.118374] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 256.118471] sd 0:0:0:0: [sda] Stopping disk
[ 256.152992] hpet1: lost 1 rtc interrupts
[ 256.153893] serial 00:06: disabled
[ 256.153899] serial 00:06: System wakeup disabled by ACPI
[ 256.154068] e1000e: EEE TX LPI TIMER: 00000011
[ 256.628281] PM: suspend of devices complete after 509.782 msecs
[ 256.628620] PM: late suspend of devices complete after 0.336 msecs
[ 256.629366] ehci-pci 0000:00:1d.0: System wakeup enabled by ACPI
[ 256.629595] tg3 0000:03:00.0: System wakeup enabled by ACPI
[ 256.629601] ehci-pci 0000:00:1a.0: System wakeup enabled by ACPI
[ 256.629652] e1000e 0000:00:19.0: System wakeup enabled by ACPI
[ 256.629812] xhci_hcd 0000:00:14.0: System wakeup enabled by ACPI
[ 256.648347] PM: noirq suspend of devices complete after 19.713 msecs
[ 256.648685] ACPI: Preparing to enter system sleep state S3
[ 256.668275] PM: Saving platform NVS memory
[ 256.668283] Disabling non-boot CPUs ...
To reproduce this, I did the following:
1. Connect the asix device and noted the net interface (ie. eth2)
2. Disabled the interface (ie. sudo ifconfig eth2 down)
3. Ran a suspend-resume cycle using rtcwake (eg. sudo rtcwake -d rtc0 -m mem -s 5)
Cheers
Jon
--
nvpublic
Dear Jon ,
We can reproduce your issue on x86 Linux kernel 4.9.0-rc system in our site
and modified the following code can fix this issue. Please let us know if
you still have problems. Thanks a lot.
static void ax88772_suspend(struct usbnet *dev)
{
struct asix_common_private *priv = dev->driver_priv;
u16 medium;
/* Stop MAC operation */
- medium = asix_read_medium_status(dev, 0);
+ medium = asix_read_medium_status(dev, 1);
medium &= ~AX_MEDIUM_RE;
- asix_write_medium_mode(dev, medium, 0);
+ asix_write_medium_mode(dev, medium, 1);
netdev_dbg(dev->net, "ax88772_suspend: medium=0x%04x\n",
- asix_read_medium_status(dev, 0));
+ asix_read_medium_status(dev, 1));
/* Preserve BMCR for restoring */
priv->presvd_phy_bmcr =
asix_mdio_read_nopm(dev->net, dev->mii.phy_id, MII_BMCR);
/* Preserve ANAR for restoring */
priv->presvd_phy_advertise =
asix_mdio_read_nopm(dev->net, dev->mii.phy_id,
MII_ADVERTISE);
}
---
Best regards,
Allan Chou
Technical Support Division
ASIX Electronics Corporation
TEL: 886-3-5799500 ext.228
FAX: 886-3-5799558
E-mail: [email protected]
http://www.asix.com.tw/
-----Original Message-----
From: Jon Hunter [mailto:[email protected]]
Sent: Tuesday, November 22, 2016 11:34 PM
To: [email protected]; [email protected]; [email protected];
[email protected]; [email protected]; [email protected];
[email protected]; [email protected]; [email protected];
[email protected]; [email protected]; [email protected];
[email protected]; [email protected]; [email protected];
[email protected]; [email protected];
[email protected]; [email protected]
Subject: Re: [PATCH v3 3/5] net: asix: Fix AX88772x resume failures
Hi Allan,
On 18/11/16 15:09, Jon Hunter wrote:
> Hi Allan,
>
> On 14/11/16 09:45, ASIX_Allan [Office] wrote:
>> Hi Jon,
>>
>> Please help to double check if the USB host controller of your Terga
>> platform had been powered OFF while running the ax88772_suspend()
>> routine or not?
>
> Sorry for the delay. Today I set up a local board to reproduce this on
> and was able to recreate the same problem. The Tegra xhci driver does
> not power off during suspend and simply calls xhci_suspend(). I also
> checked vbus to see if it was turning off but it is not. Furthermore I
> don't see a new USB device detected after the error and so I don't see
> any evidence that it ever disconnects.
In an attempt to isolate if this is a Tegra issue or not, I recompiled
v4.9-rc6 for x86 and I was able to reproduce the problem on my desktop ...
[ 256.030060] PM: Syncing filesystems ... done.
[ 256.113925] PM: Preparing system for sleep (mem) [ 256.114119] Freezing
user space processes ... (elapsed 0.002 seconds) done.
[ 256.116701] Freezing remaining freezable tasks ... (elapsed 0.001
seconds) done.
[ 256.118041] PM: Suspending system (mem) [ 256.118058] Suspending
console(s) (use no_console_suspend to debug) [ 256.118324] asix 1-1.2:1.0
eth2: Failed to read reg index 0x0000: -19 [ 256.118327] asix 1-1.2:1.0
eth2: Error reading Medium Status register: ffffffed [ 256.118329] asix
1-1.2:1.0 eth2: Failed to write reg index 0x0000: -19 [ 256.118332] asix
1-1.2:1.0 eth2: Failed to write Medium Mode mode to 0xfeed: ffffffed [
256.118374] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 256.118471] sd
0:0:0:0: [sda] Stopping disk [ 256.152992] hpet1: lost 1 rtc interrupts [
256.153893] serial 00:06: disabled [ 256.153899] serial 00:06: System
wakeup disabled by ACPI [ 256.154068] e1000e: EEE TX LPI TIMER: 00000011 [
256.628281] PM: suspend of devices complete after 509.782 msecs [
256.628620] PM: late suspend of devices complete after 0.336 msecs [
256.629366] ehci-pci 0000:00:1d.0: System wakeup enabled by ACPI [
256.629595] tg3 0000:03:00.0: System wakeup enabled by ACPI [ 256.629601]
ehci-pci 0000:00:1a.0: System wakeup enabled by ACPI [ 256.629652] e1000e
0000:00:19.0: System wakeup enabled by ACPI [ 256.629812] xhci_hcd
0000:00:14.0: System wakeup enabled by ACPI [ 256.648347] PM: noirq suspend
of devices complete after 19.713 msecs [ 256.648685] ACPI: Preparing to
enter system sleep state S3 [ 256.668275] PM: Saving platform NVS memory [
256.668283] Disabling non-boot CPUs ...
To reproduce this, I did the following:
1. Connect the asix device and noted the net interface (ie. eth2) 2.
Disabled the interface (ie. sudo ifconfig eth2 down) 3. Ran a suspend-resume
cycle using rtcwake (eg. sudo rtcwake -d rtc0 -m mem -s 5)
Cheers
Jon
--
nvpublic
Hi Allan,
On 29/11/16 08:54, ASIX_Allan [Office] wrote:
> Dear Jon ,
>
> We can reproduce your issue on x86 Linux kernel 4.9.0-rc system in our site
> and modified the following code can fix this issue. Please let us know if
> you still have problems. Thanks a lot.
>
> static void ax88772_suspend(struct usbnet *dev)
> {
> struct asix_common_private *priv = dev->driver_priv;
> u16 medium;
>
> /* Stop MAC operation */
> - medium = asix_read_medium_status(dev, 0);
> + medium = asix_read_medium_status(dev, 1);
> medium &= ~AX_MEDIUM_RE;
> - asix_write_medium_mode(dev, medium, 0);
> + asix_write_medium_mode(dev, medium, 1);
>
> netdev_dbg(dev->net, "ax88772_suspend: medium=0x%04x\n",
> - asix_read_medium_status(dev, 0));
> + asix_read_medium_status(dev, 1));
>
> /* Preserve BMCR for restoring */
> priv->presvd_phy_bmcr =
> asix_mdio_read_nopm(dev->net, dev->mii.phy_id, MII_BMCR);
>
> /* Preserve ANAR for restoring */
> priv->presvd_phy_advertise =
> asix_mdio_read_nopm(dev->net, dev->mii.phy_id,
> MII_ADVERTISE);
> }
I gave this a quick test this morning and I can confirm that with the
above change I no longer see the error messages. So feel free to add my ...
Tested-by: Jon Hunter <[email protected]>
Cheers
Jon
--
nvpublic