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 Dave Anderson 


- 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 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
> >>

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

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

2016-10-13 Thread Dave Anderson 



- 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.  

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


> 
> 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