Unable to create TX buffer recovery queue
Daron Chabot
daron.chabot at usask.ca
Fri Jun 8 16:20:53 UTC 2007
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
More information about the users
mailing list