");
+ else
+ value = symbol_value("swapper_pg_dir");
+
+ value -= symbol_value("idmap_pg_dir");
+ }
You can just use "swapper_pg_dir" and &quo
value -= symbol_value("idmap_pg_dir");
+ }
I was going to suggest checking for (THIS_KERNEL_VERSION < LINUX(4,4,0)),
but I don't think that's even necessary given that the code sequence above
will *only* be executed if the kernel is
- Original Message -
> Hi Dave,
> There is a bug for the determination of the ARM64 page size happen on kernel
> 3.18 crash kdump.
If it is a kdump, there should be a PAGESIZE vmcoreinfo entry.
As far as I can tell, the PAGE_SIZE has always been exported
as the second item for all arc
ddress.
> (gdb) p /x *(struct bt_info *) 0x7fffd640
> $4 = {task = 0xffcd74122000, flags = 0x0, instptr = 0x0, stkptr =
> 0xff800c42ba00, bptr = 0x0, stackbase = 0xff800c428000,
> stacktop = 0xff800c42c000, stackbuf = 0x55f23ae0, tc =
> 0x596e1778, hp = 0x
- Original Message -
> > The stackframe.fp(0xff9c29e4f8e0) is larger than the stacktop address,
> > so
> > lead to segmentation violation gernarated by accessing regs->sp:
> > (gdb) p /x 18446743644915693792//stkptr
> > $5 = 0xff9c29e4f8e0
> > (gdb) p /x 0xff9c29e4f8e0-0xff
- Original Message -
> Hi Dave,
> I‘m working on arm64 kdump by crash-7.2.7++.
> There is a potential segmentation violation due to an invalid exception frame
> before
> transitioning to the process stack when try using the bt command's "-S
> " options.
> For example, take the sp argument
- Original Message -
> Hi,
>
> [I'm not sure if that is a crash or mkdumpfile problem]
>
> I'm trying to use crash to read a makedumpfile vmcore from 5.3, but I always
> end up with an error when opening the dump.
>
> I'm using the latest github crash
>
> crash 7.2.7++
> ...
> crash
nfigs/xxx_config]
> CONFIG_LOG_BUF_SHIFT=21
>
> Above your suggestions, I have correct the logic error and made some
> significant changes for my patch.
> The new patch file has been upload to attachment.
> Thanks for your review. I’m looking forward to your favourable reply!
>
- Original Message -
> Hi Dave,
>
> On Fri, Oct 18, 2019 at 11:12:22AM -0400, Dave Anderson wrote:
> >
> > - Original Message -
> > >
> > >
> > > Thanks Masa -- queued for crash-7.2.8:
> > >
>
- Original Message -
>
>
> Thanks Masa -- queued for crash-7.2.8:
>
>
> https://github.com/crash-utility/crash/commit/9937878cce2fc049283d833685cb939caca462ca
>
> Dave
Hi Masa,
I spoke too soon -- I originally tested this on an x86_64 machine, but I now
see that
it fails on the
Thanks Masa -- queued for crash-7.2.8:
https://github.com/crash-utility/crash/commit/9937878cce2fc049283d833685cb939caca462ca
Dave
- Original Message -
> From: Masayoshi Mizuma
>
> Fix for Linux 5.4-rc1 and later kernels that contain commit
> b6c88d3b9d38 ("drivers/base/memory
Hi Kazu,
Your patch is queued for crash-7.2.8:
https://github.com/crash-utility/crash/commit/c1ac656508ad064ef0ef222acb73621ae0bf4f00
Thanks,
Dave
- Original Message -
> Fix for Linux 5.4-rc1 and later kernels that contain commit
> 511885d7061eda3eb1faf3f57dcc936ff75863f1, ti
- Original Message -
>
>
> WARNING: kernel relocated [178840MB]: patching 121133 gdb minimal_symbol
> values
>
>
>
> WARNING: could not find MAGIC_START!
>
> crash: cannot determine base kernel version
>
> crash: vmlinux and /var/tmp/ramdump_elf_UBqQU9 do not match!
>
> Then I usi
- Original Message -
> On Tue, Oct 08, 2019 at 04:55:48PM -0400, Dave Anderson wrote:
> >
> > > - Original Message -
> > > > Hi Dave,
> > > >
> > > > I tried to use crash v7.2.7 with kernel v5.4-rc1 on arm64.
>
> - Original Message -
> > Hi Dave,
> >
> > I tried to use crash v7.2.7 with kernel v5.4-rc1 on arm64.
> >
> > 1. VA_BITS_ACTUAL is missing in vmcoreinfo.
> >Does anyone work on fixing it on kernel side?
> >(just adding one or two lines though)
> >
> > 2. With a tweak above, I
- Original Message -
> Hi Dave,
>
> I tried to use crash v7.2.7 with kernel v5.4-rc1 on arm64.
>
> 1. VA_BITS_ACTUAL is missing in vmcoreinfo.
>Does anyone work on fixing it on kernel side?
>(just adding one or two lines though)
>
> 2. With a tweak above, I still fail to run c
- Original Message -
> Hi Dave,
>
> I've enhanced my cacheutils extension module, and now it has three commands
> "ccat", "cls" and "cfind".
>
> https://github.com/k-hagio/crash-cacheutils
>
> Could you please update the command help pages in your extensions page?
Done!
Thanks,
Download from: http://people.redhat.com/anderson
or
https://github.com/crash-utility/crash/releases
The github master branch serves as a development branch that will contain
all patches that are queued for the next release:
$ git clone git://github.com/crash
; IKCONFIG_Y) {
> + if ((ret = get_kernel_config("CONFIG_HOTPLUG_SIZE_BITS",
> &string)) == IKCONFIG_STR) {
> + machdep->section_size_bits = atol(string);
> + free(string);
> + return;
> +
Hi Qiwu,
The patch to setup_ikconfig() has been queued for crash-7.2.7:
https://github.com/crash-utility/crash/commit/70e794c10f30e29a636967bbdacdf3068bfc4897
Thanks,
Dave
- Original Message -
>
> Hi Anderson,
> I want to introduce a patch to your crash tool projec
last empty
> line into ikconfig entry. I agree that the use of STRNEQ() is better than
> strncmp().
>
> Best regards,
> Qiwu
>
>
>
> -Original Message-
> From: Dave Anderson
> Sent: Wednesday, September 18, 2019 3:22 AM
> To: 陈启武
> Cc: c
- Original Message -
> Hi Dave,
>
> On 9/17/2019 2:40 PM, Dave Anderson wrote:
> >
> > Hi Kazu,
> >
> > This seems to be an extrememly rare condition, but in any case, your
> > patch is the correct thing to do.
> >
> > However,
- Original Message -
>
> Hi Anderson,
> I want to introduce a patch to your crash tool project. It’s a bugfix for a
> segfault in setup_ikconfig.
> We add an ikconfig entry only if ent[0] != '#', it is not an advisable
> condition because there is a poten
Hi Kazu,
This seems to be an extrememly rare condition, but in any case, your
patch is the correct thing to do.
However, I do have two dumpfiles where the change causes the warning message
to be displayed unnecessarily, which was only meant to be displayed if the
mem_map cache is *not* virtua
Hello Qiwu,
I will be out of the office until Monday September 16th. I'll
review your 2 patches at that time.
Thanks,
Dave
>
> Hi Anderson,
> I want to introduce a patch to your crash tool project. Itâs a bugfix
> for a segfault in setup_ikconfig.
> We add an ikconfig
Hi Kazu,
I will be out of the office until Monday September 16th. I will check
out your patch when I get back.
Thanks,
Dave
- Original Message -
>
> fill_mem_map_cache() intends to read page-size-or-less size if it cannot
> read the whole cache size, but it seems it doesn't correctl
- Original Message -
>
> Commit 6596f1121b added a '-B' option to the list command to allow
> more efficient enumeration of longer lists. Unfortunately there
> is a small bug with this option where it may incorrectly flag a
> loop length of '0' on list of length 1. It is impossible to h
- Original Message -
> On 8/1/2019 2:31 PM, Kazuhito Hagio wrote:
> > On 8/1/2019 1:22 PM, Dave Anderson wrote:
> >>
> >>
> >> - Original Message -
> >>> Hi Dave,
> >>>
> >>> I noticed that the "t
- Original Message -
> Hi Dave,
>
> I noticed that the "timer" command prints somewhat wrongly for RHEL7.6 or
> later kernels (not including RHEL8 / upstream) and found that it is because
> struct tvec and tvec_root have an array of list_head, instead of hlist_head
> in upstream kernels
Hi Kazu,
Looks good -- queued for crash-7.2.7:
https://github.com/crash-utility/crash/commit/e1df72964f8a583000e6cb74e54f8efbab6721ac
Thanks for being so proactive on this one!
Dave
- Original Message -
>
> Hi Kazu,
>
> Do you have a sample 5.3-rc1 vmlinux/vmcore pair that I ca
Hi Kazu,
Do you have a sample 5.3-rc1 vmlinux/vmcore pair that I can test this with?
You can send it to me offline.
Thanks,
Dave
- Original Message -
> Update for the "kmem -n" option on Linux 5.3-rc1 and later kernels that
> contain commit 326e1b8f83a4318b09033ef754f40c785aed5e68,
r: fp
> > > crash> epython /root/Work/test_cmd.py
> > > {sym: invalid address: 0x123
> > > }
> > >
> > > ** Execution took 0.00s (real) 0.00s (CPU)
> > > crash> set stderr /tmp/output
> > > stderr: /tmp/output
> > &g
- Original Message -
> On Wed 2019-07-10 14:38 +0100, Aaron Tomlin wrote:
> > > So I took my own advice, and implemented the "dis -[rf] address count"
> > > capability with a simple patch to the top-level kernel.c disassembly
> > > code:
> > >
> > >
> > > https://github.com/crash-uti
t; - Original Message -
> > On Fri 2019-06-21 11:45 -0400, Dave Anderson wrote:
> > >
> > >
> > > - Original Message -
> > > > Changes since v1:
> > > >
> > > > - Update 'dis' help page
> > >
output
> sym: invalid address: 0x123
> ---
>
> Yes, in the above by using 'fp', we can redirect the error message
> into the same exec_crash_command() and prevent showing any messages on
>
alid address: 0x123
> > ---
> >
> > Yes, in the above by using 'fp', we can redirect the error message
> > into the same exec_crash_command() and prevent showing any messages on
> >
-
>
> Yes, in the above by using 'fp', we can redirect the error message
> into the same exec_crash_command() and prevent showing any messages on
> console. By doing that, we can have a full control for the messages.
> If we want to seperate error messages fro
file or
pipe stream?
It sounds like you're saying that your proposed "fp" setting would simply not
display the extra
"unnecessary" error message on the console.
Dave
>
> Regards,
> Daniel
>
> Kind regards,
>
> Daniel Kwon, RHCA
>
t; /tmp/output
> crash> !cat /tmp/output
> crash> !cat /tmp/stderr
> sym: invalid address: 0x123
> sym: invalid address: 0x124
>
> pipe: error goes into the specified file only.
>
> crash> sym 0x125 | cat
> crash> sym 0x126 | cat > /tmp/output
> crash> !cat /tmp/output
> crash> !cat /t
type for ‘set_stderr’
[-Wmissing-prototypes]
set_stderr(char *target)
^
...
Thanks,
Dave
>
> Kind regards,
> Daniel Kwon
>
> On Tue, Jun 25, 2019 at 2:06 AM Dave Anderson wrote:
>
> >
> > - Original Message -
> &
Hi Oleksandr,
Looks good -- queued for crash-7.2.7:
https://github.com/crash-utility/crash/commit/496d503e84147a24bdaf86782ab1d8af2fd76c9e
Thanks,
Dave
- Original Message -
> Extend `timer` command to show time to expire (TTE) for each timer.
>
> This is useful to verify what C
- Original Message -
> This is the release of crash gcore command, version 1.5.1.
Hi Daisuke and Masa,
The extensions page has been updated:
http://people.redhat.com/anderson/extensions.html#GCORE
Thanks very much for your help,
Dave
>
> This release includes the fo
- Original Message -
> Extend `timer` command to show time to expire (TTE) for each timer.
>
> This is useful to verify what CPU is blocked due to looping with
> interrupts disabled or due to lack of resources to run the vCPU on a
> hypervisor side.
>
> The commit doesn't implement hum
eful
to use PATH_MAX (4096). Just use malloc/free to get a buffer of the correct
length.
And please display pc->stderr and pc->stderr_path to dump_program_context()
for use by "help -p".
Thanks,
Dave
>
>
> On Sat, Jun 22, 2019 at 5:24 AM Dave Anderson < ander...@redhat.
Thanks Masa, the patch looks good.
And Daisuke, when you update crash-gcore-command package, please also
include the aarch64 patch we discussed last December:
--- crash-gcore-command-1.3.1/gcore.c.orig
+++ crash-gcore-command-1.3.1/gcore.c
@@ -501,6 +501,10 @@ static void gcore_offset_table_i
Hi Daniel,
The idea seems reasonable, but the patch below is malformed:
$ patch -p1 < error.patch
checking file defs.h
Hunk #1 FAILED at 553.
1 out of 1 hunk FAILED
checking file help.c
patch: malformed patch at line 52: displayed by",
$
You can see that there are a quite a
- Original Message -
> On Fri 2019-06-21 11:45 -0400, Dave Anderson wrote:
> >
> >
> > - Original Message -
> > > Changes since v1:
> > >
> > > - Update 'dis' help page
> > > - Resolve patch fuzz
> >
- Original Message -
> Changes since v1:
>
> - Update 'dis' help page
> - Resolve patch fuzz
>
>
> The purpose of this patch is to add support for a count value in reverse
> or forward mode, during disassembly:
>
> 'dis [-r|-f] [symbol|address] [count]'
>
> For example:
>
>
- Original Message -
> Hi.
>
> On Wed, Jun 19, 2019 at 03:39:18PM -0400, Dave Anderson wrote:
> > This makes the output somewhat sparse, ugly, and hard to read, no?
>
> In a way that there are might be empty CPUs? If so, yes, I agree.
>
> > I'm won
- Original Message -
> Implement `timer` command option (namely, `-e`) that allows filtering
> out all the non-expired timers.
>
> This is useful to verify what CPU is blocked due to looping with
> interrupts disabled or due to lack of resources to run the vCPU on a
> hypervisor side.
- Original Message -
> The purpose of this patch is to provide a -p option to generate a stack
> trace of the panic task, if available. It might be useful if the current
> context is changed with the 'set' command.
>
> This option is not supported under a live system or live dump.
Good
- Original Message -
> I'm simply doing an in-place update by:
>
> (1) applying your patch to a pre-built git tree, and
> (2) entering "make".
>
> That should just work. Anyway, I've got an idea on how to address it that
> I'll try tomorrow.
>
>
Hi Aaron,
With respect to the "seconda
inal message From: Aaron Tomlin Date:
6/18/19 5:51 PM (GMT-05:00) To: "Discussion list for crash utility usage,
maintenance and development" Subject: Re:
[Crash-utility] [PATCH] crash: dis: introduce count in reverse
and forward mode On Tue 2019-06-18 16:27 -0400,
- Original Message -
>
> - Original Message -
> > The purpose of this patch is to add support for a count value in reverse
> > or forward mode, during disassembly:
> >
> > 'dis [-r|-f] [symbol|address] [count]'
> >
> > For example:
> >
> > crash> dis -f list_del+0x16 4
>
- Original Message -
> The purpose of this patch is to add support for a count value in reverse
> or forward mode, during disassembly:
>
> 'dis [-r|-f] [symbol|address] [count]'
>
> For example:
>
> crash> dis -f list_del+0x16 4
> 0x812b3346 : jne0x8
> -Original Message-----
> > From: Dave Anderson
> > Sent: Thursday, June 6, 2019 7:22 AM
> > To: Nuno Das Neves
> > Cc: crash-utility@redhat.com
> > Subject: Re: [Crash-utility] [PATCH] Fix unsigned signed comparison causing
> > segfa
- Original Message -
> > -Original Message-
> > From: Dave Anderson
> > Sent: Wednesday, June 5, 2019 2:56 PM
> > To: Nuno Das Neves
> > Cc: Nuno Das Neves
> > Subject: Fwd: [Crash-utility] [PATCH] Fix unsigned signed comparison
> > c
- Original Message -
> Hi,
>
> This is a fix for a signed/unsigned comparison bug in vmcoreinfo_read_string.
> The bug causes a segmentation fault if size_vmcoreinfo + 1 is smaller than
> the length of the key string passed in.
I suppose that's true, but can you describe the instance w
- Original Message -
> On 5/30/2019 5:03 PM, Dave Anderson wrote:
> >
> >
> > - Original Message -
> >> Hi Dave,
> >>
> >> I don't know why this difference arises, but with certain kernel
> >> configurations,
> &
- Original Message -
> Hi Dave,
>
> I don't know why this difference arises, but with certain kernel
> configurations,
> the source file and line information of the schedule() function becomes the
> following, not "/kernel/sched/core.c".
>
> crash> sym schedule
> ab0d3666
; I updated cacheutils.c and created a github repo:
>
> https://github.com/k-hagio/crash-cacheutils
>
> Could you add the module with this link to your modules page?
>
> Thanks,
> Kazu
>
Done:
http://people.redhat.com/anderson/extensions.html#CACHEUTILS
Instead of co
- Original Message -
>
> Hello Mikhail, Philipp and Gerald,
>
> For the first time today I'm testing a 5.2.0-0.rc1 kernel that has
> been configured with CONFIG_RANDOMIZE_BASE=y, and I have verified
> that it runs live using the KERNELOFFSET value from the /proc/kcore
> VMCOREINFO as t
Hello Mikhail, Philipp and Gerald,
For the first time today I'm testing a 5.2.0-0.rc1 kernel that has
been configured with CONFIG_RANDOMIZE_BASE=y, and I have verified
that it runs live using the KERNELOFFSET value from the /proc/kcore
VMCOREINFO as the --kalsr argument.
For live system ana
Hi Kazu,
Your patch that exports the get_mount_list() and get_dump_level() functions has
been queued for crash-7.2.7:
https://github.com/crash-utility/crash/commit/3370ae03edf3d815bfffe556ffddc43619420674
Also, the CRASHDEBUG(0) in do_xarray_dump_cb() was a leftover from when I was
debuggi
Hi Dave,
Thanks for doing the legwork on this one, much appreciated. Queued for
crash-7.2.7:
https://github.com/crash-utility/crash/commit/b1a6e13a93661dfae7df15fe32862bddf4026c80
Dave
- Original Message -
> Commit e082c372c7f1a782b058ec359dfbbbee0f0b6aad reworked parse_line to
ave Wysochanski
Date: 5/15/19 12:40 PM (GMT-05:00) To: "Discussion list for crash utility
usage, maintenance and development" Subject:
[Crash-utility] Problem with crash-7.2.6 and certain print commands? We rebuilt
crash with the tarball
from:http://people.redhat.com/anderson/cr
Hi Kazu,
First patch queued for crash-7.2.7:
https://github.com/crash-utility/crash/commit/3fe4602775c086141c1e5bfb8a201a9443aeda82
Thanks,
Dave
- Original Message -
>
>
> - Original Message -
> > Hi Dave,
> >
> > I wanted to see net->flags for a vmcore and could see
- Original Message -
> On 5/6/2019 11:26 AM, Dave Anderson wrote:
> >
> >
> > - Original Message -
> >> Hi Dave,
> >>
> >> I wanted to see net->flags for a vmcore and could see it with "help -N"
> >> o
- Original Message -
> Hi Dave,
>
> I wanted to see net->flags for a vmcore and could see it with "help -N"
> option. But it is not listed in the help option list, which is printed
> by "help help" command. Is it just missed?
>
> Also, I found that -g, -O and -z options are missing f
Download from: http://people.redhat.com/anderson
or
https://github.com/crash-utility/crash/releases
The github master branch serves as a development branch that will contain
all patches that are queued for the next release:
$ git clone git://github.com/crash
- Original Message -
> Probably the loop length should be printed in decimal rather than hex.
>
> Example of output today:
> crash> list -B -r 0x88e4906ea390 | wc
> list: loop detected, loop length: 3c7
> list: length from start to loop: 3
> list: duplicate list entry: 819c1
- Original Message -
> Signed-off-by: Surendra Mobiya
> Signed-off-by: Rahul Lakkireddy
> ---
> help.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/help.c b/help.c
> index 1ec3938..7c13e55 100644
> --- a/help.c
> +++ b/help.c
> @@ -3370,7 +3370,7 @@ char *
- Original Message -
>
>
> - Original Message -
>
> > > > $ git diff memory.c
> > > > diff --git a/memory.c b/memory.c
> > > > index 8cdab06..7161d9d 100644
> > > > --- a/memory.c
> > > > +++ b/memory.c
> > > > @@ -8722,6 +8722,11 @@ dump_vmap_area(struct meminfo *vi)
> > > >
Hi Surendra,
Your patch has been queued for crash-7.2.6:
https://github.com/crash-utility/crash/commit/71a4f36767848e02f6f77fdbd6cb321151b84407
Thanks very much for this implementing this feature.
Dave
- Original Message -
>
> Hi Surendra,
>
> This version looks good. I've bee
- Original Message -
> > > $ git diff memory.c
> > > diff --git a/memory.c b/memory.c
> > > index 8cdab06..7161d9d 100644
> > > --- a/memory.c
> > > +++ b/memory.c
> > > @@ -8722,6 +8722,11 @@ dump_vmap_area(struct meminfo *vi)
> > > ld->list_head_offset = OFFSET(vmap_area_list)
- Original Message -
> On Thu, 2019-04-18 at 14:05 -0400, Dave Anderson wrote:
> >
> > - Original Message -
> > > On Thu, 2019-04-18 at 11:09 -0400, Dave Anderson wrote:
> > > >
> > > > - Original Message -
> > >
Hi Surendra,
This version looks good. I've been testing it today, and have tinkered
around with a few minor things:
1. Added vmcore.h to the Makefile for compile-dependency purposes.
2. Removed the requirement for the "-r" option, allowing just the file name
as an argument.
3. When
- Original Message -
> On Thu, 2019-04-18 at 11:09 -0400, Dave Anderson wrote:
> >
> > - Original Message -
> > > On Thu, 2019-04-18 at 15:02 +0100, Pierguido Lambri wrote:
> > > > Hello,
> > > >
> > > >
- Original Message -
> On Thu, 2019-04-18 at 15:02 +0100, Pierguido Lambri wrote:
> > Hello,
> >
> > Today while I was looking into a vmcore, I got suddenly the message
> > in $SUBJECT.
> > It started after I did a search into the process stack pages (search
> > -t)
> > and for each com
- Original Message -
>
> On Monday, April 04/15/19, 2019 at 21:16:49 +0530, Dave Anderson wrote:
> >
> >
> > - Original Message -
> > > Hi Dave,
> > >
> > > On Saturday, April 04/13/19, 2019 at 00:39:09 +053
- Original Message -
> Fix for the "dev -[dD]" options on Linux 5.1-rc1 and later kernels
> that contain commit 570d0200123fb4f809aa2f6226e93a458d664d70,
> titled "driver core: move device->knode_class to device_private".
> Without the patch, the commands fail with the following error me
- Original Message -
> Hi Dave,
>
> On Saturday, April 04/13/19, 2019 at 00:39:09 +0530, Dave Anderson wrote:
> >
> > Hi Surenda,
> >
> > Great -- I've been looking forward for this patch set to arrive.
> >
> > A couple things...
&g
Hi Surenda,
Great -- I've been looking forward for this patch set to arrive.
A couple things...
First, I'm going to need two sample vmcores (one ELF, one compressed kdump)
along with the associated vmlinux. You can contact me off-list with details
on how we can arrange a transfer.
Second, I
- Original Message -
> Since we plan to support kernel address space layout randomization (KASLR)
> for s390, we should adjust crash-utility accordingly. This is the minimal
> crash patch required to process the s390 dumps for the kernels configured
> with CONFIG_RANDOMIZE_BASE.
Hi Mikh
- Original Message -
> [snip]
>
> > Rather than making a wholesale switch, can you make it check the
> > dentry.d_inode first,
> > and if it's NULL, then check dentry.d_sb? I'm probably being paranoid, but
> > I'm worried
> > about unintended consequences.
>
> > Thanks,
> > Dave
>
>
- Original Message -
>
>
> Hi Dave,
>
>
>
> On a recurring series of crashes on kernel 3.10.0-693.17.1.el7.x86_64 (RHEL
> 7.4), a problem was triggered by deletion of a file by a process with this
> stack trace:
>
>
>
> #0 [88115b0ef798] __schedule at 816ab2ac
>
> #1
the "struct" command, where again the address
argument is taken as a file offset value. So if the device dump contains
raw dumps of data structures, you can display them as if you were supplying
a virtual address. Not sure if that helps.
Dave
> Thanks,
> Tirtsah.
>
>
>
- Original Message -
>
>
> Hi,
> I'm enabling core dump flow on my Linux, using Linux kexec mechanism. This
> flow ends with vmcore elf image reflecting the full memory situation at the
> crash moment. The vmcore driver in kernel that outputs the vmcore elf image
> has vmcore_add_device
Hi Steve,
I'm not going to wait any longer for Xu Huan to respond. Perhaps he's no
longer interested
in maintaining the package, but if he is, he can always reply later.
Your patches are queued for crash-7.2.6:
https://github.com/crash-utility/crash/commit/26488e918f065c7cdd8e8d77ef7c
- Original Message -
>
> Commit dd12805ed1db7 ("XArray: Remove radix tree compatibility") on
> linux-next changes the definition of 'radix_tree_root' back to be a struct.
> The content however differs from the original 'struct radix_tree_root'.
> Thus attempts to debug current linux-next
- Original Message -
> On Fri, 22 Mar 2019 10:38:31 -0400 (EDT)
> Dave Anderson wrote:
>
> > - Original Message -
> > > Hi Dave,
> > >
> > >
> > > On Thu, 21 Mar 2019 11:46:33 -0400 (EDT)
> > > Dave Anderson wrote
- Original Message -
> Hi Dave,
>
>
> On Thu, 21 Mar 2019 11:46:33 -0400 (EDT)
> Dave Anderson wrote:
>
> > - Original Message -
> > > Hi Dave,
> > >
> > > crash currently fails on linux-next kernel due to another radix
- Original Message -
> Hi Dave,
>
> crash currently fails on linux-next kernel due to another radix-tree rework.
> The patch attached fixes this.
>
> BTW, is there an 'official policy' about fixing linux-next issues, as commits
> can be changed/dropped on their way to the linux repo?
- Original Message -
> On Wed, 20 Mar 2019 10:25:44 -0400 (EDT)
> Dave Anderson wrote:
>
> > > >>>> but nonetheless, it does seem that Steve's patch
> > > >>>> to the trace.c module is the better course of action. Does it
- Original Message -
>
>
> - Original Message -
> >
> > On 3/19/19 6:48 PM, Dave Anderson wrote:
> > >>>>> The problem happens only with module symbols, not with kallsyms.
> > >>>>>
> > >&
- Original Message -
>
> On 3/19/19 6:48 PM, Dave Anderson wrote:
> >>>>> The problem happens only with module symbols, not with kallsyms.
> >>>>>
> >>>>> crash> sym -M
> >>>>> c0080
Let me try that again with discrete attachments.
- Original Message -
>
> - Original Message -
> >
> >>> The problem happens only with module symbols, not with kallsyms.
> >>>
> >>> crash> sym -M
> >>> c0080781 MODULE START: crc32c_vpmsum
> >>> c0080781 (^R) __cr
- Original Message -
>
>>> The problem happens only with module symbols, not with kallsyms.
>>>
>>> crash> sym -M
>>> c0080781 MODULE START: crc32c_vpmsum
>>> c0080781 (^R) __crc32c_vpmsum
>>> c00807810670 (^B) crc32c_vpmsum_cra_init
>>> c00807810690 (^B) crc32c_vpm
- Original Message -
> Hi Dave,
>
> Sorry for late reply, was busy with something else.
>
> On 3/7/19 8:50 PM, Dave Anderson wrote:
> >>> We are using ELFXX_sym->st_info directly as the 'type' of symbol,
> >>> which is wrong, because
e crash utility
itself) wasn't
acceptable, and there was no response after that. This looks to fix the same
issue.
Dave
- Forwarded Message -
From: "Steven Rostedt"
To: "Dave Anderson"
Sent: Friday, March 15, 2019 9:03:33 PM
Subject: [PATCH 0/3] trace.so: Make trac
101 - 200 of 3204 matches
Mail list logo
