![]() ![]() rcu: Preemptible hierarchical RCU implementation. SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) ![]() Dentry cache hash table entries: 65536 (order: 7, 524288 bytes) Kernel command line: console=ttyS2,115200n8 root=PARTUUID=987fd2b2-02 rw rootfstype=ext4 rootwait Built 1 zonelists, mobility grouping on. random: get_random_bytes called from start_kernel+0xb0/0x488 with crng_init=0 OMAP4: Map 0x00000000ffd00000 to (ptrval) for dram barrier Reserved memory: created CMA memory pool at 0x000000009f000000, size 8 MiB Reserved memory: created DMA memory pool at 0x000000009d000000, size 32 MiB Reserved memory: created CMA memory pool at 0x0000000099000000, size 64 MiB OF: reserved mem: initialized node compatible id shared-dma-pool Reserved memory: created CMA memory pool at 0x0000000095800000, size 56 MiB CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache CPU: div instructions available: patching division code CPU: ARMv7 Processor revision 2 (ARMv7), cr=30c5387d Loading Device Tree to 8ffe6000, end 8ffffb7e. *** Warning - bad CRC, using default environmentĪm57x_idk_lcd_detect: Failed to get I2C device 0/56 (ret 1)Ĥ370944 bytes read in 196 ms (21.3 MiB/s) ![]() (emac_rx_packet ) from (emac_rx_thread+0x1bc/0x2cc ) ![]() I would like to highlight part of this crash messages, specially: Both interfaces are connected to our Vault that is causing the issue. I was power cycling the IDK with is console active and the eth2 and eth3 interfaces configured in DHCP. In fact in the last 15 days we have only seen the issue in a very few occasions, so it is difficult to interact with it.Īnyway I want you to inform that we have seen in the IDK a crash that may be similar to the Bridge´s. The thing is that is is very difficult to reproduce the issue. It hasn´t failed yet but I will continue with the test I have made a few tests but with interfaces eth1 and eth2 in PRP mode asit means that there is a different PRU firmware than in dual-independent mode. I tried to workaround this situation to avoid the driver crashing and see in this situation that even reloading the PRU firmware (ifconfig ethx down/up) the issue persists, as if the prueth driver would be unable to recover. I have detected that sometimes the BD pointer "bd_rd_ptr" that point to BD shared memory has a wrong value so it can make the driver crash. I know that there is a shared memory between A15 prueth.c driver and PRU firmware for buffer descriptors, and that there is s shared memory in OCMC where the incoming frames are placed by PRU firmware for A15 prueth driver to take them out in a FIFO way. So I decided to put some printks in A15 "prueth.c" driver in the reception function "emac_rx_packet()" (see attached "prueth.c"). Interfaces eth1 and eth2 are configured to accept GOOSE messages (interfaces in allmulticast mode) as GOOSE messages are circulating around the local network.Īfter some time I have detected something strange in reception, as if it gets corrupted. I boot up the system over NFS with TI Linux over eth0. I have connected eth1 and eth2 to our local network where we have some traffic (see attached "crash_trafico_vault_killer.pcapng"). ![]()
0 Comments
Leave a Reply. |