site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com User-agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) Herbert, The extension is by no means perfect, BUT it dies pretty hard on the G5. 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 (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/drk%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... 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). 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? This email sent to drk@apple.com This email sent to site_archiver@lists.apple.com