OpenQNX :: The QNX Community Portal

I have no failed modules on compiling, since I wrote stubs(not
implementation) for getdomainname(), setdomainname() which is required, but
I can't get it running.
Version that available from site won't run on XFree on my box.
And one more question - How did you get shared libraries (libgtk,libglib) on
QNX??

Sergey

Hello,

I have a question about the project openqnx, so I'm sending you guys this
mail. I hope you don't mind...

I'm starting with QNX, and as my basic requirements, I need a SSH client in
my installation. I downloaded the OpenSSH binary tar.gz from the openqnx
project, but I don't know exactly what to do with it. Should I just
untar(gz) it in my root filesystem? Should I run something after unpacking
it? Or should I use the QNX Software Installer or the like?

Thanks a lot!

Filipe

You should post your question to the openqnx mailing list instead
of us individually:
http://lists.sourceforge.net/lists/listinfo/openqnx-developer

almost all packages on openqnx project site are in tar format, which
means you can simply:
su
cd -
tar zxvf file.tar.gz

Hi Franck,

I'm completely lost in xfree, I have the impression that every release figure
out a new design with different files in different locations.
I tried to start xearth yesterday, I could see the display with a lower color
depth (maybe 4), I don't know why because options are the same as my xfree336
config and xdpyinfo says that the x server depth is 16, same as my xfree336
also.
Today, xearth runs without any error but I get no display ?!?, I don't know
where to find the relevant infos to discover why xearth doesn't display anything
or where does it display something.

any idea?
Thanks,
Alain.






Frank Liu <liug=wJsaexb6DEQ3G7qi5jAxu4dd74u8MsAO@public.gmane.org> le 04/06/2003 19:32:41

Pour : openqnx-developer=5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
cc : (ccc : Alain BONNEFOY/Valence)

Objet : Re: [Openqnx-developer] extension "RENDER" missing





VNC's X server is quite old and lacks some of the newer
X extensions such as the Xrender. If you run XFree on
the console directly (which is most of us doing), you
will get a full X server and won't have those warnings.

"any" x application is probably a big statement
you will only get this warning if the x application uses
those newer extensions. "xcalc", for example, doesn't
use xrender feature, while "xclock" does.

With more and more X applications starting to take
advantage of those newer X protocol extensions, you will
probably see more of those warnings in VNC X server.

btw, "xdpyinfo -ext all" should show you which extensions
are supported, which are not, for your X server.
try it on a true X server and within VNC's X server,
or on a MS Windows x server (Exceed or ReflectionX),
you will see the differences...

Frank

On Wed, 4 Jun 2003 alain.bonnefoy=uWxFhhn2E0U@public.gmane.org wrote:

Hi,
Any x application display that message on installation xfree-4.3.1.
I saw on the web that lot of people complain about that message, Isaw that
could
be about graphic card capabilities, fonts, etc...
I use X11 through xvnc3.3.7 I never saw that message on my previous
installation
qnx 6.1, xfree 4.2 xvnc 3.3.3.

Any idea?

thanks,






-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
_______________________________________________
openqnx-developer mailing list
openqnx-developer=5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/openqnx-developer




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
_______________________________________________
openqnx-developer mailing list
openqnx-developer=5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/openqnx-developer

