More on MCF5307C3 - NE2000 network driver

[Chris Xenophontos]

Thanks, Greg-
there are printf's, that indicate when the daemon wakes up(TX or RX
interrupt).  I hooked up a scope, and noticed that when the network task
quits, the interrupt is no longer asserted by the DM9008 chip -- normally,
you can see IRQ3 pulse low, i.e, during network activity.  When it quits,
IRQ3 no longer pulses but stays high.  

Now I'm wondering if the ISR (ns8390_interrupt_handler) is getting trashed
or if the DM9008 chip is being reset somehow(??) and not generating the
interrupt. We have several boards that behave exactly the same with this
application. 

thanks
cx
  

-----Original Message-----
From: gregory.menke at gsfc.nasa.gov [mailto:gregory.menke at gsfc.nasa.gov] 
Sent: Wednesday, July 07, 2004 9:56 AM
To: Chris Xenophontos
Cc: rtems-users at rtems.com
Subject: More on MCF5307C3 - NE2000 network driver

Chris Xenophontos writes:
 > Hello, 
 > 
 > A few weeks ago, we had successfully (for the most part) integrated the
 > NE2000 driver to the Coldfire MCF5307C3 Board Support package.  We are
able
 > to send/receive application data through the network to our board. 
However,
 > it appears that the either the receive or transmit daemon in ns8390.c
quits
 > after varying lengths of time.  When that happens, ping times-out, and of
 > course, no data is received/sent to the network.  No other error messages
 > are generated ( i.e, overflow, mbuf, ).
 > 
 > We have tried hard-coding values for mbuf and mbuf clusters in
 > rtems_bsdnet_config, using values up to 256K for mbufs, and 512K for mbuf
 > clusters. 
 >  
 > CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS is currently set to 30. 
Increasing
 > it to 40 doesn’t help.  NETWORK_TASK_PRIORITY is 80, and the priority of
our
 > application task that reads (blocks) on the socket is 220.
 > 
 > Simply stopping and restarting the application, i.e, through the debugger
 > will re-initialize the entire application, but the network remains
 > unresponsive.  To get the network application to respond again, we need
to
 > do a hard reset of the board.
 > 
 > Is there some configuration parameter that I’m missing?
 > 
 > Thanks,
 > Chris Xenophontos
 > cxenophontos at hammers.com

Have you put printk's in the two daemons to see if they're waking up?
It sounds sort of like a deadlock with the network semaphore or
if_state.

Gregm