[U-Boot-Users] NetConsole tstc problems

[U-Boot-Users] NetConsole tstc problems

[Brian Prodoehl]

Has anyone else experienced problems with NetConsole's tstc?  In particular,
defining CONFIG_BOOT_RETRY_TIME makes NetConsole almost unusable for me,
because then readline() in main.c blocks on tstc and the result (for me, at
least) is that NetConsole accepts a character every second or so.  For
everything that doesn't depend on tstc, NetConsole works beautifully for me. 
I'm just wondering if anyone else has seen problems, or if anyone has
suggestions on how to make tstc less of a show-stopper (something I haven't
been able to accomplish).

Brian Prodoehl

[U-Boot-Users] NetConsole tstc problems

[Stefan Roese]

Hi Brian,

On Tuesday 01 November 2005 22:19, Brian Prodoehl wrote:
> Has anyone else experienced problems with NetConsole's tstc?  In
> particular, defining CONFIG_BOOT_RETRY_TIME makes NetConsole almost
> unusable for me, because then readline() in main.c blocks on tstc and the
> result (for me, at least) is that NetConsole accepts a character every
> second or so.

Depending on your network driver, tstc() can take pretty long. I experienced a 
similar problem in sleep() using tstc() via ctrlc(). I solved this problem 
using a "better" timeout mechanism with get_timer(). This could probably help 
here too.

> For everything that doesn't depend on tstc, NetConsole works 
> beautifully for me. I'm just wondering if anyone else has seen problems, or
> if anyone has suggestions on how to make tstc less of a show-stopper
> (something I haven't been able to accomplish).

Take a look at the sleep() fix:

http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commit;h=c4c13df284cb06156c16ee6aef49b8d23be3fadd

Best regards,
Stefan

[U-Boot-Users] NetConsole tstc problems

[Wolfgang Denk]

In message <20051101151924.c9ww4408kw8ososc@secure.uwalumni.com> you wrote:
> Has anyone else experienced problems with NetConsole's tstc?  In particular,
> defining CONFIG_BOOT_RETRY_TIME makes NetConsole almost unusable for me,
> because then readline() in main.c blocks on tstc and the result (for me, at
> least) is that NetConsole accepts a character every second or so.  For
> everything that doesn't depend on tstc, NetConsole works beautifully for me. 
> I'm just wondering if anyone else has seen problems, or if anyone has
> suggestions on how to make tstc less of a show-stopper (something I haven't
> been able to accomplish).

Please use current code. A fix inthis area  has  been  checked  in  a
couple of days ago.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Of course there's no reason for it, it's just our policy.

[U-Boot-Users] NetConsole tstc problems

[Brian Prodoehl]

> In message <20051101151924.c9ww4408kw8ososc@secure.uwalumni.com> you wrote:
> > Has anyone else experienced problems with NetConsole's tstc?  In
> particular,
> > defining CONFIG_BOOT_RETRY_TIME makes NetConsole almost unusable for me,
> > because then readline() in main.c blocks on tstc and the result (for me, at
> > least) is that NetConsole accepts a character every second or so.  For
> > everything that doesn't depend on tstc, NetConsole works beautifully for
> me.
> > I'm just wondering if anyone else has seen problems, or if anyone has
> > suggestions on how to make tstc less of a show-stopper (something I haven't
> > been able to accomplish).
>
> Please use current code. A fix inthis area  has  been  checked  in  a
> couple of days ago.

I'm not sure which fix you mean.  The fix to the sleep command corrected the
time issue, but there are still underlying problems with nc_tstc.  Try hitting
Ctrl+C to abort the sleep.  I have to hit it between 3 and 10 times before it
registers.  And that fix doesn't help at all with the CONFIG_BOOT_RETRY_TIME
problem.  I don't see any configs using NetConsole and bootretry, but I'd be
interested to hear that someone has it working without having to change core
code.  My current fix is to change the following in main.c's readline():

	for (;;) {
- #ifdef CONFIG_BOOT_RETRY_TIME
+ #if defined(CONFIG_BOOT_RETRY_TIME) && !defined(CONFIG_NETCONSOLE)
		while (!tstc()) {	/* while no incoming data */
			if (retry_time >= 0 && get_ticks() > endtime)
				return (-2);	/* timed out */
		}
#endif
		WATCHDOG_RESET();	/* Trigger watchdog, if needed */

With that change, I'm at least able to use NetConsole when
CONFIG_BOOT_RETRY_TIME is defined, but only by skirting around a tstc that
doesn't work very well.

Brian Prodoehl

[U-Boot-Users] NetConsole tstc problems

[Stefan Roese]

Hi Brian,

On Wednesday 02 November 2005 18:34, Brian Prodoehl wrote:
> I'm not sure which fix you mean.  The fix to the sleep command corrected
> the time issue, but there are still underlying problems with nc_tstc.  Try
> hitting Ctrl+C to abort the sleep.  I have to hit it between 3 and 10 times
> before it registers.

Hmmm. With my sleep fix, this works pretty well on my test platform. The main 
problem seems to be, that the delay from the ethernet driver (I was using 
ppc4xx by the way), can range from a few ms to some 100ms or even more in 
your case.

What is your platform? Can you check your ethernet driver, if there are big 
delays or timeouts.

> And that fix doesn't help at all with the 
> CONFIG_BOOT_RETRY_TIME problem.  I don't see any configs using NetConsole
> and bootretry, but I'd be interested to hear that someone has it working
> without having to change core code.  My current fix is to change the
> following in main.c's readline():
>
> 	for (;;) {
> - #ifdef CONFIG_BOOT_RETRY_TIME
> + #if defined(CONFIG_BOOT_RETRY_TIME) && !defined(CONFIG_NETCONSOLE)
> 		while (!tstc()) {	/* while no incoming data */
> 			if (retry_time >= 0 && get_ticks() > endtime)
> 				return (-2);	/* timed out */
> 		}
> #endif
> 		WATCHDOG_RESET();	/* Trigger watchdog, if needed */
>
> With that change, I'm at least able to use NetConsole when
> CONFIG_BOOT_RETRY_TIME is defined, but only by skirting around a tstc that
> doesn't work very well.

Yes, we should try to solve the problem itself. Seems to be not easy 
though. :-(

Best regards,
Stefan