• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 99 subscribers
  • Views 553 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Emergent! What happen to 8168? Thanks!

Strachey
Intellectual 920 points

Hi,

        I am using RDK4.0 and 8168 run for 4 hours later, it print the log show bellow.

       Could you tell me what happen to 8168?

Thanks!

Best regards!

[16250.790000] Unable to handle kernel paging request at virtual address 0a5d7825
[16250.800000] pgd = ce758000
[16250.800000] [0a5d7825] *pgd=00000000
[16250.810000] Internal error: Oops: 5 [#1]
[16250.810000] last sysfs file: /sys/devices/virtual/misc/vp1dir/uevent
[16250.810000] Modules linked in: vtfpga vpdir ti81xxhdmi ti81xxfb vpss osa_kermod syslink
[16250.810000] CPU: 0    Not tainted  (2.6.37+ #1)
[16250.810000] PC is at GateMP_enter+0x40/0x74 [syslink]
[16250.810000] LR is at GateMP_enter+0x28/0x74 [syslink]
[16250.810000] pc : [<bf02cc74>]    lr : [<bf02cc5c>]    psr: 00000013
[16250.810000] sp : cdacfe60  ip : 00000000  fp : cdacfe74
[16250.810000] r10: 00000000  r9 : cdace000  r8 : 00000000
[16250.810000] r7 : 003f7d40  r6 : bf0ae324  r5 : bf0ae324  r4 : bf0ae324
[16250.810000] r3 : 0a5d7824  r2 : bf06cac1  r1 : cd46cd76  r0 : 0a5d7825
[16250.810000] Flags: nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[16250.810000] Control: 10c5387d  Table: 8e758019  DAC: 00000015
[16250.810000] Process hdcard20_app.ou (pid: 610, stack limit = 0xcdace2e8)
[16250.810000] Stack: (0xcdacfe60 to 0xcdad0000)
[16250.810000] fe60: d3d9d000 d53f7d40 cdacfea4 cdacfe78 bf0284c8 bf02cc40 d53f7d40 d53f7d40
[16250.810000] fe80: 5575cac4 cdace000 bf0ae324 00000011 00000000 00000000 cdacfefc cdacfea8
[16250.810000] fea0: bf04db50 bf028480 c01cf35d 5575cac4 d3d9d000 003f7d40 0019190c 00000000
[16250.810000] fec0: 00055918 000e3e48 406b2d40 bf01b99c c010f933 5575cac8 48661080 00040000
[16250.810000] fee0: cdace000 ce1a7780 00000011 5575cac4 cdacff74 cdacff00 c00d5e48 bf04d834
[16250.810000] ff00: ce724e00 00000000 00000000 00000000 0000fd04 0000fd04 ce73df88 00000001
[16250.810000] ff20: cd2d26a0 00000000 cdace000 00000000 cdacff6c cdacff40 c00c88e0 c00f35dc
[16250.810000] ff40: 00000000 ce73df80 0000fd04 ce73dd80 cd9b5d80 5575cac4 c01cf35d 00000011
[16250.810000] ff60: 00000000 cdace000 cdacffa4 cdacff78 c00d5f14 c00d5984 00000008 00000001
[16250.810000] ff80: 00000000 5575cac4 0019190c c01cf35d 00000036 c0049568 00000000 cdacffa8
[16250.810000] ffa0: c00493c0 c00d5ec8 5575cac4 0019190c 00000011 c01cf35d 5575cac4 00000001
[16250.810000] ffc0: 5575cac4 0019190c c01cf35d 00000036 00000000 5575cc6c 5575cc68 00972520
[16250.810000] ffe0: 001918e8 5575ca98 00060a60 4024e1cc 20000010 00000011 8f25e13d 79c7642c
[16250.810000] Backtrace:
[16250.810000] [<bf02cc34>] (GateMP_enter+0x0/0x74 [syslink]) from [<bf0284c8>] (ListMP_putTail+0x54/0x170 [syslink])
[16250.810000]  r5:d53f7d40 r4:d3d9d000
[16250.810000] [<bf028474>] (ListMP_putTail+0x0/0x170 [syslink]) from [<bf04db50>] (ListMPDrv_ioctl+0x328/0x5a4 [syslink])
[16250.810000] [<bf04d828>] (ListMPDrv_ioctl+0x0/0x5a4 [syslink]) from [<c00d5e48>] (do_vfs_ioctl+0x4d0/0x544)
[16250.810000]  r6:5575cac4 r5:00000011 r4:ce1a7780
[16250.810000] [<c00d5978>] (do_vfs_ioctl+0x0/0x544) from [<c00d5f14>] (sys_ioctl+0x58/0x7c)
[16250.810000]  r9:cdace000 r8:00000000 r7:00000011 r6:c01cf35d r5:5575cac4
[16250.810000] r4:cd9b5d80
[16250.810000] [<c00d5ebc>] (sys_ioctl+0x0/0x7c) from [<c00493c0>] (ret_fast_syscall+0x0/0x30)
[16250.810000]  r8:c0049568 r7:00000036 r6:c01cf35d r5:0019190c r4:5575cac4
[16250.810000] Code: e2403001 e3730003 83a04000 8a000002 (e5903000)
[16251.090000] ---[ end trace 8027d7ee40f49d9e ]---

  • 0
    TI__Guru 59700 points

    The log indicates a GateMP instance handle in syslink kernel module is corrupted resulting in kernel panic. Memory corruption could be due to a number of h/w or s/w reasons.

    To rule out h/w issues pls check the recommendations in the following post: http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/p/250529/878774.aspx#878774

    Additionally mention the silicon version you are using. Also do you see any VIP overflow logs happening before the crash occurs ?

    Another important item to check is the junction temperature of the 816x chip. Tj should not exceed the limits mentioned in the data sheet for your 816x device. You have to ensure you have proper cooling using fan

    For s/w issues :

    1. Do you see this issue when you send some control cmd or is the issue happening during normal playback.Pls share the remote_debug_client log when the issue happens.

    2. Do you see the issue with 2G memory map configuration in RDK 4.0 release. The memory map for 2GB is significantly different and if it random memory corruption you should see difference in behaviour.

  • 0 in reply to Badri Narayanan
    Intellectual 920 points

    Hi Badri,

        Thank you!

        I will check it out as you said.

        By the way, if I use 2G memory map configuration in RDK4.0, where to find env_2048M_512M ?

    Thanks!

    Best regards!

     

  • 0 in reply to Strachey
    TI__Guru 59700 points

    The file is generated when you build a 2G build. Refer the RDK 4.0 documentation for details on how to build a 2G build.

  • 0 in reply to Badri Narayanan
    Intellectual 925 points

    Hi Badri Narayanan,

        " Also do you see any VIP overflow logs happening before the crash occurs ?"

        Is there any relationship between VIP overflow and this kind of issue ?

    Thanks 

  • 0 in reply to Zhua Bob
    TI__Guru 59700 points

    If using PG1.1 silicon a VIP overflow can result in DDR memory corruption as VIP may write wrong width/height frame (beyond allocated capture frame size) to DDR  resulting in random crashes.

  • 0 in reply to Badri Narayanan
    Intellectual 925 points

    we once found that a Overflow was still dectected on VIP1 when both VIP0 and VIP1 was stop.

    Is that mean the VIP hardware is still captureing frames after we stop VIP0 and VIP1.?

    we meet serveral vpssM3 or videoM3 crashes issue, maybe is the result of DDR  memory corruption...But we are not sure if the vip would write data to wrong DDR address.

    By the way ,we are using PG2.0 silicon

  • 0 in reply to Zhua Bob
    TI__Guru**** 475955 points

    Hi zhuohua,

     

    Could you tell which DVR-RDK release you are using? If you are using 3.5 release, there should not be any overflow after VIP is stopped and there should be any memory corruption since there is fix for this issue on ES2.0.

     

    Regards,

    Brijesh