Re: 4.14.44: BUG_ON(!list_empty(>wait_list));

On 5 June 2018 at 05:47, wrote: >> -Original Message- >> From: Daniel J Blueman [mailto:dan...@quora.org] >> Sent: Thursday, May 31, 2018 9:21 PM >> To: Linux Kernel; linux-a...@vger.kernel.org >> Cc: Limonciello, Mario; Dominguez, Jared >> Subject: 4.

Re: 4.14.44: BUG_ON(!list_empty(>wait_list));

On 5 June 2018 at 05:47, wrote: >> -Original Message- >> From: Daniel J Blueman [mailto:dan...@quora.org] >> Sent: Thursday, May 31, 2018 9:21 PM >> To: Linux Kernel; linux-a...@vger.kernel.org >> Cc: Limonciello, Mario; Dominguez, Jared >> Subject: 4.

4.14.44: BUG_ON(!list_empty(>wait_list));

8 00 04 00 00 48 c7 c1 c3 91 28 ab 48 c7 c2 20 91 28 ab be of 04 00 00 bf 00 00 00 01 03 41 85 04 00 58 eb b0 b8 01 10 00 00 c3 Ob 90 Of if 44 00 00 80 3d 74 CO 97 01 00 41 54 55 53 Of 84 RIP: acpi_os_delete_semaphore+0x6d/0x70 RSP: b0ca80037be8 -- Daniel J Blueman

4.14.44: BUG_ON(!list_empty(>wait_list));

8 00 04 00 00 48 c7 c1 c3 91 28 ab 48 c7 c2 20 91 28 ab be of 04 00 00 bf 00 00 00 01 03 41 85 04 00 58 eb b0 b8 01 10 00 00 c3 Ob 90 Of if 44 00 00 80 3d 74 CO 97 01 00 41 54 55 53 Of 84 RIP: acpi_os_delete_semaphore+0x6d/0x70 RSP: b0ca80037be8 -- Daniel J Blueman

4.14.34: kernel stack regs has bad 'bp' value

0638ad7fd0: ... 880638ad7fd8: 7f504bfe56f0 (0x7f504bfe56f0) 880638ad7fe0: 0033 (0x33) 880638ad7fe8: 0246 (0x246) 880638ad7ff0: 7ffddaab6048 (0x7ffddaab6048) 880638ad7ff8: 002b (0x2b) -- Daniel J Blueman

4.14.34: kernel stack regs has bad 'bp' value

0638ad7fd0: ... 880638ad7fd8: 7f504bfe56f0 (0x7f504bfe56f0) 880638ad7fe0: 0033 (0x33) 880638ad7fe8: 0246 (0x246) 880638ad7ff0: 7ffddaab6048 (0x7ffddaab6048) 880638ad7ff8: 002b (0x2b) -- Daniel J Blueman

drm/vc4: false-positive negative cursor position warning

__setplane_internal+0x1f4/0x260 drm_mode_cursor_universal+0xf4/0x220 drm_mode_cursor_common+0x19c/0x218 drm_mode_cursor2_ioctl+0x34/0x48 drm_ioctl_kernel+0x70/0xd8 drm_ioctl+0x30c/0x438 do_vfs_ioctl+0xc4/0x880 SyS_ioctl+0x8c/0xa8 el0_svc_naked+0x30/0x34 -- Daniel J Blueman

drm/vc4: false-positive negative cursor position warning

__setplane_internal+0x1f4/0x260 drm_mode_cursor_universal+0xf4/0x220 drm_mode_cursor_common+0x19c/0x218 drm_mode_cursor2_ioctl+0x34/0x48 drm_ioctl_kernel+0x70/0xd8 drm_ioctl+0x30c/0x438 do_vfs_ioctl+0xc4/0x880 SyS_ioctl+0x8c/0xa8 el0_svc_naked+0x30/0x34 -- Daniel J Blueman

[PATCH] drm/vc4: Fix memory leak during BO teardown

Airlie <airl...@redhat.com> Cc: sta...@vger.kernel.org Signed-off-by: Daniel J Blueman <dan...@quora.org> --- drivers/gpu/drm/vc4/vc4_bo.c | 2 ++ drivers/gpu/drm/vc4/vc4_validate_shaders.c | 1 + 2 files changed, 3 insertions(+) diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/d

[PATCH] drm/vc4: Fix memory leak during BO teardown

...@vger.kernel.org Signed-off-by: Daniel J Blueman --- drivers/gpu/drm/vc4/vc4_bo.c | 2 ++ drivers/gpu/drm/vc4/vc4_validate_shaders.c | 1 + 2 files changed, 3 insertions(+) diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c index 2decc8e2c79f..add9cc97a3b6 100644

Re: stack frame unwindind KASAN errors

On 7 March 2017 at 00:40, Josh Poimboeuf <jpoim...@redhat.com> wrote: > On Mon, Mar 06, 2017 at 02:52:01PM +0800, Daniel J Blueman wrote: >> Thanks Josh! >> >> With this patch, the KASAN warning still occurs, but at >> unwind_get_return_address+0x1d3/0x1

