from:"Sagar Borikar"

Re: [Crash-utility] kernel module parsing failure - mips

2016-12-04 Thread Sagar Borikar

On Sun, Dec 4, 2016 at 1:47 PM, Rabin Vincent <ra...@rab.in> wrote:
> On Sun, Dec 04, 2016 at 01:07:03PM -0800, Sagar Borikar wrote:
>> On Sun, Dec 4, 2016 at 8:16 AM, Rabin Vincent <ra...@rab.in> wrote:
>> >> read_netdump: READ_ERROR: offset not found for paddr: 271e9cc0
>> >>
>> >> crash: read error: kernel virtual address: c0bc9cc0  type: "module struct"
>> >
>> > Here's the error.  Either 271e9cc0 is a valid physical address and the 
>> > dump is
>> > incomplete, or it's not and the page table translation is returning a bogus
>> > physical address for c0bc9cc0.
>>
>> crash> vtop c0bc9cc0
>> VIRTUAL   PHYSICAL
>> c0bc9cc0  271e9cc0
>>
>> SEGMENT: ksseg
>> PAGE DIRECTORY: 82c3
>>   PGD: 82c300c0 => 83018000
>>   PTE: 03018bc8 => 271e87cf
>>  PAGE: 271e8000
>>
>>   PTE PHYSICAL  FLAGS
>> 271e87cf  271e8000  (PRESENT|WRITE|ACCESSED|MODIFIED|GLOBAL|VALID|DIRTY)
>>
>>   PAGEPHYSICAL   MAPPINGINDEX CNT FLAGS
>> 82dc0f40  271e8000 0 0  1 4000
>>
>> 0x271e9cc0 is a valid address but it belongs to high mem(0x2000
>> onwards for this platform). Also I don't think there is any problem in
>> dump as I have done several testing of crash without modules and every
>> time I have got correct result.
>
> Have a look at the segments at the start of the log.  The 271e9cc0
> physical address is apparently not included in the dump:
>
>  pt_load_segment[0]:
> file_offset: 8000
>  phys_start: 10
>phys_end: 703fff
>   zero_fill: 0
>  pt_load_segment[1]:
> file_offset: 60c000
>  phys_start: 44000
>phys_end: 144000
>   zero_fill: 0
>  pt_load_segment[2]:
> file_offset: 70c000
>  phys_start: 144000
>phys_end: 430
>   zero_fill: 0
>  pt_load_segment[3]:
> file_offset: 48c8000
>  phys_start: d20
>phys_end: d20

Right. Looked at it in more detail. kexec looks for "System RAM" under
/proc/iomem to build the memory segments which are passed to crash
notes.
But for some reason MIPS kernel doesn't add high mem in /proc/iomem
resource list.

Refer to arch/mips/kernel/setup.c resource_init() function

729
730 start = boot_mem_map.map[i].addr;
731 end = boot_mem_map.map[i].addr + boot_mem_map.map[i].size - 1;
732 if (start >= HIGHMEM_START)
733 continue;
734 if (end >= HIGHMEM_START)
735 end = HIGHMEM_START - 1;
736

Because of which highmem segment is not passed by kexec.

Sagar
>
>> > To check the page table translation, use "vtop " (example below)
>> > to see how crash comes to its result.  You'll have to then manually walk
>> > the page tables for this particular virtual address and verify that the
>> > correct PGD and PTE entries are being read.  It could be easier if use
>> > vmalloc_to_page() and page_address() first in your kernel to print out
>> > the correct physical address for some known vmalloc'd address.
>>
>> As the driver works fine, I think kernel translation looks ok. Wrong
>> physical address translation would have failed the nvme driver to run.
>> Stress testing with the driver is fine. But still would go through the
>> PTE entries.
>
> I wasn't implying that the kernel's virt-to-phys translation was wrong,
> but rather that the crash utility's translation might be.  But if
> 271e9cc0 is a valid physical address on your platform then the
> translation itself is probably fine.
>
> --
> Crash-utility mailing list
> Crash-utility@redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Re: [Crash-utility] kernel module parsing failure - mips

2016-12-04 Thread Sagar Borikar

On Sun, Dec 4, 2016 at 8:16 AM, Rabin Vincent <ra...@rab.in> wrote:
> On Sun, Dec 04, 2016 at 07:10:38AM -0800, Sagar Borikar wrote:
>> 
>> 
>> read_netdump: addr: 806d2c68 paddr: 6d2c68 cnt: 4 offset: 5dac68
>> GETBUF(416 -> 0)
>>
> please wait... (gathering module symbol data)module: c0bc9cc0
>> 
>> 
>> 
>> read_netdump: addr: 82c3 paddr: 2c3 cnt: 16384 offset: 31f8000
>> 
>> 
>> read_netdump: addr: 0 paddr: 3018000 cnt: 16384 offset: 35e
>> 
>> read_netdump: READ_ERROR: offset not found for paddr: 271e9cc0
>>
>> crash: read error: kernel virtual address: c0bc9cc0  type: "module struct"
>
> Here's the error.  Either 271e9cc0 is a valid physical address and the dump is
> incomplete, or it's not and the page table translation is returning a bogus
> physical address for c0bc9cc0.

crash> vtop c0bc9cc0
VIRTUAL   PHYSICAL
c0bc9cc0  271e9cc0

SEGMENT: ksseg
PAGE DIRECTORY: 82c3
  PGD: 82c300c0 => 83018000
  PTE: 03018bc8 => 271e87cf
 PAGE: 271e8000

  PTE PHYSICAL  FLAGS
271e87cf  271e8000  (PRESENT|WRITE|ACCESSED|MODIFIED|GLOBAL|VALID|DIRTY)

  PAGEPHYSICAL   MAPPINGINDEX CNT FLAGS
82dc0f40  271e8000 0 0  1 4000

0x271e9cc0 is a valid address but it belongs to high mem(0x2000
onwards for this platform). Also I don't think there is any problem in
dump as I have done several testing of crash without modules and every
time I have got correct result.
Are you accounting for high memory?

>
> To check the page table translation, use "vtop " (example below)
> to see how crash comes to its result.  You'll have to then manually walk
> the page tables for this particular virtual address and verify that the
> correct PGD and PTE entries are being read.  It could be easier if use
> vmalloc_to_page() and page_address() first in your kernel to print out
> the correct physical address for some known vmalloc'd address.

As the driver works fine, I think kernel translation looks ok. Wrong
physical address translation would have failed the nvme driver to run.
Stress testing with the driver is fine. But still would go through the
PTE entries.

Dave,

>  crash> sym -n swapper_pg_dir
>  806d (B) swapper_pg_dir
> 806d1000 (B) invalid_pte_table
>  crash>
>
> What does the command above on your kernel show?

crash>  sym -n swapper_pg_dir
82c3 (B) swapper_pg_dir
82c34000 (B) invalid_pte_table

Thanks
Sagar


>
>  crash> vtop c01050c0
>  VIRTUAL   PHYSICAL
>  c01050c0  71550c0
>
>  SEGMENT: ksseg
>  PAGE DIRECTORY: 8054
>PGD: 805400c0 => 872b
>PTE: 072b0104 => 071545ef
>   PAGE: 07154000
>
>PTEPHYSICAL  FLAGS
>  71545ef   7154000  
> (PRESENT|READ|WRITE|ACCESSED|MODIFIED|GLOBAL|VALID|NO_READ|DIRTY)
>
>PAGEPHYSICAL   MAPPINGINDEX CNT FLAGS
>  81038e60   7154000 0 0  1 4000
>
> --
> Crash-utility mailing list
> Crash-utility@redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Re: [Crash-utility] kernel module parsing failure - mips

2016-12-03 Thread Sagar Borikar

On Sat, Dec 3, 2016 at 1:59 AM, Rabin Vincent <ra...@rab.in> wrote:
> On Fri, Dec 02, 2016 at 04:06:20PM -0800, Sagar Borikar wrote:
>> With 7.1.7, crash is working for MIPS when all drivers are embedded
>> inside kernel.
>> When I make the driver loadable and panic the kernel, crash doesn't
>> locate some symbols correctly.
>>
>> please wait... (gathering module symbol data)
>> crash: invalid size request: 0  type: "pgd page"
>>
>> debugged further and find  that PGD_ORDER provides incorrect number
>> due to which the PGD_SIZE macro results in 0.
>>
>> Just for fun, I replaced PGD_ORDER with 0(I know its incorrect) and it
>> went ahead but couldn't run "mod" command successfully as it threw
>> following error
>>
>> crash> mod
>> mod: cannot access vmalloc'd module memory
>
> In order to access vmalloc'd memory we need interpret the page tables
> correctly.  This isn't needed when the modules are built in since then
> the memory will be in the direct-mapped kseg0 segment.  So the "mod"
> failure is just a consequence of replacing PGD_ORDER with 0.

