Re: Error building libbsd

[Christian Mauderer]

Hello Niko,

thanks for the feedback. Still sounds odd. Especially because it seems
that the error happens before the wscript is called for build (otherwise
you should have seen a message with the additional patch). So it has to
be something in one of the generated cache files (either in build or the
.lock-waf... file).

I can't reproduce the problem so I don't think that we can find it
easily. The only possibility would be that you start digging into the
files with the python debugger pdb. But I assume that you are not that
curious about the problem? So if you have a setup you can work with, I
would suggest to use that.

Best regards

Christian Mauderer

Am 28.06.2018 um 14:10 schrieb Nicolas Tsiogkas:
> Hi,
> 
> some later report. I compiled the examples and some private project with
> waf and all was smoothly. I suspect that there must be something with
> the libbsd scripts.
> 
> Cheers,
> Niko
> 
> On Mon, Jun 25, 2018 at 10:20 AM Nicolas Tsiogkas  > wrote:
> 
> Hi Christian,
> 
> I will go with python3 indeed as I have to finally close a patch for
> Ethercat SOEM working with RTEMS 5. In parallel I will try to
> investigate with the waf examples and report back.
> 
> Thanks for the prompt reply and effort. :)
> 
> Regards,
> Niko
> 
> On Mon, Jun 25, 2018 at 10:15 AM Christian Mauderer
>  > wrote:
> 
> Hello Niko,
> 
> if the patch didn't do anything to your output, the error has to
> happen
> quite early. The first one should have been printed when the build()
> function of the wscript has been reached. So I would assume that it
> already happens before that.
> 
> If you have time and desire to find the bug, you might could try to
> build some other tools that use waf as a build system (for
> example the
> waf examples from the waf website). Otherwise I would suggest to
> go with
> python3 for now.
> 
> Note that it shouldn't really be a problem with python2 in
> general: My
> OpenSUSE machine is using python2 too and has no problems with the
> current libbsd. As far as I know most distributions still use
> python2 as
> the default case. I only know Arch Linux that does use python3.
> 
> Best regards
> 
> Christian Mauderer
> 
> Am 25.06.2018 um 10:08 schrieb Nicolas Tsiogkas:
> > Hi,
> >
> > sorry for the late reply.
> >
> > So, the patch didn't do a thing. Got the same print.
> >
> > But I tried to run waf with python3
> >
> > python3 /home/niko/.local/bin/waf-2.0.8
> >
> > and
> >
> > python3 /home/niko/.local/bin/waf-2.0.8 install
> >
> > That was successful. From that I can assume that there is some
> issue
> > with the python2 shipped with ubuntu? I can try at home as
> well in case
> > there is something specific with the python configuration on
> my current
> > pc and report back.
> >
> > Thanks for the help.
> >
> > Regards,
> > Niko
> >
> > On Fri, Jun 22, 2018 at 9:56 PM Christian Mauderer
> mailto:l...@c-mauderer.de>
> > >> wrote:
> >
> >     Hello Niko,
> >
> >     Am 22.06.2018 um 13:23 schrieb Nicolas Tsiogkas:
> >     > Hi,
> >     >
> >     > waf was downloaded by the website (waf.io
>  
> >     )
> >     >
> >     > niko@im-desktop-021:~/sandbox/rtems-libbsd$ which waf-2.0.8 
> >     > /home/niko/.local/bin/waf-2.0.8
> >
> >     Should be OK.
> >
> >     >
> >     > running also with waf-2.0.4 which used to work gives the
> same error
> >     >
> >     > ~/sandbox/rtems-libbsd$ waf-2.0.8 -v
> >     > Could not create the directory ///h
> >     >
> >     > ~/sandbox/rtems-libbsd$ waf-2.0.4 -v
> >     > Could not create the directory ///h
> >     >
> >     > that's pretty weird.
> >
> >     Yes it is. The build scripts do a lot of stuff in
> preparation for the
> >     real build. But as far as I know nothing of it should create a
> >     directory. The first operation that creates a directory
> should print the
> >     following line:
> >
> >     [ 1/99] Compiling
> >     testsuite/include/rtems/bsd/test/network-config.h.in
> 
> >     
> >
> >     Anyway: To find out how far you get into the build
>

