Hi Maxim, I just tested it again and I am seeing the same behaviour I explained in the mail above. In Master branch odp_classifier and odp_generator fails and both are working on api-next branch. This behaviour was seen by Stuart as well.
Regards, Bala On 11 December 2015 at 01:41, Maxim Uvarov <maxim.uva...@linaro.org> wrote: > That patches introduce segfault. Pktio is socket_mmap: > > 8cf523f api: classification: add odp_cls_cos_pool_set() api > 8da0ee0 example: classifier: add odp_cls_cos_pool_set() api > 4ade6a3 validation: classification: add odp_cls_cos_pool_set() api > e695969 linux-generic: classification: implements odp_cls_cos_pool_set() api > > Maxim. > > > On 12/10/2015 23:04, Maxim Uvarov wrote: >> >> Bala, >> >> I have opposite result. After you patch master never fails. api-next fails >> and my merge master to api-next also fails. >> So it looks like we have something in api-next that breaks the work. >> >> >> queue1 |queue2 |queue3 |DefaultCos |Total Packets >> queue pool |queue pool |queue pool |queue pool | >> 437867 437867|131602 131602|653612 653612|59811 59811 |1282892 >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to Thread 0x7ffff4a91700 (LWP 3363)] >> 0x000000000042652a in _odp_packet_cls_enq (pktio_entry=0x2aaaab600040, >> base=0x7ffff5307042 "33", buf_len=107, pkt_ret=0x7ffff4a90c40) at >> pktio/pktio_common.c:29 >> 29 pool = cos->s.pool->s.pool_hdl; >> (gdb) bt >> #0 0x000000000042652a in _odp_packet_cls_enq (pktio_entry=0x2aaaab600040, >> base=0x7ffff5307042 "33", buf_len=107, pkt_ret=0x7ffff4a90c40) at >> pktio/pktio_common.c:29 >> #1 0x0000000000410a88 in pkt_mmap_v2_rx (pktio_entry=0x2aaaab600040, >> pkt_sock=0x2aaaab600080, pkt_table=0x7ffff4a90c40, len=8, >> if_mac=0x2aaaab6001a4 "") at pktio/socket_mmap.c:152 >> #2 0x00000000004118b3 in sock_mmap_recv (pktio_entry=0x2aaaab600040, >> pkt_table=0x7ffff4a90c40, len=8) at pktio/socket_mmap.c:519 >> #3 0x000000000040cee1 in odp_pktio_recv (id=0x1, >> pkt_table=0x7ffff4a90c40, len=8) at odp_packet_io.c:397 >> #4 0x000000000040d843 in pktin_poll (entry=0x2aaaab600040) at >> odp_packet_io.c:667 >> #5 0x0000000000417a0f in schedule (out_queue=0x7ffff4a90e10, >> out_ev=0x7ffff4a90dd8, max_num=1, max_deq=4) at odp_schedule.c:496 >> #6 0x0000000000417d90 in schedule_loop (out_queue=0x7ffff4a90e10, >> wait=18446744073709551615, out_ev=0x7ffff4a90dd8, max_num=1, max_deq=4) at >> odp_schedule.c:594 >> #7 0x0000000000417e67 in odp_schedule (out_queue=0x7ffff4a90e10, >> wait=18446744073709551615) at odp_schedule.c:626 >> #8 0x000000000040321f in pktio_receive_thread (arg=0x7ffff7ff4000) at >> odp_classifier.c:304 >> #9 0x000000000042900b in odp_run_start_routine (arg=0x6954e0) at >> linux.c:36 >> #10 0x00007ffff73a3182 in start_thread (arg=0x7ffff4a91700) at >> pthread_create.c:312 >> #11 0x00007ffff70d047d in clone () at >> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 >> (gdb) p cos >> $1 = (cos_t *) 0x0 >> (gdb) >> >> >> On 12/10/2015 18:12, Bala Manoharan wrote: >>> >>> odp_classifier runs on api-next branch but if we run on master it >>> currently crashes during queue_enq function. >>> I remember the crash was similar to the one we had during queue >>> reorder implementation. >>> >>> Regards, >>> Bala >>> >>> On 10 December 2015 at 20:38, Stuart Haslam <stuart.has...@linaro.org> >>> wrote: >>>> >>>> On Thu, Dec 10, 2015 at 06:01:05PM +0300, Maxim Uvarov wrote: >>>>> >>>>> How to reproduce that it is broken? >>>>> >>>> I was looking at: >>>> >>>> sudo ODP_PLATFORM=linux-generic ./test/performance/odp_l2fwd_run >>>> >>>> This shows a few packets going through initially then 0. Turns out this >>>> is related to the netmap pktio, this works: >>>> >>>> sudo ODP_PKTIO_DISABLE_NETMAP=y ODP_PLATFORM=linux-generic >>>> ./test/performance/odp_l2fwd_run >>>> >>>> Not sure if this is the same failure Bala was seeing. >>>> >>>> -- >>>> Stuart. >>> >>> >>> >> > -- Regards, Bala _______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
