On 11/29/19 9:10 AM, Sebastian Andrzej Siewior wrote:
> I've been looking at phandle_cache and noticed the following: The raw
> phandle value as generated by dtc starts at zero and is incremented by
> one for each phandle entry. The qemu pSeries model is using Slof (which
> is probably the same thi
>Le 29/11/2019 à 08:46, Christophe Leroy a écrit :
>>
>>
>> Le 29/11/2019 à 08:04, Lexi Shao a écrit :
>>> CONFIG_RELOCATABLE and CONFIG_KASAN cannot be enabled at the same
>>> time on ppce500 fsl_booke. All functions called before
>>> kasan_early_init() should be disabled with kasan check. When
>>
Hi Michael,
On Thu, Nov 28, 2019 at 7:38 PM Michael Walle wrote:
>
> The LS1028A SoC uses the same interrupt line for adjacent SAIs. Use
> IRQF_SHARED to be able to use these SAIs simultaneously.
On i.MX8M SAI5 and SAI6 share the same interrupt number too:
Reviewed-by: Fabio Estevam
Thanks
On 11/29/19 3:23 AM, Jan Kara wrote:
On Mon 25-11-19 15:10:33, John Hubbard wrote:
1. Convert from get_user_pages() to pin_user_pages().
2. As required by pin_user_pages(), release these pages via
put_user_page(). In this case, do so via put_user_pages_dirty_lock().
That has the side effect of
On 11/29/19 10:07 AM, Pavel Begunkov wrote:
On 29/11/2019 20:16, Jens Axboe wrote:
On 11/29/19 8:14 AM, Christophe Leroy wrote:
Reverting commit 311ae9e159d8 ("io_uring: fix dead-hung for non-iter
fixed rw") clears the failure.
Most likely an #include is missing.
Huh weird how the build bot
Hi Will,
On Fri, Nov 29, 2019 at 3:54 PM Will Deacon wrote:
>
> On Fri, Nov 29, 2019 at 01:53:36AM +0530, Bhupesh Sharma wrote:
> > Changes since v4:
> >
> > - v4 can be seen here:
> > http://lists.infradead.org/pipermail/kexec/2019-November/023961.html
> > - Addressed comments
Add documentation for TCR_EL1.T1SZ variable being added to
vmcoreinfo.
It indicates the size offset of the memory region addressed by TTBR1_EL1
and hence can be used for determining the vabits_actual value.
Cc: James Morse
Cc: Mark Rutland
Cc: Will Deacon
Cc: Steve Capper
Cc: Catalin Marinas
Add documentation for 'MAX_PHYSMEM_BITS' variable being added to
vmcoreinfo.
'MAX_PHYSMEM_BITS' defines the maximum supported physical address
space memory.
Cc: Boris Petkov
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: James Morse
Cc: Will Deacon
Cc: Michael Ellerman
Cc: Paul Mackerras
Cc: Benj
Fix a simple typo in arm64/memory.rst
Cc: Jonathan Corbet
Cc: James Morse
Cc: Mark Rutland
Cc: Will Deacon
Cc: Steve Capper
Cc: Catalin Marinas
Cc: Ard Biesheuvel
Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Bhupesh S
vabits_actual variable on arm64 indicates the actual VA space size,
and allows a single binary to support both 48-bit and 52-bit VA
spaces.
If the ARMv8.2-LVA optional feature is present, and we are running
with a 64KB page size; then it is possible to use 52-bits of address
space for both userspa
Right now user-space tools like 'makedumpfile' and 'crash' need to rely
on a best-guess method of determining value of 'MAX_PHYSMEM_BITS'
supported by underlying kernel.
This value is used in user-space code to calculate the bit-space
required to store a section for SPARESMEM (similar to the exist
- Resending the v5 version as Will Deacon reported that the patchset was
split into two seperate threads while sending out. It was an issue
with my 'msmtp' settings which seems to be now fixed. Please ignore
all previous v5 versions.
Changes since v4:
- v4 can be seen here:
Right now user-space tools like 'makedumpfile' and 'crash' need to rely
on a best-guess method of determining value of 'MAX_PHYSMEM_BITS'
supported by underlying kernel.
This value is used in user-space code to calculate the bit-space
required to store a section for SPARESMEM (similar to the exist
- Resending the v5 version as Will Deacon reported that the patchset was
split into two seperate threads while sending out. It was an issue
with my 'msmtp' settings which is now fixed.
Changes since v4:
- v4 can be seen here:
http://lists.infradead.org/pipermail/kexec/2019-N
Hi!
On Wed, Nov 27, 2019 at 04:15:15PM +0100, Christophe Leroy wrote:
> Le 27/11/2019 à 15:59, Segher Boessenkool a écrit :
> >On Wed, Nov 27, 2019 at 02:50:30PM +0100, Christophe Leroy wrote:
> >>So what do we do ? We just drop the "r2" clobber ?
> >
> >You have to make sure your asm code works f
On 11/29/19 8:14 AM, Christophe Leroy wrote:
Le 29/11/2019 à 17:04, Jens Axboe a écrit :
On 11/29/19 6:53 AM, Christophe Leroy wrote:
CC fs/io_uring.o
fs/io_uring.c: In function ‘loop_rw_iter’:
fs/io_uring.c:1628:21: error: implicit declaration of function ‘kmap’
[-Werror=implicit-f
Le 29/11/2019 à 17:04, Jens Axboe a écrit :
On 11/29/19 6:53 AM, Christophe Leroy wrote:
CC fs/io_uring.o
fs/io_uring.c: In function ‘loop_rw_iter’:
fs/io_uring.c:1628:21: error: implicit declaration of function ‘kmap’
[-Werror=implicit-function-declaration]
iovec.iov_base = km
On 11/29/19 6:53 AM, Christophe Leroy wrote:
CC fs/io_uring.o
fs/io_uring.c: In function ‘loop_rw_iter’:
fs/io_uring.c:1628:21: error: implicit declaration of function ‘kmap’
[-Werror=implicit-function-declaration]
iovec.iov_base = kmap(iter->bvec->bv_page)
^
>
> Nope, it's vm_map_ram() not being handled
Another suspicious one. Related to kasan/vmalloc?
>>>
>>> Very likely the same as with ion:
>>>
>>> # git grep vm_map_ram|grep xfs
>>> fs/xfs/xfs_buf.c:* vm_map_ram() will allocate auxiliary
>>> structures (e
I've been looking at phandle_cache and noticed the following: The raw
phandle value as generated by dtc starts at zero and is incremented by
one for each phandle entry. The qemu pSeries model is using Slof (which
is probably the same thing as used on real hardware) and this looks like
a poiner valu
Daniel
>
>>
>>>
>>> BUG: unable to handle page fault for address: f52005b8
>>> #PF: supervisor read access in kernel mode
>>> #PF: error_code(0x) - not-present page
>>> PGD 7ffcd067 P4D 7ffcd067 PUD 2cd10067 PMD 66d76067 PTE 0
&
CC fs/io_uring.o
fs/io_uring.c: In function ‘loop_rw_iter’:
fs/io_uring.c:1628:21: error: implicit declaration of function ‘kmap’
[-Werror=implicit-function-declaration]
iovec.iov_base = kmap(iter->bvec->bv_page)
^
fs/io_uring.c:1628:19: warning: assignment makes
When enabling CONFIG_RELOCATABLE and CONFIG_KASAN on FSL_BOOKE,
the kernel doesn't boot.
relocate_init() requires KASAN early shadow area to be set up because
it needs access to the device tree through generic functions.
Call kasan_early_init() before calling relocate_init()
Reported-by: Lexi Sh
Le 29/11/2019 à 08:46, Christophe Leroy a écrit :
Le 29/11/2019 à 08:04, Lexi Shao a écrit :
CONFIG_RELOCATABLE and CONFIG_KASAN cannot be enabled at the same time
on ppce500 fsl_booke. All functions called before kasan_early_init()
should be disabled with kasan check. When CONFIG_RELOCATAB
gt;
> >>
> >> BUG: unable to handle page fault for address: f52005b8
> >> #PF: supervisor read access in kernel mode
> >> #PF: error_code(0x) - not-present page
> >> PGD 7ffcd067 P4D 7ffcd067 PUD 2cd10067 PMD 66d76067 PTE 0
> >> Oops: 00
e involved?
Regards,
Daniel
>
>>
>> BUG: unable to handle page fault for address: f52005b8
>> #PF: supervisor read access in kernel mode
>> #PF: error_code(0x) - not-present page
>> PGD 7ffcd067 P4D 7ffcd067 PUD 2cd10067 PMD 66d76067 PTE 0
>> Oops: 000
Hi all,
hmm, that subject is completely wrong, sorry.
On Fri, 29 Nov 2019 23:12:00 +1100 Stephen Rothwell
wrote:
>
> Commit
>
> 6f090192f822 ("x86/efi: remove unused variables")
>
> is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
pgpUTv7q4WJWs.pgp
Description
Hi all,
Commit
6f090192f822 ("x86/efi: remove unused variables")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
pgpwOkerSneth.pgp
Description: OpenPGP digital signature
Hi Dmitry,
>> I am testing this support on next-20191129 and seeing the following warnings:
>>
>> BUG: sleeping function called from invalid context at mm/page_alloc.c:4681
>> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 44, name: kworker/1:1
>> 4 locks
;b_addr = vm_map_ram(bp->b_pages,
bp->b_page_count,
>
> BUG: unable to handle page fault for address: f52005b8
> #PF: supervisor read access in kernel mode
> #PF: error_code(0x) - not-present page
> PGD 7ffcd067 P4D 7ffcd067 PUD 2cd10067 PMD 66d76067 PTE 0
> Oops: 00
t;>>>
>>>>> setup_vmalloc_vm_locked(vms[area], vas[area], VM_ALLOC,
>>>>> pcpu_get_vm_areas);
>>>>> + }
>>>>> + spin_unlock(&vmap_area_lock);
>>>>>
>&g
On Mon 25-11-19 15:10:33, John Hubbard wrote:
> 1. Convert from get_user_pages() to pin_user_pages().
>
> 2. As required by pin_user_pages(), release these pages via
> put_user_page(). In this case, do so via put_user_pages_dirty_lock().
>
> That has the side effect of calling set_page_dirty_lock
_locked(vms[area], vas[area], VM_ALLOC,
> > > pcpu_get_vm_areas);
> > > + }
> > > + spin_unlock(&vmap_area_lock);
> > >
> > > + /* populate the shadow space outside of the lock */
> > >
On Fri, Nov 29, 2019 at 01:53:36AM +0530, Bhupesh Sharma wrote:
> Changes since v4:
>
> - v4 can be seen here:
> http://lists.infradead.org/pipermail/kexec/2019-November/023961.html
> - Addressed comments from Dave and added patches for documenting
> new variables appended to v
CONFIG_RELOCATABLE and CONFIG_KASAN cannot be enabled at the same time
on ppce500 fsl_booke. All functions called before kasan_early_init()
should be disabled with kasan check. When CONFIG_RELOCATABLE is enabled
on ppce500 fsl_booke, relocate_init() is called before kasan_early_init()
which trigger
35 matches
Mail list logo