Re: [ath9k-devel] [PATCH 3/7] ath9k: Merge wiphy and misc debugfs files

[Ben Greear <greearb@candelatech.com>]

On 02/14/2012 02:29 PM, Felix Fietkau wrote:
> On 2012-02-14 7:43 PM, Ben Greear wrote:
>> On 02/14/2012 10:29 AM, Sujith wrote:
>>> Ben Greear wrote:
>>>> Actually, I think it might be useful to have a second level of debugging.
>>>> I hope to soon have time&   resources to add some logic to dump lots of register
>>>> info and such in human-readable format, (like, when DMA times out).  That is going to be a lot
>>>> of strings added to the driver, so the compile size will definitely
>>>> increase.  If keeping the size small is important, then this sort of verbose thing
>>>> could be hidden behind a second level of debugging...
>>>
>>> That could be implemented similar to what usbmon does. A debugfs file that could
>>> be read and redirected to a file. And there would be no overhead to the
>>> driver, I think. We could call it the 'event log'. :)
>>
>> I was thinking about adding a method that grabbed as many registers
>> as I have info for and dumping them with printk when DMA errors
>> hit.  This would make kernel splats more useful.
>>
>> And also have a debugfs file called 'registers' or similar that one
>> could cat out and get similar info.  And this can let folks look
>> at steady-state or whatever.
>>
>> But, the logic to turn the register bit values into strings would
>> be in the driver (and thus add some code size bloat).
>>
>> My hope is that this would allow a better chance of understanding
>> the stop-DMA errors that some people get reliably (but which I can never reliably
>> reproduce).
>>
>> I'm not sure how that plays into your 'event log' idea, but maybe
>> one will help the other.
> I think the 'let's dump all kinds of random crap when the issue occurs
> until we find somebody that can parse it' approach won't work here, and
> I really think it's not a good idea in general.
>
> In the past the stop-DMA crap has been a symptom with a wild variety of
> different causes, most of which were actually *software* race
> conditions, e.g. dma tx or rx enable during reset, locking issues, etc.

I'm interested in parsing it.  There are folks that can reproduce
this bug every time, and it seems none of the developers can reproduce
it.  So, the only thing I can think to do is to try to get more info
from the folks that see the problem.

The good news is that some of them are desperate enough to run my
hacked kernel, so if such patches are not wanted upstream,
I'll just put it in my tree and see if I can get any useful
info from them that way...

> Let's not carpet-bomb the driver with lots of debug crap that probably
> won't ever lead anybody to any good solution for the remaining issues,
> let's fix stuff the old-fashioned way: by reading the code,
> understanding what's going on, analyzing problems in a systematic way,
> rather than clouding the whole process with assumptions based on old
> bugs that have since been fixed.

That sounds good, and I hope folks are doing that.  But as for me,
unless I can reproduce a problem I don't think I'll be able to
do much, as I don't understand the code that well
and I don't have any access to folks who know the details
of the hardware and such...

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com