-----Original Message-----
From: openqnx-developer-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
[mailto:openqnx-developer-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On
Behalf Of Prajith
Sent: Tuesday, October 05, 2004 8:57 AM
To: Frank Liu
Cc: OpenQNX
Subject: Re: [Openqnx-developer] Getting an error display,
vp_freepkt: Bad file descriptor.

Hi all.

Our Bandwidth Manager is showing around 20 times the error message
"vp_freepkt: Bad file descriptor." while transfering a 5MB
file at a bandwidth regulation of 1Mbits/sec, irespective of
the available no.of file descripters/process.(even I have
tied with Proc32 -f 16 10240 20480, then too I got around 20
error messages.).

We have implemented a queueing discipline (CBQ) in the
application space, where we are getting network packets using
the VPI (Virtual Packet
Interface) as a IP FILTER. These queueing disciplines keeps
the netwoks packets for a while and send them back in a
random order(not in the sequeuece in which packets are
received). Will this make any problem in VPI (keeping packets
for a while in memory and send them back in a random order)?
Or is there any way to configure the Virtual Packet Interface?

Please give us some solution/suggestion/comments.

Thanks in advance
Jith.


----- Original Message -----
From: Frank Liu <gfrankliu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
To: Prajith <prajith-U1VcRrJwn5T8CqgTAz400NBPR1lH4CV8@public.gmane.org
Sent: Friday, October 01, 2004 10:54 PM
Subject: Re: [Openqnx-developer] Getting an error display,
vp_freepkt: Bad file descriptor.


Maybe you ran out of file descriptors, and possibly other resources.
Try to increase that (make a new boot image).

Frank


----- Original Message -----
From: Prajith <prajith-U1VcRrJwn5T8CqgTAz400NBPR1lH4CV8@public.gmane.org
Date: Fri, 1 Oct 2004 20:54:55 +0530
Subject: [Openqnx-developer] Getting an error display, vp_freepkt:
Bad file descriptor.
To: openqnx-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org


Hello all,

We have developed a bandwidth regulating software in
QNX4.25(In application space). We are getting the network
packets into the application space using the Virtual Packet
Interface(VPI) and regulating them and send it back using the
same VPI.

It's working fine with moderate network traffic. But in the
case of heavy traffic, it's working but displays the
following error message continuously.

vp_freepkt: Bad file descriptor.

If anybody have any idea about this, please let me know.

Thanks in advance
Jith.
«·´`·.(*·.¸(`·.¸ ¸.·´)¸.·*).·´`·»
«..........Prajith P.K..............»
«·´`·.(¸.·*(¸.·´ `·.¸)*·.¸).·´`·»
GlobalEdge Software Ltd.
Bangalore 560003
Cell : 9886171652




-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on
ITManagersJournal Use IT products in your business? Tell us
what you think of them. Give us Your Opinions, Get Free
ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
openqnx-developer mailing list
openqnx-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/openqnx-developer

-----Original Message-----
From: Prajith [mailto:prajith-U1VcRrJwn5T8CqgTAz400NBPR1lH4CV8@public.gmane.org]
Subject: Re: [Openqnx-developer] Getting an error display,
vp_freepkt: Bad file descriptor.

And I am not doing any fork() in my code.

I am creating a thread in our code and using VPI library
functions across the thread. ( I found, none of the VPI
library functions are thread safe. Will this be the problem?)

Hm...

This is QNX4 right? So a "thread" is basically another vfork()
isn't it? (the new "thread" is just another process).

Do you really HAVE TO create a "thread"? Can you make
it so that you only use one thread using VPI functions?
Something like:

int main() {
crate_new_thread();
vp_attach();
...
}

Make sure attach to VPI *AFTER* create thread, and the
new thread never call VPI function?

But I feel, once when I was doing a stress test on VPI
using a program (without thread), I got he same error
(vp_freepkt: Bad file descriptor.) If I get that program
I will let u all know.

That is also an interesting test to prove/denial our guess.

BTW, what is this vp_freepkt() function? Can I get any
implementation document of the VPI?

I don't think there is an "implementation document" ever
publiced, but let me explain the basic ideas behind VPI.


1) The stack (Tcpip) allocate all it's buffers/clusters from a
shared memory pool.

2) A VPI program will find out the pool, and map it into
local virtual space.

3) The Tcpip Stack and the VPI program have "queues"
in shared memroy, so they can exchange mbufs.
VPI program use vp_getpkt()/vp_putpkt() to get/put
mbufs on the queues.

