A number of users are experiencing DMA descriptor or data errors using 64-bit
DMA with the Broadcom BCM4312 wireless device. After careful review and a
rewrite of the DMA code in the driver, we have not been able to fix the problem,
but we have determined the following:
(1) The problem is much more likely to occur on netbook systems. Several of the
developers have this card in regular notebook systems. None of us have the
problem. Several brand/model combinations are affected including Dell Inspiron
910 and Acer Aspire One A150. Linus has also reported the same symptoms with a
Core 2 ULV CPU. One of our devs questions if the deep-sleep support in the CPU
is a problem. It is also believed that affected systems have a Phoenix BIOS.
(2) If CONFIG_ACPI_PROCESSOR is not set on affected systems, the error rate is
much lower.
(3) When a DMA descriptor error occurs, a dump of the descriptors does not
reveal any obvious problems.
(4) Once the problem occurs, resetting of the device does not restore proper
operations. It is not a transient error.
Support for this device was not enabled in mainline until 2.6.32-rc2.
I do not know enough about either the ACPI or DMA code to begin debugging in
either of those regions. Any suggestions on debugging strategies, or links to
similar problems would be appreciated.
Thanks,
Larry
On Fri, Nov 13, 2009 at 11:21:18AM -0600, Larry Finger wrote:
> I do not know enough about either the ACPI or DMA code to begin debugging in
> either of those regions. Any suggestions on debugging strategies, or links to
> similar problems would be appreciated.
Could the hardware be highly sensitive to DMA latencies? Take a look at
the pm_qos code in ipw2100.
--
Matthew Garrett | [email protected]
On Friday 13 November 2009 21:11:12 Matthew Garrett wrote:
> On Fri, Nov 13, 2009 at 11:21:18AM -0600, Larry Finger wrote:
>
> > I do not know enough about either the ACPI or DMA code to begin debugging in
> > either of those regions. Any suggestions on debugging strategies, or links to
> > similar problems would be appreciated.
>
> Could the hardware be highly sensitive to DMA latencies? Take a look at
> the pm_qos code in ipw2100.
This makes perfect sense, yes. The DMA engine has so many quirks, I wouldn't be
surprised if it couldn't handle pm properly.
--
Greetings, Michael.
On 11/13/2009 02:44 PM, Michael Buesch wrote:
> On Friday 13 November 2009 21:11:12 Matthew Garrett wrote:
>> On Fri, Nov 13, 2009 at 11:21:18AM -0600, Larry Finger wrote:
>>
>>> I do not know enough about either the ACPI or DMA code to begin debugging in
>>> either of those regions. Any suggestions on debugging strategies, or links to
>>> similar problems would be appreciated.
>>
>> Could the hardware be highly sensitive to DMA latencies? Take a look at
>> the pm_qos code in ipw2100.
>
> This makes perfect sense, yes. The DMA engine has so many quirks, I wouldn't be
> surprised if it couldn't handle pm properly.
I'm in the process of creating a patch to set the latency to 200 usec. The
default is 2000. On my fast prosessors, it should not be anything nearly that
slow. If we determine this to be the problem, then we can try tuning.
Larry
On Fri, Nov 13, 2009 at 03:05:18PM -0600, Larry Finger wrote:
> I'm in the process of creating a patch to set the latency to 200 usec. The
> default is 2000. On my fast prosessors, it should not be anything nearly that
> slow. If we determine this to be the problem, then we can try tuning.
The latency is the amount of time it takes to get out of deep C states
and into C0. That's a function of the processor design rather than the
frequency.
--
Matthew Garrett | [email protected]
On 11/13/2009 03:13 PM, Matthew Garrett wrote:
> On Fri, Nov 13, 2009 at 03:05:18PM -0600, Larry Finger wrote:
>
>> I'm in the process of creating a patch to set the latency to 200 usec. The
>> default is 2000. On my fast prosessors, it should not be anything nearly that
>> slow. If we determine this to be the problem, then we can try tuning.
>
> The latency is the amount of time it takes to get out of deep C states
> and into C0. That's a function of the processor design rather than the
> frequency.
Thanks for that info. I should have said my Turion 64 X2 is different.
Larry
On 11/13/2009 03:13 PM, Matthew Garrett wrote:
> On Fri, Nov 13, 2009 at 03:05:18PM -0600, Larry Finger wrote:
>
>> I'm in the process of creating a patch to set the latency to 200 usec. The
>> default is 2000. On my fast prosessors, it should not be anything nearly that
>> slow. If we determine this to be the problem, then we can try tuning.
>
> The latency is the amount of time it takes to get out of deep C states
> and into C0. That's a function of the processor design rather than the
> frequency.
Thanks for your suggestion. The value of 200 fixed one of the two machines and
greatly improved the other. He is currently testing with a value of 150, and
will try 100 if that still fails.
Larry