WLAN Race Condition Demonstration

Demonstration of WLAN Race Condition

MV8787 WLAN version 14.66.09.p96 exhibits different behavior under Open Firmware on XO-4 compared to version 14.66.09.p80 .

Specifically, there appears to be a race condition between the HOST_INTSTATUS register and the WRBITMAP register. WRBITMAP returns the wrong value if it is read too soon after the 8787 firmware is initialized. The sequence is as follows.

Sequence

• Write 0x03 to HOST_INT_MASK register (function 1 reg 2)
• Load 8787 firmware
• Write 0x02 to CONFIG register (function 1 reg 0)
• (Optional time delay).
• Read HOST_INTSTATUS register (function 1 reg 3) - it returns 2, saying that it is okay to read the WRBITMAP register.
• Read WRBITMAP register (function 1 reg 6) ...
  • In version 14.66.09.p80 (Works) , the return value is always 0xffff, saying that the command port and the write data ports are available.
  • In version 14.66.09.p96 ...
    • (Fails) If the optional delay is less than (approximately) 90 ms, the return value is 0x0001, saying that only the command port is available.
    • (Works) If the optional delay is greater than (approximately) 90 ms, the return value is 0xffff, saying that the command port and the write data ports are available.

In the failing case, the WRBITMAP register will eventually return the correct value 0xffff - but the 0x02 mask bit in the HOST_INTSTATUS register is not set, so it should not be valid for software to read WRBITMAP.

Demonstration Firmware

I have prepared a version of OFW with tools to demonstrate this problem.

Put http://dev.laptop.org/~wmb/q7b08ma.rom on a USB stick and put it into the XO-4.

Power on the XO-4 and hit the ESC key when you hear the startup jingle. You should see an "ok" prompt.

Reflash the XO-4 with:

  ok flash u:\q7b08ma.rom

Configuring an Access Point

If you can set up an open access point named "OLPCOFW", you can run the tests very easily, as OFW defaults to that name. Otherwise you will have to issue these commands after every power-up:

  ok essid MY_ESSID
  ok wpa MY_WPA_PASSWORD

The essid line is unnecessary if the access point is named "OLPCOFW", and the wpa line is unnecessary if the access point is open.

Example Test Runs

Here is a successful run using the old 8787 firmware:

 ok use-old-fw
 ok set-delay 0
 ok ping 192.168.200.1
 host-intstatus-reg is 0x2  wr-bitmap-reg is 0xffff  delay is 0
 Scan for: OLPCOFW found
 Associate with: OLPCOFW
 DHCP got 192.168.200.64
 203 ms

Here is another successful run using the new 8787 firmware plus a 100 ms delay (which hides the problem):

 ok use-new-fw
 ok set-delay 100
 ok ping 192.168.200.1
 host-intstatus-reg is 0x2  wr-bitmap-reg is 0xffff  delay is 100
 Scan for: OLPCOFW found
 Associate with: OLPCOFW
 DHCP got 192.168.200.64
 203 ms

Here is a failing run, using new firmware, with the delay too short to hide the problem:

 ok use-new-fw
 ok set-delay 80
 ok ping 192.168.200.1
 host-intstatus-reg is 0x2  wr-bitmap-reg is 0x1  delay is 80
   wr-bitmap-value was wrong - rereading after 100 ms ...
 host-intstatus-reg is 0x0  wr-bitmap-reg is 0xffff
 Associate with: OLPCOFW

In the failing run, the first problem indication is "wr-bitmap-reg is 0x1" (instead of 0xffff). When the test software notices that situation, it waits 100 ms and re-reads both the HOST_INTSTATUS and WRBITMAP registers. Notice that WRBITMAP has changed to the correct 0xffff, but HOST_INTSTATUS is 0, so normal software would not know that it should read WRBITMAP.

The final result in the failing case is that the software hangs. The hang is caused by the transmit routine not having a write data port available (because the WRBITMAP mask is 0x1, with no write data port bits set).