Stuck at "Semaphore Timeout" When Formatting an HP MSA Disk? Here's the Fix

Have you ever created a shiny new volume on your HP P2000 G3 MSA, presented it to a Windows server (like Windows Server 2008 R2), and then hit a wall when trying to initialize or format it?

It’s a frustrating scenario: Disk Management freezes, the command line utility Diskpart hangs, and after a painfully long wait, you get the infamous error: "The semaphore timeout period has expired."

If you've checked your server's System Event Log and found Event ID 10 from the Virtual Disk Service (VDS), you've confirmed the issue.

---

The Clue: Event ID 10 and the VDS Error

The giveaway in the Windows Event Log is often this specific error message:

Source	Level	Event ID
Virtual Disk Service	Error	10

Description: “VDS fails to write boot code on a disk during clean operation. Error code: 80070015@02070008."

This error often indicates a low-level communication failure, and in the case of the HP P2000 G3 MSA, it points to a common storage bottleneck.

---

The Root Cause: Unwritable Cache Memory

The issue isn't with Windows, the Fibre Channel, or the disk itself—it's with the MSA's cache.

The MSA array uses cache memory to temporarily hold data before it's safely written to disk. If, for any reason (like battery issues, maintenance mode, or a software state), the array cannot commit data from the cache to the physical drives, that cache becomes "unwritable."

When you try to format or clean a disk, Windows tries to write initial data (like the boot code or partition table) that the MSA's firmware intercepts and places in this cache. If the cache is full of uncommitted data, the write operation is effectively blocked, leading to the "semaphore timeout" on the host server.

---

The Solution: Check and Clear the MSA Cache

The fix is straightforward and requires direct interaction with the MSA's Command Line Interface (CLI).

Step 1: Check the Unwritable Cache Status

Log into your MSA CLI and execute the following command to see the status of the uncommitted cache on both controllers (A and B):

Bash

# show unwritable-cache

Expected Output (when you have a problem):

Unwritable System Cache
-----------------------
Percent of unwritable cache in controller A: 98
Percent of unwritable cache in controller B: 98

If the "Percent of unwritable cache" is anything more than 0, it's the source of your problem. A high percentage (like 98%) means the cache is essentially full of data the array can't flush.

Step 2: Clear the Cache

Once you've confirmed the unwritable cache is high, you must execute the command to clear it. This process will usually force the data to be written to the disks before it's cleared, but it's important to be sure the array is in a stable state before proceeding.

Note: Clearing the cache is typically safe, but always check your array's health status and documentation first.

Bash

# clear cache

This command should force the array to commit the held data to disk, resetting the percentage of unwritable cache back to 0%.

Step 3: Re-Try Initialisation

Once the cache is cleared, go back to your Windows Server 2008 R2 machine. You should now be able to initialise the disk, partition it, and format it in Disk Management or using Diskpart without seeing the "The semaphore timeout period has expired" error.