Re: stack frame unwindind KASAN errors

On 7 March 2017 at 00:40, Josh Poimboeuf wrote: > On Mon, Mar 06, 2017 at 02:52:01PM +0800, Daniel J Blueman wrote: >> Thanks Josh! >> >> With this patch, the KASAN warning still occurs, but at >> unwind_get_return_address+0x1d3/0x130 instead; the rest of the trace

Re: stack frame unwindind KASAN errors

On 27 February 2017 at 23:47, Josh Poimboeuf <jpoim...@redhat.com> wrote: > On Mon, Feb 27, 2017 at 12:49:59PM +0800, Daniel J Blueman wrote: >> On 4.9.13 with KASAN enabled [1], we see a number of stack unwinding >> errors reported [2,3]. >> >> This seems to occ

Re: stack frame unwindind KASAN errors

On 27 February 2017 at 23:47, Josh Poimboeuf wrote: > On Mon, Feb 27, 2017 at 12:49:59PM +0800, Daniel J Blueman wrote: >> On 4.9.13 with KASAN enabled [1], we see a number of stack unwinding >> errors reported [2,3]. >> >> This seems to occur at half of boots. >>

stack frame unwindind KASAN errors

f1 00 f4 f4 f4 f2 f2 f2 f2 00 00 f4 f4 f3 f3 ^ 881034eafa80: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 881034eafb00: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 f4 Disabling lock debugging due to kernel taint -- Daniel J Blueman

stack frame unwindind KASAN errors

f1 00 f4 f4 f4 f2 f2 f2 f2 00 00 f4 f4 f3 f3 ^ 881034eafa80: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 881034eafb00: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 f4 Disabling lock debugging due to kernel taint -- Daniel J Blueman

Re: [4.9.10] ip_route_me_harder() reading off-slab

On 17 February 2017 at 13:36, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Fri, 2017-02-17 at 12:36 +0800, Daniel J Blueman wrote: >> When booting a VM in libvirt/KVM attached to a local bridge and KASAN >> enabled on 4.9.10, we see a stream of KASAN warnings about

Re: [4.9.10] ip_route_me_harder() reading off-slab

On 17 February 2017 at 13:36, Eric Dumazet wrote: > On Fri, 2017-02-17 at 12:36 +0800, Daniel J Blueman wrote: >> When booting a VM in libvirt/KVM attached to a local bridge and KASAN >> enabled on 4.9.10, we see a stream of KASAN warnings about off-slab >> access [1]. >&

[4.9.10] ip_route_me_harder() reading off-slab

fc fc fc fc fc fc fc fc fc [ 473.581151] ^ [ 473.581157] 8801e1eb2900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 473.581164] 8801e1eb2980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc -- Daniel J Blueman

[4.9.10] ip_route_me_harder() reading off-slab

fc fc fc fc fc fc fc fc fc [ 473.581151] ^ [ 473.581157] 8801e1eb2900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 473.581164] 8801e1eb2980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc -- Daniel J Blueman

Re: Dell XPS13: MCE (Hardware Error) reported

On 5 January 2017 at 13:00, Daniel J Blueman <dan...@quora.org> wrote: > On Thursday, January 5, 2017 at 9:20:04 AM UTC+8, Raj, Ashok wrote: >> Hi Boris >> >> thanks for forwarding. >> >> > > CPUID Vendor Intel Family 6 Model 142 >&g

Re: Dell XPS13: MCE (Hardware Error) reported

On 5 January 2017 at 13:00, Daniel J Blueman wrote: > On Thursday, January 5, 2017 at 9:20:04 AM UTC+8, Raj, Ashok wrote: >> Hi Boris >> >> thanks for forwarding. >> >> > > CPUID Vendor Intel Family 6 Model 142 >> This is Kabylake Mobile >>

Re: Question regarding power button of Dell XPS13

uys run into bit-depth colour issues [1] on the Skylake/9350 with USB-C to HDMI adapters? Dan [1] https://bugs.freedesktop.org/show_bug.cgi?id=99137 -- Daniel J Blueman

Re: Question regarding power button of Dell XPS13

depth colour issues [1] on the Skylake/9350 with USB-C to HDMI adapters? Dan [1] https://bugs.freedesktop.org/show_bug.cgi?id=99137 -- Daniel J Blueman

Re: Dell XPS13: MCE (Hardware Error) reported

s, it is between the local APIC space at FEE0:FEE and SPI BIOS at FFE0:, so will be subtractively decoded to the PCH, maybe being aborted due to a device not being enabled (hello TPM3 or new image processor). As it is logged as soon as the MCE driver initialises, it was probably logged during BIOS init, so there's not much we can do about it anyways. Dan -- Daniel J Blueman

Re: Dell XPS13: MCE (Hardware Error) reported

