August 2007 - Darwin-kernel

Re: printf logs are not getting printed properly on system.log
by Carlos Calderon 28 Aug '07

28 Aug '07

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: printf logs are not getting printed properly on system.log
by Herb Petschauer 28 Aug '07

28 Aug '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZMjwroF6z1mveVY4jidyJz+XoNP5TRpGL0LYSQTc03IM5B370PLfF6RmYieMtMDYNUGL5zirpwGHrGmMzz38HKq/tccwRaTTH7QmqkMqBB66gdrUkFAy0hyIC1U+czr85yI4RFq5lOEv/sOAlz0LMbc3qF2VTcqyBfBb3C8t6H0= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nYKsTA2BnF7NHH2tdXR21KukZsMdXj8EJOxqJ65hntII1Sw7Ol4sY9qUjOy1ouMgYfuOU9RqTj1TXUnJjy5hImfn49M29TcXhK0o0ekJjgdW5eMiGVHnXmxy/di16h4EHTRhlyWckvUHiD3EIxjyi6feubhLHffSjNzXJyRZrLo= Search the archives for "Firewire kprintf" <http://search.lists.apple.com/> On 28/08/07, JanakiRam <johnyatforums(a)gmail.com> wrote: > Hi Terry, > > I'm using logging ( IOLog ) for debugging purpose. Can you > provide some links/documentation for firewire debugging KEXT ? . > > Please help me to solve this. Thanks in Advance. > > -JanakiRam. > > > On 8/25/07, Terry Lambert <tlambert(a)apple.com> wrote: > > > > Basically, if you want reliable communication from the kernel to user > > space, don't use logging, use one of the IPC facilities (sockets, > > IOKitUser, etc.) instead. If this is for debugging, and it's critical > > you don't lose data, then use the firewire debugging KEXT instead. > > > > -- 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/bogvardi%40gmail.com > > This email sent to bogvardi(a)gmail.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: printf logs are not getting printed properly on system.log
by JanakiRam 28 Aug '07

28 Aug '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=Uxa6maNxUoqqkVfCnAVcI2nxkW9uW5uNcsnuho00mH4+xTU2wv+4DHsPAxmJc+luZgca2C7xwpx8neMrewpp6pxEEjccsOo7tlw0G601sHc9dREZsl2Ot43F5gcRTbplqaXagYatEzDtDqVd5ZEb8dsrINPU3o/6wKs7q9KquHk= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=mK1QIWHBlUaXkDBL2x9ofNnqXk86gR3T0JiTE24FJU2xskxtgrgHJxCkPRXxVIDyt8h0LU8/DumD4Y0LRBxQ4ongiZBwrv3Kux7gIPazs0trf5YIxaKeL2fL0mDxt7n6fkwJChc5WRzJF+VQh+aK/cBvcXU1IBwVSYpGoPuVqPc= _______________________________________________ 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: Wait-Queue Panic while loading the Kext
by Garth Cummings 27 Aug '07

27 Aug '07

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: Reg : Understanding Kernel Panic - (panic(cpu 0 caller 0x00036B48): wait queue deadlock - wq=0x4061504, cpu=0)
by JanakiRam 27 Aug '07

27 Aug '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=LGnlVXbZDaOptu/fPdwCIjWn9IZowi35pe+lMtKI/LvOz912LjvTbAm5WoDXVru24VZWYhpWxB9PPNWfC+OwMwL5qPRpfB3mSopHxizSlhgljuFQmxMF7imZ6MzdBwWLEk/SBCH5jok0hSYWo2ch3ByOIpI49yHJKAwureD3o3s= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=uhOCQgtSmoe7ZRRE6DpZrqgdAVFEwiQVJFvlDOD9EjXDIqFrhTzasRdM4eeIPKOliCuH3Az9XqcwM61uR6voGWHK6Im1uTGfea7M89DAeqBOl0my1TNyYlcaGIXP1X9SIhDAlI2E41yd28XR3k5mTqIx7xPJjjvEJ6ntXZSx8Vc= _______________________________________________ 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: mbuf_pullup practically useless
by Andrew Gallatin 27 Aug '07

27 Aug '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Platon Fomichev writes: > Hey Andrew > > Thanks for quite a complete answer! Btw speaking about 32-bit kernel > - will Leopard feature a full 64-bit kernel? From what I've heard > this seems to be the case. Hope things will improve then a bit. > The first rule of Leopard is that you don't talk about Leopard, but the the publically available information talks only about "64-bit drivers". Note, there is no mention of a 64-bit kernel. The "64-bit driver" stuff is talking about overcoming the limit in Tiger where 64-bit applications couldn't talk to devices through the Apple IOKit mechanisms, as there was no 64-bit version of libIOKit. FWIW, you can get around this in Tiger by using (faster, more portable) Unix ioctls via 64-bit applications. Drew _______________________________________________ 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: Poll support implementation
by Jernej Azarija 27 Aug '07

