October 2006 - Darwin-kernel

Re: panic.log on Intel?
by Peter Lovell 19 Oct '06

19 Oct '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hi Justin, Cheers.....Peter On Oct 18, 2006, at 8:59 PM, Justin C. Walker wrote: On Oct 18, 2006, at 11:33 , Peter Lovell wrote: Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for the Absorption of Federal Funds -------- If you're not confused, You're not paying attention -------- _______________________________________________ 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.… that's true, but the kernel dump code doesn't use the arp table. It has its own values provided from the establishment of the default gateway (and maybe something else - I haven't looked at the code in a little while). So a permanent arp entry won't help, unfortunately. A small note on the kernel dump server. [snip] Your choices are to put the dump server on a different subnet (the router will obviously forward in this case, as that what it must do) or write your own arp code in a modified kernel. That's what we did, since we already had kernel mods. Most folks won't go that way :) You can also make a permanent ARP entry ("man arp") for the kernel dump server on all your local systems. This doesn't help, of course, after the fact :-} This email sent to site_archiver(a)lists.apple.com

1 0

SocketFilter, Sockets & PCB
by Stephane 19 Oct '06

19 Oct '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Stupid question: ---------------- _______________________________________________ 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.… Is it possible for a socket without a pcb to be seen by a (KPI) socket filter? This email sent to site_archiver(a)lists.apple.com

1 0

RE: Thread locks in 10.3
by Quinn 19 Oct '06

19 Oct '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

RE: Thread locks in 10.3
by Quinn 19 Oct '06

19 Oct '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

RE: Filesystem bundles
by Quinn 19 Oct '06

19 Oct '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com What happens when the Finder Eject button is pressed, and how can I register my filesystem's userspace client to receive notification when that happens so I can unmount? <http://developer.apple.com/technotes/tn2004/tn2124.html> S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware _______________________________________________ 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.… At 15:18 -0700 17/10/06, Michael Welch wrote: In contrast to mount, unmount is handled pretty much automatically by the system. The Finder calls File Manager (FSEjectVolumeSync/Async), which calls Disk Arb (DADiskUnmount, DADiskEject), which, to unmount the volume, fork/exec's <x-man-page://8/umount> (IIRC), which calls <x-man-page://2/unmount>, which does the unmount, calling your VFSOPUnmount entry point. Disk Arb also listens for unmount notifications via <x-man-page://3/notify_register_mach_port>. If a volume is unmounted outside of the scope of Disk Arb (you run "unmount" from the command line, say), Disk Arb will hear about it that way. If you file system has a user space helper daemon that needs to know about the unmounts of a particular file system, the best solution is to have your VFSOPUnmount routine notify your daemon through whatever communication channel it's using for general file system operations. This is exactly what WebDAV does. Check it out by searching the WebDAV source for "WEBDAV_UNMOUNT". The gotcha that I've encountered in getting unmount to work is that your mount tool has to call <x-man-page://3/realpath> on the mount point before passing it to <x-man-page://2/mount>. If you don't do this, it causes problems for <x-man-page://8/umount>. However, this wouldn't explain the hangs that you're seeing. To debug that, you probably should start by enabling DiskArb logging. Instruction for doing this are in the Technote 2124 "Mac OS X Debugging Magic". This email sent to site_archiver(a)lists.apple.com

1 0

Re: BSD Flags further
by Jeffrey Ellis 19 Oct '06

