On Mon, Mar 01, 2021 at 08:09:52PM -0800, Florian Fainelli wrote:
>
>
> On 3/1/2021 1:22 AM, Serge Semin wrote:
> > On Sun, Feb 28, 2021 at 07:50:45PM -0800, Florian Fainelli wrote:
> >> Hi Serge,
> >>
> >> On 2/28/2021 3:08 PM, Serge Semin wrote:
> >>> Hi folks,
> >>> What you've got here seems
On Mon, Mar 01, 2021 at 07:55:21PM -0800, Roman Gushchin wrote:
> On Mon, Mar 01, 2021 at 11:45:42AM +0200, Mike Rapoport wrote:
> > On Sun, Feb 28, 2021 at 07:50:45PM -0800, Florian Fainelli wrote:
> > > Hi Serge,
> > >
> > > On 2/28/2021 3:08 PM, Serge Semin wrote:
> > > > Hi folks,
> > > > What
On 3/1/2021 1:22 AM, Serge Semin wrote:
> On Sun, Feb 28, 2021 at 07:50:45PM -0800, Florian Fainelli wrote:
>> Hi Serge,
>>
>> On 2/28/2021 3:08 PM, Serge Semin wrote:
>>> Hi folks,
>>> What you've got here seems a more complicated problem than it
>>> could originally look like. Please, see my c
On Mon, Mar 01, 2021 at 11:45:42AM +0200, Mike Rapoport wrote:
> On Sun, Feb 28, 2021 at 07:50:45PM -0800, Florian Fainelli wrote:
> > Hi Serge,
> >
> > On 2/28/2021 3:08 PM, Serge Semin wrote:
> > > Hi folks,
> > > What you've got here seems a more complicated problem than it
> > > could original
On Sun, Feb 28, 2021 at 07:50:45PM -0800, Florian Fainelli wrote:
> Hi Serge,
>
> On 2/28/2021 3:08 PM, Serge Semin wrote:
> > Hi folks,
> > What you've got here seems a more complicated problem than it
> > could originally look like. Please, see my comments below.
> >
> > (Note I've discarded so
On Sun, Feb 28, 2021 at 07:50:45PM -0800, Florian Fainelli wrote:
> Hi Serge,
>
> On 2/28/2021 3:08 PM, Serge Semin wrote:
> > Hi folks,
> > What you've got here seems a more complicated problem than it
> > could originally look like. Please, see my comments below.
> >
> > (Note I've discarded so
Hi Serge,
On 2/28/2021 3:08 PM, Serge Semin wrote:
> Hi folks,
> What you've got here seems a more complicated problem than it
> could originally look like. Please, see my comments below.
>
> (Note I've discarded some of the email logs, which of no interest
> to the discovered problem. Please als
Hi folks,
What you've got here seems a more complicated problem than it
could originally look like. Please, see my comments below.
(Note I've discarded some of the email logs, which of no interest
to the discovered problem. Please also note that I haven't got any
Broadcom hardware to test out a so
Hi Mike,
On 2/28/2021 1:00 AM, Mike Rapoport wrote:
> Hi Florian,
>
> On Sat, Feb 27, 2021 at 08:18:47PM -0800, Florian Fainelli wrote:
>>
>> On 12/17/2020 12:12 PM, Roman Gushchin wrote:
>>> With kaslr the kernel image is placed at a random place, so starting
>>> the bottom-up allocation with th
Hi Florian,
On Sat, Feb 27, 2021 at 08:18:47PM -0800, Florian Fainelli wrote:
>
> On 12/17/2020 12:12 PM, Roman Gushchin wrote:
> > With kaslr the kernel image is placed at a random place, so starting
> > the bottom-up allocation with the kernel_end can result in an
> > allocation failure and a w
On 12/17/2020 12:12 PM, Roman Gushchin wrote:
> With kaslr the kernel image is placed at a random place, so starting
> the bottom-up allocation with the kernel_end can result in an
> allocation failure and a warning like this one:
>
> [0.002920] hugetlb_cma: reserve 2048 MiB, up to 2048 MiB
Mike Rapoport writes:
> On Sat, Jan 23, 2021 at 06:09:11PM -0800, Andrew Morton wrote:
>> On Fri, 22 Jan 2021 01:37:14 -0300 Thiago Jung Bauermann
>> wrote:
>>
>> > Mike Rapoport writes:
>> >
>> > > > Signed-off-by: Roman Gushchin
>> > >
>> > > Reviewed-by: Mike Rapoport
>> >
>> > I've
Mike Rapoport writes:
> On Sat, Jan 23, 2021 at 06:09:11PM -0800, Andrew Morton wrote:
>> On Fri, 22 Jan 2021 01:37:14 -0300 Thiago Jung Bauermann
>> wrote:
>>
>> > Mike Rapoport writes:
>> >
>> > > > Signed-off-by: Roman Gushchin
>> > >
>> > > Reviewed-by: Mike Rapoport
>> >
>> > I've
On Sat, Jan 23, 2021 at 06:09:11PM -0800, Andrew Morton wrote:
> On Fri, 22 Jan 2021 01:37:14 -0300 Thiago Jung Bauermann
> wrote:
>
> > Mike Rapoport writes:
> >
> > > > Signed-off-by: Roman Gushchin
> > >
> > > Reviewed-by: Mike Rapoport
> >
> > I've seen a couple of spurious triggers of
On Fri, 22 Jan 2021 01:37:14 -0300 Thiago Jung Bauermann
wrote:
> Mike Rapoport writes:
>
> > > Signed-off-by: Roman Gushchin
> >
> > Reviewed-by: Mike Rapoport
>
> I've seen a couple of spurious triggers of the WARN_ONCE() removed by this
> patch. This happens on some ppc64le bare metal (
Mike Rapoport writes:
> > Signed-off-by: Roman Gushchin
>
> Reviewed-by: Mike Rapoport
I've seen a couple of spurious triggers of the WARN_ONCE() removed by this
patch. This happens on some ppc64le bare metal (powernv) server machines with
CONFIG_SWIOTLB=y and crashkernel=4G, as described in
On Thu, Dec 17, 2020 at 12:12:14PM -0800, Roman Gushchin wrote:
> With kaslr the kernel image is placed at a random place, so starting
> the bottom-up allocation with the kernel_end can result in an
> allocation failure and a warning like this one:
>
> [0.002920] hugetlb_cma: reserve 2048 MiB,
On Sat, Dec 19, 2020 at 11:52:19PM +0900, Wonhyuk Yang wrote:
> Hi Roman,
>
> On Fri, Dec 18, 2020 at 5:12 AM Roman Gushchin wrote:
> >
> > With kaslr the kernel image is placed at a random place, so starting
> > the bottom-up allocation with the kernel_end can result in an
> > allocation failure
Hi Roman,
On Fri, Dec 18, 2020 at 5:12 AM Roman Gushchin wrote:
>
> With kaslr the kernel image is placed at a random place, so starting
> the bottom-up allocation with the kernel_end can result in an
> allocation failure and a warning like this one:
>
> [0.002920] hugetlb_cma: reserve 2048 M
With kaslr the kernel image is placed at a random place, so starting
the bottom-up allocation with the kernel_end can result in an
allocation failure and a warning like this one:
[0.002920] hugetlb_cma: reserve 2048 MiB, up to 2048 MiB per node
[0.002921] [ cut here ]--
20 matches
Mail list logo