Syslinux - Mar 2005 - [Fwd: Re: etherboot 5.3.14 and pxelinux keyboard problem]

Tim Legge has passed the following message on to me:

hpa wrote:
> Quinn wrote:
> > Now it seems I have found a bug in PXELINUX with regards to etherboot.
> > Up until 2.07 pxelinux was responsive to the keyboard.  From 2.08 and
> > up the keyboard is locked at the boot prompt when pxelinux is loaded
> > via etherboot 5.3.14.
>
> That would not be a PXELINUX bug, but an Etherboot bug.  The PXE READ
> UDP call is defined as non-blocking, but several implementors have
> screwed that one up (including VMWare.)  Unfortunately not answering
> ARPs has bad effects, too.
Etherboot's implementation of PXENV_UDP_READ is and has always been
non-blocking.  I don't see this problem when I try pxelinux from
syslinux-3.08-pre5 and current Etherboot CVS.  The relevant routine,
pxenv_udp_read() in Etherboot's core/pxe_export.c, hasn't changed since
July last year.

You can debug this by defining -DTRACE_PXE when compiling Etherboot.  This 
will show you a call trace such as 

Loading 10.254.254.2:pxelinux.0 ...(PXE).........done
[PXENV_GET_CACHED_INFO 2 to 00000800][PXENV_GET_CACHED_INFO 3 to 
00000800][PXENV_UDP_OPEN][PXENV_UDP_WRITE 40705->10.254.254.2:69 
(63)][PXENV_UDP_READ 10.254.254.2:32833->10.254.254.1:40705 
(19)][PXENV_UDP_WRITE 40706->10.254.254.2:69 (51)][PXENV_UDP_READ 
10.254.254.2:32833->10.254.254.1:40706 (19)][PXENV_UDP_WRITE 
40707->10.254.254.2:69 (50)] etc etc.

Please try compiling Etherboot with this option and send me the resulting
call trace from a run in which pxelinux ceases to respond to the keyboard.

I am not on this mailing list, so please Cc all replies to me.

Michael

After a lot of testing with Michael Brown, we have pinpointed that the 
locked keyboard problem is not due to a etherboot bug, but due to a 
pxelinux bug.  I did some more testing with the code and have narrowed 
the problem down.  Up until pxelinux.0-2.08-pre6 - the keyboard is 
responsive when booted via etherboot.  pxelinux.0-2.08-pre7 and up start 
having the keyboard lockup problem.

Here is a diff file of the changes between pxelinux.0-2.08-pre6 and 
pxelinux.0-2.08-pre7:

--- syslinux-2.08-pre6/pxelinux.asm     2003-11-27 06:36:16.000000000 +0100
+++ syslinux-2.08-pre7/pxelinux.asm     2003-12-04 04:47:57.000000000 +0100
@@ -1,5 +1,5 @@
 ; -*- fundamental -*- (asm-mode sucks)
-; $Id: pxelinux.asm,v 1.140 2003/11/27 05:36:16 hpa Exp $
+; $Id: pxelinux.asm,v 1.141 2003/12/04 03:47:57 hpa Exp $
 ; 
****************************************************************************
 ;
 ;  pxelinux.asm
@@ -55,6 +55,9 @@
 ;
 ; This is what we need to do when idle
 ;
+%macro RESET_IDLE 0
+       call reset_idle
+%endmacro
 %macro DO_IDLE 0
        call check_for_arp
 %endmacro
@@ -264,6 +267,7 @@
 LocalBootType  resw 1                  ; Local boot return code
 RealBaseMem    resw 1                  ; Amount of DOS memory after freeing
 APIVer         resw 1                  ; PXE API version found
+IdleTimer      resw 1                  ; Time to check for ARP?
 TextAttrBX      equ $
 TextAttribute   resb 1                 ; Text attribute for message file
 TextPage        resb 1                 ; Active display page
@@ -2293,8 +2297,28 @@
 ; ARP messages, but perhaps in the future this can be used to do network
 ; console.
 ;
