Unable to create TX buffer recovery queue
Joel Sherrill
joel.sherrill at oarcorp.com
Fri Jun 8 16:32:14 UTC 2007
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
>
More information about the users
mailing list