4) The memory pool can only be operated by Tcpip.

So if a VPI program calling vp_mget*() try to get some
memory, it actually turns into a Message send to
Tcpip, saying "I want this much mbuf...".

When a VPI program calling vp_mfree() to free some
mbufs, this also turns into a Message send to Tcpip,
saying "these mbufs I can return to you..."

Of cause to minimize the message passing, the VPI
program keep arround some free mbufs/mclusters
and recycle them. Only if there is no more free mbufs
locally during vp_mget*(), or there is too much free
mbufs during vp_mfree(), then a message passing
happened.

The internal function "vp_freepkt()" is the one to free
mbufs back to Tcpip when vp_mfree() find there is
too much free bufs locally.

Hope this can give you some view of the VPI library.

Regards,

-xtang

Hi X.Tang,

Thanks a lot for your detailed explanation about VPI. I respect and
appreciate these efforts.

In our code, as per the present design, we can't avoid using the VPI
across the threads. Because, in our code one thread is getting the packet
from the Tcpip and putting it into the Queues, and the other thread is
getting the packet from the Queues and send it back to the Tcpip. We will
have to think over it for a solution.

----- Original Message -----
From: Xiaodan Tang <xiaodan.tang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
To: <prajith-U1VcRrJwn5T8CqgTAz400NBPR1lH4CV8@public.gmane.org>; Frank Liu <gfrankliu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Sent: Friday, October 08, 2004 9:09 PM
Subject: RE: [Openqnx-developer] Getting an error display, vp_freepkt: Bad
file descriptor.




-----Original Message-----
From: Prajith [mailto:prajith-U1VcRrJwn5T8CqgTAz400NBPR1lH4CV8@public.gmane.org]
Subject: Re: [Openqnx-developer] Getting an error display,
vp_freepkt: Bad file descriptor.

And I am not doing any fork() in my code.

I am creating a thread in our code and using VPI library
functions across the thread. ( I found, none of the VPI
library functions are thread safe. Will this be the problem?)

Hm...

This is QNX4 right? So a "thread" is basically another vfork()
isn't it? (the new "thread" is just another process).

Do you really HAVE TO create a "thread"? Can you make
it so that you only use one thread using VPI functions?
Something like:

int main() {
crate_new_thread();
vp_attach();
...
}

Make sure attach to VPI *AFTER* create thread, and the
new thread never call VPI function?

But I feel, once when I was doing a stress test on VPI
using a program (without thread), I got he same error
(vp_freepkt: Bad file descriptor.) If I get that program
I will let u all know.

That is also an interesting test to prove/denial our guess.

BTW, what is this vp_freepkt() function? Can I get any
implementation document of the VPI?

I don't think there is an "implementation document" ever
publiced, but let me explain the basic ideas behind VPI.


1) The stack (Tcpip) allocate all it's buffers/clusters from a
shared memory pool.

2) A VPI program will find out the pool, and map it into
local virtual space.

3) The Tcpip Stack and the VPI program have "queues"
in shared memroy, so they can exchange mbufs.
VPI program use vp_getpkt()/vp_putpkt() to get/put
mbufs on the queues.

4) The memory pool can only be operated by Tcpip.

So if a VPI program calling vp_mget*() try to get some
memory, it actually turns into a Message send to
Tcpip, saying "I want this much mbuf...".

When a VPI program calling vp_mfree() to free some
mbufs, this also turns into a Message send to Tcpip,
saying "these mbufs I can return to you..."

Of cause to minimize the message passing, the VPI
program keep arround some free mbufs/mclusters
and recycle them. Only if there is no more free mbufs
locally during vp_mget*(), or there is too much free
mbufs during vp_mfree(), then a message passing
happened.

The internal function "vp_freepkt()" is the one to free
mbufs back to Tcpip when vp_mfree() find there is
too much free bufs locally.

Hope this can give you some view of the VPI library.

Regards,

-xtang