site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com [...] I can track down the bad KEXT if you can send a patch to turn that panic() into a stack trace that will fire just once. Eg, so I can boot up multi-user and pull it out of dmesg, rather than copy down 15 hex addresses at the limit of my vision. I can give you a kernel programmers pig-trick: -- Terry _______________________________________________ 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... On Apr 24, 2010, at 5:50 AM, Andrew Gallatin <gallatin@cs.duke.edu> wrote: Terry Lambert wrote: It would also be useful to know the criminal KEXT; if this one is too hard to track down with your setup, I'd understand if you said not to it, but it can never hurt to ask... Reenable the assert and put a return in the panic routine instead of halting or rebooting the machine. You can write down the hex numbers from the stack trace. You'll have to grab a window and use it as a chalkboard eraser to get the panic off your screen. This will also leave the machine up so you can do a kextstat to see the addresses the kexts are loaded and compare them to the stack addresses and get the culprit. If it happens too early and it gets overwritten by the window server, also switch out printf/kprintf to send it to the console log instead, or add an IOSleep before the return that's long enough for you to scribble it down. It's a pig-trick because you do NOT want to be on that hacked kernel when you get a real panic rather than an assert panic. I also didn't suggest just sending it to the console log in the first place because unless you look there, you'd probably never see it; you'd have been a long time finding your task bug, too. Oh and minimum code footprint on panics avoids double panics. I put this sort of thing into the "general kernel debugging techniques you can't use unless you build your own mach_kernel" bucket. It probably also fits in the "how can I hack kernel/KEXTs on my Mac Book Pro on that long international flight?" bucket. 8-). This email sent to site_archiver@lists.apple.com