Created attachment 516582 [details]
fix lost command issue and prevent controller lockups
Description of problem: An extra readl is required to prevent commands from being lost or stuck under certain workloads
Version-Release number of selected component (if applicable):
How reproducible: Hard to reproduce.
Steps to Reproduce:
1. Run heavy read workload on Smart Array
Actual results: A command may get lost or stuck resulting in system instability.
Expected results: All commands should complete.
The 2.6.40 (3.0.0) update we have in f15 has this line (from upstream)
(void) readl(h->vaddr + SA5_REQUEST_PORT_OFFSET);
I assume the actual register being written is irrelevant, and it's just working around write posting ?
(In reply to comment #1)
> The 2.6.40 (3.0.0) update we have in f15 has this line (from upstream)
> (void) readl(h->vaddr + SA5_REQUEST_PORT_OFFSET);
> I assume the actual register being written is irrelevant, and it's just working
> around write posting ?
It actually does matter. At the time of the patch you reference it was assumed to be safe to read back from the request queue register. That register is defined by the spec as being read-only but on the controllers in the field it didn't matter. However, the next generation of controllers lockup when reading that register so it was changed to read from the scratchpad register instead. So please use the patch I posted to the bz.
This is (hopefully) a temporary work around. But you are right, it's only acting as a fence to ensure all commands get posted to the controller. I'm working with our 3rd level support engineers to root cause the issue.
ok, I'll switch it to use the version you attached in the next update.
Can you make sure this gets into Linus' tree & Greg's -stable branches ?
actually disregard that. I see this made it into 3.0.1rc, which we've already picked up for the next f15 update.