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
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.
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?!?
This issue becomes really ugly...
Thanks for any feedback!
Regards
Mathias
> >
> > thanks for your response.
> > I have printed out the state of the STACK_manger.event and the rx.fifo in
> the situation that
> > I have a missing signaling.
> > The result is the following:
> > STACK_manager.event.pending is 0,
> > STACK_manager.event.synch_base.count is -1,
> > rx.fifo.read_pos == rx.fifo.write_pos.
> >
> > I think this is fine. No data waiting in the rx fifo. Thus, the message
> seems to be still in the driver.
>
> What about the socket queue? Keep in mind that the stack manager
> migrates the rtskb to it once it got woken up by the driver.
>
> >
> > My assumption is now that there could be an issue with the rt_eepro100
> interrupt routine.
> > What happens if a second message comes in while speedo_interrupt() is
> running but
> > has already left the do { } while(1) loop?
> > The second message that has been received will not be delivered within
> that interrupt routine.
> > But will this cause a new interrupt that will be processed directly after
> the first interrupt?
> > Or will the interrupt for the second message silently forgotten?
>
> The logic is that as long as some IRQ event is pending in the hardware,
> it will keep its IRQ line up to re-trigger an interrupt once the CPU
> accepts it again. Nothing is lost. This is actually a generic pattern
> for all drivers, you will find the same in rt_e1000 for instance.
>
> That's the theory. Still some subtle bug may play against us. To rule
> out IRQ issues, you could trace the numbers of rt_eepro100 IRQs (or even
> just rx events), e.g. before starting a new tx/rx cycle in your
> application. After the error occurred, you could compare the progress
> with the expected increment.
>
> Jan
--
Mathias Koehrer
[EMAIL PROTECTED]
Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur 44,85 inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2
-------------------------------------------------------------------------
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
