March 2006 - Darwin-kernel - lists.apple.com

Re: Tips for resolving hpfBadPmap?
by Terry Lambert 17 Mar '06

17 Mar '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Mar 16, 2006, at 10:39 AM, david tay wrote: Hi, Program received signal SIGTRAP, Trace/breakpoint trap. 0x0009ff50 in hpfBadPmap () My memory allocations are done either myMemory = IOMalloc(), buffer2 = OSTypeAlloc(), buffer2->initSubRange(); buffer2->prepare(); -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… I'm getting random kernel panics when my kext is used with the following message - It seems that the physical mapping is somehow incorrect. Any ideas on what could be causing this? buffer = IOBufferMemoryDescriptor:withOptions(kIODirectionInOut, some_computed_size, page_size); bufferPtr = buffer->getBytesNoCopy(); Check that the pointers returned to your allocation requests have not been denied, before you dereference the pointers. Turn on the debugging flags indicated in the kernel debugging documentation that comes with the kernel debug kits, and also on developer.apple.com, so that you can provide better information other than "it panic's" - e.g. Is it a DAR panic, and if so, at what address does the panic happen, and if it's a low address, is this indicative of you dereferencing a NULL pointer, etc., etc.. If none of this is happening because of a direct coding error, then that panic is somewhat indicative of your kext going off into the weeds and corrupting pmap data structures in memory. If your kext is a device driver for a device that uses DMA, make sure that the DMA target addresses are not required to be in low memory because the device in question is unable to address as much memory as you have in the system, either as a result of a devie limitation or a bus limitation - if you pass a DMA request an out of range memory address, it will (obviously) wrap to that address modulo the number of bits it's capable of addressing, and then the transfer will take place to memory other than the memory you were intending it to go to. In general, it's probably time for you to start to become comfortable with two machine kernel debugging. More information is available from developer.apple.com. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Lost Process?
by Terry Lambert 17 Mar '06

17 Mar '06