Re: rtems-libbsd bpf BIOCSRTIMEOUT behaviour

[Nicolas Tsiogkas]

Thanks!

Shouldn't net have some device though since I want to debug the networking
stack?

For now I run it with -nographic -serial stdio -serial
mon:tcp:localhost:12456 -M xilinx-zynq-a9 -net
nic,model=cadence_gem,macaddr=0e:b0:ba:5e:ba:11 -net
tap,ifname=tap0,script=no,downscript=no -m 256M -kernel slaveinfo.exe

I'll check soon and report back. Thanks again!

Cheers,
Niko

On Fri, Jun 29, 2018 at 9:32 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 29/06/18 09:14, Nicolas Tsiogkas wrote:
> > I see thanks.
> >
> > Any idea or documentation on how to do that on qemu? I'm afraid that
> > my experience is rather limited.
> >
> > I'm running on qemu 2.10 using the xilinx_zynq_a9_qemu bsp.
>
> You can run the xilinx_zynq_a9_qemu with
>
> QEMU_AUDIO_DRV=none qemu-system-arm  -serial null -serial mon:stdio -net
> none  -nographic -M xilinx-zynq-a9 -m 256M  -kernel app.exe -s -S
>
> It waits for a GDB client connection on localhost:1234.
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: rtems-libbsd bpf BIOCSRTIMEOUT behaviour

[Sebastian Huber]

On 29/06/18 09:14, Nicolas Tsiogkas wrote:

I see thanks.

Any idea or documentation on how to do that on qemu? I'm afraid that 
my experience is rather limited.


I'm running on qemu 2.10 using the xilinx_zynq_a9_qemu bsp.


You can run the xilinx_zynq_a9_qemu with

QEMU_AUDIO_DRV=none qemu-system-arm  -serial null -serial mon:stdio -net 
none  -nographic -M xilinx-zynq-a9 -m 256M  -kernel app.exe -s -S


It waits for a GDB client connection on localhost:1234.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: rtems-libbsd bpf BIOCSRTIMEOUT behaviour

[Nicolas Tsiogkas]

I see thanks.

Any idea or documentation on how to do that on qemu? I'm afraid that my
experience is rather limited.

I'm running on qemu 2.10 using the xilinx_zynq_a9_qemu bsp.

Thank you for your time.

Kind regards,
Niko

On Fri, Jun 29, 2018 at 7:01 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 28/06/18 14:09, Nicolas Tsiogkas wrote:
> > Hi,
> >
> > I have observed a weird behaviour while setting the BIOCSRTIMEOUT for
> > a bpf.
> >
> > When setting it to low values (less than a second) as it can be seen
> > below the bpf is actually blocking instead of waiting and continuing.
> >
> > struct timeval timeout;
> > timeout.tv_sec =  0;
> > timeout.tv_usec = 1;
> > if (ioctl(*bpf, BIOCSRTIMEOUT, &timeout) == -1) {
> > perror("BIOCSRTIMEOUT");
> >   return 0;
> > }
> >
> > This was working with the libbsd 4.11 branch. Is this a known bug?
>
> No, we use the bpf with libpcap on the master. You have to debug this.
>
> >
> > In addition the bpf is not receiving/reading anything incoming while
> > with wireshark I can confirm that there are things on the wire and the
> > bpf is in promiscuous mode. Still this was working on the 4.11 branch.
> > Any idea on how to debug this?
>
> I would set a break point to the network interface receive function and
> then follow the path of the Ethernet frame.
>
> >
> > Thanks in advance.
> >
> > Cheers,
> > Niko
> >
> >
> > ___
> > users mailing list
> > users@rtems.org
> > http://lists.rtems.org/mailman/listinfo/users
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users