*was* Unable to create TX buffer recovery queue

[Joel Sherrill]

I agree with Daron's point about a dedicated subnet.

Also some drivers have had auto-negotiation issues in the
past.  Which driver are you using again?  Which source file?

Do you happen to know the PCI Id of your NIC?

--joel

Amalaye Oyake wrote:
> 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
>>   
>>     
>
>