19 Oct '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Thread-index: AcbzPx/hXk/Ktl8yEdu9uAANk0QgEg== Thread-topic: BSD Flags further User-agent: Microsoft-Entourage/11.2.5.060620 Thanks, Mike. I'll give it a try :) All My Best, Jeffrey on 10/18/06 10:55 AM, Michael Smith at drivers(a)mu.org wrote: > There are instructions printed as you enter single-user mode, however > I find that > > # mount / > > is sufficient. > > = Mike > > On Oct 18, 2006, at 10:48 AM, Jeffrey Ellis wrote: > >> Hi, Michael-- >> >> Thanks... Sorry... How do I do the remount? >> >> All My Best, >> Jeffrey >> >> >> >> on 10/18/06 10:38 AM, Michael Smith at drivers(a)mu.org wrote: >> >>> >>> On Oct 18, 2006, at 9:22 AM, Jeffrey Ellis wrote: >>> >>>>> Each of these three pairs comes in two variants; the 'u' version >>>>> which permits the >>>>> flag to be set and reset by the owner, or root, at runtime, and the >>>>> 's' version which >>>>> can be set at runtime, but cannot be cleared except in single-user >>>>> mode. >>>> >>>> How can I reboot into single-user mode to clear these files? >>> >>> Hold down command-S during the boot chime, and keep it held until you >>> see the prompt. >>> >>> Note that you will only have the root filesystem visible, and you >>> will have to remount it read/write before you can change anything. >>> >>> = Mike >>> >> >> > _______________________________________________ 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: BSD Flags further
by Jeffrey Ellis 19 Oct '06

19 Oct '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Thread-index: AcbzPxBiTtMHf18yEdu9uAANk0QgEg== Thread-topic: BSD Flags further User-agent: Microsoft-Entourage/11.2.5.060620 Hi, Terry-- Thank you very much. This was exactly what I needed... :) All My Best, Jeffrey on 10/18/06 3:19 PM, Terry Lambert at tlambert(a)apple.com wrote: > On Oct 18, 2006, at 9:22 AM, Jeffrey Ellis wrote: > >> on 10/18/06 4:01 AM, Michael Smith at drivers(a)mu.org wrote: >>> On Oct 18, 2006, at 12:26 AM, Jeffrey Ellis wrote: >>>> Can someone explain what the actual effect of setting each flag is, >>>> namely: >>>> >>>> arch >>>> opaque >>>> nodump >>> >>> These three have no significant meaning. >> >> I actually read a discussion somewhere, where the user was saying that >> setting the opaque flag was supposed to help in some instances >> (sorry, I >> didn't quite follow what they were trying to do, and I can't find that >> thread anymore...) >> >> The only definition I've found so far is: >> >> The opaque flag will prevent a full union stack >> traversal on later lookups. >> >> I have absolutely no idea what this means. > > Actually: > > more /usr/include/sys/stat.h > ... > /* > * Definitions of flags stored in file flags word. > * > * Super-user and owner changeable flags. > */ > #define UF_SETTABLE 0x0000ffff /* mask of owner changeable > flags */ > #define UF_NODUMP 0x00000001 /* do not dump file */ > #define UF_IMMUTABLE 0x00000002 /* file may not be changed */ > #define UF_APPEND 0x00000004 /* writes to file may only > append */ > #define UF_OPAQUE 0x00000008 /* directory is opaque wrt. > union */ > /* > * The following bit is reserved for FreeBSD. It is not implemented > * in Mac OS X. > */ > /* #define UF_NOUNLINK 0x00000010 */ /* file may not be removed or > renamed */ > /* Bits 0x0020 through 0x4000 are currently undefined. */ > #define UF_HIDDEN 0x00008000 /* hint that this item should > not be */ > /* displayed in a GUI */ > /* > * Super-user changeable flags. > */ > #define SF_SETTABLE 0xffff0000 /* mask of superuser > changeable flags */ > #define SF_ARCHIVED 0x00010000 /* file is archived */ > #define SF_IMMUTABLE 0x00020000 /* file may not be changed */ > #define SF_APPEND 0x00040000 /* writes to file may only > append */ > /* > * The following two bits are reserved for FreeBSD. They are not > * implemented in Mac OS X. > */ > /* #define SF_NOUNLINK 0x00100000 */ /* file may not be removed or > renamed */ > /* #define SF_SNAPSHOT 0x00200000 */ /* snapshot inode */ > /* NOTE: There is no SF_HIDDEN bit. */ > --- > > If it's not clear from the comments: > > UF_NODUMP The "dump" command (man dump) will ignore the file > UF_OPAQUE If a directory has this flag, and the file system is mounted > over top of another FS which has the same directory, then only this > directory will show, rather than the underlying FS directory being > visible. > > NODUMP is generally useful only if your backup utility knows about it. > > OPAQUE is generally useful for things like mounting an object file > directory over top of a CDROM so you can e.g. do builds of source code > off a CDROM without neding to copy it all to a writeable disk. > > SF_ flags are "system" flags, as opposed to UF) flags, which are user > flags. > > As Mike noted, you can't reset SF_ flags if the kern.securelevel > sysctl is 1 or higher. Mac OS X runs at secure level 1 in mutiluser, > and secure level 0 in single user. For more information on secure > levels, which are generally not a user feature for Mac OS X, you can > look at the FreeBSD "init" documentation, available at: > > <http://www.freebsd.org/cgi/man.cgi?query=init&apropos=0&sektion=0&manpath=F… > eBSD+6.1-RELEASE&format=html >> > > Bottom line is that you will not be unable to reset these except in > single user mode, for security reasons, so be selective in where and > when you set 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.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: panic.log on Intel?
by Justin C. Walker 19 Oct '06

