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

From: Edward Ruggeri <smallhand_at_crawblog.com>
Date: Fri, 18 Jul 2008 20:29:15 -0400
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!
Received on Fri Jul 18 2008 - 22:29:16 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:33 UTC