If EM Transmit bit is busy during init ata_msleep() is called.
It is wrong - msleep() should be used instead of ata_msleep(),
because if EM Transmit bit is busy for one port, it will be busy
for all other ports too, so using ata_msleep() causes wasting
tries for another ports.

The most common scenario looks like that now
(six ports try to transmit a LED meaasege):
- port #0 tries for the 1st time and succeeds
- ports #1-5 try for the 1st time and sleeps
- port #1 tries for the 2nd time and succeeds
- ports #2-5 try for the 2nd time and sleeps
- port #2 tries for the 3rd time and succeeds
- ports #3-5 try for the 3rd time and sleeps
- port #3 tries for the 4th time and succeeds
- ports #4-5 try for the 4th time and sleeps
- port #4 tries for the 5th time and succeeds
- port #5 tries for the 5th time and sleeps
At this moment port #5 wasted all its five tries and failed to initialize.
Because there are only 5 (EM_MAX_RETRY) tries available usually only five ports
succeed to initialize. The sixth port and next ones usually will fail.

If msleep() is used instead of ata_msleep() the first port succeeds to 
initialize
in the first try and next ones usually succeed to initialize in the second try.

Signed-off-by: Lukasz Dorau <lukasz.do...@intel.com>
---
 drivers/ata/libahci.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
index acfd0f7..cf38692 100644
--- a/drivers/ata/libahci.c
+++ b/drivers/ata/libahci.c
@@ -779,7 +779,7 @@ static void ahci_start_port(struct ata_port *ap)
                                                               emp->led_state,
                                                               4);
                                if (rc == -EBUSY)
-                                       ata_msleep(ap, 1);
+                                       msleep(1);
                                else
                                        break;
                        }

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to