Re: device driver crashing on G5 Tower (dual processor)
Re: device driver crashing on G5 Tower (dual processor)
- Subject: Re: device driver crashing on G5 Tower (dual processor)
- From: Derek Kumar <email@hidden>
- Date: Wed, 14 Sep 2005 00:54:56 -0400
No call that I know of, but you can examine
current_thread()->kernel_stack (hopefully that's available in kexts - if
not, you can do the same through the debugger, or for debugging
purposes, examine SPRG1, which maintains a pointer to the current
thread, and proceed from there) and either use an inline asm call to
examine r1 (GPR1, used as the stack pointer), or take the address of a
local (probably less accurate); the delta (SP - kernel_stack) would be
the available stack. You'd have to do this in the deepest call in your
stack, of course. Unless you have reason to believe an overflow is
likely (you're storing a lot of data on the stack, or you have lots of
recursion/deep call stacks), I wouldn't rule out other forms of stack
corruption.
Derek
Herbert wrote:
You are right, my description is a little lite on details. From your
info, it seems likely that I am overflowing the stack.
Is there a call that will let you know how much stack you are using?
On Sep 13, 2005, at 11:00 AM, Derek Kumar wrote:
Herbert,
Did the paniclog (either the "panic.log" file, or the one displayed
with the paniclog kgmacro with the kernel crashdump or debugger
connection) contain a trace from the previous savearea? You can also
manually walk the thread savearea chain in the crashdump, to look at
the state of your thread prior to the immediate fatal exception.
The "corrupt stack" message is often (but not always, of course)
indicative of a stack overflow - the kernel stack size is 4 pages,
and if you overflow that, you will encounter the unmapped "guard
page", causing a DSI. It's often helpful to translate the PC (or
rather srr0, the extrapolated program counter at the time of the
exception) to a symbol, and to look at the contents of the DAR (or
data access register) which holds the faulting address, the access
to which caused the fatal DSI (the "data access" exception). Both of
those should be in the paniclog - does the DAR, for instance, look
like something on your thread's stack? If so, what's the offset from
the base of the stack? You should also use the debugger to examine
the faulting instruction (the PC) and look at what the immediate
cause of the exception was.
Your post is a tad light on details - what sort of synchronization
mechanism are you using? Is there a memory descriptor being passed
down from a user client, whose contents are manipulated prior to an
eventual "down call" through a command gate for serialization/ queueing?
Derek
Herbert wrote:
I'm writing a driver that does encryption. I am testing it on
several machines, including a mac mini, an iMac, and a G5 Tower
(two processors).
The extension is by no means perfect, BUT it dies pretty hard on
the G5.
I do a bunch of copies for testing, and on the mini and iMac I can
do 9+ gigs, but the G5 will die (with a kernel panic) after about
270 megs.
There were a couple of things I tried to narrow it down. I took
out one HD (that didn't help), and I disabled one processor (that
didn't help, either).
The kernel panic shows a data access error, and I'm corrupting the
stack - getting a kernel dump didn't help much because of that.
I suspect a threading problem of some kind, i.e. two threads
accessing my write method, but I've got locks on that. Even with
the locks I sometimes see two writes happening (I print a message
when that happens). With locks, I would have thought I'd never see
that (I see it rarely on the other machines, too).
So I'm out of ideas. Is there some docs someone has seen somewhere
that might help?
Does anyone have any ideas to try?
Thanks in advance.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden