On 3/24/21 9:55 AM, Christoph Hellwig wrote:
> On Tue, Mar 23, 2021 at 07:04:31PM -0700, Stephen Boyd wrote:
>> x5 : x4 : 0001
>> x3 : 0008 x2 : ff93fef25a70
>> x1 : ff93fef15788 x0 : ffe3622352e0
>> Call trace:
>> lkdtm_WARNING+0x28/0x30 [
On 3/24/21 3:04 AM, Stephen Boyd wrote:
> This series adds the kernel's build ID[1] to the stacktrace header printed
> in oops messages, warnings, etc. and the build ID for any module that
> appears in the stacktrace after the module name. The goal is to make the
> stacktrace more self-contained an
It used to be true that we can have system RAM (IORESOURCE_SYSTEM_RAM |
IORESOURCE_BUSY) only on the first level in the resource tree. However,
this is no longer holds for driver-managed system RAM (i.e., added via
dax/kmem and virtio-mem), which gets added on lower levels, for example,
inside devi
All functions that search for IORESOURCE_SYSTEM_RAM or IORESOURCE_MEM
resources now properly consider the whole resource tree, not just the first
level. Let's drop the unused first_lvl / siblings_only logic.
Remove documentation that indicates that some functions behave differently,
all consider t
It used to be true that we can have system RAM (IORESOURCE_SYSTEM_RAM |
IORESOURCE_BUSY) only on the first level in the resource tree. However,
this is no longer holds for driver-managed system RAM (i.e., added via
dax/kmem and virtio-mem), which gets added on lower levels, for example,
inside devi
Quoting peter enderborg (2021-03-25 04:14:31)
> > el0_sync_compat_handler+0xa8/0xcc
> > el0_sync_compat+0x178/0x180
> > ---[ end trace 3d95032303e59e68 ]---
>
> How will this work with the ftrace?
>
It won't affect ftrace, if that's the question you're asking.
_
Quoting peter enderborg (2021-03-25 04:06:17)
> On 3/24/21 9:55 AM, Christoph Hellwig wrote:
> > On Tue, Mar 23, 2021 at 07:04:31PM -0700, Stephen Boyd wrote:
> >> x5 : x4 : 0001
> >> x3 : 0008 x2 : ff93fef25a70
> >> x1 : ff93fef15788 x0 : ffe