s, it is between the local APIC space at FEE0:FEE and SPI BIOS at FFE0:, so will be subtractively decoded to the PCH, maybe being aborted due to a device not being enabled (hello TPM3 or new image processor). As it is logged as soon as the MCE driver initialises, it was probably logged during BIOS init, so there's not much we can do about it anyways. Dan -- Daniel J Blueman

FOSSASIA'17 Kernel Track: Call for Speakers

; for more details see: http://blog.fossasia.org/fossasia-summit-2017-singapore-call-for-speakers/ We are looking forward to seeing you at the summit! Daniel -- Daniel J Blueman

FOSSASIA'17 Kernel Track: Call for Speakers

; for more details see: http://blog.fossasia.org/fossasia-summit-2017-singapore-call-for-speakers/ We are looking forward to seeing you at the summit! Daniel -- Daniel J Blueman

[PATCH] x86/urgent: Fix NumaConnect2 MMCFG PCI access

The MMCFG PCI accessors weren't being setup for NumacConnect2 correctly due to over-early assignment; this would create the potential for the wrong PCI domain to be accessed. Fix this by using the correct arch-specific PCI init function. Signed-off-by: Daniel J Blueman Acked-by: Steffen

[tip:x86/urgent] x86/numachip: Fix NumaConnect2 MMCFG PCI access

Commit-ID: dd7a5ab495019d424c2b0747892eb2e38a052ba5 Gitweb: http://git.kernel.org/tip/dd7a5ab495019d424c2b0747892eb2e38a052ba5 Author: Daniel J Blueman AuthorDate: Thu, 31 Dec 2015 02:06:47 +0800 Committer: Thomas Gleixner CommitDate: Wed, 30 Dec 2015 19:19:03 +0100 x86/numachip: Fix

[tip:x86/urgent] x86/numachip: Fix NumaConnect2 MMCFG PCI access

Commit-ID: dd7a5ab495019d424c2b0747892eb2e38a052ba5 Gitweb: http://git.kernel.org/tip/dd7a5ab495019d424c2b0747892eb2e38a052ba5 Author: Daniel J Blueman <dan...@numascale.com> AuthorDate: Thu, 31 Dec 2015 02:06:47 +0800 Committer: Thomas Gleixner <t...@linutronix.de> CommitD

[PATCH] x86/urgent: Fix NumaConnect2 MMCFG PCI access

The MMCFG PCI accessors weren't being setup for NumacConnect2 correctly due to over-early assignment; this would create the potential for the wrong PCI domain to be accessed. Fix this by using the correct arch-specific PCI init function. Signed-off-by: Daniel J Blueman <dan...@numascale.

[PATCH 1/2] PCI: Add mechanism to find topologically near cores

to find cores with reasonable locality to a device; use the existing precendent of RECLAIM_DISTANCE (30), wrapping the offset. Signed-off-by: Daniel J Blueman --- drivers/pci/pci.c | 15 +++ include/linux/pci.h | 1 + 2 files changed, 16 insertions(+) diff --git a/drivers/pci/pci.c b

[PATCH 2/2] ixgbe: Use core to device locality interface

Signed-off-by: Daniel J Blueman --- drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c index f3168bc..12c4ce1 100644 --- a/drivers/net

[PATCH 2/2] ixgbe: Use core to device locality interface

Signed-off-by: Daniel J Blueman <dan...@numascale.com> --- drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c index f3168bc..12c4ce1

[PATCH 1/2] PCI: Add mechanism to find topologically near cores

to find cores with reasonable locality to a device; use the existing precendent of RECLAIM_DISTANCE (30), wrapping the offset. Signed-off-by: Daniel J Blueman <dan...@numascale.com> --- drivers/pci/pci.c | 15 +++ include/linux/pci.h | 1 + 2 files changed, 16 insertions(+) diff

Re: [TESTPATCH v2] xhci: fix usb2 resume timing and races.

or Resume state. > > v2. fix parentheses when checking for uncleared resume variables. > we want: if ((unclear1 OR unclear2 ) AND !in_resume AND !in_U3) { .. } > > Signed-off-by: Mathias Nyman Excellent; this correctly prevents the cyclic chain of suspend attempts, resolving the

Re: [TESTPATCH v2] xhci: fix usb2 resume timing and races.

riables if port > is not in U0 or Resume state. > > v2. fix parentheses when checking for uncleared resume variables. > we want: if ((unclear1 OR unclear2 ) AND !in_resume AND !in_U3) { .. } > > Signed-off-by: Mathias Nyman <mathias.ny...@linux.intel.com> Excellent; this c

RE: overriding ACPI _CRS method

On Mon, Nov 30, 2015 at 11:09 AM, Zheng, Lv wrote: Hi, IMO, if you want the new _CRS to be applied during the Linux early boot stage, you can override the table using initrd override or DSDT override mechanism. Please see Documentation/acpi/initrd_table_override.txt or

overriding ACPI _CRS method

