- Original Message -
> Hello Dave,
>
> I've rewritten the mentioned logic, now crash communicates with gdb by means
> of gdb_interface.
Hello Alexandr,
I've been playing with your patch for the last couple of days, and in the
interest of getting it checked in without us having to go ba
tial mounts of the cgroups.
Both are the same odd-ball interim Fedora 3.13.0-0.rc1.git2.1.fc20 kernel,
and no sources exist that I am aware of. Here are the vmlinux and vmcore
if you want to play with the dumpfile:
http://people.redhat.com/anderson/nborisov
Dave
--
Crash-utility mailing list
C
- Original Message -
... [ cut ] ...
> > And lastly, I only have one 3.14-based kernel, which shows this:
> >
> > crash> sys | grep RELEASE
> >RELEASE: 3.14.0-rc1+
> > crash> showcg
> > showcg: zero-size memory allocation! (called from 7f3280273719)
> > crash>
> >
> >
seeing is the
cgroup name and path? I don't know -- that's up to you.
Also, you don't have to post your module as a patch to the
extensions subdirectory. I'm not going to add the file to the
crash sources contained in the tar.gz or src.rpm releases, but
rather I will post your
- Original Message -
> >
> > In your test code, you could simply NOT initialize the total_objects offset
> > and see what happens.
> >
> Yes that shows the negative ALLOCATED values. One more minor change to
> the previous patch was required (attached).
> What I have tested and confirmed
- Original Message -
> >
> > While this is an improvement over your last post, there are still issues
> > with this patchset. I've been testing it with a wide range of stashed
> > vmcores, and I see problems with all of the old 2.6.24 vmcores. Those
> > kernels used an early version of
- Original Message -
> Initial version of a crash module which can be used to show which cgroups
> is the currently active process member of.
> ---
> Hello this is a simple crash extension that I hacked up over the weekend, in
> my
> case when I look at kernel crash dump I want to quickl
- Original Message -
> From: Rabin Vincent
>
> Since v4.2, irq_data is no longer the first element in irq_desc, because
> there is now an irq_common_data before it. So we need to get the offset
> of irq_data in irq_desc.
>
> Side note: Since v4.3, affinity (used by irq -a) appears to
- Original Message -
>
>
> - Original Message -
> > Dave,
> >
> > thank you for your comment. I've also reviewed the set of existing gdb
> > functions more carefully. Looks like it wasn't necessary to modify existing
> > code in gdb. It suffice to use another function from the
- Original Message -
> Dave,
>
> thank you for your comment. I've also reviewed the set of existing gdb
> functions more carefully. Looks like it wasn't necessary to modify existing
> code in gdb. It suffice to use another function from the same structure (it
> hasn't been used before -
- Original Message -
> Hello Dave,
>
> Here is the brief background for the patch.
>
> We had a problem - there was a page which contained some structure which we
> weren't able to identify,
> but we could specify approximate size of this structure. Also it might be
> said that this str
You can set up your own subscription at
https://www.redhat.com/mailman/listinfo/crash-utility,
but I see that you already are subscribed, at the address you sent, and at what
appears
to be another address of yours @live.com.
Dave
- Original Message -
>
>
>
>
>
>
>
>
>
>
> Dav
- Original Message -
> One of the specific items I wanted is /proc/buddyinfo.
Well, it looks like /proc/buddyinfo date comes down to the functions
in the kernel's seq_operations structure, where:
proc_create("buddyinfo", S_IRUGO, NULL, &fragmentation_file_operations);
leads to:
- Original Message -
> Is it possible to get the /proc data from the saved crash dump file?
>
> --
> Mahmoud Hanafi
>
It would be helpful if you could be more specific, but generally speaking,
the data displayed by /proc files comes from kernel data structures,
and all kernel data shou
Dave,
Can you write me up a header for sparc64.c that has a GPL statement
and any desired copyright lines? No need for a full patch repost,
just the header.
Thanks,
Dave
- Original Message -
> These patches add support for the sparc64 architecture.
>
> This supports running against
- Original Message -
> On Tue, Mar 15, 2016 at 8:08 PM, vinayak menon
> wrote:
> >>
> >> Although looking at it now, get_slabinfo() doesn't seem to take into
> >> account
> >> the objects in the per_cpu caches?
> >>
> >> Anyway, 200 of 200 is clearly wrong.
> >>
> >> Dave
> >>
> >
>
>
Alexey,
I'm not sure what you want me to do with this. Seems like a good
candidate to be put on the upstream web page, maybe in the "Python
Scripts" section, separated from, but next to the "mpykdump.so"
section.
Dave
- Original Message -
> Add simple script with caching (just one sta
Hi Dave,
Welcome to the party after all these years.
With any new architecture addition, one of the primary requirements
for acceptance is that it in no way impacts any of the other architectures.
This patchset was nicely done with that in mind, although there are two
places in task.c where it
ZRSS COMM
> > 0 0 0 81c0f4c0 RU 0.0 0 0 [swapper/0]
> crash>
>
> Any ideas?
>
> I'm using top-o-tree from Dave's git repo
> https://github.com/crash-utility/crash.git:
>
> commit 04ab5c560a58246e782509d99214af
> >
> > > Any ideas?
> > >
> > > I'm using top-o-tree from Dave's git repo
> > > https://github.com/crash-utility/crash.git:
> > >
> > > commit 04ab5c560a58246e782509d99214afcaf8462b4c
> > > Author: Dave Anderson
> >
- Original Message -
> Dear Dave,
>
> could you please update vz.c extension on your site.
> New version supports RHEL7-based Vz7 kernels.
>
> Thank you,
> Vasily Averin
Done.
Thanks,
Dave
>
> On 30.04.2015 18:57, Dave Anderson wrote:
> >
- Original Message -
>
> Hi Dave,
>
> Looks like this is because of counting the per cpu objects twice. They
> are already included in kmem_cache_node.total_objects. This should fix
> that. New patch attached.
>
> diff --git a/memory.c b/memory.c
> index 7b645b8..1343a11 100644
> --- a
- Original Message -
> Hi,
>
> With a ramdump of a system with 386MB of available memory, "kmem -s"
> shows something like this
>
> CACHE NAME OBJSIZE ALLOCATED TOTAL SLABS
> SSIZE
> dd801c00 kmalloc-20482048 670869 670960
- Original Message -
> > How is your system configured?
> 4k pages with 3-level PTE
> I did not backport any of the support for deeper level PTE's or larger page
> sizes
>
> >You might even be able to get to a crash> prompt by running:
> > $ crash /proc/kcore --no_modules
>
> no_modules
- Original Message -
> root@odroid64-pre:~/crash-7.1.4# ./crash /proc/kcore
>
> crash 7.1.4
> Copyright (C) 2002-2015 Red Hat, Inc.
> Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation
> Copyright (C) 1999-2006 Hewlett-Packard Co
> Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited
>
- Original Message -
> root@odroid64-pre:~/crash-7.1.4# ./crash --minimal
> crash> rd linux_banner 30
> ffc00186a090: 00160102 5018 .P..
> ffc00186a0a0: 000115f9 00160102
> ffc00186a0b0: 3e11
- Original Message -
> I have the new Odroid-C2 arm64 cortex-a53 board and have been trying to get
> crash to work against the live kernel.
>
> I think the key error is this:
> linux_banner:
> crash: /lib/modules/3.14.29+/build/vmlinux and /dev/mem do not match!
>
> They should match as
Laurence and Joe,
Can you gents test Atsushi's fix in your environments?
Thanks,
Dave
- Original Message -
> Hello Dave,
>
> >>Note that PAGE_MAPPING_ANON is now only set in the compound_head page,
> >>so when makedumpfile walks though the pages, it will have to look
> >>at each pag
R_DATA uses isAnon(), whereas the
other two use !isAnon(). So if my logic is correct, if you try to
filter out page-cache pages as well -- i.e., with "-d23" -- worst case
it may result in some pages *not* being filtered. And I'm not even
sure of that, given the page->flags ch
Hello Atsushi,
I've recently had a couple 4.5-era vmcores issues reported to me as crash bugs
because they generate numerous initialization-time errors of the type:
crash: page excluded: kernel virtual address: 880075459000 type:
"fill_task_struct"
Initially I thought it was related to
- Original Message -
>
>
> Hi everyone,
>
>
>
> I am curious for inspecting FreeBSD VM dump by crash-utility.
>
>
>
> I built crash from source, and changed the configure option of gdb to target
> FreeBSD.
>
> And used virsh dump --memory-only to generate freebsd.dump.
>
> But I
4:34:15PM -0500, Dave Anderson wrote:
> >
> > - Original Message -
> > >
> > > Linux kernel commit 054954eb051f35e74b75a566a96fe756015352c8
> > > (xen: switch to linear virtual mapped sparse p2m list), which
> > > appeared in 3.19, introduced line
Clean up codes
>
> md5sum:
> dea92b22142d59e73340a8af35e15c92
>
> [1] http://people.redhat.com/anderson/extensions.html#PTDUMP
>
> Thanks,
> Takao Indoh
Hi Takao,
Done...
Thanks,
Dave
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
- Original Message -
> Hi Dave,
>
> Sorry for delay but I have missed your email.
>
> On Thu, Jan 21, 2016 at 04:34:15PM -0500, Dave Anderson wrote:
> >
> > - Original Message -
> > >
> > > Linux kernel commit 054954eb051f35e74
- Original Message -
>
> Linux kernel commit 054954eb051f35e74b75a566a96fe756015352c8
> (xen: switch to linear virtual mapped sparse p2m list), which
> appeared in 3.19, introduced linear virtual mapped sparse p2m
> list. If readmem() reads p2m then it access this list using
> physical add
- Original Message -
> Hi,
>
> Crash fails to start with current (4.4+) kernels. The following patch
> fixes this.
>
> Regards,
> Sebastian
Sebastian,
Appreciate the heads-up -- queued for crash-7.1.5:
https://github.com/crash-utility/crash/commit/6f1f78e33474d00d5f261d7ed9d835c55
- Original Message -
> Hi Dave:
>
> >From the kernel codes, I found the member in my kernel was changed to
> >module_core_rx in CGL kernel, in crash's codes(6.1.4): kernel.c, there have
> >the following content:
> /**/
> case KM
- Original Message -
> Hi Dave,
>
> I just wanted to report a minor issue.
>
> The -t option on the 'ps' command will return invalid values for newer
> kernels.
>
> I believe that this has to do with newer kernels around the 3.17
> timeframe having the 'start_time' field in the task_st
- Original Message -
> Hi Experts:
>
> Here is crash tool failed to work issue:
>
> 0, it occur on pwoerpc p2041(e500mc) board, p2020(e500v2) will not have this
> issue.
> kernel version: 2.6.34
> crash tool version: 6.1.4
That's a 3-year-old version of crash, you really should upgrad
- Original Message -
> Hi Dave,
>
> I just wanted to report a minor issue.
>
> The -t option on the 'ps' command will return invalid values for newer
> kernels.
>
> I believe that this has to do with newer kernels around the 3.17
> timeframe having the 'start_time' field in the task_st
- Original Message -
> On 2016/01/06 12:32, Dave Anderson wrote:
> >
> >
> > - Original Message -
> >> On 2016/01/06 1:42, Dave Anderson wrote:
> >>>
> >>>
> >>> - Original Message -
> >>>>
- Original Message -
> Hi David,
>
> I recently tested makedumpfile on ARM64 with 3level-4K, 3level-64K and
> 4level-4K page tables.
>
> I tried to analyze the dumpfile with the crash tool.
> I noticed that with 3level-64K and 4level-4K I got the following error
> when I tried to run "k
- Original Message -
> On 2016/01/06 1:42, Dave Anderson wrote:
> >
> >
> > - Original Message -
> >>
> >>
> >> - Original Message -
> >>> Hi Dave,
> >>>
> >>> The attached files are ex
- Original Message -
>
>
> - Original Message -
> > (Somehow I wasn't on CC for your reply.)
> >
> > On Mon, Jan 04, 2016 at 04:14:51PM -0500, Dave Anderson wrote:
> > >
> > >
> > > - Original Message -
>
- Original Message -
> (Somehow I wasn't on CC for your reply.)
>
> On Mon, Jan 04, 2016 at 04:14:51PM -0500, Dave Anderson wrote:
> >
> >
> > - Original Message -
> > > On Fri, Dec 18, 2015 at 11:55:07PM +0100, Andrew Jones wrote:
ptdump-1.0.0/fastdecode.c
> ptdump-1.0.0/map.c
> ptdump-1.0.0/map.h
> ptdump-1.0.0/ptdump.c
> ptdump-1.0.0/ptdump.mk
> $ mv ptdump-1.0.0/* extensions
> $ make extensions
> gcc -Wall -g -nostartfiles -shared -rdynamic -o fastdecode.so fastdecode.c
> -fPIC -D
gcc -DLZO -DSNAPPY -Wall -I.. -fPIC -DX86_64 -c -o fastdecode.o fastdecode.c
gcc -DLZO -DSNAPPY -Wall -I.. -fPIC -DX86_64 -c -o map.o map.c
gcc -Wall -g -shared -rdynamic -o map.so map.c -fPIC -DX86_64 -DLZO -DSNAPPY
-DGDB_7_6
$ ls -ltr extensions/*.so
-rwxrwxr-x 1 anderson anderson
- Original Message -
> On Fri, Dec 18, 2015 at 11:55:07PM +0100, Andrew Jones wrote:
> > compat user mode prstatus already just works, almost. This missing
> > pieces are that pt_regs->sp and pt_regs->fp are not in their usual
> > locations. We need to pull them out of their architectural
>From f02ffc131933a8da8e516b2558c0945873ea290d Mon Sep 17 00:00:00 2001
From: HATAYAMA Daisuke
Date: Fri, 18 Dec 2015 10:59:57 +0900
Subject: [PATCH 2/2] Switch to zero excluded mode by default on sadump-related
formats. This is a fix for the regression, introduced by the commit
5e887f898c709f91
ff6b : push %rbx
> 0xff6c : mov%rsi,%rbx
> 0xff60000f : sub$0x8,%rsp
> 0xff600013 : test %rdi,%rdi
> 0xff600016 : je 0xff6000d5
>
> // abbreviation //
>
>
> On 2015/12/22 22:42, Dave Anderso
- Original Message -
> Hello,
>
> I've observed the following rather peculiar behavior of crash 7.1.3 (gdb
> 7.6).
>
> crash> set 88000376d280
> PID: 9615
> COMMAND: "jbd2/dm-32-8"
>TASK: 88000376d280 [THREAD_INFO: 880002bdc000]
> CPU: 2
> STATE: TASK_UNINTERR
- Original Message -
> I didn't check XEN HYPER MODE, I don't have XEN.
> If we need similar statement "if (kvaddr < MODULES_END)"
> please add inside in "if (XEN_HYPER_MODE())" (1859@x86_64_kvtop)
>
>
>
>
> >From ed300b74998e0923313e4fd14b9a41e305942b44 Mon Sep 17 00:00:00 2001
> Fr
>From f02ffc131933a8da8e516b2558c0945873ea290d Mon Sep 17 00:00:00 2001
From: HATAYAMA Daisuke
Date: Fri, 18 Dec 2015 10:59:57 +0900
Subject: [PATCH 2/2] Switch to zero excluded mode by default on sadump-related
formats. This is a fix for the regression, introduced by the commit
5e887f898c709f91
Hi Drew,
I am out of the office until Jan 4th, so I may not get around to checking
this out fully until then. But in the meantime, can you save this dumpfile
and send me a pointer to it offline? I want to keep it around for future
testing.
Thanks,
Dave
- Original Message -
> Hi Da
- Original Message -
> On Fri, 18 Dec 2015 09:33:55 -0500 (EST)
> Dave Anderson wrote:
>
> > - Original Message -
> > > Hello Dave,
> > >
> > > Let me send you a cleanup/fix for Xen DomU dumps.
> > >
> > > When op
- Original Message -
> Hello Dave,
>
> Let me send you a cleanup/fix for Xen DomU dumps.
>
> When opening a Xen DomU dump without auto-translated addresses (e.g.
> from an x86_64 PV domain), a mapping between physical and machine
> pages is needed. An xc_core dump file does not contain
Download from: http://people.redhat.com/anderson
or
https://github.com/crash-utility/crash/releases
The 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-utility
- Original Message -
> Thanks the patch works very well!
> Only a minor nit, now the n_type has changed:
>
> Elf64_Nhdr:
>n_namesz: 15 ("VMCOREINFO_XEN")
>n_descsz: 4068
> n_type: 0 (?)
>
> I'm not familiar enough what should be the righ
- Original Message -
> On Tue 2015-12-08 12:15 -0500, Dave Anderson wrote:
>
> Hi Dave,
>
> Sorry for the delay. Please find a v2 patch attached with a similar
> approach to your attempt to add support for 'dmi_field' when available.
>
> > The att
- Original Message -
>
> Hi Experts:
>
> I met a issue when try to analysis vmcore which was triggered by a error in
> module on powerpc target.
>
> BG:
> Crash version is 6.1.4, I cross build it with powerpc toolchain, and run it
> on p2020(e500v2) target directly.
>
>
> It sho
- Original Message -
>
>
> - Original Message -
> >
> >
> > - Original Message -
> > > Hi,
> > >
> > > I have a SuSE SLES11 vmcore with xen and tried to read the osrelease from
> > > the vmcore with
> > > # crash --osrelease vmcore
> > > unknown
> > >
> > > The probl
- Original Message -
>
>
> - Original Message -
> > Hi,
> >
> > I have a SuSE SLES11 vmcore with xen and tried to read the osrelease from
> > the vmcore with
> > # crash --osrelease vmcore
> > unknown
> >
> > The problem is that there are two notes in the vmcore starting with
- Original Message -
> Hi,
>
> I have a SuSE SLES11 vmcore with xen and tried to read the osrelease from the
> vmcore with
> # crash --osrelease vmcore
> unknown
>
> The problem is that there are two notes in the vmcore starting with
> "VMCOREINFO":
>
> Elf64_Nhdr:
>n
- Original Message -
> Aaron and Buland,
>
> I was just about to check this in when I thought that maybe it could
> be a bit more informative than just "dmi_ident[#]: ", given
> that the output could also incorporate the enum name/index, as is done
> with a few other crash commands:
>
Aaron and Buland,
I was just about to check this in when I thought that maybe it could
be a bit more informative than just "dmi_ident[#]: ", given
that the output could also incorporate the enum name/index, as is done
with a few other crash commands:
crash> dmi_field
enum dmi_field {
DMI_NONE
Hi Aaron,
This kind of kernel/machine specific information has no place in the "help"
command, which is wholly concerned with crash utility internal debug related
information.
It's probably not worthy of its own command, so maybe it could be a "sys" or
"mach" option?
Dave
Sent from my Ver
- Original Message -
> On 11/29/15 at 10:52pm, Dave Young wrote:
> [snip]
>
> With the new build it fails at later point, but I noticed I enabled
> CONFIG_DEBUG_INFO_REDUCED=y
>
> A retest without CONFIG_DEBUG_INFO_REDUCED succeed with latest latest
> crash build, but there's some read er
- Original Message -
> By default, the clear screen behaviour is only used when not in
> insertion mode. This causes the screen to clear in insertion mode
> instead of just printing a '^L'.
>
> Signed-off-by: Kyle Walker
> ---
> cmdline.c | 2 ++
> 1 file changed, 2 insertions(+)
>
>
- Original Message -
>
>
> Hi Experts:
>
> I got vmcore file on powerpc board(P2020 or P2040), but failed to do crash
> analysis on x86 host, it showed we need to build a powerpc supported crash
> binary.
>
> On the README of the latest crash-7.1.3, it state to get crash binary which
- Original Message -
> On s390 we have stand-alone dump tools that write the dump directly to a
> block device partition. It is possible to use the partition device node
> instead of a dump file when running crash. When we do that, everything works
> fine but we get the following (a bit m
- Original Message -
> > > Drew,
> > >
> > > Can you sanity-test the attached patch? If it works OK for you, I'll post
> > > it as-is.
> >
> > Works. I tested on both arm and aarch64. I still think we should commit
> > it as two patches though. The qemu one, with its commit message foc
- Original Message -
> On Mon, Nov 23, 2015 at 11:35:38AM -0500, Dave Anderson wrote:
> >
> >
> > - Original Message -
> > > > > Would you like me to spin a v4 with this condition added? Or, since
> > > > > it
> > > &
- Original Message -
> > > Would you like me to spin a v4 with this condition added? Or, since it
> > > actually seems to be addressing a non-qemu-generated dump issue, then
> > > maybe you just want to submit it as a new patch on top of the qemu
> > > patch?
> >
> > No, I'm cleaning it
- Original Message -
> On Fri, Nov 20, 2015 at 03:18:55PM -0500, Dave Anderson wrote:
> >
> >
> > - Original Message -
> > >
> > >
> > > - Original Message -
> > > > QEMU can generate both non-makedumpf
- Original Message -
>
>
> - Original Message -
> > QEMU can generate both non-makedumpfile (just elf) and makedumpfile
> > formatted kdumps. In neither case will crash_notes have prstatus, as
> > crash_kexec doesn't run in the kernel, however the elf notes will
> > contain the
- Original Message -
> QEMU can generate both non-makedumpfile (just elf) and makedumpfile
> formatted kdumps. In neither case will crash_notes have prstatus, as
> crash_kexec doesn't run in the kernel, however the elf notes will
> contain the prstatus, and we can dig them out of there.
- Original Message -
> Thanks to kernel commit 9d372c9fab34 "arm64: Add page size to the
> kernel image header", we don't need a heuristic to determine the
> pagesize on arm64. Keep the heuristic for older kernels, but try
> reading the header first.
This looks good -- I also added the n
- Original Message -
> I was originally thinking about the same as yourself but decided against
> it due to thinking first that, in English, QUIET is a bit abstract for
> "don't try to switch devmem source" as well as avoid output.
>
> Plus, if any other readmem() that's QUIET fails REA
TASK: 881ea93b2140 [THREAD_INFO: 881e869f2000]
> CPU: 112
>STATE: TASK_RUNNING (ACTIVE)
>
> So just from a user's viewpoint, I think it is enough for normal use.
> Is it right?
> Thanks in advance!
> Best Regards
> Nan Xiao
Yes, you&#x
- Original Message -
> On 11/19/2015 12:20 PM, Dave Anderson wrote:
> >
> >
> > - Original Message -
> >> On 11/19/2015 08:37 AM, David Mair wrote:
> >>> On 11/19/2015 07:45 AM, Dave Anderson wrote:
> >>&
- Original Message -
>
> Below is a (hardly tested, pretty messy, incomplete - needs to address
> other architectures verify_symbol() prototypes) patch that illustrates
> this idea. I'm OK with special casing _kernel_flags_le, but generally
> prefer to look for general solutions. Let me
- Original Message -
> On 11/19/2015 08:37 AM, David Mair wrote:
> > On 11/19/2015 07:45 AM, Dave Anderson wrote:
> >
> > Hi Dave,
> >
> >> - Original Message -
> >
> >>
> >>> (2) Execute "crash -d8" on p
- Original Message -
> On Thu, Nov 19, 2015 at 11:50:22AM -0500, Dave Anderson wrote:
> >
> >
> > - Original Message -
> > > QEMU can generate both non-makedumpfile (just elf) and makedumpfile
> > > formatted kdumps. In neither
- Original Message -
> On 11/19/2015 07:45 AM, Dave Anderson wrote:
>
> Hi Dave,
>
> > - Original Message -
>
> >
> >> (2) Execute "crash -d8" on physical machine will cause crash utility core
> >> dump.
> >
>
- Original Message -
> QEMU can generate both non-makedumpfile (just elf) and makedumpfile
> formatted kdumps. In neither case will crash_notes have prstatus, as
> crash_kexec doesn't run in the kernel, however the elf notes will
> contain the prstatus, and we can dig them out of there.
- Original Message -
> Thanks to kernel commit 9d372c9fab34 "arm64: Add page size to the
> kernel image header", we don't need a heuristic to determine the
> pagesize on arm64. Keep the heuristic for older kernels, but try
> reading the header first.
> ---
> arm64.c | 30
- Original Message -
> On 11/19/2015 08:56 AM, Dave Anderson wrote:
> >
> >
> > - Original Message -
> >>>
> >>> So my questions are:
> >>>
> >>> (1) Is it OK to use "/proc/kcore" instead of &qu
- Original Message -
> We need to pass some absolute symbols through, but the highest bit test
> is filtering all of them out. Remove that, and filter more specifically.
> ---
> arm64.c | 4 ++--
> defs.h | 3 +++
> 2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arm6
- Original Message -
> >
> > So my questions are:
> >
> > (1) Is it OK to use "/proc/kcore" instead of "/dev/mem" as a workaround?
> > Is there any side-effect?
>
> As I read it, /proc/kcore is the kernel's virtual address space and
> /dev/mem is the system's physical address space. It
- Original Message -
> On 11/19/2015 08:37 AM, David Mair wrote:
> > On 11/19/2015 07:45 AM, Dave Anderson wrote:
> >
> > Hi Dave,
> >
> >> - Original Message -
> >
> >>
> >>> (2) Execute "crash -d8" on p
t;,
> error_handle=error_handle@entry=6) at memory.c:2209
> #20 0x0048704a in devmem_is_restricted () at memory.c:2414
> #21 readmem (addr=1052672, memtype=memtype@entry=4,
> buffer=buffer@entry=0x7fff463c21f8, size=size@entry=8,
> type=type@entry=0x8563e1 "devmem_is_allowed -
-unknown-linux-gnu"...
> > GETBUF(248 -> 0)
> > GETBUF(1500 -> 1)
> >
> > FREEBUF(1)
> > FREEBUF(0)
> > > 2de9ff0>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > WARNING: could not fin
;
>
>
> base kernel version: 0.8.0
> 7ffc9636f928>
>
> (ROE|Q), 7ffc9636fc80>
>
> WARNING: cannot read linux_banner string
> /proc/version:
> Linux version 3.12.49-6-xen (geeko@buildhost) (gcc version 4.8.5 (SUSE
> Linux) ) #1 SMP Mon Oct 26 16:05:37 UT
- Original Message -
>
>
> - Original Message -
> > Hello,
> >
> > This is a follow-up report of the issue I found in the release test
> > for makedumpfile-1.5.9. The original report was posted in kexec-ML:
> >
> > http://lists.infradead.org/pipermail/kexec/2015-October/0146
(248 -> 0)
> GETBUF(1500 -> 1)
>
> FREEBUF(1)
> FREEBUF(0)
> 2f22000>
>
>
>
>
>
>
>
>
>
> WARNING: could not find MAGIC_START!
> GETBUF(248 -> 0)
> FREEBUF(0)
> GETBUF(64 -> 0)
> 7fffb4ff6918>
>
> 7ff
- Original Message -
> Hello,
>
> This is a follow-up report of the issue I found in the release test
> for makedumpfile-1.5.9. The original report was posted in kexec-ML:
>
> http://lists.infradead.org/pipermail/kexec/2015-October/014620.html
>
> > o Support new kernels
> > - The s
ash
..
WARNING: could not find MAGIC_START!
WARNING: cannot read linux_banner string
crash: /var/tmp/vmlinux-3.12.49-6-xen.gz_JWv5bU and /dev/mem do not match!
..
So why does this operation fail?
Best Regards
Nan Xiao
On Mon, Nov 16, 2015 at 10:48 PM, Dave Anderson wrote:
>
>
> -
> License GPLv3+: GNU GPL version 3 or later
> > <http://gnu.org/licenses/gpl.html>
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> > and "show
- Original Message -
>
>
> - Original Message -
> > Hello,
> >
> > I'd like to ask whether it's possible to traverse the chains of a
> > hashtable which is defined via the hashtable.h infrastructure? If
> > there is no support for this currently I guess crash has to be taught
>
- Original Message -
> > (1) There are so may warnings like this:
> >
> > crash: xx: original filename unknown
> > Use "-f xx" on command line to prevent this message.
> >
> > Do I need to add somay "-f xx" options on command line? Is there
> > any better method?
>
> The
701 - 800 of 3204 matches
Mail list logo
