site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Sorry, but DTS is the best bet. -- Terry Hi Chris, why don't you send directly a private e-mail to Terry or Mike or the both ? -mm w On Sep 17, 2007, at 2:33 PM, Shawn Erickson wrote: I am getting a kernel panic and I wonder if it is okay to post the kernel panic log output here for a possible answer. _______________________________________________ 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/openspecies%40gmail.com This email sent to openspecies@gmail.com -- echo zapydapntpd.rxltw@nzx | tr a-z@. p-za-o.@ _______________________________________________ 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/tlambert%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... I'm sure I'm not saying anything that isn't common knowledge to most of the people here, but it occasionally needs said... Neither Mike nor I have the ability to verify access to seed builds, or authenticate NDAs, which means we can't talk to anyone about unreleased product outside channels without authorization. If, however, it shows up in a bug report, and that bug report gets handed off to one of us, then we can jump in on that side of things, since that means there's DTS authentication. It also means you are more likely to get a fix, because we can point to a documented customer issue to justify spending the time working on the problem to our management, and have a place to hang the fix so that it will make it through the process into a customer build. If you can reproduce the problem in a shipped version of the OS (e.g. a Tiger release), then we could just pull out the decoder rings and look for you. Often, though, the stack traceback won't be enough for a panic fix, if there is a KEXT involved. In those cases, we like to get a core dump attached to a bug report so we can poke around and see what's going on; it's not as good as two machine debugging, but it lets us better track down side effects of side effects. That's the other reason for going through the normal bug reporting process. The best bug report is one with a reproducible test case, rather than a frozen core; that way if we have to go to hardware level debugging (JTAG, etc.), then we can. That's something that would be necessary for, for example, an issue in the pmap layer on a 64 bit machine, where not all of the structures are visible from virtual rather than physical memory addressing (which could also leave them missing from a kernel core image). The absolute best bug report, of course, has a patch attached to it. 8-). On Sep 18, 2007, at 7:41 AM, mm w wrote: On 9/17/07, driggett@mac.com <driggett@mac.com> wrote: Shawn, I have submitted a bug report to Apple. What I wanted to know is if it is permissible to show the summary for the kernel panic and see if someone can tell me if it is an easy pointer to a fix like I missed something or not. Thanks, Chris On 9/17/07, driggett@mac.com <driggett@mac.com> wrote: Review the release notes for the Leopard preview to understand how to submit an issue like this. -Shawn This email sent to tlambert@apple.com This email sent to site_archiver@lists.apple.com