ne2k driver issue with RTEMS/Qemu platform [was: Re: netdemo echoServer issue [was: Re: listen/select and then accept pattern not working?]]
Karel Gardas
kgardas at objectsecurity.com
Tue Jan 18 19:14:23 UTC 2005
On Mon, 17 Jan 2005, Karel Gardas wrote:
> Interesting. I have different issue: the first connection come OK: NIC
> (I'm using ne2000) signals received packet, then yet another packet,
> socket A (my guess is that this is the socket on which server is listening
> by using select) is wakenup, then socket B is wakenup (my guess is that
> this is socket created by accept call), again several times socket B, then
> Hello World is printed (CORBA servant is invoked), again several times
> socket B is wakenup, again NIC receive packet, then several times socket B
> is wakenup and that's all. For the second client run, RTEMS even does not
> signal received packet on NIC nor it signals wake up for socket A, but
> strangelly signals wake-up on socket B several times.
> Note: Socket A and socket B are two different socket pointers obtained
> during RTEMS debuging.
Because of missing notification about other interupts on NIC, I've thought
it might be interesting to try to use RTEMS on a real hardware. With one
box with Intel's etherexpress NIC I've been succesfull and even I've been
able to run MICO-based hello world server on it w/o any noticable issue.
i.e. I've started client invoking hello CORBA message on server on
another machine several times and hello server running on top of RTEMS
serves all requests well.
So as it seems, this is something bad in interaction between Qemu NE2k
emulated NIC and RTEMS's NE2k driver. As I've already written, Qemu's NE2k
is ok under OpenBSD OS guest, so my guess is either RTEMS ne2k driver or
some strange interation bug between qemu and rtems. Unfortunatelly, I've
not been able yet to try qemu/rtems with different NIC.
Thanks,
Karel
--
Karel Gardas kgardas at objectsecurity.com
ObjectSecurity Ltd. http://www.objectsecurity.com
More information about the users
mailing list