19 Oct '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Oct 18, 2006, at 11:33 , Peter Lovell wrote: Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for the Absorption of Federal Funds -------- If you're not confused, You're not paying attention -------- _______________________________________________ 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.… A small note on the kernel dump server. [snip] Your choices are to put the dump server on a different subnet (the router will obviously forward in this case, as that what it must do) or write your own arp code in a modified kernel. That's what we did, since we already had kernel mods. Most folks won't go that way :) You can also make a permanent ARP entry ("man arp") for the kernel dump server on all your local systems. This doesn't help, of course, after the fact :-} This email sent to site_archiver(a)lists.apple.com

1 0

Re: BSD Flags further
by Terry Lambert 18 Oct '06

18 Oct '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Oct 18, 2006, at 9:22 AM, Jeffrey Ellis wrote: Can someone explain what the actual effect of setting each flag is, namely: arch opaque nodump The only definition I've found so far is: The opaque flag will prevent a full union stack traversal on later lookups. Actually: If it's not clear from the comments: NODUMP is generally useful only if your backup utility knows about it. -- 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.… on 10/18/06 4:01 AM, Michael Smith at drivers(a)mu.org wrote: On Oct 18, 2006, at 12:26 AM, Jeffrey Ellis wrote: These three have no significant meaning. I actually read a discussion somewhere, where the user was saying that setting the opaque flag was supposed to help in some instances (sorry, I didn't quite follow what they were trying to do, and I can't find that thread anymore...) I have absolutely no idea what this means. more /usr/include/sys/stat.h ... /* * Definitions of flags stored in file flags word. * * Super-user and owner changeable flags. */ #define UF_SETTABLE 0x0000ffff /* mask of owner changeable flags */ #define UF_NODUMP 0x00000001 /* do not dump file */ #define UF_IMMUTABLE 0x00000002 /* file may not be changed */ #define UF_APPEND 0x00000004 /* writes to file may only append */ #define UF_OPAQUE 0x00000008 /* directory is opaque wrt. union */ /* * The following bit is reserved for FreeBSD. It is not implemented * in Mac OS X. */ /* #define UF_NOUNLINK 0x00000010 */ /* file may not be removed or renamed */ /* Bits 0x0020 through 0x4000 are currently undefined. */ #define UF_HIDDEN 0x00008000 /* hint that this item should not be */ /* displayed in a GUI */ /* * Super-user changeable flags. */ #define SF_SETTABLE 0xffff0000 /* mask of superuser changeable flags */ #define SF_ARCHIVED 0x00010000 /* file is archived */ #define SF_IMMUTABLE 0x00020000 /* file may not be changed */ #define SF_APPEND 0x00040000 /* writes to file may only append */ /* * The following two bits are reserved for FreeBSD. They are not * implemented in Mac OS X. */ /* #define SF_NOUNLINK 0x00100000 */ /* file may not be removed or renamed */ /* #define SF_SNAPSHOT 0x00200000 */ /* snapshot inode */ /* NOTE: There is no SF_HIDDEN bit. */ --- UF_NODUMP The "dump" command (man dump) will ignore the file UF_OPAQUE If a directory has this flag, and the file system is mounted over top of another FS which has the same directory, then only this directory will show, rather than the underlying FS directory being visible. OPAQUE is generally useful for things like mounting an object file directory over top of a CDROM so you can e.g. do builds of source code off a CDROM without neding to copy it all to a writeable disk. SF_ flags are "system" flags, as opposed to UF) flags, which are user flags. As Mike noted, you can't reset SF_ flags if the kern.securelevel sysctl is 1 or higher. Mac OS X runs at secure level 1 in mutiluser, and secure level 0 in single user. For more information on secure levels, which are generally not a user feature for Mac OS X, you can look at the FreeBSD "init" documentation, available at: <http://www.freebsd.org/cgi/man.cgi?query=init&apropos=0&sektion=0&manpath=F… > Bottom line is that you will not be unable to reset these except in single user mode, for security reasons, so be selective in where and when you set them. This email sent to site_archiver(a)lists.apple.com

1 0

Re: panic.log on Intel?
by Derek Kumar 18 Oct '06

18 Oct '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Derek On Oct 18, 2006, at 2:33 PM, Peter Lovell wrote: A small note on the kernel dump server. Regards.....Peter On Oct 13, 2006, at 5:26 PM, Brian Bechtel wrote: Thank you. That was quite helpful. I imagine we're doing something to induce random memory corruption, which is not a good sign. Unfortunately, this customer is pretty clueless, and cannot setup dumps. To setup your coredump server (from <http://developer.apple.com/technotes/tn2004/tn2118.html>) do the following: mkdir /PanicDumps chmod ugo+wx /PanicDumps cat > /tmp/macosxkdump <<EOF service macosxkdump { disable = no type = UNLISTED socket_type = dgram protocol = udp port = 1069 user = nobody groups = yes server = /usr/libexec/kdumpd server_args = /PanicDumps wait = yes } EOF sudo cp /tmp/macosxkdump /etc/xinetd.d sudo kill -HUP `cat /var/run/xinetd.pid` _______________________________________________ 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/vpndev%40mac.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/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.… The 10.4.8/Intel kernel (and, I believe, some PPC server versions, but I haven't verified this) performs ARP discovery, and also adds a couple of boot-args to specify the IP of the router to forward to (if discovery fails, useful if the default gateway doesn't forward to the specified server) and another to specify the crashdump server's port. There's also a boot-arg that specifies the interface the kernel debugger (and crashdumps) are bound to. These are, respectively, "_router_ip", "panicd_port" and "kdp_match_name". In order for this to work (at least as recently as 10.4.6, haven't checked 10.4.7 and there's no source available yet for 10.4.8) you should plan to have your dump server on a different subnet. This is because the kernel dump code on the crashed machine does not ARP for the ethernet address of the dump server. Instead it sends it to the default gateway and expects the gateway to forward it. Some do, many do not. Even for some routers which support same- subnet-forwarding, sysadmins not infrequently disable it for various reasons. Your choices are to put the dump server on a different subnet (the router will obviously forward in this case, as that what it must do) or write your own arp code in a modified kernel. That's what we did, since we already had kernel mods. Most folks won't go that way :) On 10/13/06, Andrew Gallatin <gallatin(a)cs.duke.edu> wrote: Derek Kumar writes: > As to why the backtrace doesn't show any more, it's because the > framepointer linkage was terminated prematurely (zeroed)...could be > stack corruption. If you can connect to the machine or examine a > crashdump, you can try trawling the stack for traces. I'd also > suggest verifying that you were, in fact, on the appropriate thread > stack at the time of the panic. Here's a simple thing. Set up a kernel coredump server on one of your machines. It doesn't have to be fast, but it helps to have enough hard disk space. On the client (i.e. panic-prone machine) sudo nvram boot-args="debug=0xd44 _panicd_ip=10.0.40.2" {and reboot for this to take effect.} where you replace 10.0.40.2 with the IP address of your coredump server. You must restart to enable this setting. Next time that machine panics, you'll get a core dump. This email sent to vpndev(a)mac.com This email sent to drk(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0