Yes, mod will not work as I said earlier. Crash was exiting hence I
wanted to have quick workaround.

> So the first error should be fixed properly before attempting "mod".  What
> kernel version is this and what page size do to use?

4.4.20 kernel and page size is 16K

>
> Try running the "help -m" and "mach" commands (you can skip module loading 
> with
> --no_modules to get to the crash> prompt) and check if the values for the
> various page table sizes and bits match what your kernel is using.
>
>  crash> help -m
>  ...
>pagesize: 4096
>   pageshift: 12
>pagemask: f000
>  pageoffset: fff
> pgdir_shift: 22
>ptrs_per_pgd: 1024
>ptrs_per_pte: 1024
>  ...
>
>
>  crash-mips> mach
>PAGE SIZE: 4096
>
>_PAGE_PRESENT: 0001
>   _PAGE_READ: 0002
>  _PAGE_WRITE: 0004
>   _PAGE_ACCESSED: 0008
>   _PAGE_MODIFIED: 0010
> _PAGE_GLOBAL: 0020
>  _PAGE_VALID: 0040
>  _PAGE_DIRTY: 0080
This appears to be correct info for my platform.
Thanks
Sagar

>
> --
> Crash-utility mailing list
> Crash-utility@redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Re: [Crash-utility] crash doesn't decode regs with 7.1.5

2016-10-21 Thread Sagar Borikar

Rabin,

New it works fine! Thanks!

Sagar

On Wed, Oct 19, 2016 at 3:36 PM, Rabin Vincent <ra...@rab.in> wrote:
> On Tue, Oct 18, 2016 at 04:10:51PM -0700, Sagar Borikar wrote:
>> I tried these patches but still don't get correct bt output.
>
> I think I see the problem now.  Your EPC is 0 so we hit the if
> (!IS_KVADDR(current.pc)) condition on the first iteration of the
> backtrace loop and exit without trying futher.
>
> Could you please try the following patch?  Please include a log with
> debugging enabled ("set debug 8") if it still doesn't work.  Thanks.
>
> 8<--
> >From 4ae6ab8d181deea53ece847007d27d228166370d Mon Sep 17 00:00:00 2001
> From: Rabin Vincent <rab...@axis.com>
> Date: Thu, 20 Oct 2016 00:19:33 +0200
> Subject: [PATCH] mips: allow one invalid PC at start or after exception
>
> Before:
>
> PID: 2810   TASK: 835e41a8  CPU: 1   COMMAND: "sh"
>  #0 [8315bb00] crash_kexec at 800b26a4
>  #1 [8315bbe0] panic at 800dc0fc
>  #2 [8315bc20] die at 8001fa74
>  #3 [8315bc50] __do_page_fault at 8002de74
>  #4 [8315bd28] ret_from_irq at 80019624
> $ 0   :  0001 8069 
> $ 4   : 0063 812972dc 81297db8 00c2
> $ 8   : 4b38 0001 8068 8062
> $12   : 0104 0002  
> $16   : 80622530 8062 0063 8062
> $20   : 80622470 0001  00b9f322
> $24   : 0003  0044 800dca80
> $28   : 8315a000 8315bde0  80313b30
> Hi: 0046
> Lo: 0f5c2a0e
> epc   : 
> ra: 80313b30 __handle_sysrq+0x144
> Status: 1100fc03
> Cause : 1088
> BadVA : 
>
> After:
>
>  crash> bt
>  PID: 2810   TASK: 835e41a8  CPU: 1   COMMAND: "sh"
>   #0 [8315bb00] crash_kexec at 800b26a4
>   #1 [8315bbe0] panic at 800dc0fc
>   #2 [8315bc20] die at 8001fa74
>   #3 [8315bc50] __do_page_fault at 8002de74
>   #4 [8315bd28] ret_from_irq at 80019624
>  $ 0   :  0001 8069 
>  $ 4   : 0063 812972dc 81297db8 00c2
>  $ 8   : 4b38 0001 8068 8062
>  $12   : 0104 0002  
>  $16   : 80622530 8062 0063 8062
>  $20   : 80622470 0001  00b9f322
>  $24   : 0003  0044 800dca80
>  $28   : 8315a000 8315bde0  80313b30
>  Hi: 0046
>  Lo: 0f5c2a0e
>  epc   : 
>  ra: 80313b30 __handle_sysrq+0x144
>  Status: 1100fc03
>  Cause : 1088
>  BadVA : 
>   #5 [8315bde0] (invalid) at 0
>   #6 [8315bde0] __handle_sysrq at 80313b30
>   #7 [8315be18] write_sysrq_trigger at 80313c24
>   #8 [8315be38] proc_reg_write at 80178074
>   #9 [8315be58] __vfs_write at 8011ea78
>  #10 [8315bec0] vfs_write at 8011fe7c
>  #11 [8315bef0] sys_write at 801201e8
>  #12 [8315bf28] syscall_common at 800275c8
> ---
>  mips.c | 35 +--
>  1 file changed, 25 insertions(+), 10 deletions(-)
>
> diff --git a/mips.c b/mips.c
> index 6cd8d1f..1bb4d27 100644
> --- a/mips.c
> +++ b/mips.c
> @@ -413,7 +413,7 @@ mips_dump_backtrace_entry(struct bt_info *bt, struct 
> syment *sym,
>   struct mips_unwind_frame *current,
>   struct mips_unwind_frame *previous, int level)
>  {
> -   const char *name = sym->name;
> +   const char *name = sym ? sym->name : "(invalid)";
> struct load_module *lm;
> char *name_plus_offset;
> char buf[BUFSIZE];
> @@ -447,7 +447,7 @@ mips_dump_backtrace_entry(struct bt_info *bt, struct 
> syment *sym,
> fprintf(fp, "%s\n", buf);
> }
>
> -   if (mips_is_exception_entry(sym)) {
> +   if (sym && mips_is_exception_entry(sym)) {
> char pt_regs[SIZE(pt_regs)];
>
> GET_STACK_DATA(current->sp, _regs, SIZE(pt_regs));
> @@ -533,6 +533,7 @@ mips_back_trace_cmd(struct bt_info *bt)
>  {
> struct mips_unwind_frame current, previous;
> int level = 0;
> +   int invalid_ok = 1;
>
> if (bt->flags & BT_REGS_NOT_FOUND)
> return;
> @@ -549,22 +550,24 @@ mips_back_trace_cmd(struct bt_info *bt)
> }
>
> while (INSTACK(current.sp, bt)) {
> -   struct syment *symbol;
> +   struct syment *symbol = NULL;
> ulong offset;
>
> if (CRASHDEBUG(8))
> fprintf(fp, "level %d pc %#lx ra %#lx sp %lx\n",
>

Re: [Crash-utility] crash doesn't decode regs with 7.1.5

2016-10-18 Thread Sagar Borikar

Hi Rabin,

I tried these patches but still don't get correct bt output.

Thanks
Sagar

On Mon, Oct 17, 2016 at 2:19 PM, Rabin Vincent <ra...@rab.in> wrote:
> On Thu, Oct 13, 2016 at 01:46:43PM -0700, Sagar Borikar wrote:
>> I am facing issues with crash 7.1.5 for little endian mips CPU. Crash
>> is not able to decode the registers. But except registers all other
>> information is good. I tried to look at the notes section in the core
>> but doesn't seem anything wrong there. If I trace the vmcore with mips
>> gdb I can get the correct stack trace and register info.
>
> Do you have more than one CPU?  And if so, does your dump ELF notes
> section have CORE notes for all CPUs (readelf --notes should give be
> able to give you this info)?  I notice that the note to CPU mapping is
> incorrect for mips if some CPU (other than the last one) didn't save its
> registers.  I've just sent a patch to the list to fix that and some
> other problems with the dump register handling, could you please try
> that out and see if it gives you a backtrace?
>
> --
> Crash-utility mailing list
> Crash-utility@redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Re: [Crash-utility] crash doesn't decode regs with 7.1.5 (32-bit MIPS)

2016-10-13 Thread Sagar Borikar

Thanks a lot Dave. That helps.

Sagar

On Thu, Oct 13, 2016 at 4:03 PM, Dave Anderson  wrote:
>
>
> - Original Message -
>> On Thu, Oct 13, 2016 at 2:05 PM, Dave Anderson  wrote:
>> >
>> >
>> >
>> > - Original Message -
>> >> Hi,
>> >>
>> >> I am facing issues with crash 7.1.5 for little endian mips CPU. Crash
>> >> is not able to decode the registers. But except registers all other
>> >> information is good. I tried to look at the notes section in the core
>> >> but doesn't seem anything wrong there. If I trace the vmcore with mips
>> >> gdb I can get the correct stack trace and register info.
>> >>
>> >> crash> i r
>> >> The program has no registers now.
>> >> gdb: gdb request failed: i r
>> >>
>> >> crash> bt
>> >> PID: 267TASK: 808f66d0  CPU: 0   COMMAND: "sh"
>> >>
>> >
>> > Hi Sagar,
>> >
>> > The "i r" gdb command is not supported by the gdb embedded in the crash
>> > utility because it is invoked as "gdb vmlinux", and therefore it has no
>> > clue about any task or register set in a vmcore.
>>
>> Thanks Dave.
>> I didn't quite get how to poke the registers from crash.  Can you give
>> me example?
>
> If the backtrace ended in an exception, then the register set would be
> dumped as part of the "bt" output at the point where the exception occurred.
>
> There is a "help -r" option for dumping the registers that were saved in
> the dumpfile header, but looking at the sources, I see that support for
> that option for the MIPS architecture was never put in place.
>
> Looking at the mips.c backtrace code, it looks like "bt" would print nothing
> if the sp that it got for the active task from the dumpfile header was 
> invalid.
> If you enter "help -D" to dump the dumpfile header contents, you would 
> normally
> see the stored registers as part of the NT_PRSTATUS dump of each cpu.  But I
> see that that feature is also not done for MIPS.
>
> Lastly, there is a "bt -e" command that searches the stack of the current
> task for exception frames (register dumps), but again, that feature was never
> implemented for MIPS.
>
>>
>> > I don't know why the "bt" command is not working.  MIPS support was wholly
>> > written (and supported) by Rabin Vincent.  I've modified the subject line
>> > to indicate such, as well as cc'ing him directly.
>> >
>> > Dave
>>
>> BTW, I have cross compiled gdb for mips and decoding regs and bt and
>> rest through that. Not sure whether the gdb in crash detect little
>> endian 32 bit mips vmcore.
>
> It is compiled for 32 bit MIPS, but as I mentioned before, when the
> internal embedded gdb module in the crash utility is invoked, it is
> as "gdb vmlinux" (i.e., with no "vmcore" argument).  It is only used
> for accessing the debuginfo data for the kernel source code.  It has
> absolutely no concept of any tasks, register sets, or anything that
> comes from a core file.
>
> Dave
>
>>
>> Thanks
>> Sagar
>>
>>
>>
>>
>> >
>> >>
>> >> For the same vmcore, on gdb:
>> >>
>> >> (gdb) i r
>> >>   zero   at   v0   v1   a0   a1   a2
>> >>   a3
>> >>  R0    004b376a 0002 0001 24b0 000a 
>> >>  0002
>> >> t0   t1   t2   t3   t4   t5   t6
>> >> t7
>> >>  R8   808f1180  0001 77ab8000 7fd53050 004b4580 
>> >>  
>> >> s0   s1   s2   s3   s4   s5   s6
>> >> s7
>> >>  R16  0002 808f0b80 808f1180 fff2 80d97f10 808f0b8c 0030
>> >>  0048
>> >> t8   t9   k0   k1   gp   sp   s8
>> >> ra
>> >>  R24  0002 803b05bc 000a 81005890 80d94000 80d97e18 0020
>> >>  803b05e0
>> >> sr   lo   hi  badcause   pc
>> >>   50808000 1100fc03  0002 803b05e0 
>> >>
>> >>
>> >> (gdb) bt
>> >> #0  0x in ?? ()
>> >> #1  0x803b05e0 in pcieport_sysfs_store (kobj=,
>> >> attr=, data=, len=) at
>> >> /build/sborikar/bodegadev/bodega-dev/mcpu/firmware/linux-4.4/drivers/cisco/pcieport/sysfs.c:59
>> >> #2  0x8021c6bc in kernfs_fop_write (file=,
>> >> user_buf=, count=, ppos=0x80d97f10) at
>> >> /build/sborikar/bodegadev/bodega-dev/mcpu/firmware/linux-4.4/fs/kernfs/file.c:312
>> >> #3  0x801c9020 in __vfs_write (file=0x24b0, p=,
>> >> count=, pos=) at
>> >> /build/sborikar/bodegadev/bodega-dev/mcpu/firmware/linux-4.4/fs/read_write.c:489
>> >> #4  0x801c9eac in vfs_write (file=0x83b187c0, buf=0xa > >> of bounds>, count=, pos=0x80d97f10) at
>> >> /build/sborikar/bodegadev/bodega-dev/mcpu/firmware/linux-4.4/fs/read_write.c:538
>> >> #5  0x801ca0dc in SYSC_write (count=, buf=> >> out>, fd=) at
>> >> /build/sborikar/bodegadev/bodega-dev/mcpu/firmware/linux-4.4/fs/read_write.c:585
>> >> #6  SyS_write (fd=, buf=,
>> >> count=) at
>> >> /build/sborikar/bodegadev/bodega-dev/mcpu/firmware/linux-4.4/fs/read_write.c:578
>> >> #7  0x8010e1dc in

Re: [Crash-utility] crash doesn't decode regs with 7.1.5 (32-bit MIPS)

2016-10-13 Thread Sagar Borikar

On Thu, Oct 13, 2016 at 2:05 PM, Dave Anderson  wrote:
>
>
>
> - Original Message -
>> Hi,
>>
>> I am facing issues with crash 7.1.5 for little endian mips CPU. Crash
>> is not able to decode the registers. But except registers all other
>> information is good. I tried to look at the notes section in the core
>> but doesn't seem anything wrong there. If I trace the vmcore with mips
>> gdb I can get the correct stack trace and register info.
>>
>> crash> i r
>> The program has no registers now.
>> gdb: gdb request failed: i r
>>
>> crash> bt
>> PID: 267TASK: 808f66d0  CPU: 0   COMMAND: "sh"
>>
>
> Hi Sagar,
>
> The "i r" gdb command is not supported by the gdb embedded in the crash
> utility because it is invoked as "gdb vmlinux", and therefore it has no
> clue about any task or register set in a vmcore.

Thanks Dave.
I didn't quite get how to poke the registers from crash.  Can you give
me example?

> I don't know why the "bt" command is not working.  MIPS support was wholly
> written (and supported) by Rabin Vincent.  I've modified the subject line
> to indicate such, as well as cc'ing him directly.
>
> Dave

BTW, I have cross compiled gdb for mips and decoding regs and bt and
rest through that. Not sure whether the gdb in crash detect little
endian 32 bit mips vmcore.

Thanks
Sagar




>
>>
>> For the same vmcore, on gdb:
>>
>> (gdb) i r
>>   zero   at   v0   v1   a0   a1   a2   a3
>>  R0    004b376a 0002 0001 24b0 000a  0002
>> t0   t1   t2   t3   t4   t5   t6   t7
>>  R8   808f1180  0001 77ab8000 7fd53050 004b4580  
>> s0   s1   s2   s3   s4   s5   s6   s7
>>  R16  0002 808f0b80 808f1180 fff2 80d97f10 808f0b8c 0030 0048
>> t8   t9   k0   k1   gp   sp   s8   ra
>>  R24  0002 803b05bc 000a 81005890 80d94000 80d97e18 0020 803b05e0
>> sr   lo   hi  badcause   pc
>>   50808000 1100fc03  0002 803b05e0 
>>
>>
>> (gdb) bt
>> #0  0x in ?? ()
>> #1  0x803b05e0 in pcieport_sysfs_store (kobj=,
>> attr=, data=, len=) at
>> /build/sborikar/bodegadev/bodega-dev/mcpu/firmware/linux-4.4/drivers/cisco/pcieport/sysfs.c:59
>> #2  0x8021c6bc in kernfs_fop_write (file=,
>> user_buf=, count=, ppos=0x80d97f10) at
>> /build/sborikar/bodegadev/bodega-dev/mcpu/firmware/linux-4.4/fs/kernfs/file.c:312
>> #3  0x801c9020 in __vfs_write (file=0x24b0, p=,
>> count=, pos=) at
>> /build/sborikar/bodegadev/bodega-dev/mcpu/firmware/linux-4.4/fs/read_write.c:489
>> #4  0x801c9eac in vfs_write (file=0x83b187c0, buf=0xa > of bounds>, count=, pos=0x80d97f10) at
>> /build/sborikar/bodegadev/bodega-dev/mcpu/firmware/linux-4.4/fs/read_write.c:538
>> #5  0x801ca0dc in SYSC_write (count=, buf=> out>, fd=) at
>> /build/sborikar/bodegadev/bodega-dev/mcpu/firmware/linux-4.4/fs/read_write.c:585
>> #6  SyS_write (fd=, buf=,
>> count=) at
>> /build/sborikar/bodegadev/bodega-dev/mcpu/firmware/linux-4.4/fs/read_write.c:578
>> #7  0x8010e1dc in syscall_common () at
>> /build/sborikar/bodegadev/bodega-dev/mcpu/firmware/linux-4.4/arch/mips/kernel/scall32-o32.S:102
>>
>> Any idea?
>>
>> Thanks
>> Sagar
>>
>> --
>> Crash-utility mailing list
>> Crash-utility@redhat.com
>> https://www.redhat.com/mailman/listinfo/crash-utility
>>
>
> --
> Crash-utility mailing list
> Crash-utility@redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

