On 12/05/2019 06:36 AM, Kazuhito Hagio wrote:
> Hi Pingfan,
>
> Thank you for the patch.
>
>> -Original Message-
>> since the following commit, -lebl has been removed from elfutils.
>> commit b833c731359af12af9f16bcb621b3cdc170eafbc
>> Author: Mark Wielaard
>> Date: Thu Aug 29 23:34
You got the "n" on "down" in the subject, but still missing "of" ;)
On Tue, Dec 03, 2019 at 12:47:40PM +0100, Nicolas Saenz Julienne wrote:
> Some users need to make sure their rounding function accepts and returns
> 64bit long variables regardless of the architecture. Sadly
> roundup/rounddown_po
On Thu, Dec 05, 2019 at 06:55:45PM +0800, Dave Young wrote:
> >esrt: Unsupported ESRT version 2904149718861218184.
> >
> > The ESRT memory stays in EFI boot services data, and it was reserved
> > in kernel via efi_mem_reserve(). The initial purpose of the reservation
> > is to reuse the E
> -Original Message-
> This is your makedumpfile pulled from sourceforge .
>
> It would be helpful if you bumped the VERSION and DATE to be certain we are
> using the correct pieces .
Good suggestion.
I wanted the command line that executed makedumpfile in debug message
as well, so I'll
> -Original Message-
> > > > +/*
> > > > + * The linear kernel range starts at the bottom of the virtual address
> > > > + * space. Testing the top bit for the start of the region is a
> > > > + * sufficient check and avoids having to worry about the tag.
> > > > + */
> > > > +#define is_li
> -Original Message-
> Hi Kazu,
>
> On Wed, Dec 4, 2019 at 11:07 PM Kazuhito Hagio wrote:
> >
> > > -Original Message-
> > > ARMv8.2-LPA architecture extension (if available on underlying hardware)
> > > can support 52-bit physical addresses, while the kernel virtual
> > > address
Hi Bhupesh,
> -Original Message-
> > > -Original Message-
> > > This patch adds a common feature for archs (except arm64, for which
> > > similar support is added via subsequent patch) to retrieve
> > > 'MAX_PHYSMEM_BITS' from vmcoreinfo (if available).
> >
> > We already have the
Hi Kazu,
On Wed, Dec 4, 2019 at 11:20 PM Kazuhito Hagio wrote:
>
> > -Original Message-
> > This patch marks '--mem-usage' option as unsupported for arm64
> > architecture.
> >
> > With the newer arm64 kernels supporting 48-bit/52-bit VA address spaces
> > and keeping a single binary for
Hi Kazu,
On Wed, Dec 4, 2019 at 11:07 PM Kazuhito Hagio wrote:
>
> > -Original Message-
> > ARMv8.2-LPA architecture extension (if available on underlying hardware)
> > can support 52-bit physical addresses, while the kernel virtual
> > addresses remain 48-bit.
> >
> > Make sure that we r
Hi Kazu,
On Wed, Dec 4, 2019 at 11:05 PM Kazuhito Hagio wrote:
>
> Hi Bhupesh,
>
> Sorry for the late reply.
No problem.
> > -Original Message-
> > This patch adds a common feature for archs (except arm64, for which
> > similar support is added via subsequent patch) to retrieve
> > 'MAX
Hi Kazu,
On Thu, Dec 5, 2019 at 9:00 PM Kazuhito Hagio wrote:
>
> > -Original Message-
> > > -Original Message-
> > > With ARMv8.2-LVA architecture extension availability, arm64 hardware
> > > which supports this extension can support upto 52-bit virtual
> > > addresses. It is spe
On 03/12/2019 11:47 am, Nicolas Saenz Julienne wrote:
Some users need to make sure their rounding function accepts and returns
64bit long variables regardless of the architecture. Sadly
roundup/rounddown_pow_two() takes and returns unsigned longs. It turns
out ilog2() already handles 32/64bit cal
> -Original Message-
> > -Original Message-
> > With ARMv8.2-LVA architecture extension availability, arm64 hardware
> > which supports this extension can support upto 52-bit virtual
> > addresses. It is specially useful for having a 52-bit user-space virtual
> > address space while
Hi Prarit,
On 2019-12-05, Prarit Bhargava wrote:
> Based on the comments there is going to be a v6 but in any case I am
> starting testing of this patchset on several large core systems across
> multiple architectures (x86_64, ARM64, s390, ppc64le). Some of those
> systems are known to fail boot
John Ogness wrote:
> Hello,
>
> This is a follow-up RFC on the work to re-implement much of the
> core of printk. The threads for the previous RFC versions are
> here[0][1][2][3].
>
> This RFC includes only the ringbuffer and a test module. This is
> a rewrite of the proposed ringbuffer, now b
On 2019-12-03, Steven Rostedt wrote:
> +/* Reserve a new descriptor, invalidating the oldest if necessary. */
> +static bool desc_reserve(struct printk_ringbuffer *rb, u32 *id_out)
> +{
> + struct prb_desc_ring *desc_ring = &rb->desc_ring;
> + struct prb_desc *desc;
> + u32
On 12/04/19 at 11:14am, Ingo Molnar wrote:
>
> * Dave Young wrote:
>
> > On 12/04/19 at 03:52pm, Dave Young wrote:
> > > Michael Weiser reported he got below error during a kexec rebooting:
> > > esrt: Unsupported ESRT version 2904149718861218184.
> > >
> > > The ESRT memory stays in EFI boot s
On Wed, 4 Dec 2019 at 20:13, Bhupesh SHARMA wrote:
>
> Hello Masa,
>
> (+Cc Simon)
>
> On Thu, Dec 5, 2019 at 12:27 AM Masayoshi Mizuma
> wrote:
> >
> > On Wed, Dec 04, 2019 at 06:17:59PM +, James Morse wrote:
> > > Hi Masa,
> > >
> > > On 04/12/2019 17:17, Masayoshi Mizuma wrote:
> > > > Th
On Tue, Dec 03, 2019 at 12:47:40PM +0100, Nicolas Saenz Julienne wrote:
> Some users need to make sure their rounding function accepts and returns
> 64bit long variables regardless of the architecture. Sadly
> roundup/rounddown_pow_two() takes and returns unsigned longs. It turns
> out ilog2() alre
19 matches
Mail list logo
