******************************************
* WARNING: Boot tests are now deprecated *
******************************************
As kernelci.org is expanding its functional testing capabilities, the concept
of boot testing is now deprecated. Boot results are scheduled to be dropped on
*5th June 2020*. The full schedule for boot tests deprecation is available on
this GitHub issue: https://github.com/kernelci/kernelci-backend/issues/238
The new equivalent is the *baseline* test suite which also runs sanity checks
using dmesg and bootrr: https://github.com/kernelci/bootrr
See the *baseline results for this kernel revision* on this page:
https://kernelci.org/test/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.225-…
-------------------------------------------------------------------------------
stable-rc/linux-4.4.y boot: 88 boots: 5 failed, 75 passed with 3 offline, 4 untried/unknown, 1 conflict (v4.4.225-49-gdc230329b026)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.…
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.225-49-…
Tree: stable-rc
Branch: linux-4.4.y
Git Describe: v4.4.225-49-gdc230329b026
Git Commit: dc230329b026cacfc8ecbb46f6f25630bb09388e
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 51 unique boards, 18 SoC families, 16 builds out of 150
Boot Regressions Detected:
arm:
omap2plus_defconfig:
gcc-8:
omap3-beagle-xm:
lab-baylibre: new failure (last pass: v4.4.225-39-g04192ccac174)
sama5_defconfig:
gcc-8:
at91-sama5d4_xplained:
lab-baylibre: failing since 67 days (last pass: v4.4.216-127-g955137020949 - first fail: v4.4.217)
Boot Failures Detected:
arm:
multi_v5_defconfig:
gcc-8:
imx27-phytec-phycard-s-rdk: 1 failed lab
omap2plus_defconfig:
gcc-8:
omap3-beagle-xm: 1 failed lab
imx_v4_v5_defconfig:
gcc-8:
imx27-phytec-phycard-s-rdk: 1 failed lab
mxs_defconfig:
gcc-8:
imx28-duckbill: 1 failed lab
sama5_defconfig:
gcc-8:
at91-sama5d4_xplained: 1 failed lab
Offline Platforms:
arm:
multi_v7_defconfig:
gcc-8
exynos5800-peach-pi: 1 offline lab
qcom-apq8064-cm-qs600: 1 offline lab
exynos_defconfig:
gcc-8
exynos5800-peach-pi: 1 offline lab
Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.)
i386:
i386_defconfig:
qemu_i386:
lab-collabora: FAIL (gcc-8)
lab-baylibre: PASS (gcc-8)
---
For more info write to <info(a)kernelci.org>
******************************************
* WARNING: Boot tests are now deprecated *
******************************************
As kernelci.org is expanding its functional testing capabilities, the concept
of boot testing is now deprecated. Boot results are scheduled to be dropped on
*5th June 2020*. The full schedule for boot tests deprecation is available on
this GitHub issue: https://github.com/kernelci/kernelci-backend/issues/238
The new equivalent is the *baseline* test suite which also runs sanity checks
using dmesg and bootrr: https://github.com/kernelci/bootrr
See the *baseline results for this kernel revision* on this page:
https://kernelci.org/test/job/stable-rc/branch/linux-5.4.y/kernel/v5.4.43-1…
-------------------------------------------------------------------------------
stable-rc/linux-5.4.y boot: 138 boots: 2 failed, 127 passed with 4 offline, 5 untried/unknown (v5.4.43-143-g1fd4226c4fe1)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.4.y/kernel/v5.4.…
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-5.4.y/kernel/v5.4.43-143-…
Tree: stable-rc
Branch: linux-5.4.y
Git Describe: v5.4.43-143-g1fd4226c4fe1
Git Commit: 1fd4226c4fe1a358bb8277e25ebb03950180443a
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 98 unique boards, 25 SoC families, 16 builds out of 155
Boot Regressions Detected:
arm:
multi_v7_defconfig:
gcc-8:
sun8i-h2-plus-orangepi-r1:
lab-baylibre: new failure (last pass: v5.4.43)
qcom_defconfig:
gcc-8:
qcom-apq8064-cm-qs600:
lab-baylibre-seattle: failing since 114 days (last pass: v5.4.17-99-gbd0c6624a110 - first fail: v5.4.17-238-gbffcaa93483d)
sama5_defconfig:
gcc-8:
at91-sama5d4_xplained:
lab-baylibre: failing since 54 days (last pass: v5.4.30-37-g40da5db79b55 - first fail: v5.4.30-39-g23c04177b89f)
arm64:
defconfig:
gcc-8:
sun50i-h6-orangepi-3:
lab-clabbe: new failure (last pass: v5.4.43)
Boot Failures Detected:
arm64:
defconfig:
gcc-8:
sun50i-h6-orangepi-3: 1 failed lab
arm:
sama5_defconfig:
gcc-8:
at91-sama5d4_xplained: 1 failed lab
Offline Platforms:
arm:
multi_v7_defconfig:
gcc-8
exynos5800-peach-pi: 1 offline lab
qcom-apq8064-cm-qs600: 1 offline lab
stih410-b2120: 1 offline lab
qcom_defconfig:
gcc-8
qcom-apq8064-cm-qs600: 1 offline lab
---
For more info write to <info(a)kernelci.org>
******************************************
* WARNING: Boot tests are now deprecated *
******************************************
As kernelci.org is expanding its functional testing capabilities, the concept
of boot testing is now deprecated. Boot results are scheduled to be dropped on
*5th June 2020*. The full schedule for boot tests deprecation is available on
this GitHub issue: https://github.com/kernelci/kernelci-backend/issues/238
The new equivalent is the *baseline* test suite which also runs sanity checks
using dmesg and bootrr: https://github.com/kernelci/bootrr
See the *baseline results for this kernel revision* on this page:
https://kernelci.org/test/job/stable-rc/branch/linux-4.19.y/kernel/v4.19.12…
-------------------------------------------------------------------------------
stable-rc/linux-4.19.y boot: 140 boots: 1 failed, 130 passed with 5 offline, 4 untried/unknown (v4.19.125-96-g47f49ba00628)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.1…
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.125-9…
Tree: stable-rc
Branch: linux-4.19.y
Git Describe: v4.19.125-96-g47f49ba00628
Git Commit: 47f49ba00628e7ce16eda75304e947f7ddb149d1
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 82 unique boards, 21 SoC families, 19 builds out of 161
Boot Regressions Detected:
arm:
qcom_defconfig:
gcc-8:
qcom-apq8064-cm-qs600:
lab-baylibre-seattle: failing since 19 days (last pass: v4.19.122 - first fail: v4.19.122-48-g92ba0b6b33ad)
sama5_defconfig:
gcc-8:
at91-sama5d4_xplained:
lab-baylibre: failing since 80 days (last pass: v4.19.108-87-g624c124960e8 - first fail: v4.19.109)
Boot Failure Detected:
arm:
sama5_defconfig:
gcc-8:
at91-sama5d4_xplained: 1 failed lab
Offline Platforms:
arm:
multi_v7_defconfig:
gcc-8
exynos5800-peach-pi: 1 offline lab
qcom-apq8064-cm-qs600: 1 offline lab
stih410-b2120: 1 offline lab
exynos_defconfig:
gcc-8
exynos5800-peach-pi: 1 offline lab
qcom_defconfig:
gcc-8
qcom-apq8064-cm-qs600: 1 offline lab
---
For more info write to <info(a)kernelci.org>
******************************************
* WARNING: Boot tests are now deprecated *
******************************************
As kernelci.org is expanding its functional testing capabilities, the concept
of boot testing is now deprecated. Boot results are scheduled to be dropped on
*5th June 2020*. The full schedule for boot tests deprecation is available on
this GitHub issue: https://github.com/kernelci/kernelci-backend/issues/238
The new equivalent is the *baseline* test suite which also runs sanity checks
using dmesg and bootrr: https://github.com/kernelci/bootrr
See the *baseline results for this kernel revision* on this page:
https://kernelci.org/test/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.225-…
-------------------------------------------------------------------------------
stable-rc/linux-4.4.y boot: 88 boots: 3 failed, 77 passed with 4 offline, 4 untried/unknown (v4.4.225-39-g04192ccac174)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.…
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.225-39-…
Tree: stable-rc
Branch: linux-4.4.y
Git Describe: v4.4.225-39-g04192ccac174
Git Commit: 04192ccac17413ef4b8969b054c12eaae27ea194
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 49 unique boards, 18 SoC families, 14 builds out of 151
Boot Regressions Detected:
arm:
qcom_defconfig:
gcc-8:
qcom-apq8064-cm-qs600:
lab-baylibre-seattle: failing since 19 days (last pass: v4.4.223 - first fail: v4.4.223-36-g32f5ec9b096d)
sama5_defconfig:
gcc-8:
at91-sama5d4_xplained:
lab-baylibre: failing since 67 days (last pass: v4.4.216-127-g955137020949 - first fail: v4.4.217)
Boot Failures Detected:
arm:
multi_v5_defconfig:
gcc-8:
imx27-phytec-phycard-s-rdk: 1 failed lab
sama5_defconfig:
gcc-8:
at91-sama5d4_xplained: 1 failed lab
imx_v4_v5_defconfig:
gcc-8:
imx27-phytec-phycard-s-rdk: 1 failed lab
Offline Platforms:
arm:
multi_v7_defconfig:
gcc-8
exynos5800-peach-pi: 1 offline lab
qcom-apq8064-cm-qs600: 1 offline lab
exynos_defconfig:
gcc-8
exynos5800-peach-pi: 1 offline lab
qcom_defconfig:
gcc-8
qcom-apq8064-cm-qs600: 1 offline lab
---
For more info write to <info(a)kernelci.org>
From: Vladimir Oltean <vladimir.oltean(a)nxp.com>
In kernel 4.19 (and probably earlier too) there are issues surrounding
the PHY_AN state.
For example, if a PHY is in PHY_AN state and AN has not finished, then
what is supposed to happen is that the state machine gets rescheduled
until it is, or until the link_timeout reaches zero which triggers an
autoneg restart process.
But actually the rescheduling never works if the PHY uses interrupts,
because the condition under which rescheduling occurs is just if
phy_polling_mode() is true. So basically, this whole rescheduling
functionality works for AN-not-yet-complete just by mistake. Let me
explain.
Most of the time the AN process manages to finish by the time the
interrupt has triggered. One might say "that should always be the case,
otherwise the PHY wouldn't raise the interrupt, right?".
Well, some PHYs implement an .aneg_done method which allows them to tell
the state machine when the AN is really complete.
The AR8031/AR8033 driver (at803x.c) is one such example. Even when
copper autoneg completes, the driver still keeps the "aneg_done"
variable unset until in-band SGMII autoneg finishes too (there is no
interrupt for that). So we have the premises of a race condition.
In practice, what really happens depends on the log level of the serial
console. If the log level is verbose enough that kernel messages related
to the Ethernet link state are printed to the console, then this gives
in-band AN enough time to complete, which means the link will come up
and everyone will be happy. But if the console is not that verbose, the
link will sometimes come up, and sometimes will be forced down by the
.aneg_done of the PHY driver (forever, since we are not rescheduling).
The conclusion is that an extra condition needs to be explicitly added,
so that the state machine can be rescheduled properly. Otherwise PHY
devices in interrupt mode will never work properly if they have an
.aneg_done callback.
In more recent kernels, the whole PHY_AN state was removed by Heiner
Kallweit in the "[net-next,0/5] net: phy: improve and simplify phylib
state machine" series here:
https://patchwork.ozlabs.org/cover/994464/
and the problem was just masked away instead of being addressed with a
punctual patch.
Fixes: 76a423a3f8f1 ("net: phy: allow driver to implement their own aneg_done")
Signed-off-by: Vladimir Oltean <vladimir.oltean(a)nxp.com>
---
I'm not sure the procedure I'm following is correct, sending this
directly to Greg. The patch doesn't apply on net.
drivers/net/phy/phy.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index cc454b8c032c..ca4fd74fd2c8 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -934,7 +934,7 @@ void phy_state_machine(struct work_struct *work)
struct delayed_work *dwork = to_delayed_work(work);
struct phy_device *phydev =
container_of(dwork, struct phy_device, state_queue);
- bool needs_aneg = false, do_suspend = false;
+ bool recheck = false, needs_aneg = false, do_suspend = false;
enum phy_state old_state;
int err = 0;
int old_link;
@@ -981,6 +981,8 @@ void phy_state_machine(struct work_struct *work)
phy_link_up(phydev);
} else if (0 == phydev->link_timeout--)
needs_aneg = true;
+ else
+ recheck = true;
break;
case PHY_NOLINK:
if (!phy_polling_mode(phydev))
@@ -1123,7 +1125,7 @@ void phy_state_machine(struct work_struct *work)
* PHY, if PHY_IGNORE_INTERRUPT is set, then we will be moving
* between states from phy_mac_interrupt()
*/
- if (phy_polling_mode(phydev))
+ if (phy_polling_mode(phydev) || recheck)
queue_delayed_work(system_power_efficient_wq, &phydev->state_queue,
PHY_STATE_TIME * HZ);
}
--
2.25.1
On Wed, May 27, 2020 at 1:57 PM Bill Wendling <morbo(a)google.com> wrote:
>
>
>
> On Wed, May 27, 2020 at 11:04 AM Nick Desaulniers <ndesaulniers(a)google.com> wrote:
>>
>> On Wed, May 27, 2020 at 7:16 AM Arnd Bergmann <arnd(a)arndb.de> wrote:
>> >
>> > clang and gas seem to interpret the symbols in memmove_64.S and
>> > memset_64.S differently, such that clang does not make them
>> > 'weak' as expected, which leads to a linker error, with both
>> > ld.bfd and ld.lld:
>> >
>> > ld.lld: error: duplicate symbol: memmove
>> > >>> defined at common.c
>> > >>> kasan/common.o:(memmove) in archive mm/built-in.a
>> > >>> defined at memmove.o:(__memmove) in archive arch/arm64/lib/lib.a
>> >
>> > ld.lld: error: duplicate symbol: memset
>> > >>> defined at common.c
>> > >>> kasan/common.o:(memset) in archive mm/built-in.a
>> > >>> defined at memset.o:(__memset) in archive arch/arm64/lib/lib.a
>> >
>> > Copy the exact way these are written in memcpy_64.S, which does
>> > not have the same problem.
>> >
>> > I don't know why this makes a difference, and it would be good
>> > to have someone with a better understanding of assembler internals
>> > review it.
>> >
>> > It might be either a bug in the kernel or a bug in the assembler,
>> > no idea which one. My patch makes it work with all versions of
>> > clang and gcc, which is probably helpful even if it's a workaround
>> > for a clang bug.
>> >
>> > Cc: stable(a)vger.kernel.org
>> > Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
>>
>> + Bill, Fangrui, Jian
>> I think we saw this bug or a very similar bug internally around the
>> ordering of .weak to .global.
>>
> I think that would be this patch by Fangrui:
>
> https://prodkernel-review.git.corp.google.com/c/kernel/release/9xx/+/292011
Thanks. That patch references this discussion:
https://lore.kernel.org/linuxppc-dev/20200325164257.170229-1-maskray@google…
>
> -bw
>
>>
>> > ---
>> > arch/x86/lib/memmove_64.S | 4 ++--
>> > arch/x86/lib/memset_64.S | 4 ++--
>> > 2 files changed, 4 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/arch/x86/lib/memmove_64.S b/arch/x86/lib/memmove_64.S
>> > index 7ff00ea64e4f..dcca01434be8 100644
>> > --- a/arch/x86/lib/memmove_64.S
>> > +++ b/arch/x86/lib/memmove_64.S
>> > @@ -26,8 +26,8 @@
>> > */
>> > .weak memmove
>> >
>> > -SYM_FUNC_START_ALIAS(memmove)
>> > -SYM_FUNC_START(__memmove)
>> > +SYM_FUNC_START_ALIAS(__memmove)
>> > +SYM_FUNC_START_LOCAL(memmove)
>> >
>> > mov %rdi, %rax
>> >
>> > diff --git a/arch/x86/lib/memset_64.S b/arch/x86/lib/memset_64.S
>> > index 9ff15ee404a4..a97f2ea4e0b2 100644
>> > --- a/arch/x86/lib/memset_64.S
>> > +++ b/arch/x86/lib/memset_64.S
>> > @@ -19,8 +19,8 @@
>> > *
>> > * rax original destination
>> > */
>> > -SYM_FUNC_START_ALIAS(memset)
>> > -SYM_FUNC_START(__memset)
>> > +SYM_FUNC_START_ALIAS(__memset)
>> > +SYM_FUNC_START_LOCAL(memset)
>> > /*
>> > * Some CPUs support enhanced REP MOVSB/STOSB feature. It is recommended
>> > * to use it when possible. If not available, use fast string instructions.
>> > --
>> > 2.26.2
>> >
>> > --
>> > You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
>> > To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-linux+unsubscribe(a)googlegroups.com.
>> > To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/20200527141553.1768675-….
>>
>>
>>
>> --
>> Thanks,
>> ~Nick Desaulniers
--
Thanks,
~Nick Desaulniers