Date: Sun, 09 Jun 2002 00:30:37 -0600 (MDT) From: "M. Warner Losh" <imp@village.org> To: morganw@chemikals.org Cc: mobile@FreeBSD.ORG Subject: Re: newcard panic Message-ID: <20020609.003037.08625897.imp@village.org> In-Reply-To: <20020608231828.P19738-100000@volatile.chemikals.org> References: <20020608.114035.14403964.imp@village.org> <20020608231828.P19738-100000@volatile.chemikals.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20020608231828.P19738-100000@volatile.chemikals.org>
Wesley Morgan <morganw@chemikals.org> writes:
: *AHEM* well now that I had the time to rebuild with stabs debugging
: symbols, here is the trace:
Cool! Thanks for going to the trouble. I hope you've saved the core,
since I have a few questions.
First, I'm assuming that you are doing this against a fairly recent
-current, Please correct me of I'm wrong.
: Fatal trap 12: page fault while in kernel mode
: fault virtual address = 0xdb6c7000
This is a very very odd address to fault at.
: #11 0xc015efcc in pccard_scan_cis (dev=0xd4b1c800,
: fct=0xc015fe82 <pccard_parse_cis_tuple>, arg=0xd91dcb8c)
: at ../../../dev/pccard/pccard_cis.c:1196
Here's where we get into trouble. It looks like the Fault is at the
return line:
1195: return (0);
1196:}
Does that match your sources?
What is mfc_count and mfc_index claim to be at this point?
If you run with a serial console, what effect does adding
hw.pccard.cis_debug=1
to /boot/loader.conf tell you? It should print something very
verbose.
My guess is that we're walking off into the weeds for some reason, and
that we're overrunning some array. This overrun is causing us to
trash the stack, and we're trying to return to a really bogus address.
I'll go take a look at your dumpcis output. I may need you to do
something like
pccardc rdattr 0 0 512
while running an oldcard kernel and send me the results so I can step
through the code with each byte of the CIS that's causing problems
(dumpcis sometimes does bad things to cis output).
scan_cis is way too complex. I'm seriously thinking about re-writing
it to make proper use of functions so that overflows like this are
easier to catch and debug.
Warner
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-mobile" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020609.003037.08625897.imp>