M. Koehrer wrote: > Hi Jan, > > I have extended my debug code. > Apart from the values I knew already: > STACK_manager.event.pending is 0, > STACK_manager.event.synch_base.count is -1, > rx.fifo.read_pos == rx.fifo.write_pos. > > I additionaly measured the values of my socket: > sock->pending_sem.count is 0 > sock->incoming.first (pointer) is 00000000 > sock->incoming.last (pointer) is d7055800
Ok, looks really like a driver/hardware issue. > > That looks as if no data is in the socket queue. > In addition to that I also read in directly the status register from the > rt_eepro100. > I.e. I do the same the speedo_interrupt() does at the very beginning: > status = inw(ioaddr + SCBStatus). > The status value I get there is 0xb70f. Extremely weird. According to the 8255x manual (page 35/36), this is an impossible value. The lowest 2 bits should be 0, and when the succeeding two bits are both 1 like here, this means a "reserved" state. Just to cross-check: how do normal status value look like for you? > And this value looks fairly strange to me. > If I understand the driver, this value indicates that a packet has > been received or there was an rx error as (status & 0x5000) is not zero. > The question is: Why can I get this status value but not being in the > interrupt routine?!? Don't know yet, maybe some "errata" of your chip revision that is not caught by the eepro100. What is your revision by the way? We are mostly on 8 or 9 here. Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users