Unable to create TX buffer recovery queue

[Daron Chabot]

On Fri, 2007-06-08 at 09:38 -0700, Amalaye Oyake wrote:
> Yes,
> 
> that is true. The name server is on a different subnet. That is the way our
> topology is configured. I simply hooked the box to the institutional LAN and
> setup the network just as I would on a PC.

For testing purposes a point-to-point (target-to-host) network
connection eliminates a lot of possible hangups... especially in an
institutional environment.

i.e. keep things as simple as possible...

> 
> I also made the change for microseconds per tick yesterday (I caught that
> one) ... 

great !

> 
> The gateway is on the same subnet, but the name server is on a different
> one.
> 
> 
>   A.B.C.9 (NAMESERVER)
>     |
>     |
> X.Y.Z.1 (GATEWAY)
> |
> |----X.Y.Z.65 (RTEMS BOX)

The code you sent me offline shows the rtems box at X.Y.Z.66, so I'm
assuming the above is a typo...?

> |
> |----X.Y.Z.90
> |
> |----X.Y.Z.100

You really need to get a packet-sniffer on this problem: that will
provide the who, what, where, and when of the problem...

The "why" is still up to you, however... ;)

-- dc

> 
> 
> -----Original Message-----
> From: Daron Chabot [mailto:daron.chabot at usask.ca] 
> Sent: Friday, June 08, 2007 9:21 AM
> To: Amalaye Oyake
> Cc: RTEMS
> Subject: RE: Unable to create TX buffer recovery queue
> 
> 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.
> 
> 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...
> 
> 
> -- dc
>