From: David Gounaris
Date: Wed, 29 Aug 2018 15:13:25 +0200
> @@ -513,6 +517,8 @@ static int hdlc_rx_done(struct ucc_hdlc_private *priv,
> int rx_work_limit)
> break;
>
> case ARPHRD_PPP:
> + case ARPHRD_ETHER:
> +
Please don
On Sat, 2018-09-01 at 09:36 +1000, Finn Thain wrote:
> > The patched kernel (Finn's vmlinux-4.18.0-1-gd44cf7e41c19) boots
> > normally on my Beige G3 Desktop using BootX.
> >
>
> Ben sent two patches, so I picked the most recent one and applied it by
> hand due to corrupted whitespace.
Yup
On Fri, 2018-08-31 at 06:28 -0600, Mac User wrote:
> On 8/30/18 10:49 PM, Benjamin Herrenschmidt wrote:
>
> > On Fri, 2018-08-31 at 14:35 +1000, Benjamin Herrenschmidt wrote:
> >
> > ...
> > Assuming you are using BootX (or miBoot), can you try this patch ?
>
> Yes, I'm using BootX.
>
> Thanks
On Fri, 31 Aug 2018, Mac User wrote:
> On 8/30/18 10:49 PM, Benjamin Herrenschmidt wrote:
>
> > On Fri, 2018-08-31 at 14:35 +1000, Benjamin Herrenschmidt wrote:
> >
> > ...
> > Assuming you are using BootX (or miBoot), can you try this patch ?
>
> Yes, I'm using BootX.
>
> Thanks to Finn for ap
On Tue, Aug 21, 2018 at 12:44:12PM +0200, David Hildenbrand wrote:
> This is the same approach as in the first RFC, but this time without
> exporting device_hotplug_lock (requested by Greg) and with some more
> details and documentation regarding locking. Tested only on x86 so far.
Hi David,
I wo
On Fri, 2018-08-31 at 06:12 +, Andy Tang wrote:
> Hi Scott,
>
> Please see my replay inline.
>
> > -Original Message-
> > From: linux-arm-kernel
> > On Behalf Of Scott Wood
> > Sent: 2018年8月31日 1:43
> > To: Vabhav Sharma ;
> > linux-ker...@vger.kernel.org; devicet...@vger.kernel.org;
On 30.08.2018 21:35, Pasha Tatashin wrote:
>> +
>> +void __ref remove_memory(int nid, u64 start, u64 size)
>
> Remove __ref, otherwise looks good:
Indeed, will do.
Thanks for the review. Will resend in two weeks when I'm back from vacation.
Cheers!
>
> Reviewed-by: Pavel Tatashin
>
>> +{
>>
* Peter Zijlstra [2018-08-31 13:26:39]:
> On Fri, Aug 31, 2018 at 01:12:53PM +0200, Peter Zijlstra wrote:
> > NAK, not until you've fixed every cpu_to_node() user in the kernel to
> > deal with that mask changing.
>
> Also, what happens if userspace reads that information; uses libnuma and
> the
On Fri, Aug 31, 2018 at 04:53:50AM -0700, Srikar Dronamraju wrote:
> The topology events are suppose to be very rare.
> From whatever small experiments I have done till now, unless tasks are
> bound to both cpu and memory, they seem to be coping well with topology
> updates.
IOW, if you're not us
On Fri, Aug 31, 2018 at 04:53:50AM -0700, Srikar Dronamraju wrote:
> * Peter Zijlstra [2018-08-31 13:26:39]:
>
> > On Fri, Aug 31, 2018 at 01:12:53PM +0200, Peter Zijlstra wrote:
> > > NAK, not until you've fixed every cpu_to_node() user in the kernel to
> > > deal with that mask changing.
> >
>
On Fri, Aug 31, 2018 at 04:56:18PM +0530, Srikar Dronamraju wrote:
> This was the same in my previous posting too. Before the topology update
> happened, all the cpus would be in SMT, DIE. The topology updates can be
> disabled using a kernel parameter topology_updates=off. Its documented under
> h
On 08/31/2018, 02:10 PM, Pasha Tatashin wrote:
> Thanks Jiri, I am now able to reproduce it with your new config.
>
> I have tried yesterday to enable sparsemem and deferred_struct_init on
> x86_32, and that kernel booted fine, there must be something else in
> your config that helps to trigger th
Thanks Jiri, I am now able to reproduce it with your new config.
I have tried yesterday to enable sparsemem and deferred_struct_init on
x86_32, and that kernel booted fine, there must be something else in
your config that helps to trigger this problem. I am studying it now.
[0.051245] Initial
Hi Joerg/Robin,
Can you please let me know when these patches will be applied onto the tree.
Is there anything else pending from my side.
Thanks,
Nipun
> -Original Message-
> From: Nipun Gupta
> Sent: Monday, July 9, 2018 4:48 PM
> To: robin.mur...@arm.com; will.dea...@arm.com; robh...@k
On 08/31/2018, 01:26 PM, Jiri Slaby wrote:
> On 08/30/2018, 05:45 PM, Pasha Tatashin wrote:
>> Hi Jiri,
>>
>> I believe this bug is fixed with this change:
>>
>> d39f8fb4b7776dcb09ec3bf7a321547083078ee3
>> mm: make DEFERRED_STRUCT_PAGE_INIT explicitly depend on SPARSEMEM
>
> Hi,
>
> it only shift
On Fri, Aug 31, 2018 at 01:12:53PM +0200, Peter Zijlstra wrote:
> NAK, not until you've fixed every cpu_to_node() user in the kernel to
> deal with that mask changing.
Also, what happens if userspace reads that information; uses libnuma and
then you go and shift the world underneath their feet?
>
* Peter Zijlstra [2018-08-31 12:41:15]:
> On Fri, Aug 31, 2018 at 03:22:48AM -0700, Srikar Dronamraju wrote:
>
> > At boot: Before topology update.
>
> How does that work; you do SMP bringup _before_ you know the topology !?
>
If you look at the other mail that I sent, the system boots to its
On Fri, Aug 31, 2018 at 03:27:24AM -0700, Srikar Dronamraju wrote:
> * Peter Zijlstra [2018-08-29 10:02:19]:
> Powerpc lpars running on Phyp have 2 modes. Dedicated and shared.
>
> Dedicated lpars are similar to kvm guest with vcpupin.
Like i know what that means... I'm not big on virt. I supp
On Fri, Aug 31, 2018 at 03:22:48AM -0700, Srikar Dronamraju wrote:
> At boot: Before topology update.
How does that work; you do SMP bringup _before_ you know the topology !?
> After topology update.
>
> For CPU 0
> domain-0: span=0-7 level=SMT
> groups: 0:{ span=0 }, 1:{ span=1 }, 2:{ span=2
* Peter Zijlstra [2018-08-29 10:02:19]:
> On Fri, Aug 10, 2018 at 10:30:19PM +0530, Srikar Dronamraju wrote:
> > With commit 051f3ca02e46 ("sched/topology: Introduce NUMA identity node
> > sched domain") scheduler introduces an new numa level. However on shared
> > lpars like powerpc, this extra
* Peter Zijlstra [2018-08-29 10:43:48]:
> On Fri, Aug 10, 2018 at 09:45:33AM -0700, Srikar Dronamraju wrote:
>
> >
> > CPU302 attaching NULL sched-domain.
> > CPU303 attaching NULL sched-domain.
> > BUG: arch topology borken
> > the DIE domain not a subset of the NODE domain
>
> ^
If no start address is specified for crashkernel, the current program hard
code as: crashk_res.start = min(0x800ULL, (ppc64_rma_size / 2));
This limits the candidate memory region, and may cause failure while there
is enough mem for crashkernel. This patch suggests to find a suitable mem
chunk
In early_init_dt_scan_cpus() -> allocate_paca(), using ppc64_bolted_size()
to get the limitation. Although MMU_SEGSIZE_256M is enough for boot cpu's
paca, but in fact the bolted segment size may be MMU_SEGSIZE_1T. Hence
moving mmu_early_init_devtree() a little earlier, and let any callers of
ppc64_
If no start address is specified for crashkernel, the current program hard
code as: crashk_res.start = min(0x800ULL, (ppc64_rma_size / 2));
This limits the candidate memory region, and may cause failure while there
is enough mem for crashkernel. This patch suggests to find a suitable mem
chunk
24 matches
Mail list logo
