[ a lot of stuff deleted ]
I apologize in advance if this is redundant because the
problem has been dealt with already.

This is reminiscent of a problem I had with a Samsung CD vs. ahci

The ahci driver was attempting to use NCQ to send commands to
the CD which, according to the ahci standard, may not be queued.
When I forcibly disabled NCQ the system would boot.

The immediate symptom was a panic saying that an interrupt
referenced a control block which was idle. This was caused by
the interrupt code reading a zero as the active slot from the
drive.

I may have read the ahci standard wrong, but it only allows
commands like read and write data to be queued. Identify, etc,
are not listed as queueable.
Some target devices are forgiving and accept any command as
a queued command, so the ahci driver works with most devices.
This particular one apparently believes that there can only be
one non-queued command active so it does not return a slot number.

In discussion with several people, the "shadow registers" of the
ATA controller model were mentioned. I don't believe that the
standards ever allow them to be used as a way to queue commands
like identify.

I tried to make the proper changes to ahci.c but ran out of time
and energy. If anyone would like, I can try to reconstruct
the situation more exactly but it would take a little time.

geoff steckel

Reply via email to