On Fri, Nov 23, 2018 at 02:59:32PM +0500, mbilal wrote: > Hi, > > Thanks for reply. > > According to your suggestion I've tested with 3.1 rc2 release and problem is > still exist in this release also. > > Here is my reproducible scenario.
Thanks, I've had a look and the assert looks bogus to me. We shouldn't be asserting on RX descriptor setups when the receiver is disabled. I'll send a patch in a moment. Best regards, Edgar > > QEMU launching > -------------- > > ./qemu-system-aarch64 -M xlnx-zcu102 -m 1G -kernel /dev/null -S -s -net nic > -net nic -net nic -net nic -net user,hostfwd=tcp::8080-:8080 -smp 1 -serial > stdio -serial /dev/null > > gdb session > ------------ > > (gdb) file zcu102_net_uni.out > Reading symbols from zcu102_net_uni.out...done. > (gdb) tar rem :1234 > Remote debugging using :1234 > _ld_text_start () at os/arch/armv8/common/arch_asm.S:381 > 381 MOV X14, X0 > (gdb) load > Loading section .text, size 0x59c0c lma 0x0 > Loading section .rodata, size 0x2bbc lma 0x59c0c > Loading section .rtl.data, size 0x770 lma 0x5c7c8 > Loading section .data, size 0x4dc lma 0x5cf54 > Start address 0x0, load size 381972 > Transfer rate: 23313 KB/sec, 2021 bytes/write. > (gdb) c > Continuing. > ^C > > > So any breakpoint or Ctrl-C asserts the QEMU. > > qemu-system-aarch64: qemu-3.1.0-rc2/hw/net/cadence_gem.c:982: gem_receive: > Assertion `!first_desc' failed. > > > Our networking demo application running fine unless you interrupt the GDB > (either with breakpoints or interrupt signal). > You can see following message on QEMU console which is the indication of > demo is fine (it also well tested on actual hardware) > > Open the following Nucleus node address in your web browser: > http://127.0.0.1:8080/ > > > I'm attaching demo application binary. > > > > > Thanks for care about this issue, > -Bilal > > > > On 11/23/2018 01:59 PM, Peter Maydell wrote: > > On 23 November 2018 at 04:13, mbilal <muhammad_bi...@mentor.com> wrote: > > > Hi, > > > > > > I'm using qemu emulation for xilinx zcu102 platform, this board have four > > > networking GEM0, GEM1, GEM2 and GEM3 devices. > > > > > > To run network demo on this board *only* require GEM3 device to be > > > configure > > > while other GEM devices don't need to be configure, that's why u-boot and > > > other RTOS only configure GEM3 device. > > > > > > > > > QEMU is enabling these GEM devices with networking '-net nic' option and > > > QEMU consider first '-net nic' option for GEM0 and second '-net nic' > > > option > > > for GEM1 and so on. that's why if need to enable GEM3 network device we > > > must > > > need to give following full command line options > > > > > > -net nic -net nic -net nic -net nic -net user, ... > > > > > > In this way all four GEM devices would be enable but first three GEM0-GEM2 > > > devices are un-configured and useless. In our case QEMU is being *crashed* > > > due to trying to use these un-configured GEM devices to o send/receive GDB > > > breakoint/interrupt cause. IIUC QEMU uses first device in the -nic loop > > > i.e > > > > > > qemu-system-aarch64: hw/net/cadence_gem.c:921: gem_receive: Assertion > > > `!first_desc' failed. > > > > If QEMU asserts like this, this is a bug in QEMU. I've cc'd > > the maintainers of the Xilinx board. > > > > Could you provide a complete set of instructions to reproduce > > this bug, please ? (full command line, guest image, etc) > > > > Could you also tell us which version of QEMU you are using? > > If possible, try with the current git master or > > with the 3.1 rc2 release candidate we've just put out, to > > see if it's already been fixed. > > > > thanks > > -- PMM > >