+; hpa sez: people using automatic control on the serial port get very
+; unhappy if we poll for ARP too often (the PXE stack is pretty slow,
+; typically.)  Therefore, only poll if at least 4 BIOS timer ticks have
+; passed since the last poll, and reset this when a character is
+; received (RESET_IDLE).
+;
+reset_idle:
+               push ax
+               mov ax,[cs:BIOS_timer]
+               mov [cs:IdleTimer],ax
+               pop ax
+               ret
+
 check_for_arp:
-               pushad
+               push ax
+               mov ax,[cs:BIOS_timer]
+               sub ax,[cs:IdleTimer]
+               cmp ax,4
+               pop ax
+               jae .need_poll
+               ret
+.need_poll:    pushad
                push ds
                push es
                mov ax,cs
@@ -2315,6 +2339,7 @@
                pop es
                pop ds
                popad
+               RESET_IDLE
                ret

 ; 
-----------------------------------------------------------------------------

I hope this helps us find the problem.  Unfortunately, I do not have 
enough assembler knowledge to know what piece of the code that causes 
this problem on 486's.  I hope somebody can see what the problem is in 
the diff code I posted.

One last question, is there a debug mode one can enable in pxelinux?

Quinn


Michael Brown wrote:
>Tim Legge has passed the following message on to me:
>
>hpa wrote:
>  
>
>>Quinn wrote:
>>    
>>
>>>Now it seems I have found a bug in PXELINUX with regards to
etherboot.
>>>Up until 2.07 pxelinux was responsive to the keyboard.  From 2.08
and
>>>up the keyboard is locked at the boot prompt when pxelinux is loaded
>>>via etherboot 5.3.14.
>>>      
>>>
>>That would not be a PXELINUX bug, but an Etherboot bug.  The PXE READ
>>UDP call is defined as non-blocking, but several implementors have
>>screwed that one up (including VMWare.)  Unfortunately not answering
>>ARPs has bad effects, too.
>>    
>>
>
>Etherboot's implementation of PXENV_UDP_READ is and has always been
>non-blocking.  I don't see this problem when I try pxelinux from
>syslinux-3.08-pre5 and current Etherboot CVS.  The relevant routine,
>pxenv_udp_read() in Etherboot's core/pxe_export.c, hasn't changed
since
>July last year.
>
>You can debug this by defining -DTRACE_PXE when compiling Etherboot.  This 
>will show you a call trace such as 
>
>Loading 10.254.254.2:pxelinux.0 ...(PXE).........done
>[PXENV_GET_CACHED_INFO 2 to 00000800][PXENV_GET_CACHED_INFO 3 to 
>00000800][PXENV_UDP_OPEN][PXENV_UDP_WRITE 40705->10.254.254.2:69 
>(63)][PXENV_UDP_READ 10.254.254.2:32833->10.254.254.1:40705 
>(19)][PXENV_UDP_WRITE 40706->10.254.254.2:69 (51)][PXENV_UDP_READ 
>10.254.254.2:32833->10.254.254.1:40706 (19)][PXENV_UDP_WRITE 
>40707->10.254.254.2:69 (50)] etc etc.
>
>Please try compiling Etherboot with this option and send me the resulting
>call trace from a run in which pxelinux ceases to respond to the keyboard.
>
>I am not on this mailing list, so please Cc all replies to me.
>
>Michael
>
>  
>

Quinn wrote:
>  I did some more testing with the code and have narrowed 
> the problem down.  Up until pxelinux.0-2.08-pre6 - the keyboard is 
> responsive when booted via etherboot.  pxelinux.0-2.08-pre7 and up start 
> having the keyboard lockup problem.
> 
> Here is a diff file of the changes between pxelinux.0-2.08-pre6 and 
> pxelinux.0-2.08-pre7: 
Okay, this is weird.  There is nothing in this code *at all* that would 
cause this kind of problems.  Michael, does Etherboot muck with the
18.2 Hz BIOS timer interrupt at all?

	-hpa