: AE_NOT_FOUND, (SSDT:POWERNOW) while loading table (20150930/tbxfload-193) ACPI Error: 2 table load failures, 0 successful (20150930/tbxfload-214) -- Daniel J Blueman Principal Software Engineer, Numascale -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" i

overriding ACPI _CRS method

: AE_NOT_FOUND, (SSDT:POWERNOW) while loading table (20150930/tbxfload-193) ACPI Error: 2 table load failures, 0 successful (20150930/tbxfload-214) -- Daniel J Blueman Principal Software Engineer, Numascale -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" i

RE: overriding ACPI _CRS method

On Mon, Nov 30, 2015 at 11:09 AM, Zheng, Lv wrote: Hi, IMO, if you want the new _CRS to be applied during the Linux early boot stage, you can override the table using initrd override or DSDT override mechanism. Please see Documentation/acpi/initrd_table_override.txt or

Re: [4.3] kworker busy in pm_runtime_work

On 23 November 2015 at 23:52, Alan Stern wrote: > On Sun, 22 Nov 2015, Daniel J Blueman wrote: > >> On 16 November 2015 at 23:22, Alan Stern wrote: >> > On Mon, 16 Nov 2015, Daniel J Blueman wrote: >> > >> >> Tuning USB suspend [1] in 4.3 on a Dell XP

Re: [4.3] kworker busy in pm_runtime_work

On 23 November 2015 at 23:52, Alan Stern <st...@rowland.harvard.edu> wrote: > On Sun, 22 Nov 2015, Daniel J Blueman wrote: > >> On 16 November 2015 at 23:22, Alan Stern <st...@rowland.harvard.edu> wrote: >> > On Mon, 16 Nov 2015, Daniel J Blueman wrote: >>

Re: [4.3] kworker busy in pm_runtime_work

On 16 November 2015 at 23:22, Alan Stern wrote: > On Mon, 16 Nov 2015, Daniel J Blueman wrote: > >> Tuning USB suspend [1] in 4.3 on a Dell XPS 15 9553 (Skylake), I see a >> kworker thread spinning in rpm_suspend [2]. >> >> What is the most useful debug to ge

Re: [4.3] kworker busy in pm_runtime_work

On 16 November 2015 at 23:22, Alan Stern <st...@rowland.harvard.edu> wrote: > On Mon, 16 Nov 2015, Daniel J Blueman wrote: > >> Tuning USB suspend [1] in 4.3 on a Dell XPS 15 9553 (Skylake), I see a >> kworker thread spinning in rpm_suspend [2]. >> >> What

Re: [lkp] [x86/numachip] db1003a719: BUG: kernel early-boot hang

Hi Ying Huang, On Tue, Nov 10, 2015 at 6:12 AM, kernel test robot wrote: FYI, we noticed the below changes on https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit db1003a719d75cebe5843a7906c02c29bec9922c ("x86/numachip: Cleanup Numachip support") Elapsed

Re: [lkp] [x86/numachip] db1003a719: BUG: kernel early-boot hang

