Thanks Gary for the explanations I really appreciate it and know you're busy.
At 04:06 AM 2/23/2007, Gary Thomas wrote: 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?
This is my current line of investigation. If I raise the default number of receive buffers from the config from 4 to 8 it seems to not get reset so you probably nailed it.
The first thing I had tried was auditing the .h file to see if any of my constants were wrong (had the offset of CR0 erroneously in them) then looked through the source for any multibyte access to an offset before CR0 which would overwrite it. The number of places that directly write CR0 are few (3 I believe).
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 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'.
I'm looking into this. I was trying to get the Phy to tell me if link status had changed so that I could optimize the can_send function a bit (cache the link state) and its possible that after its auto-poll expires it simply generates an interrupt to have the driver check the state. Still I would like it to generate a flag somewhere if this is the case. I going to turn off autopoll and see if it stops.
--Chuck
-- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
