Re: [PATCH] x86/boot: Mark global variables as static

Feel free to add my tested by On Mon, 11 May 2020 at 23:58, Arvind Sankar wrote: > > Mike Lothian reports that after commit > 964124a97b97 ("efi/x86: Remove extra headroom for setup block") > gcc 10.1.0 fails with > > HOSTCC arch/x86/boot/tools/build > >

Re: [PATCH v2 4/5] efi/x86: Remove extra headroom for setup block

Hi This patch has been causing issues for me since switching to GCC 10.1: CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h HOSTCC arch/x86/boot/tools/build

Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

--enable-default-ssp Thread model: posix gcc version 9.2.0 (Gentoo 9.2.0 p1) Could this be related to the --enable-default-ssp or --enable-default-pie? On Mon, 19 Aug 2019 at 14:31, Thomas Gleixner wrote: > > On Mon, 19 Aug 2019, Mike Lothian wrote: > > > > I'm using GCC 9.2, bin

Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

On Mon, 19 Aug 2019 at 14:08, Thomas Gleixner wrote: > > On Mon, 19 Aug 2019, Mike Lothian wrote: > > On Wed, 14 Aug 2019 at 12:09, Mike Lothian wrote: > > > > > > As it's related. I've raised > > > https://bugzilla.kernel.org/show_bug.cgi?id=204495 about

Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

On Wed, 14 Aug 2019 at 12:09, Mike Lothian wrote: > > As it's related. I've raised > https://bugzilla.kernel.org/show_bug.cgi?id=204495 about the > relocatition I'm seeing since switching back to ld.bfd - is this safe > to ignore? I'm guessing this is why gold isn't working as it

Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

On Thu, 25 Jul 2019 at 07:59, Greg KH wrote: > > On Wed, Jul 24, 2019 at 10:20:34PM +0200, Thomas Gleixner wrote: > > On Wed, 24 Jul 2019, Thomas Gleixner wrote: > > > > > On Wed, 24 Jul 2019, Greg KH wrote: > > > > On Wed, Jul 24, 2019 at 06:03:41PM +0200, Thomas Gleixner wrote: > > > > > >

Re: [PATCH v2] kbuild: Fail if gold linker is detected

On Sat, 20 Jul 2019 at 11:54, Thomas Gleixner wrote: > > On Sat, 20 Jul 2019, Mike Lothian wrote: > > Here is my config > > > > https://github.com/FireBurn/KernelStuff/blob/9b7e96581598d50b266f9df258e7de764949147a/dot_config_tip > > > > Builds perfectly f

Re: [PATCH v2] kbuild: Fail if gold linker is detected

On Sat, 20 Jul 2019 at 10:34, Thomas Gleixner wrote: > > On Sat, 20 Jul 2019, Mike Lothian wrote: > > On Wed, 17 Jul 2019 at 08:57, Thomas Gleixner wrote: > > I've done a bit more digging, I had a second machine that was building > > Linus's tree just fine with ld.gold

Re: [PATCH v2] kbuild: Fail if gold linker is detected

On Wed, 17 Jul 2019 at 08:57, Thomas Gleixner wrote: > > On Wed, 17 Jul 2019, Masahiro Yamada wrote: > > On Wed, Jul 17, 2019 at 4:47 AM Thomas Gleixner wrote: > > > So instead of dealing with attempts to duct tape gold support without > > > understanding the root cause and without support from

Re: [PATCH v2] kbuild: Fail if gold linker is detected

On Tue, 16 Jul 2019 at 21:00, Nathan Chancellor wrote: > > On Tue, Jul 16, 2019 at 09:47:27PM +0200, Thomas Gleixner wrote: > > The gold linker has known issues of failing the build both in random and in > > predictible ways: > > > > - The x86/X32 VDSO build fails with: > > > >

Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

Will the fix be in the next RC? On Sun, 14 Jul 2019 at 11:16, Thomas Gleixner wrote: > > On Sat, 13 Jul 2019, Mike Lothian wrote: > > > This appears to be causing issues with gold again: > > > > axion /usr/src/linux # make > > CALLscripts/checksyscalls.sh &

[PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

Hi This appears to be causing issues with gold again: axion /usr/src/linux # make CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h VDSOCHK arch/x86/entry/vdso/vdso64.so.dbg VDSOCHK

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

On 12 February 2018 at 03:39, Lukas Wunner <lu...@wunner.de> wrote: > On Mon, Feb 12, 2018 at 12:35:51AM +0000, Mike Lothian wrote: >> I've not been able to reproduce the original problem you're trying to >> solve on amdgpu thats with or without your patch set and the a

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

On 12 February 2018 at 03:39, Lukas Wunner wrote: > On Mon, Feb 12, 2018 at 12:35:51AM +0000, Mike Lothian wrote: >> I've not been able to reproduce the original problem you're trying to >> solve on amdgpu thats with or without your patch set and the above >> "trigger&q

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

Hi I've not been able to reproduce the original problem you're trying to solve on amdgpu thats with or without your patch set and the above "trigger" too Is anything else required to trigger it, I started multiple DRI_PRIME glxgears, in parallel, serial waiting the 12 seconds and serial within

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

Hi I've not been able to reproduce the original problem you're trying to solve on amdgpu thats with or without your patch set and the above "trigger" too Is anything else required to trigger it, I started multiple DRI_PRIME glxgears, in parallel, serial waiting the 12 seconds and serial within

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

On 11 February 2018 at 09:38, Lukas Wunner wrote: > Fix a deadlock on hybrid graphics laptops that's been present since 2013: > > DRM drivers poll connectors in 10 sec intervals. The poll worker is > stopped on ->runtime_suspend with cancel_delayed_work_sync(). However > the

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

On 11 February 2018 at 09:38, Lukas Wunner wrote: > Fix a deadlock on hybrid graphics laptops that's been present since 2013: > > DRM drivers poll connectors in 10 sec intervals. The poll worker is > stopped on ->runtime_suspend with cancel_delayed_work_sync(). However > the poll worker invokes

Kbuild Regression

Hi I've raised https://bugzilla.kernel.org/show_bug.cgi?id=177741 Unfortunately I wasn't sure which component to file this under and I was unable to CC any of your emails directly to the bug I can't currently build the kernel with ld.gold I've bisected this back to: commit

Kbuild Regression

Hi I've raised https://bugzilla.kernel.org/show_bug.cgi?id=177741 Unfortunately I wasn't sure which component to file this under and I was unable to CC any of your emails directly to the bug I can't currently build the kernel with ld.gold I've bisected this back to: commit

Re: [PATCH v12 5/7] drm/i915/skl: Ensure pipes with changed wms get added to the state

Hi Is there any chance this could be removed from the upcoming drm-4.9 pull, at least until this issue has been fixed Regards Mike On 21 September 2016 at 12:34, Mike Lothian <m...@fireburn.co.uk> wrote: > I've raised https://bugs.freedesktop.org/show_bug.cgi?id=97888 I'll > att

Re: [PATCH v12 5/7] drm/i915/skl: Ensure pipes with changed wms get added to the state

Hi Is there any chance this could be removed from the upcoming drm-4.9 pull, at least until this issue has been fixed Regards Mike On 21 September 2016 at 12:34, Mike Lothian wrote: > I've raised https://bugs.freedesktop.org/show_bug.cgi?id=97888 I'll > attach the info you requested

Re: [PATCH v12 5/7] drm/i915/skl: Ensure pipes with changed wms get added to the state

I've raised https://bugs.freedesktop.org/show_bug.cgi?id=97888 I'll attach the info you requested once I get back to my machine On 21 September 2016 at 07:56, Maarten Lankhorst <maarten.lankho...@linux.intel.com> wrote: > Hey, > > Op 20-09-16 om 20:45 schreef Mike Lothian: &

Re: [PATCH v12 5/7] drm/i915/skl: Ensure pipes with changed wms get added to the state

I've raised https://bugs.freedesktop.org/show_bug.cgi?id=97888 I'll attach the info you requested once I get back to my machine On 21 September 2016 at 07:56, Maarten Lankhorst wrote: > Hey, > > Op 20-09-16 om 20:45 schreef Mike Lothian: >> Hi >> >> I've bisected bac

Re: [PATCH v12 5/7] drm/i915/skl: Ensure pipes with changed wms get added to the state

Hi I've bisected back to this commit in the drm-intel-nightly branch 05a76d3d6ad1ee9f9814f88949cc9305fc165460 is the first bad commit commit 05a76d3d6ad1ee9f9814f88949cc9305fc165460 Author: Lyude Date: Wed Aug 17 15:55:57 2016 -0400 drm/i915/skl: Ensure pipes with

Re: [PATCH v12 5/7] drm/i915/skl: Ensure pipes with changed wms get added to the state

Hi I've bisected back to this commit in the drm-intel-nightly branch 05a76d3d6ad1ee9f9814f88949cc9305fc165460 is the first bad commit commit 05a76d3d6ad1ee9f9814f88949cc9305fc165460 Author: Lyude Date: Wed Aug 17 15:55:57 2016 -0400 drm/i915/skl: Ensure pipes with changed wms get added to

Re: hrtimer deadlock caused by nohz_full

I think this might be the bug I reported here https://bugzilla.kernel.org/show_bug.cgi?id=84131 On 2 October 2014 19:24, Dave Jones wrote: > On Fri, Sep 26, 2014 at 01:46:59AM +0200, Frederic Weisbecker wrote: > > > > > [] hrtimer_try_to_cancel+0x58/0x1f0 > > > > [] hrtimer_cancel+0x1a/0x30

Re: hrtimer deadlock caused by nohz_full

I think this might be the bug I reported here https://bugzilla.kernel.org/show_bug.cgi?id=84131 On 2 October 2014 19:24, Dave Jones da...@redhat.com wrote: On Fri, Sep 26, 2014 at 01:46:59AM +0200, Frederic Weisbecker wrote: [a10f95f8] hrtimer_try_to_cancel+0x58/0x1f0

Hard lockups under high CPU load with DynTicks - RCU Related?

Hi I've raised https://bugzilla.kernel.org/show_bug.cgi?id=84131 and attempted to bisect The bug I'm stumbling on happens on both and Intel Sandybridge and AMD Kabini system - it manifests itself as a hard lockup when the system is under high load If I switch off DynTicks the problem doesn't

Hard lockups under high CPU load with DynTicks - RCU Related?

Hi I've raised https://bugzilla.kernel.org/show_bug.cgi?id=84131 and attempted to bisect The bug I'm stumbling on happens on both and Intel Sandybridge and AMD Kabini system - it manifests itself as a hard lockup when the system is under high load If I switch off DynTicks the problem doesn't

Linking VDSO with ld.gold

Hi I've raised https://bugzilla.kernel.org/show_bug.cgi?id=74391 as I've been having issues compiling the kernel since 26f5ef2e3c3c18f1dc31461ddf1db00b014edcd4 I'm not sure if linking with ld.gold is officially supported but it did used to work before this commit and continues to work if I

Linking VDSO with ld.gold

Hi I've raised https://bugzilla.kernel.org/show_bug.cgi?id=74391 as I've been having issues compiling the kernel since 26f5ef2e3c3c18f1dc31461ddf1db00b014edcd4 I'm not sure if linking with ld.gold is officially supported but it did used to work before this commit and continues to work if I