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_UNINTERRUPTIBLE
crash> gdb set disassembly-flavor intel
On 04/11/2016 05:06 PM, Dave Anderson wrote:
>
>
> - 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
>>
nse for more details.
+ *
+ * Nikolay Borisov <n.borisov.l...@gmail.com>
+ */
+
+#include "defs.h"
+
+#define CGROUP_PATH_MAX
+void proccgroup_init(void);
+void proccgroup_fini(void);
+
+void show_proc_cgroups(void);
+char *help_proc_cgroups[];
+
+static struct command_table_
Initial version of a crash module which can be used to show which cgroups
is a process member of.
Signed-off-by: Nikolay Borisov <n.borisov.l...@gmail.com>
---
So here is the second version of the proccgroup module. Changes since v1:
* Now show the full path to the cgroup (limited to 4
On 04/14/2016 09:50 PM, Dave Anderson wrote:
>
>
> - Original Message -
>
>> Considering that as far back as 2.6.34 this member has been encapsulated
>> by CONFIG_CGROUPS I think this is unlikely, unless of course the
>> "patched rebuild" specifically had the ifdef guard removed. In
Hello,
I'd like to ask whether the crash utility would actually benefit from
enabling CONFIG_DEBUG_INFO_DWARF4 in the kernel when debugging a crash
dump. And by "benefit" I mean "better" output when disassembling
function etc?
Regards,
Nikolay
--
Crash-utility mailing list
Hello,
I tried running crash-head (HEAD: 5d172b230cf4) against today's linus'
master on a dump obtained via dump-guest-memory in qemu. And I got the
following when the image is loaded:
please wait... (determining panic task)
bt: read error: kernel virtual address: fe007000 type: "stack
On 4.04.2018 17:48, Dave Anderson wrote:
>
>
> - Original Message -
>> Hello,
>>
>> I tried running crash-head (HEAD: 5d172b230cf4) against today's linus'
>> master on a dump obtained via dump-guest-memory in qemu. And I got the
>> following when the image is loaded:
>>
>> please
On 4.04.2018 18:48, Dave Anderson wrote:
>
>
> - Original Message -
>>
>>
>> On 4.04.2018 17:48, Dave Anderson wrote:
>>>
>>>
>>> - Original Message -
Hello,
I tried running crash-head (HEAD: 5d172b230cf4) against today's linus'
master on a dump obtained
d. I'm now interested in understanding why s390 on
x86_64 is not supported.
>
>
>
> Honglei
>
>
> On 2019/5/20 15:18, Nikolay Borisov wrote:
>> Hello Dave,
>>
>> I'd like to better understand why s390-on-x86_64 analysis is not
>> supported e.g. res
Hello Dave,
I'd like to better understand why s390-on-x86_64 analysis is not
supported e.g. respective pair in get_current_configuration is missing?
Is it due to the endianness mismatch ? gdb does support setting the
endianness of a target? Or are there other problems?
--
Crash-utility mailing
Hello,
I haven't been able to open a crashdump generated by 'dump-guest-memory
-z' option. When I run crash -d10 vmlinux dump.img last thing I get is:
kaslr_helper: failed to determine which kernel was running at crash,
kaslr_helper: asssuming the kdump 1st kernel.
calc_kaslr_offset:
e.
Signed-off-by: Nikolay Borisov
---
symbols.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/symbols.c b/symbols.c
index 70b1455750ee..e3594ce0ed48 100644
--- a/symbols.c
+++ b/symbols.c
@@ -12711,9 +12711,11 @@ numeric_forward(const void *P_x, const
erivation when we crash tries to open a qemu image dump. Fix it
>> by also checking symbols for the presence of the new name.
>>
>> Signed-off-by: Nikolay Borisov
>
> Thank you for catching this.
>
> The divide_error way would be rarely used with Alexey's patchset
On 29.10.20 г. 14:42 ч., Nikolay Borisov wrote:
> Hello,
>
> I haven't been able to open a crashdump generated by 'dump-guest-memory
> -z' option. When I run crash -d10 vmlinux dump.img last thing I get is:
>
> kaslr_helper: failed to determine which kernel was running at cra
15 matches
Mail list logo