Hi Ying Huang, On Tue, Nov 10, 2015 at 6:12 AM, kernel test robot wrote: FYI, we noticed the below changes on https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit db1003a719d75cebe5843a7906c02c29bec9922c ("x86/numachip: Cleanup

Re: [PATCH 3/3] x86/apic: Use smaller array for __apicid_to_node[] mapping

On Fri, Oct 9, 2015 at 11:35 PM, Jiang Liu wrote: On 2015/10/3 3:12, Denys Vlasenko wrote: From: Daniel J Blueman The Intel x2APIC spec states the upper 16-bits of APIC ID is the cluster ID [1, p2-12], intended for future distributed systems. Beyond the legacy 8-bit APIC ID, Numascale

Re: [PATCH 3/3] x86/apic: Use smaller array for __apicid_to_node[] mapping

On Fri, Oct 9, 2015 at 11:35 PM, Jiang Liu <jiang@linux.intel.com> wrote: On 2015/10/3 3:12, Denys Vlasenko wrote: From: Daniel J Blueman <dan...@numascale.com> The Intel x2APIC spec states the upper 16-bits of APIC ID is the cluster ID [1, p2-12], intended for future

Re: igb: do not re-init SR-IOV during probe

It would be great if the patch "igb: do not re-init SR-IOV during probe" [1] can be backported from 4.3-rc to stable kernels, since it fixes the regression introduced by "igb: do a reset on SR-IOV re-init if device is down" [2]. The regression was introduced in 3.16 and can isolate the IPMI

Re: igb: do not re-init SR-IOV during probe

It would be great if the patch "igb: do not re-init SR-IOV during probe" [1] can be backported from 4.3-rc to stable kernels, since it fixes the regression introduced by "igb: do a reset on SR-IOV re-init if device is down" [2]. The regression was introduced in 3.16 and can isolate the IPMI

[PATCH v2] x86/apic: Use smaller array for __apicid_to_node[] mapping

C ID space, and on a 48-core legacy 8-bit APIC ID system with and without CONFIG_NUMA, CONFIG_NUMA_EMU and CONFIG_AMD_NUMA. v2: Improved readability by moving static variable out; integrated Denys's numa emulation fix Signed-off-by: Daniel J Blueman CC: Denys Vlasenko CC: Ingo Molnar CC: Thomas Gl

[PATCH v2] x86/apic: Use smaller array for __apicid_to_node[] mapping

C ID space, and on a 48-core legacy 8-bit APIC ID system with and without CONFIG_NUMA, CONFIG_NUMA_EMU and CONFIG_AMD_NUMA. v2: Improved readability by moving static variable out; integrated Denys's numa emulation fix Signed-off-by: Daniel J Blueman <dan...@numascale.com> CC: Denys Vlasenko <

Re: [PATCH RFC] x86: Reduce MAX_LOCAL_APIC and MAX_IO_APICS

81472 223640051553f65 vmlinux 182330341786168 2281472 223006741544802 vmlinux-patched Works peachy on a 256-core system with a 20-bit APIC ID space, and on a 48-core legacy 8-bit APIC ID system. If we care, I can make numa_cpu_node O(1) lookup for typical cases. Signe

Re: [PATCH RFC] x86: Reduce MAX_LOCAL_APIC and MAX_IO_APICS

81472 223640051553f65 vmlinux 182330341786168 2281472 223006741544802 vmlinux-patched Works peachy on a 256-core system with a 20-bit APIC ID space, and on a 48-core legacy 8-bit APIC ID system. If we care, I can make numa_cpu_node O(1) lookup for typical cases. Signed-

Re: [RFC] PCI: Unassigned Expansion ROM BARs

, option ROMs are a dying trend in favour of shipped binary blobs and open-coded initialisation for cross-platform support, and there are only 10 users of pci_map_rom(). Thanks, Daniel [1] https://github.com/numascale/nc-utils/blob/master/bootloader/dnc-mmio.c -- Daniel J Blueman -- To unsubsc

Re: [RFC] PCI: Unassigned Expansion ROM BARs

, option ROMs are a dying trend in favour of shipped binary blobs and open-coded initialisation for cross-platform support, and there are only 10 users of pci_map_rom(). Thanks, Daniel [1] https://github.com/numascale/nc-utils/blob/master/bootloader/dnc-mmio.c -- Daniel J Blueman -- To unsubsc

[tip:x86/apic] x86/numachip: Add Numachip IPI optimisations

Commit-ID: ad03a9c25d258641556c7198e26fd882c741987a Gitweb: http://git.kernel.org/tip/ad03a9c25d258641556c7198e26fd882c741987a Author: Daniel J Blueman AuthorDate: Mon, 21 Sep 2015 01:02:01 +0800 Committer: Thomas Gleixner CommitDate: Tue, 22 Sep 2015 22:25:33 +0200 x86/numachip: Add

[tip:x86/apic] x86/numachip: Introduce Numachip2 timer mechanisms

Commit-ID: ce2e572cfe7b2fc3f0e9da4aa7bc61a2c2c51fc7 Gitweb: http://git.kernel.org/tip/ce2e572cfe7b2fc3f0e9da4aa7bc61a2c2c51fc7 Author: Daniel J Blueman AuthorDate: Mon, 21 Sep 2015 18:02:25 +0800 Committer: Thomas Gleixner CommitDate: Tue, 22 Sep 2015 22:25:33 +0200 x86/numachip

[tip:x86/apic] x86/numachip: Add Numachip2 APIC support

Commit-ID: d9d4dee6cedfa17e5eedcba242dca3091bf73bc3 Gitweb: http://git.kernel.org/tip/d9d4dee6cedfa17e5eedcba242dca3091bf73bc3 Author: Daniel J Blueman AuthorDate: Mon, 21 Sep 2015 01:02:00 +0800 Committer: Thomas Gleixner CommitDate: Tue, 22 Sep 2015 22:25:33 +0200 x86/numachip: Add

[tip:x86/apic] x86/numachip: Cleanup Numachip support

Commit-ID: db1003a719d75cebe5843a7906c02c29bec9922c Gitweb: http://git.kernel.org/tip/db1003a719d75cebe5843a7906c02c29bec9922c Author: Daniel J Blueman AuthorDate: Mon, 21 Sep 2015 01:01:59 +0800 Committer: Thomas Gleixner CommitDate: Tue, 22 Sep 2015 22:25:32 +0200 x86/numachip

[tip:x86/apic] x86/numachip: Add Numachip IPI optimisations

Commit-ID: ad03a9c25d258641556c7198e26fd882c741987a Gitweb: http://git.kernel.org/tip/ad03a9c25d258641556c7198e26fd882c741987a Author: Daniel J Blueman <dan...@numascale.com> AuthorDate: Mon, 21 Sep 2015 01:02:01 +0800 Committer: Thomas Gleixner <t...@linutronix.de> CommitD

[tip:x86/apic] x86/numachip: Introduce Numachip2 timer mechanisms

Commit-ID: ce2e572cfe7b2fc3f0e9da4aa7bc61a2c2c51fc7 Gitweb: http://git.kernel.org/tip/ce2e572cfe7b2fc3f0e9da4aa7bc61a2c2c51fc7 Author: Daniel J Blueman <dan...@numascale.com> AuthorDate: Mon, 21 Sep 2015 18:02:25 +0800 Committer: Thomas Gleixner <t...@linutronix.de> CommitD

[tip:x86/apic] x86/numachip: Cleanup Numachip support

Commit-ID: db1003a719d75cebe5843a7906c02c29bec9922c Gitweb: http://git.kernel.org/tip/db1003a719d75cebe5843a7906c02c29bec9922c Author: Daniel J Blueman <dan...@numascale.com> AuthorDate: Mon, 21 Sep 2015 01:01:59 +0800 Committer: Thomas Gleixner <t...@linutronix.de> CommitD

[tip:x86/apic] x86/numachip: Add Numachip2 APIC support

Commit-ID: d9d4dee6cedfa17e5eedcba242dca3091bf73bc3 Gitweb: http://git.kernel.org/tip/d9d4dee6cedfa17e5eedcba242dca3091bf73bc3 Author: Daniel J Blueman <dan...@numascale.com> AuthorDate: Mon, 21 Sep 2015 01:02:00 +0800 Committer: Thomas Gleixner <t...@linutronix.de> CommitD

[PATCH v2] x86: Introduce Numachip2 timer mechanisms

-by: Daniel J Blueman Acked-by: Steffen Persvold --- arch/x86/include/asm/numachip/numachip_csr.h | 9 +++ drivers/clocksource/Makefile | 1 + drivers/clocksource/numachip.c | 95 3 files changed, 105 insertions(+) create mode 100644

[PATCH v2] x86: Introduce Numachip2 timer mechanisms

-by: Daniel J Blueman <dan...@numascale.com> Acked-by: Steffen Persvold <s...@numascale.com> --- arch/x86/include/asm/numachip/numachip_csr.h | 9 +++ drivers/clocksource/Makefile | 1 + drivers/clocksource/numachip.c | 95 3 f

[PATCH 3/4] x86: Add Numachip IPI optimisations

bit for efficiency. Signed-off-by: Daniel J Blueman Acked-by: Steffen Persvold --- arch/x86/include/asm/numachip/numachip_csr.h | 1 + arch/x86/kernel/apic/apic_numachip.c | 36 2 files changed, 32 insertions(+), 5 deletions(-) diff --git a/arch/x86

[PATCH 4/4] x86: Introduce Numachip2 timer mechanisms

Add 1GHz 64-bit Numachip2 clocksource timer support for accurate system-wide timekeeping, as core TSCs are unsynchronised. Additionally, add a per-core clockevent mechanism that interrupts via the platform IPI vector after a programmed period. Signed-off-by: Daniel J Blueman Acked-by: Steffen

[PATCH 2/4] x86: Add Numachip2 APIC support

Introduce support for Numachip2 remote interrupts via detecting the right ACPI SRAT signature. Access is performed via a fixed mapping in the x86 physical address space. Signed-off-by: Daniel J Blueman Acked-by: Steffen Persvold --- arch/x86/include/asm/numachip/numachip.h | 1 + arch

[PATCH 1/4] x86: Cleanup Numachip support

Drop unused code and includes in Numachip header files and APIC driver. Additionally, use the 'numachip1' prefix on Numachip1-specific functions; this prepares for adding Numachip2 support in later patches. Signed-off-by: Daniel J Blueman Acked-by: Steffen Persvold --- arch/x86/include/asm

[PATCH 3/4] x86: Add Numachip IPI optimisations

bit for efficiency. Signed-off-by: Daniel J Blueman <dan...@numascale.com> Acked-by: Steffen Persvold <s...@numascale.com> --- arch/x86/include/asm/numachip/numachip_csr.h | 1 + arch/x86/kernel/apic/apic_numachip.c | 36 2 files changed, 32 inse

[PATCH 4/4] x86: Introduce Numachip2 timer mechanisms

Add 1GHz 64-bit Numachip2 clocksource timer support for accurate system-wide timekeeping, as core TSCs are unsynchronised. Additionally, add a per-core clockevent mechanism that interrupts via the platform IPI vector after a programmed period. Signed-off-by: Daniel J Blueman <

[PATCH 2/4] x86: Add Numachip2 APIC support

Introduce support for Numachip2 remote interrupts via detecting the right ACPI SRAT signature. Access is performed via a fixed mapping in the x86 physical address space. Signed-off-by: Daniel J Blueman <dan...@numascale.com> Acked-by: Steffen Persvold <s...@numascale.com> --- arch

[PATCH 1/4] x86: Cleanup Numachip support

Drop unused code and includes in Numachip header files and APIC driver. Additionally, use the 'numachip1' prefix on Numachip1-specific functions; this prepares for adding Numachip2 support in later patches. Signed-off-by: Daniel J Blueman <dan...@numascale.com> Acked-by: Steffen Persv

Re: [PATCH] mm: meminit: Finish initialisation of struct pages before basic setup

Hi Nate, On Wed, Jun 24, 2015 at 11:50 PM, Nathan Zimmer wrote: My apologies for taking so long to get back to this. I think I did locate two potential sources of slowdown. One is the set_cpus_allowed_ptr as I have noted previously. However I only notice that on the very largest boxes. I did

Re: [PATCH] mm: meminit: Finish initialisation of struct pages before basic setup

Hi Nate, On Wed, Jun 24, 2015 at 11:50 PM, Nathan Zimmer nzim...@sgi.com wrote: My apologies for taking so long to get back to this. I think I did locate two potential sources of slowdown. One is the set_cpus_allowed_ptr as I have noted previously. However I only notice that on the very

Re: lockup when C1E and high-resolution timers enabled

On 14 June 2015 at 22:49, Christoph Fritz wrote: > On Sun, 2015-06-14 at 15:54 +0800, Daniel J Blueman wrote: >> As a workaround, you can probably just disable message triggered C1E >> (see the BKDG p399 [1]): >> >> val=0x$(setpci -s 00:18.4 0xd4.l) # read D18F3xD4 >

Re: lockup when C1E and high-resolution timers enabled

On 14 June 2015 at 12:39, Christoph Fritz wrote: > On Sun, 2015-06-14 at 11:13 +0800, Daniel J Blueman wrote: >> On Sunday, June 14, 2015 at 4:00:06 AM UTC+8, Christoph Fritz wrote: >> > Hi, >> > >> > on following computer configuration, I do get hard lockup u

Re: lockup when C1E and high-resolution timers enabled

On 14 June 2015 at 12:39, Christoph Fritz chf.fr...@googlemail.com wrote: On Sun, 2015-06-14 at 11:13 +0800, Daniel J Blueman wrote: On Sunday, June 14, 2015 at 4:00:06 AM UTC+8, Christoph Fritz wrote: Hi, on following computer configuration, I do get hard lockup under heavy IO-Load

Re: lockup when C1E and high-resolution timers enabled

On 14 June 2015 at 22:49, Christoph Fritz chf.fr...@googlemail.com wrote: On Sun, 2015-06-14 at 15:54 +0800, Daniel J Blueman wrote: As a workaround, you can probably just disable message triggered C1E (see the BKDG p399 [1]): val=0x$(setpci -s 00:18.4 0xd4.l) # read D18F3xD4 mhm

Re: lockup when C1E and high-resolution timers enabled

e from http://www.amd64.org/microcode/amd-ucode-latest.tar.bz2 Thanks, Daniel -- Daniel J Blueman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: lockup when C1E and high-resolution timers enabled

is updated in the F2g BIOS: http://www.gigabyte.com/products/product-page.aspx?pid=4717#bios Did you try both BIOS releases with defaults? If still issues, also try with the current family 10h microcode from http://www.amd64.org/microcode/amd-ucode-latest.tar.bz2 Thanks, Daniel -- Daniel J

[PATCH -next] iommu: Fix build failure without INTEL_IOMMU

Fix Intel IOMMU build failure in linux-next when CONFIG_INTEL_IOMMU is not enabled. Signed-off-by: Daniel J Blueman --- drivers/iommu/intel_irq_remapping.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/iommu/intel_irq_remapping.c b/drivers/iommu/intel_irq_remapping.c

[PATCH -next] iommu: Fix build failure without INTEL_IOMMU

Fix Intel IOMMU build failure in linux-next when CONFIG_INTEL_IOMMU is not enabled. Signed-off-by: Daniel J Blueman dan...@numascale.com --- drivers/iommu/intel_irq_remapping.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/iommu/intel_irq_remapping.c b/drivers/iommu

Re: [PATCH] mm: meminit: Finish initialisation of struct pages before basic setup

-- Daniel J Blueman Principal Software Engineer, Numascale On Sat, May 23, 2015 at 1:14 AM, Waiman Long wrote: On 05/22/2015 05:33 AM, Mel Gorman wrote: On Fri, May 22, 2015 at 02:30:01PM +0800, Daniel J Blueman wrote: On Thu, May 14, 2015 at 6:03 PM, Daniel J Blueman wrote: On Thu, May

Re: [PATCH] mm: meminit: Finish initialisation of struct pages before basic setup

On Thu, May 14, 2015 at 6:03 PM, Daniel J Blueman wrote: On Thu, May 14, 2015 at 12:31 AM, Mel Gorman wrote: On Wed, May 13, 2015 at 10:53:33AM -0500, nzimmer wrote: I am just noticed a hang on my largest box. I can only reproduce with large core counts, if I turn down the number of cpus

Re: [PATCH] mm: meminit: Finish initialisation of struct pages before basic setup

On Thu, May 14, 2015 at 6:03 PM, Daniel J Blueman dan...@numascale.com wrote: On Thu, May 14, 2015 at 12:31 AM, Mel Gorman mgor...@suse.de wrote: On Wed, May 13, 2015 at 10:53:33AM -0500, nzimmer wrote: I am just noticed a hang on my largest box. I can only reproduce with large core counts

Re: [PATCH] mm: meminit: Finish initialisation of struct pages before basic setup

-- Daniel J Blueman Principal Software Engineer, Numascale On Sat, May 23, 2015 at 1:14 AM, Waiman Long waiman.l...@hp.com wrote: On 05/22/2015 05:33 AM, Mel Gorman wrote: On Fri, May 22, 2015 at 02:30:01PM +0800, Daniel J Blueman wrote: On Thu, May 14, 2015 at 6:03 PM, Daniel J Blueman dan

Re: [PATCH] mm: meminit: Finish initialisation of struct pages before basic setup

On Thu, May 14, 2015 at 12:31 AM, Mel Gorman wrote: On Wed, May 13, 2015 at 10:53:33AM -0500, nzimmer wrote: I am just noticed a hang on my largest box. I can only reproduce with large core counts, if I turn down the number of cpus it doesn't have an issue. Odd. The number of core counts

irq_work_sync hangs

irq_work *work) { WARN_ON_ONCE(irqs_disabled()); + if (!(work->flags & ~IRQ_WORK_LAZY)) + pr_err("sync id %lu start flags=0x%lx\n", work->id, work->flags); + while (work->flags & IRQ_WORK_BUSY) cpu_relax(); + + if (!(w

irq_work_sync hangs

); + while (work-flags IRQ_WORK_BUSY) cpu_relax(); + + if (!(work-flags ~IRQ_WORK_LAZY)) + pr_err(sync id %lu end\n, work-id); } EXPORT_SYMBOL_GPL(irq_work_sync); -- Daniel J Blueman Principal Software Engineer, Numascale AS -- To unsubscribe from this list: send

Re: [PATCH] mm: meminit: Finish initialisation of struct pages before basic setup

On Thu, May 14, 2015 at 12:31 AM, Mel Gorman mgor...@suse.de wrote: On Wed, May 13, 2015 at 10:53:33AM -0500, nzimmer wrote: I am just noticed a hang on my largest box. I can only reproduce with large core counts, if I turn down the number of cpus it doesn't have an issue. Odd. The number

Re: [Patch v3] x86, irq: Allocate CPU vectors from device local CPUs if possible

policies. It tries to allocate CPU vectors from CPUs on device local node first, and then fallback to all online(global) CPUs. This mechanism may be used to support NumaConnect systems to allocate CPU vectors from device local node. Signed-off-by: Jiang Liu Cc: Daniel J Blueman --- Hi Thomas

Re: [Patch v3] x86, irq: Allocate CPU vectors from device local CPUs if possible

@linux.intel.com Cc: Daniel J Blueman dan...@numascale.com --- Hi Thomas, I feel this should be simpliest version now:) Thanks! Gerry --- arch/x86/kernel/apic/vector.c | 23 ++- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/arch/x86/kernel/apic/vector.c b/arch

