#9693 HIGH Not Tri: Reset when SCI coincides with SMI handler

[Zarro Boogs per Child]

#9693: Reset when SCI coincides with SMI handler
---------------------------------+------------------------------------------
 Reporter:  wmb at firmworks.com    |                 Owner:  wmb at firmworks.com
     Type:  defect               |                Status:  new              
 Priority:  high                 |             Milestone:  Not Triaged      
Component:  ofw - open firmware  |               Version:  not specified    
 Keywords:                       |           Next_action:  diagnose         
 Verified:  0                    |   Deployment_affected:                   
Blockedby:                       |              Blocking:                   
---------------------------------+------------------------------------------
 On q3a16, if you auto-boot Windows XP from an external SD card, the system
 will reset early in the Windows bootloading process.  The problem does not
 occur if get to the ok prompt and wait about 4 seconds before typing
 "boot".

 The problem is related to the occurrence of an SCI interrupt signal from
 the EC that happens 8.5 seconds after CPU power-on.  Apparently there is
 some strange interaction with the OFW SMI handler that services BIOS INT
 13.  If you arrange for a "rdtsc" instruction to happen inside the SMI
 handler just after the SCI signal is asserted, the system behaves
 normally, with no reset.

 "rdmsr" instead of "rdtsc" does not quench the problem.

 One way to observer the occurrence of the SCI is to look for the 0x02 bit
 in register PMIO+0x20 to be set.

 All of the obvious delivery paths for the SCI are blocked - the 0x02 bits
 in PMIO+0x22 (SCI enable) and PMIO+0x24 (SMI enable) are clear, and IRQ 10
 (the SCI interrupt) is masked off at the PIC.

 The analysis above is suspect because the reset can be made to happen
 before time 8.5 seconds by interrupting auto-boot and typing boot quickly
 - then it resets at time 6.03 seconds.  So perhaps the occurrence of the
 SCI *prevents* the future occurrence of the reset.

 The problem "went away" on q3a16b, because of a change that added a
 fraction of a second to the startup time, thus pushing the beginning of
 Windows boot just past the magic 8.5 second time.
 (The change was the re-enabling of "unused" USB ports 4,5, which added
 about 200 mS to the startup time due to port probing time.  The other
 factor is whether or not the startup sound is on - that adds 2 seconds to
 the startup time - 0.5 seconds to start the sound and 1.5 to wait for its
 completion.)

-- 
Ticket URL: <http://dev.laptop.org/ticket/9693>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system