*was* Unable to create TX buffer recovery queue

[Amalaye Oyake]

I changed the line to #define CONFIGURE_MICROSECONDS_PER_TICK	1000 

I actually caught that one yesterday. What I do see that is strange when I
hit enter on the "host?" prompt is this

interrupts: 14
carrier_lost: 14

Lifting the computer and looking at the NIC I see no activity lights on.
Usually there should be something on (green blinking). It just seems dead
... 

Auto-negotiation was turned on at the port ... so I had it set to 100 full
duplex. I restarted the computer, the 100Mbps light came on and then once
the driver tasks started, the light turned off. All the lights on the card
(100, 10 and ACT) are off.

Some stats that may be useful that I now see (since restart)

interrupts: 5
carrier_lost: 5
bad_ssd: 1
avg_chain_len: -1

I think the application *is* working, but somehow the card is losing
carrier. Am I correct?

Sincerely,
AO


-----Original Message-----
From: Joel Sherrill [mailto:joel.sherrill at oarcorp.com] 
Sent: Friday, June 08, 2007 9:32 AM
To: Daron Chabot
Cc: Amalaye Oyake; RTEMS
Subject: Re: Unable to create TX buffer recovery queue

Daron Chabot wrote:
> On Thu, 2007-06-07 at 17:24 -0700, Amalaye Oyake wrote:
>   
>> Hello Daron,
>>
>> Something fishy is still going on ...
>>
>> Yes I changed MANAGERS=all (not in the stuff I sent)
>> I put an fflush(stdout) after the line that says printf("\nhost?"); and
that
>> prompt started showing up ...
>>
>> I enter a host and it says Host information not available. I looked at
the
>> network config file and do I need to set the task priority, mbuf and mbuf
>> cluster capacity? They are all set to 0.
>>     
>
> By specifying a network task priority, mbuf, and mbuf cluster size of
> zero you are telling RTEMS to use the default values. 
>
>   
>> >From rtems_bsdnet.h:
>>     
>
> struct rtems_bsdnet_config {
> 	/*
> 	 * This entry points to the head of the ifconfig chain.
> 	 */
> 	struct rtems_bsdnet_ifconfig *ifconfig;
>
> 	/*
> 	 * This entry should be rtems_bsdnet_do_bootp if BOOTP
> 	 * is being used to configure the network, and NULL
> 	 * if BOOTP is not being used.
> 	 */
> 	void			(*bootp)(void);
>
> 	/*
> 	 * The remaining items can be initialized to 0, in
> 	 * which case the default value will be used.
> 	 */
> 	rtems_task_priority	network_task_priority;	/* 100		*/
> 	unsigned long		mbuf_bytecount;		/* 64 kbytes	*/
> 	unsigned long		mbuf_cluster_bytecount;	/* 128 kbytes	*/
> 	char			*hostname;		/* BOOTP	*/
> 	char			*domainname;		/* BOOTP	*/
> 	char			*gateway;		/* BOOTP	*/
> 	char			*log_host;		/* BOOTP	*/
> 	char			*name_server[3];	/* BOOTP	*/
> 	char			*ntp_server[3];		/* BOOTP	*/
> };
>
> i.e. those defaults should OK.
>
> Other than your MICROSECONDS_PER_TICK=100 setting is quite fast (you're
> generating clock ticks (interrupts) at 10 kHz), values of 1000 or 10000
> are more typical, I don't really see anything "wrong" with your
> configuration.
>   

I didn't spot this.  That should be higher.  You may be spending longer
taking clock ticks than doing real work.  Lower it to 1000 usecs and
see if it helps any.
> This leads me to suspect that the problem may be external to your RTEMS
> target. What does your network topology look like ? I see that the
> nameserver you've specified is on a different subnet...
>
> Can you use a packet-sniffer like Ethereal (aka WireShark) to observe
> the traffic sent to/from your RTEMS target ?  That tool is invaluable in
> diagnosing network related problems...
>
>   
This is really the key to solving this.

Hitting return at the "host?" prompt should print out a lot of information
which should have hints.

--joel
> -- dc
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>