Re: 7.0 CURRENT kernel's ath driver causes page fault, kernel panic (debugging kernel)

On Fri, Jul 18, 2008 at 5:29 PM, Edward Ruggeri <smallhand_at_crawblog.com> wrote:
> On Fri, Jul 18, 2008 at 6:36 AM, Garrett Cooper <yanefbsd_at_gmail.com> wrote:
>> Some notes:
>>
>> 1. *blinks*... I hope you mean 8-CURRENT, not 7-CURRENT. 7 hasn't been
>> CURRENT for some months now (~6 months IIRC).
>
> Oh my, I am an idiot.  I'm using 7-STABLE, making this the wrong list
> to ask; sorry.  I guess I could repost to freebsd-stable in addition
> to filing a PR.  Would that be wise?
>
>> 2. pciconf -lv might help with the PCI ID info. Then someone might be
>> able to tie your card back to the appropriate chipset.
>
> This gives me:
> ath0_at_pci0:3:0:0:        class=0x020000 card=0x058a1014 chip=0x1014168c
> rev=0x01 hdr=0x00
>    vendor     = 'Atheros Communications Inc.'
>    device     = 'AR5212 Atheros AR5212 802.11abg wireless'
>    class      = network
>    subclass   = ethernet
>   class      = base peripheral
>
> I get 167 pages on google that contain ar5212 and 0x1014168c and
> 0x058a1014.  I only get one with ar5006ex instead of ar5212.  I'm
> inclined to believe my Lenovo representative was wrong; she's just a
> sales rep and asked around about the part...
>
>> 3. KDB, DDB, WITNESS and INVARIANTS support compiled into the kernel
>> would be extremely helpful, if not required to debug your issue.
>
> I'm currently recompiling the kernel with these debug options:
>
> makeoptions     DEBUG=-g                # Build kernel with gdb(1) debug symbols
> options         KDB
> options         DDB
> options         INVARIANTS
> options         WITNESS
>
> As soon as it's done compiling, I'll try reproducing the error.  I've
> added "set dumpdev="/var/crash" in /etc/rc.conf.
>
>> As for the actual debug process, there's a spot in the dev handbook
>> about it (http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html),
>> but when I tried debugging my issue with NTFS and SMB I didn't really
>> find it helpful to be honest...
>
> Once I have a core dump, how should I proceed?  Use kdb, and execute
> "list *[instruction pointer]" to find out what (NULL) pointer is being
> dereferenced?  Run backtrace?  If I post a PR, is it likely that
> someone can guide me through this?  I'm fairly familiar with C, but my
> experience using debuggers is very limited...
>
>> You may also have to compile without SMP and with the 4BSD scheduler
>> just to see whether or not it's an issue reproducible with the ULE
>> scheduler, the driver, or something else...
>
> After I get the dump with the current options (+ debug options), I'll
> try w/o SMP and ULE...
>
>> Hopefully this gets you started on the right path...
>> -Garrett
>
> Thanks so much, Garrett!

No problem :).

The steps I just had you go through were to rule out the kernel
scheduler and multiprocessing -- 2 points that make debugging issues
like these difficult. With all of the locking changes in 7-RELEASE,
it's harder to track down driver bugs to some extent.

The error seems straightforward (albeit it may not sound like it)
though: it's an issue with how your card is interfacing with the
driver.

-Garrett