#2401 BLOC Trial-2: Wakeup event is repeated continuously

[Zarro Boogs per Child]

#2401: Wakeup event is repeated continuously
----------------------+-----------------------------------------------------
  Reporter:  cjb      |       Owner:  rsmith            
      Type:  defect   |      Status:  new               
  Priority:  blocker  |   Milestone:  Trial-2           
 Component:  kernel   |     Version:  Git as of bug date
Resolution:           |    Keywords:                    
  Verified:  0        |  
----------------------+-----------------------------------------------------
Changes (by dilinger):

  * owner:  dilinger => rsmith

Comment:

 Richard has looked into this; he has discovered one problem, and we have a
 theory about the *real* problem.

 The theory is as follows.  The EC will not complete an EC command while it
 is waiting for its keyboard buffer to be emptied.  If it times out waiting
 for the OS to read the keyboard buffer (after 100ms), it clears the buffer
 and re-enters its state machine (at which point, it finishes processing
 the EC command).  From the kernel, when we run an EC command, we disable
 interrupts.  When a gamekey is pressed, that generates 4 8042 interrupts
 total (2 for key down, 2 for key up).

 So, we press a key; the EC stuffs byte #1 into the keyboard buffer.
 Linux's i8042 interrupt handler reads that byte and sends it to the input
 layer.  At this point, the battery is inserted, it does some SCI
 processing, and schedules some EC commands to run.  The EC command starts;
 we disable interrupts, send out the EC command, and wait for the EC to
 read the byte.  meanwhile, the EC stuffs byte #2 into the keyboard buffer.
 This would normally trigger an interrupt, but the cpu has interrupts
 disabled.  The kernel is waiting for the EC to read the command byte; the
 EC is waiting for the kernel to read the key from the 8042 buffer.  The EC
 spins for 100ms, gives up, and flushes the byte from the 8042 buffer.  It
 reenters its state machine, processes the EC command, and sends back a
 reply.  The kernel gets the reply, finishes the EC command, and re-enables
 interrupts.  The EC then goes back to dealing with key presses, but a byte
 has been lost.  Since we're also waiting for 100ms with interrupts
 disabled, we could also be losing *more* keypresses; however, at that
 point we're pretty hosed anyways.

 The first problem (which has been verified) which Richard has identified
 is that we should not be dropping keys from the 8042 buffer when we get a
 timeout.  The second problem is the deadlock; this has not been verified,
 there needs to be more attention paid to it.

 Reassigning to Richard

-- 
Ticket URL: <http://dev.laptop.org/ticket/2401#comment:8>
One Laptop Per Child <http://laptop.org/>