27 Aug '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha1; c=relaxed/simple; d=hermes-softlab.com; s=hsl2007; t=1188220928; bh=y3BBfN7zkI9lwR1Ih8u6MCwz3pU=; h=X-Virus-Scanned:Received:Received:X-MimeOLE:Content-class: MIME-Version:Content-Type:Subject:Date:Message-ID:X-MS-Has-Attach: X-MS-TNEF-Correlator:Thread-Topic:Thread-Index:References:From:To: Cc; b=cS8v0kTb9AQlLNhfiwXyGA9WvYd6aAARyDSjuRa1j+TtXNgzwrCnzrREceNL y+7AXNKw533yfywnjAcdJ9jU1mLyAtHyoXQsDB5Y2VTPXJDyFqJeRzl0PtGAnWFTOU/ n3EYrVVaodu5Ghhvuo2eku+G18HYQkTwOHM6Tn2cs2IQ= Thread-index: AcfTbQ8VgOO7atYlRuae8d1EtYfRcAVQBW3W Thread-topic: Poll support implementation _______________________________________________ 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: mbuf_pullup practically useless
by Platon Fomichev 27 Aug '07

27 Aug '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hey Andrew Best regards, Stauff__ On Aug 27, 2007, at 4:58 PM, Andrew Gallatin wrote: Ah, one of my pet peeves :) At least part of the reason for this is the decision to use a 32-bit kernel with a 4GB address space rather than a 64-bit kernel on 64-bit hardware. Every syscall to the kernel takes a bit longer because copying the syscall arguments is no longer just a simple bcopy with a fault handler. This is because, unlike on most other *nixes, the kernel and the application don't share an address space. I'm pointing my finger at this because I've seen similar slowdowns running 32-bit linux with the 4G/4G kernel/user address space patch applied. _______________________________________________ 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.… Thanks for quite a complete answer! Btw speaking about 32-bit kernel - will Leopard feature a full 64-bit kernel? From what I've heard this seems to be the case. Hope things will improve then a bit. Platon Fomichev writes: As another side-note I am constantly in question why does ./configure like scripts take an exceptionally big amount of time on even most powerful Mac Pro's compared to FreeBSD? Is this related to fork()/ exec () or sh port itself or something else? Anyone ever did some research on this? Drew This email sent to site_archiver(a)lists.apple.com

1 0

Re: mbuf_pullup practically useless
by Andrew Gallatin 27 Aug '07

27 Aug '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Platon Fomichev writes: > > As another side-note I am constantly in question why does ./configure > like scripts take an exceptionally big amount of time on even most > powerful Mac Pro's compared to FreeBSD? Is this related to fork()/exec > () or sh port itself or something else? Anyone ever did some research > on this? Ah, one of my pet peeves :) It is at least partially because most system calls take roughly between a factor of two and an order of magnitude longer on MacOSX than they do on other *nix platforms on the same hardware. Run lmbench and compare the results between MacOSX and Linux (or Solaris, or FreeBSD) on the same hardware if you don't believe me. At least part of the reason for this is the decision to use a 32-bit kernel with a 4GB address space rather than a 64-bit kernel on 64-bit hardware. Every syscall to the kernel takes a bit longer because copying the syscall arguments is no longer just a simple bcopy with a fault handler. This is because, unlike on most other *nixes, the kernel and the application don't share an address space. I'm pointing my finger at this because I've seen similar slowdowns running 32-bit linux with the 4G/4G kernel/user address space patch applied. The thing is, Apple really doesn't seem to care about performance at this level. I think this is because Apple's bread and butter is the "desktop experience", and such things, by and large, are lost in the noise to 99.9% of their customers. Eg, how often do Mac users start Mail.app or Safari.app? Will they notice an extra few milliseconds once every few months? Probably not. Speeding things up other ways (pre-linking, faster booting via launchd) tend to speed things up more in the user's eyes. Where such performance problems impact the desktop experiance, they've worked very hard to speed things up by several orders of magnitude using clever workarounds. For example, many threaded apps like to call gettimeofday() often (sometimes seemingly in a tight loop). To speedup gettimeofday, they started reading or caching the time in userpace inside the C library, so that the vast majority of gettimeofday() calls ended up just going into the library, rather than all the way down to the kernel. Look at the commpage stuff to see what I mean. Drew _______________________________________________ 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: mbuf_pullup practically useless
by Stephane Sudre 27 Aug '07

27 Aug '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On 26 août 07, at 23:19, Platon Fomichev wrote: Hello Everyone - probability it will be part of Mac OS X 10.4.x (with x>=10): 0% - probability it will be part of Mac OS X 10.5.0: 0.0000000000000001% - probability it will be part of Mac OS X 10.5.x (with x>0): 10% - probability it will be part of Mac OS X 10.6: 50% - probability it will be included when we reach the 3rd millenium: 70% N.B: with the exceptions of the first 2 probabilities, YMMV. _______________________________________________ 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.… [...] Also I am interested in smth. like this - if for example I will write such a routines - can I submit them to Apple? This is more a rhetorical question than anything else. There is no law preventing you from submitting it. So, yes you can. If they will accept them will they appear in next OS release or at some fix level? Honestly, whether they use your code or their code (that would assume it's not part of 10.5 already which I don't know and wouldn't be able to tell anyway): So in the meantime, it's obvious you will need to add this improved version of mbuff_pullup to your kernel extension if you want to benefit from it. This email sent to site_archiver(a)lists.apple.com

1 0