[Crash-utility] crash doesn't decode regs with 7.1.5

2016-10-13 Thread Sagar Borikar

Hi,

I am facing issues with crash 7.1.5 for little endian mips CPU. Crash
is not able to decode the registers. But except registers all other
information is good. I tried to look at the notes section in the core
but doesn't seem anything wrong there. If I trace the vmcore with mips
gdb I can get the correct stack trace and register info.

crash> i r
The program has no registers now.
gdb: gdb request failed: i r

crash> bt
PID: 267TASK: 808f66d0  CPU: 0   COMMAND: "sh"


For the same vmcore, on gdb:

(gdb) i r
  zero   at   v0   v1   a0   a1   a2   a3
 R0    004b376a 0002 0001 24b0 000a  0002
t0   t1   t2   t3   t4   t5   t6   t7
 R8   808f1180  0001 77ab8000 7fd53050 004b4580  
s0   s1   s2   s3   s4   s5   s6   s7
 R16  0002 808f0b80 808f1180 fff2 80d97f10 808f0b8c 0030 0048
t8   t9   k0   k1   gp   sp   s8   ra
 R24  0002 803b05bc 000a 81005890 80d94000 80d97e18 0020 803b05e0
sr   lo   hi  badcause   pc
  50808000 1100fc03  0002 803b05e0 


