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
>> Subje
58
Code: b8 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
005 (0x5)
880638ad7fd0: ...
880638ad7fd8: 7f504bfe56f0 (0x7f504bfe56f0)
880638ad7fe0: 0033 (0x33)
880638ad7fe8: 0246 (0x246)
880638ad7ff0: 7ffddaab6048 (0x7ffddaab6048)
880638ad7ff8: 0000002b (0x2b)
--
Daniel J Blueman
e+0x124/0x1a0
__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
Airlie
Cc: sta...@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..add9cc97a3
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
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.
>>
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
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].
>&
fc fc 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
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
>>
of you guys 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
For core-generated cycles, 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
; 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
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: St
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
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
essed
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/driver
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, resolvin
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
Documentation/acpi/dsd
ption: 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
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
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
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 time:
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
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
i
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: Thom
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
execution in linux. That said, 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
--
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
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
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
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
: 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
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
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
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
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/i
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 c
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
>
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
rrent family 10h microcode 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/
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
--
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
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
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
>id, work->flags);
}
}
@@ -190,7 +205,13 @@ void irq_work_sync(struct 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);
+
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
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
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: h
On Wed, Apr 29, 2015 at 2:38 AM, nzimmer wrote:
On 04/28/2015 11:06 AM, Pekka Enberg wrote:
On Tue, Apr 28, 2015 at 5:36 PM, Mel Gorman wrote:
Struct page initialisation had been identified as one of the
reasons why
large machines take a long time to boot. Patches were posted a long
time ago
From f822139736cab8434302693c635fa146b465273c Mon Sep 17 00:00:00 2001
From: Daniel J Blueman
Date: Thu, 23 Apr 2015 23:26:27 +0800
Subject: [RFC] Speedup PMD setup
Using non-temporal writes prevents read-modify-write cycles,
which are much slower over large topologies.
Adapt the existing memset() function into a _nocache va
On Tue, Apr 7, 2015 at 10:39 PM, Joe Perches wrote:
On Tue, 2015-04-07 at 22:29 +0800, Daniel J Blueman wrote:
Quite a few platforms use ttyS2 for their serial-over-LAN, so fix
early
printk support for ttyS2 and 3, avoiding the need to hard-code the
IO port.
[]
diff --git a/arch/x86/boot
Quite a few platforms use ttyS2 for their serial-over-LAN, so fix early
printk support for ttyS2 and 3, avoiding the need to hard-code the IO port.
Signed-off-by: Daniel J Blueman
---
arch/x86/boot/early_serial_console.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git
g a lot of IPIs, is calling
stop_machine() via something like:
while :; do
echo "base=0x200 size=0x800 type=write-back" >/proc/mtrr
echo "disable=4" >| /proc/mtrr
done
Of course, ensure base is above DRAM and any 64-bit MMIO for no
side-effects and en
On Thu, Mar 19, 2015 at 2:42 AM, Borislav Petkov wrote:
On Wed, Mar 18, 2015 at 11:02:27AM +0100, Borislav Petkov wrote:
I don't like the ifdeffery in your solution and would like to try
to fix
it in a cleaner way. Unless you come up with a better solution
first.
Ok, how about this below?
On Wed, Mar 4, 2015 at 7:45 PM, Borislav Petkov wrote:
On Wed, Mar 04, 2015 at 10:18:47AM +0100, Borislav Petkov wrote:
Let me try to reproduce that here.
Well, it works fine on a single-socket box here:
[1.045426] microcode: updated early to new patch_level=0x01dc
[1.060957] mi
Commit-ID: c8a470cab030bae8f9e6e5cfff72b047b7c627a7
Gitweb: http://git.kernel.org/tip/c8a470cab030bae8f9e6e5cfff72b047b7c627a7
Author: Daniel J Blueman
AuthorDate: Thu, 12 Mar 2015 16:55:13 +0100
Committer: Ingo Molnar
CommitDate: Thu, 12 Mar 2015 16:58:59 +0100
x86/apic/numachip: Fix
s per Boris's feedback
v3: Test against boot cpu to correct behaviour on larger systems with global IO
v4: Use static_cpu_has_safe(), as Boris suggests
Candidate for stable.
Signed-off-by: Daniel J Blueman
---
arch/x86/kernel/apic/apic_numachip.c | 22 --
1 file changed, 16
On 04/03/2015 00:38, Borislav Petkov wrote:
On Tue, Mar 03, 2015 at 11:10:44PM +0800, Daniel J Blueman wrote:
The changes in 871b72dd "x86: microcode: use smp_call_function_single instead
of set_cpus_allowed, cleanup of synchronization logic" introduced a check
that prevents built-in
On 04/03/2015 06:38, Bjorn Helgaas wrote:
[+cc linux-pci, linux-acpi]
On Tue, Feb 24, 2015 at 12:37:39PM +0800, Daniel J Blueman wrote:
Hi Bjorn, Jiang,
On 29/01/2015 23:23, Bjorn Helgaas wrote:
Hi Daniel,
On Wed, Jan 28, 2015 at 2:42 AM, Daniel J Blueman wrote:
With systems with a large
s per Boris's feedback
v3: Test against boot cpu features to correct behaviour on larger systems
with global IO
Candidate for stable.
Signed-off-by: Daniel J Blueman
---
arch/x86/kernel/apic/apic_numachip.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
di
s per Boris's feedback
Candidate for stable.
Signed-off-by: Daniel J Blueman
---
arch/x86/kernel/apic/apic_numachip.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/apic/apic_numachip.c
b/arch/x86/kernel/apic/apic_numachip.c
ind
24-31
physical_package_id:3
thread_siblings:,3000
thread_siblings_list:28-29
After fixing:
core_id:5
core_siblings:,
core_siblings_list:16-31
physical_package_id:1
thread_siblings:,3000
thread_siblings_list:28-29
Candidate for stable.
Signed-off-by: Daniel J Bl
e expected behaviour
when early microcode loading is enabled, and when it is not. This has potential
importance as BIOSes often don't load the current microcode.
Signed-off-by: Daniel J Blueman
---
arch/x86/kernel/cpu/microcode/core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch
Hi Bjorn, Jiang,
On 29/01/2015 23:23, Bjorn Helgaas wrote:
Hi Daniel,
On Wed, Jan 28, 2015 at 2:42 AM, Daniel J Blueman wrote:
With systems with a large number of PCI devices, we're seeing lack of 32-bit
MMIO space, eg one quad-port NetXtreme-2 adapter takes 128MB of space [1].
An erra
On Saturday, February 21, 2015 at 3:50:05 AM UTC+8, Ingo Molnar wrote:
> * Linus Torvalds wrote:
>
> > On Fri, Feb 20, 2015 at 1:30 AM, Ingo Molnar wrote:
> > >
> > > So if my memory serves me right, I think it was for
> > > local APICs, and even there mostly it was a performance
> > > issue: if
as per Boris's suggestion
Signed-off-by: Daniel J Blueman
-- [1]
BUG: unable to handle kernel NULL pointer dereference at 0320
IP: [] decode_bus_error+0x2f/0x2b0
PGD 2f8b5a3067 PUD 2f8b5a2067 PMD 0
Oops: [#2] SMP
Modules linked in:
CPU: 224 PID: 11930 Comm: stream_c.exe.gn Ta
: Daniel J Blueman
-- [1]
BUG: unable to handle kernel NULL pointer dereference at 0320
IP: [] decode_bus_error+0x2f/0x2b0
PGD 2f8b5a3067 PUD 2f8b5a2067 PMD 0
Oops: [#2] SMP
Modules linked in:
CPU: 224 PID: 11930 Comm: stream_c.exe.gn Tainted: G D3.19.0 #1
Hardware name
/www.pcisig.com/specifications/pciexpress/base2/PCIe_Base_r2.1_Errata_08Jun10.pdf
-- [3]
pci 0002:01:00.0: BAR 0: [mem size 0x2000 64bit] conflicts with PCI
Bus 0002:00 [mem 0x1002000-0x10027ff pref]
--
Daniel J Blueman
Principal Software Engineer, Numascale
--
To unsubscribe from this
24-31
physical_package_id:3
thread_siblings:,3000
thread_siblings_list:28-29
After fixing:
core_id:5
core_siblings:,
core_siblings_list:16-31
physical_package_id:1
thread_siblings:,3000
thread_siblings_list:28-29
Candidate for stable.
Signed-off-by: Daniel J Bl
own as "FPU".
>
> On Wed, Dec 10, 2014 at 4:25 PM, Daniel J Blueman wrote:
>> With 3.18, I was seeing a significant number of allocation warnings
>> from load_elf_binary call paths [1].
>>
>> Allocating FPU state atomically [2] does prevent potentially sleep
ong)fpu->state & 15);
--
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/
p with a patch in the next day or so; further support for
other systems can be added later as and when tested.
Signed-off-by: Jiang Liu
Cc: Daniel J Blueman
---
Documentation/kernel-parameters.txt |6 ++
arch/x86/kernel/apic/vector.c | 11 +++
2 files changed, 17 insert
On 11/06/2014 07:56 PM, Borislav Petkov wrote:
On Thu, Nov 06, 2014 at 07:10:45PM +0800, Daniel J Blueman wrote:
"As the first check for 64GB or larger memory returns a 2GB memory
block size in that case, the following check for less than 64GB will
always
Right, but why isn't ther
On 11/06/2014 06:40 PM, Borislav Petkov wrote:
On Thu, Nov 06, 2014 at 06:33:40PM +0800, Daniel J Blueman wrote:
As the first check for 64GB or larger memory returns a 2GB memory block size
in that case, the following check for less than 64GB will always evaluate
true, leading to unreachable
On 11/06/2014 05:40 PM, Borislav Petkov wrote:
On Thu, Nov 06, 2014 at 12:50:14PM +0800, Daniel J Blueman wrote:
Drop the unused code from selecting a fixed memory block size of 2GB
on large-memory x86-64 systems.
Signed-off-by: Daniel J Blueman
This commit message is seriously lacking an
Drop the unused code from selecting a fixed memory block size of 2GB
on large-memory x86-64 systems.
Signed-off-by: Daniel J Blueman
---
arch/x86/mm/init_64.c | 18 +-
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
Commit-ID: 00e7977dd1bbd46e336d7ef907d0fb6b6a4c294f
Gitweb: http://git.kernel.org/tip/00e7977dd1bbd46e336d7ef907d0fb6b6a4c294f
Author: Daniel J Blueman
AuthorDate: Tue, 4 Nov 2014 16:29:41 +0800
Committer: Thomas Gleixner
CommitDate: Tue, 4 Nov 2014 18:17:27 +0100
x86: numachip: Fix
Commit-ID: b980dcf25d0ee1f0f8c7b6afc0e715a2f5da5ec4
Gitweb: http://git.kernel.org/tip/b980dcf25d0ee1f0f8c7b6afc0e715a2f5da5ec4
Author: Daniel J Blueman
AuthorDate: Tue, 4 Nov 2014 16:29:43 +0800
Committer: Thomas Gleixner
CommitDate: Tue, 4 Nov 2014 18:17:27 +0100
x86: numachip: APIC
Commit-ID: bdee237c0343a5d1a6cf72c7ea68e88338b26e08
Gitweb: http://git.kernel.org/tip/bdee237c0343a5d1a6cf72c7ea68e88338b26e08
Author: Daniel J Blueman
AuthorDate: Tue, 4 Nov 2014 16:29:44 +0800
Committer: Thomas Gleixner
CommitDate: Tue, 4 Nov 2014 18:19:27 +0100
x86: mm: Use 2GB
Commit-ID: 25e5a76bae106e1673887db09e22b19cb1a86c45
Gitweb: http://git.kernel.org/tip/25e5a76bae106e1673887db09e22b19cb1a86c45
Author: Daniel J Blueman
AuthorDate: Tue, 4 Nov 2014 16:29:42 +0800
Committer: Thomas Gleixner
CommitDate: Tue, 4 Nov 2014 18:17:27 +0100
x86: numachip: Elide
Drop printing that serves no purpose, as it's printing fixed or known
values, and mark constant structure appropriately.
Signed-off-by: Daniel J Blueman
---
arch/x86/kernel/apic/apic_numachip.c | 22 +++---
arch/x86/pci/numachip.c | 2 +-
2 files chang
Prevent 16-bit APIC IDs being truncated by using correct mask. This fixes
booting large systems, where the wrong core would receive the startup and
init IPIs, causing hanging.
Signed-off-by: Daniel J Blueman
---
apic_numachip.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
that the memory can't be offlined (for hotplug or otherwise)
with finer 128MB granularity, but this is unimportant due to the high
memory densities generally used with such large-memory systems, where
eg a single DIMM is the order of 16GB.
Signed-off-by: Daniel J Blueman
---
init_64.c |
The default self-IPI path polls the ICR to delay sending the IPI until
there is no IPI in progress. This is redundant on x86-86 APICs, since
IPIs are queued. See the AMD64 Architecture Programmer's Manual, vol 2,
p525.
Signed-off-by: Daniel J Blueman
---
apic_numachip.c |2 +-
1
On 11/04/2014 07:36 AM, Thomas Gleixner wrote:
On Tue, 4 Nov 2014, Daniel J Blueman wrote:
On 11/04/2014 03:38 AM, Thomas Gleixner wrote:
On Sun, 2 Nov 2014, Daniel J Blueman wrote:
On larger x64-64 systems, use a 2GB memory block size to reduce sysfs
entry creation time by 16x. Large is
On 11/04/2014 03:38 AM, Thomas Gleixner wrote:
On Sun, 2 Nov 2014, Daniel J Blueman wrote:
On larger x64-64 systems, use a 2GB memory block size to reduce sysfs
entry creation time by 16x. Large is defined as 64GB or more memory.
This changelog sucks.
It neither tells which sysfs entries
On 11/04/2014 03:45 AM, Thomas Gleixner wrote:
On Sun, 2 Nov 2014, Daniel J Blueman wrote:
Add safe function to check if Numachip is detected, to be used elsewhere.
I cannot find a use case for this. I guess this is a left over of the
earlier 2G change, right?
I left it in as it's c
__kthread_bind(k, kthread->cpu, TASK_PARKED);
> +
>clear_bit(KTHREAD_SHOULD_PARK, &kthread->flags);
>/*
> * We clear the IS_PARKED bit here as we don't wait
> @@ -389,11 +398,8 @@ static void __kthread_unpark(struct task
> * park before that hap
The default self-IPI path polls the ICR to delay sending the IPI until
there is no IPI in progress. This is redundant on x86-86 APICs, since
IPIs are queued. See the AMD64 Architecture Programmer's Manual, vol 2,
p525.
Signed-off-by: Daniel J Blueman
---
arch/x86/kernel/apic/apic_numachip.
Drop printing that serves no purpose, as it's printing fixed or known
values, and mark constant structure appropriately.
Signed-off-by: Daniel J Blueman
---
arch/x86/kernel/apic/apic_numachip.c | 22 +++---
arch/x86/pci/numachip.c | 2 +-
2 files chang
On larger x64-64 systems, use a 2GB memory block size to reduce sysfs
entry creation time by 16x. Large is defined as 64GB or more memory.
Signed-off-by: Daniel J Blueman
---
arch/x86/mm/init_64.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/x86/mm/init_64.c b
Prevent 16-bit APIC IDs being truncated by using correct mask. This fixes
booting large systems, where the wrong core would receive the startup and
init IPIs, causing hanging.
Signed-off-by: Daniel J Blueman
---
arch/x86/kernel/apic/apic_numachip.c | 4 ++--
1 file changed, 2 insertions(+), 2
Add safe function to check if Numachip is detected, to be used elsewhere.
Signed-off-by: Daniel J Blueman
---
arch/x86/include/asm/numachip/numachip.h | 9 +
arch/x86/kernel/apic/apic_numachip.c | 9 +++--
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/x86
On 25/10/2014 21:48, Paul E. McKenney wrote:
On Sat, Oct 25, 2014 at 02:59:24PM +0800, Daniel J Blueman wrote:
Hi Paul,
Finding earlier reference to increasing RCU fanout leaf for the
purpose of "decrease[ing] cache-miss overhead for large systems",
would your suggestion be to in
RCU_FANOUT? 4x leaf?
Or, would it be more cache-friendly to set RCU_FANOUT_LEAF to 8 and
RCU_FANOUT to 48?
Many thanks,
Daniel
--
Daniel J Blueman
Principal Software Engineer, Numascale
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On 19/10/2014 17:23, Ingo Molnar wrote:
* Daniel J Blueman wrote:
Use appropriate memory block size to reduce sysfs entry creation time
by 16x.
Boot-tested with the four permutations of X86_UV and X86_NUMACHIP.
Signed-off-by: Daniel J Blueman
---
arch/x86/mm/init_64.c | 7 ---
1
Drop printing that serves no purpose, as it's printing fixed or known
values, and mark constant structure appropriately.
Signed-off-by: Daniel J Blueman
---
arch/x86/kernel/apic/apic_numachip.c | 22 +++---
arch/x86/pci/numachip.c | 2 +-
2 files chang
Fix 16-bit APIC ID truncation and redundant APIC ICR idle polling for IPI
to self (AMD64 APICs are documented in the system developer manuals to
queue APIC writes).
Signed-off-by: Daniel J Blueman
---
arch/x86/kernel/apic/apic_numachip.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
1 - 100 of 310 matches
Mail list logo