Re: [PATCH 0/13] Parallel struct page initialisation v4

On Sat, May 2, 2015 at 4:52 PM, Daniel J Blueman wrote: On Sat, May 2, 2015 at 8:09 AM, Waiman Long wrote: On 05/01/2015 06:02 PM, Waiman Long wrote: Bad news! I tried your patch on a 24-TB DragonHawk and got an out of memory panic. The kernel log messages were: : [ 80.126186] CPU

Re: [PATCH 0/13] Parallel struct page initialisation v4

On Sat, May 2, 2015 at 8:09 AM, Waiman Long wrote: On 05/01/2015 06:02 PM, Waiman Long wrote: Bad news! I tried your patch on a 24-TB DragonHawk and got an out of memory panic. The kernel log messages were: : [ 80.126186] CPU 474: hi: 186, btch: 31 usd: 0 [ 80.131457] CPU 475:

Re: [PATCH 0/13] Parallel struct page initialisation v4

On Sat, May 2, 2015 at 8:09 AM, Waiman Long waiman.l...@hp.com wrote: On 05/01/2015 06:02 PM, Waiman Long wrote: Bad news! I tried your patch on a 24-TB DragonHawk and got an out of memory panic. The kernel log messages were: : [ 80.126186] CPU 474: hi: 186, btch: 31 usd: 0 [

Re: [PATCH 0/13] Parallel struct page initialisation v4

On Sat, May 2, 2015 at 4:52 PM, Daniel J Blueman dan...@numascale.com wrote: On Sat, May 2, 2015 at 8:09 AM, Waiman Long waiman.l...@hp.com wrote: On 05/01/2015 06:02 PM, Waiman Long wrote: Bad news! I tried your patch on a 24-TB DragonHawk and got an out of memory panic. The kernel log

  1   2   3   4   5   6   7   >