(gdb) bt
#0  0x in ?? ()
#1  0x803b05e0 in pcieport_sysfs_store (kobj=,
attr=, data=, len=) at
/build/sborikar/bodegadev/bodega-dev/mcpu/firmware/linux-4.4/drivers/cisco/pcieport/sysfs.c:59
#2  0x8021c6bc in kernfs_fop_write (file=,
user_buf=, count=, ppos=0x80d97f10) at
/build/sborikar/bodegadev/bodega-dev/mcpu/firmware/linux-4.4/fs/kernfs/file.c:312
#3  0x801c9020 in __vfs_write (file=0x24b0, p=,
count=, pos=) at
/build/sborikar/bodegadev/bodega-dev/mcpu/firmware/linux-4.4/fs/read_write.c:489
#4  0x801c9eac in vfs_write (file=0x83b187c0, buf=0xa , count=, pos=0x80d97f10) at
/build/sborikar/bodegadev/bodega-dev/mcpu/firmware/linux-4.4/fs/read_write.c:538
#5  0x801ca0dc in SYSC_write (count=, buf=, fd=) at
/build/sborikar/bodegadev/bodega-dev/mcpu/firmware/linux-4.4/fs/read_write.c:585
#6  SyS_write (fd=, buf=,
count=) at
/build/sborikar/bodegadev/bodega-dev/mcpu/firmware/linux-4.4/fs/read_write.c:578
#7  0x8010e1dc in syscall_common () at
/build/sborikar/bodegadev/bodega-dev/mcpu/firmware/linux-4.4/arch/mips/kernel/scall32-o32.S:102

Any idea?

Thanks
Sagar

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Re: [Crash-utility] kernel module parsing failure - mips

Re: [Crash-utility] kernel module parsing failure - mips

Re: [Crash-utility] kernel module parsing failure - mips

Re: [Crash-utility] crash doesn't decode regs with 7.1.5

Re: [Crash-utility] crash doesn't decode regs with 7.1.5

Re: [Crash-utility] crash doesn't decode regs with 7.1.5 (32-bit MIPS)

Re: [Crash-utility] crash doesn't decode regs with 7.1.5 (32-bit MIPS)

[Crash-utility] crash doesn't decode regs with 7.1.5

8 matches

Site Navigation

Mail list logo

Footer information