site_archiver(a)lists.apple.com Delivered-To: Darwin-kernel(a)lists.apple.com On Mar 16, 2006, at 12:54 PM, Spencer Nielsen wrote: I have an interesting problem that I am trying to understand. These are really bad interfaces to use for this. err = kill( pid, 0); switch(err) { case 0: /* exists, we have permission to kill */ case EPERM: /* exists, we don not have permission to kill */ ... break; case ESRCH: /* process does not exist */ default: /* unexpected error - treat as not exists */ ... break; } Basically, this means you shouldn't use them. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… I have a PreferencePane that uses code based off of Apple's GetPID example (which in turn uses sysctl with CTL_KERN, KERN_PROC and KERN_PROC_ALL) to query the state of currently running processes and searches by name to see if a companion program is currently running. My problem is that right now the results that the sysctl call are not the same results displayed by top and Activity Monitor; most notably that sysctl says that my companion program is currently running, has a PID for it and everything but neither top nor Activity Monitor say that it is. A more proper interface to use for this is to apriori know the pid. This is normally done on UNIX systems by storing the in a file in the directory /var/run. A program reads that file and gets the PID. It then uses code like the following: If you need this information to find the process bundle, this is not how you should do it, either. Instead, you should popen() the program "/bin/ps" with appropriate arguments (specifically, use the '-o' option to retrieve only the field you are interested in, and the '-p' option to select a specific process ID, if desired. Throw away the first line read fron the pipe, as that's the header. You may also want to use the option '-ww' to avoid the 80/132 column output restriction). I'm not going to write sample code for that because I believe that people should be discouraged from using this method, rather than writing bundle information into /var/run file(s) as well (e.g. as the second line, after the pid, or, if the pid is a known value, in a file named "program.pid" in /var/run as a means of supporting multiple instances of the program you are interested in (e.g. for support of a licensed program inFast User Switching, or some other environment). I have tried to sudo kill PID and nothing happens. sysctl always reports back that the companion process is running. Up until now sysctl would accurately report that my program is not running if it is in fact not running and my PreferencePane would work as intended. Because I have been working on developing the companion program I have been launching and stopping it all over the place, both through the debugger, the finder and otherwise. I had been working on one portion of it for the last few days and have been running the machine for a while and put it to sleep a few times. It was not until I returned to working on the PreferencePane that I noticed that it always said that my companion program was still running even though top said that it was not. I started to debug the PreferencePane to see if it was maybe some weird thing that I missed. I isolated it down to the fact that sysctl is still including a process structure for the companion program in the results when as far as I understand, it shouldn't be. I have also created a separate test program that simply calls sysctl and looks for the same process. It also reports back that it is running. I suspect that if I reboot my machine the problem will go away or it will easily reproduce (which will then point me towards the bug which is most likely mine). However, I am afraid that if I do reboot that it will in fact go away and I will not be able to reproduce the behavior (because I have no idea what behavior caused it in the first place). Thus my opportunity to hunt this bug might be gone for a while. I don't know much about how the kernel stores process structures but possibilities that I have run through my head are that something went wrong in the bsd process management of the kernal (but then why does "top" not reflect the same results? does top use sysctl or something else like mach calls?). Then again it could also be random cosmic rays or my own bug that I am still overlooking. So before I do actually reboot I wanted to throw it out there and see if anybody more knowledgeable in these things than me could provide any insight. In general, the sysctl() interfaces you are attempting to use are considered SPI - that means we may change them at any point, and that you should use programs that use utilities that rev when the system revs in order to obtain the information (for example, we guarantee that the /bin/ps program will continue to work, no matter what we do to the sysctl(0 interfaces it uses, or if we change it over to some other interface, etc.). That said, it's likely that your mistake is that you are not examining the process state information from the first sysctl before calling subsequent sysctl's, and therefore are not seeing some of the process state flags that might indicate that the process has been zombied, or that something else is going on (e.g. it's in the process of exiting, etc.). In general, this information is reported back in portable format from / bin/ps, if you give it the appropriate '-o' option to select the information you want back from it. This email sent to site_archiver(a)lists.apple.com

1 0

Lost Process?
by Spencer Nielsen 16 Mar '06

16 Mar '06

site_archiver(a)lists.apple.com Delivered-To: Darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:mime-version:to:message-id:content-type:from:subject:date:x-mailer; b=B1iKkbSYPSdiMeiZGp00pjIL45ftcuxBUvWapPW4XSqBR9Kxyo3fgUfHPk/CwkApFe6+0tX8SXRJ7rIi3A1VVZ3v4FUALpgAS1hXklrm57cYG+F1HxnmZ8Af1NpbDEBGSt/Y1Imb5azLE2aPk5xyQqv4sd4mvthumVLXgeU994w= _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Tips for resolving hpfBadPmap?
by david tay 16 Mar '06

16 Mar '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

ia32_feature_control MSR
by Joshua LeVasseur 16 Mar '06

16 Mar '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com I have a question about Mac OS X on the Core Duo: Regards, Joshua _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… I've inspected the ia32_feature_control MSR on a Mac Book Pro and on the Mac Mini. On the Mac Book Pro, the ia32_feature_control MSR is untouched, and still has the CPU reset value of 0. On the Mac Mini though, the firmware sets this register to 1. Could someone from Apple explain why they have different values? Is it a bug? Or is it a "Pro" feature, which the Pro products get to have? I can understand if every x86 Mac sets this value to 1 for security reasons. But the Mac Book Pro doesn't set it to 1. Note that the agent setting the value to 1 is the Mac Mini firmware. Darwin doesn't do it. Is there someway I can configure the Mac Mini firmware to ignore the register, or to set the value to 5? Or is that a Pro capability? This email sent to site_archiver(a)lists.apple.com

1 0

Re: FW: Panther OS installation
by Peter Bierman 15 Mar '06

15 Mar '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com -pmb _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… I am not sure if this is the right place to put this question. If it is not plz redirect me. I have PowerPC G5 Panther OS X installation CD. I want to install Powerbook G4 with Panther OS X. But with PowerPC G5 cd I am unable to install powerbook? Are these installation CD are platform specific?? Can I somehow change the CD contents to install for Powerbook? Please help me as I donot want to purchase one more CD. Install CDs are not platform specific, but you do have to use a CD that shipped AFTER the hardware you're trying to install on. There were several PowerBook G4 models that shipped _after_ the G5, and after Panther. If your PowerBook is newer than the install CD, you'll have to use another CD, preferably the one that came with the PowerBook. This email sent to site_archiver(a)lists.apple.com

1 0

FW: Panther OS installation
by Priti Rathi 15 Mar '06

15 Mar '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Thread-index: AcZHaBnBzyA9ceejToueDwBGIKfZtAAnWcjQ _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

NewWorld CD Booting?
by Andrei Warkentin 15 Mar '06

15 Mar '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:mime-version:x-gpgmail-state:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer; b=Rh7RDxMduUatPbJpoId9myIDmn7hVmv+zZ3uRnvXj1UKN7j3U5bk+k3fFksu4R7VlX48hqyded22gZ3IQgp/QPIl1hO9MSTgPUKevSIjGRjMRSPCQ2B2lCJ4dL0BPmyLV6ArFhb5Luqevo0BKeQGgI944th41ghqIkzyCFhic8Y= Hello, I created the bootinfo file (like this): <CHRP-BOOT> <COMPATIBLE> MacRISC MacRISC3 MacRISC4 </COMPATIBLE> <DESCRIPTION> EKP++ for Mac. </DESCRIPTION> <BOOT-SCRIPT> boot cd:,\ekp++\kernel </BOOT-SCRIPT> </CHRP-BOOT> So what works: 0> boot cd:,\ekp++\kernel (kernel is an ELF image) 0> boot cd:,\ekp++\BootX (BootX is a bootinfo file) 0> boot cd:,\\:tbxi What doesn't work: Hold down "C" to boot from CD. Andrei Evgenievich Warkentin andrey.warkentin(a)gmail.com Cell: (+1) (847) 321-15-55 _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… I really don't know who else to approach with this, ). Basically I hack away at my "kernel attempt" on a an '05 iBook (dev system is 10.4), and decided to look into making a bootable CD so I could use QEMU PPC emulator instead of rebooting my iBook to test after every compile. Created a a CD image with hdiutil. Formatted the slice with HFS+. Blessed the right folder. Basically OF considers the made CD a "bootable CD". Moreover, I can boot everything fine if I do something like... boot cd:,\ekp++\BootX <--- note that BootX is what bless(8) copies my bootinfo script as to the image. By "everything fine", I mean I get the gray screen, then it says "Booting ELF" and I see the text printed by my "kernel". If I boot up while holding "C", I get the gray screen, I can hear the CDROM spin up, then I get kicked back to the white and black OF screen and there is an error about memory access violation. Is there some technical difference between both boot-ups? Maybe the OF entry is passed differently? Maybe stdout handle isn't open? Help :(. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Hello Debugger/Goodbye Machine
by Eric Long 14 Mar '06

14 Mar '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User-agent: Microsoft-Entourage/11.1.0.040913 > it appears that forcing the PMU driver (on > portables like the PB G4 which are PMU-based) to operate in polled > mode by adding the "pmuflags=1" boot-arg will bypass one possible > cause of shutdowns while debugging That seemed to do the trick for my PB. Thanks for the info. > Also, from your description, it appears that you're seeing a > spurious "breakpoint" entry, perhaps because the "NMI" button press > isn't being adequately de-bounced. Feel free to add to the > information in radar 4473217 (with a backtrace from the spurious > breakpoint) if you continue seeing that with the pmuflags boot-arg. Yeah, that's what it is. I am using the shift-ctrl-opt-cmd-esc method to break. The backtrace shows: #0 Debugger (message=0x525754 "USB Programmer Key") at /SourceCache/xnu/xnu-792.6.61/osfmk/ppc/model_dep.c:639 #1 0x00512860 in mhp.1758 () Cannot access memory at address 0x436a68 #2 0x00512710 in mhp.1758 () Cannot access memory at address 0x436a68 #3 0x00512298 in mhp.1758 () Cannot access memory at address 0x436a68 #4 0x0051221c in mhp.1758 () Cannot access memory at address 0x436a68 #5 0x002d0040 in IOInterruptEventSource::checkForWork (this=0x1f97c00) at /SourceCache/xnu/xnu-792.6.61/iokit/Kernel/IOInterruptEventSource.cpp:196 #6 0x002cef08 in IOWorkLoop::threadMain (this=0x1eaf880) at /SourceCache/xnu/xnu-792.6.61/iokit/Kernel/IOWorkLoop.cpp:267 I added the info to the bug report. Thanks, Eric _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Hello Debugger/Goodbye Machine
by Derek Kumar 14 Mar '06

14 Mar '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com My two machines are a 15" 1.5GHz G4 PB and a Dual 2Ghz G5 Tower. Both running 10.4.5. Both with the Xcode 2.2.1 dev tools. Program received signal SIGTRAP, Trace/breakpoint trap. 0x00095dec in Debugger () And the PB immediately shut down! Huh? This is pretty much a fresh system on the PB. The only third party extension besides mine installed is Cisco VPN extension. I've ensured the sources on both machines are in sync, if that has any bearing. I don't know what gives here. Any ideas? Thanks in advance, Eric _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)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(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… After some investigation, it appears that forcing the PMU driver (on portables like the PB G4 which are PMU-based) to operate in polled mode by adding the "pmuflags=1" boot-arg will bypass one possible cause of shutdowns while debugging (when breakpoints cause kernel debugger entry in the middle of a PMU transaction, causing the PMU watchdog to trigger on timeout). The correlation, if any, with the presence of the Airport card is unclear. Hope that helps, Derek P.S.: Also, from your description, it appears that you're seeing a spurious "breakpoint" entry, perhaps because the "NMI" button press isn't being adequately de-bounced. Feel free to add to the information in radar 4473217 (with a backtrace from the spurious breakpoint) if you continue seeing that with the pmuflags boot-arg. On Mar 9, 2006, at 3:14 PM, Eric Long wrote: I'm wondering if anyone has seen the kind of problems I am experiencing debugging my kext with gdb. I'm following the same basic process for debugging as the Hello Debugger example: http://developer.apple.com/documentation/Darwin/Conceptual/ KEXTConcept/KEXT ConceptDebugger/hello_debugger.html If I attempt to make the PB the target and the Tower the dev machine, at the point in gdb when I enter "continue" I immediately get a message in the Terminal that says: I haven't set any breakpoints nor does my kext have any code to drop into the debugger. Just selecting continue after attaching shouldn't get tangled with my kext as far as I know, so I don't what is dropping into the debugger or causing the machine to shut down. If I go the other direction and make the PB the dev machine and the tower the target, I don't see this happen, but when I try to list any sources all I get is a line number and the path to the source. It's completely useless. The last time I did kext debugging was under Panther. I didn't have problems like this. This email sent to drk(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0