This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Well its working but ...
- From: Gary Thomas <gary at mlbassoc dot com>
- To: Chuck McManis <ecos at mcmanis dot com>
- Cc: ECOS Discussion List <ecos-discuss at sources dot redhat dot com>
- Date: Fri, 23 Feb 2007 05:06:06 -0700
- Subject: Re: [ECOS] Well its working but ...
- References: <7.0.1.0.0.20070222220559.01b0b9c0@mcmanis.com>
Chuck McManis wrote:
Ok, so its working. Even better pings are nice and fast :
-------------------------------------------------------------
ping 192.168.110.122
PING 192.168.110.122 (192.168.110.122): 56 data bytes
64 bytes from 192.168.110.122: icmp_seq=0 ttl=64 time=0.261 ms
64 bytes from 192.168.110.122: icmp_seq=1 ttl=64 time=0.237 ms
64 bytes from 192.168.110.122: icmp_seq=2 ttl=64 time=0.244 ms
64 bytes from 192.168.110.122: icmp_seq=3 ttl=64 time=0.247 ms
64 bytes from 192.168.110.122: icmp_seq=4 ttl=64 time=0.237 ms
64 bytes from 192.168.110.122: icmp_seq=5 ttl=64 time=0.238 ms
64 bytes from 192.168.110.122: icmp_seq=6 ttl=64 time=0.240 ms
64 bytes from 192.168.110.122: icmp_seq=7 ttl=64 time=0.242 ms
^C
--- 192.168.110.122 ping statistics ---
8 packets transmitted, 8 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.237/0.243/0.261/0.007 ms
--------------------------------------------------------------
Quarter millisecond is definitely in the ball park.
The way I got it to work was to force the RXEnable flag in CR0 at the
end of the TxSent interrupt service routine. Basically before I exit I
turn RXEnable on regardless and it stays set through calls to the
ISR/DSR and packets are received. If I don't turn this flag on there it
gets reset at some point and the device stops receiving packets :-(.
So a couple of questions for Gary or anyone else who knows the ethernet
driver internals.
So which is the "preferred" (and by that I mean the one that is used by
most people so it gets the most testing) network stack ? Because I'm
somewhat familiar with the FreeBSD one I chose it and was surprised to
see ECOS complaining that it couldn't set multicast address groups. (Not
sure what I'd do with them). So my driver simply lies at the moment to
keep the stack from calling that function again and again and resetting
the interface... any way, why does it want to do that?
Either you have broken hardware (possible, but rare) or somewhere else
in your driver code there is a place that's not so careful with CR0 that's
resetting the bit inadvertently. I'd track down all places where those
control registers are being manipulated and make sure that it's not just
a case where a bit is not being preserved.
I don't know anything about your particular hardware, but maybe there's
some magic like if all the Rx buffers go full, then Rx enable is dropped?
Or perhaps there is some error condition that causes this that you're not
testing for?
If you don't find anything else, at least your solution of always forcing
the Rx enable seems correct - if the driver is active, then the receiver
must be as well.
The second question is this output from the httpd test (which just calls
init_all_network_devices())
Route - dst: 0.0.0.0, mask: 0.0.0.0, gateway: 192.168.110.254
So basically this is like the static route to tell every packet that is
sent to any address should go out of my network adapter? I was expecting
route: 192.168.110.0 mask 255.255.255.0, gateway: 192.168.110.254.
If the 0.0.0.0 route is just a stand-in for "default route" then I'm
certainly ok with that, just wondering why it wouldn't say route: default.
This is the case - 0.0.0.0 stands for any (default). The routine that
prints it just doesn't spell out this special case.
The last question is that I periodically get my dsr called with no
interrupt event. I'm wondering why. Nothing seems to have interrupted. I
can use that to go check the Phy to see if the link state has changed
but other than that was wondering who called in so to speak.
The DSR can only be called if the corresponding ISR tells the
system to do so. My guess would be that there was an ISR (actual
interrupt) that happened and your driver did something that cleared
the interrupt condition [or indicator thereof] before the DSR got
called. Notice that the DSR in an ethernet driver is not actually
called directly by the ISR/DSR scheme, but rather by a thread in
the interrupt stack and it can be a *long* time between the ISR
and the "DSR'.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss