December 2007 - Darwin-kernel

Re: clear_wait() using thread address
by Michael Smith 12 Dec '07

12 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Dec 10, 2007, at 9:27 PM, Vishal Shetye wrote: I didn't find any function for getting thread state (like sleeping). For now I just do a proc_find() and assume true return value = thread sleeping (bad assumption). Please suggest alternative??? You must maintain this state yourself. = 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.… How are you assuring that the thread wasn't already awoken and already terminated itself (in case of a process termination, system shutdown, etc...) That being said, condvars were invented for a reason. Attempting to determine the state of one thread from within another is intrinsically race-prone, and if you ever find yourself thinking this would be a good idea, it's time to toss out your design and start again. I dropped wait_queue/clear_wait(). Now I use msleep()/ thread_wakeup_prim() so that I wake up thread sleeping on particular condition. These are not symmetrical. msleep() pairs with wakeup(), which you should probably be using instead. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Sparse files on Mac
by Terry Lambert 11 Dec '07

11 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com -- 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 Dec 11, 2007, at 12:46 AM, Anton Altaparmakov wrote: On 11 Dec 2007, at 00:00, Terry Lambert wrote: On Dec 8, 2007, at 1:51 AM, Anton Altaparmakov wrote: As there is no sparse support this is not relevant. You can get allocation information using the fcntl F_LOG2PHYS (see the fcntl man page) but that is quite a cumbersome interface. Also note that it will (at least on Leopard have not checked Tiger) return RANDOM JUNK for file systems supporting sparse files. Radar is down for maintenance at the moment or I would file a bug report immediately! Which FS are you talking about? For UFS, I see zero filled pages being returned, which is per the spec.. Are you sure this is not a bug specific to the FS you were testing on? The FS is more or less required to fake this up for any sparse areas, and if it doesn't, it's broken (not to mention a security issue, if it's returning random data from the disk). You misunderstood. Read the fcntl man page, the bit about F_LOG2PHYS. That returns a structure: struct log2phys { u_int32_t l2p_flags; /* unused so far */ off_t l2p_contigbytes; /* unused so far */ off_t l2p_devoffset; /* bytes into device */ }; And the l2p_devoffset contains random junk when F_LOG2PHYS is called for a sparse block. The bug is in the fcntl F_LOG2PHYS implementation in the kernel. If you want the gory details I described it in the Radar I filed: <rdar://problem/5637597>. Ah, OK. I consider that fcntl() to basically be SPI at this point. If you can make a business case as to why you need access to F_LOG2PHYS, we can maybe change this. We mostly didn't expect people to try to use that call, given that they are not allowed direct access to the device while it's mounted enough for you to be able to make the call to ask. The F_LOG2PHYS turns into a VNOP_BLOCKMAP, which the FS is supposed to handle. Mostly, this is used by hfsutil and the boot cache only, which makes it pretty special case code. In HFS, this turns out to be iterrable as an extent list (if the file is not a single extent). For UFS, you are correct:: you will not get valid information for sparse regions. I'm not sure this is really a bug. The documentation is pretty clear that "For some filesystems it might be too inefficient to provide anything beyond the advisory value". I'm more or less OK with that as an answer to UFS, which in Leopard you are not permitted to designate as a boot volume, and the boot loader for x86 more or less does not recognize the FS format, so it's unlikely to either have a boot cache on it, or have the HFS utilities run against it. You would probably not be happy with the fix you proposed in the radar; first, you can compare "< 0" rather than "== -1" and get the same effect, and second, for truly sparse FSs, we would need to fake up extents by iterating the emply blocks to the first non-empty block to give you an extent, and this would have to be done in the FS itself (and UFS doesn't do it). For block rather than extent based FS's, this would mean scanning the entire file length on a block by block basis. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Page Fault Kernel Panic on Leopard
by Brian Bechtel 11 Dec '07

11 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=dfAta8eFdzZ5heLosr+lPb/NTnSbTHDib83BqKJ1IWA=; b=VzHnw9ukWi0I1KqQwYgO9sHo2b4DBvCT9R/Go5C5Tknma3w8asdCeC1XfjZd0+QqZlfx0he/LBvwk+ahdWM3xiJAZBDQsEh0QUOMgjoIno4SUJi1mvvu0YFV3bAjIZ+LdS6gnMj+89eqpY7rm1jvouRuKwlYSjRVms61gYib6vQ= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bPSeEmDRQfOAIg0rfitxQKO5AdGwv6X7fPr4mkQz6635DEx3sH3rhrK1tUo8Qik5AW56B9QhrUaqP0CbCqW9u+tFPmujqoKxRl1qFNauuvqH6xT4kCp41IF7ejDmAprfp3LV0vheUGJynlzrRardDLLKVELJdrsaUN+KKI5q4DQ= On Dec 11, 2007 8:20 AM, Rick Macklem <rmacklem(a)uoguelph.ca> wrote: > Just thought I'd add that I've found the technique described in TN2063 > down around "Listing 7" works well for me. I haven't had to revert to two > machine debugging yet;-) Unless it doesn't work for Intel Macs (haven't > tried it on Intel). Yes, the technique you describe is essentially using the panic log and gdb on one machine. Load the kext symbols into gdb then do x/i {address} for each address in the backtrace (the second value of each line in the backtrace). This can be very helpful. _______________________________________________ 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: Page Fault Kernel Panic on Leopard
by Rick Macklem 11 Dec '07

11 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Tue, 11 Dec 2007, Brian Bechtel wrote: Your best bet to debug this further is to use two machines. Generate symbols by setting the DWARF with dSYM option in your Xcode project. The command cd build/Development kextload -z -n -a com.yourcompany.kext.mydriver@0x346e5000 -s . ./mydriver.kext should generate the appropriate symbol files. On a host (debugging) machine, download the 10.5.1 Kernel Debug Kit and mount it. Panic the target Just thought I'd add that I've found the technique described in TN2063 down around "Listing 7" works well for me. I haven't had to revert to two machine debugging yet;-) Unless it doesn't work for Intel Macs (haven't tried it on Intel). Brian, thanks for the post. It gives me info on an Intel crash that I may need to know someday, rick _______________________________________________ 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.… [good stuff snipped] This email sent to site_archiver(a)lists.apple.com

1 0

Re: Page Fault Kernel Panic on Leopard
by JanakiRam 11 Dec '07

11 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=+jy8BDO0uxWrxLxhP73Clsl+j3X9qsa0WuwM/2CofmM=; b=jHIeyxBqYz24BV58e4XchXs2E/7o0jVk9w8mndHkFCL6EhkjUFJXg/X3pS/gsD8zWhZd8QP4GVf3FK/AWELMHcr+lBAHb+50dyUGgY6Sx1fPjqhH7OM+HZ0y3r0/q8YhSuCGAc+UVANz3pgUhiVKLzprJU71wXn0cpht3C2YCg4= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=klP68PzRFX6o4rS3QH1gE17X9nk5qvg+6DecXhnth+1QKFk767ICfC2E9rLpxs7S9q84auEchhL1jHbcHgk3/LyyKzvEf4Au/0f4MIR9vpX2Chmz+/yiTDKkW+iLxSUXPlfe3H/LaQk0CBkQrTFuUEnwa+2vTuiqzaZv9NqpLpo= Hi Brian, Thanks for the information. Will get back to you. -JanakiRam. On Dec 11, 2007 8:14 PM, Brian Bechtel <brian.bechtel(a)gmail.com> wrote: > On Dec 11, 2007 5:48 AM, JanakiRam <johnyatforums(a)gmail.com> wrote: > > Hi Brian, > > > > Thanks for the initial response. > > > > > Why not post the rest of the panic log? That's the information that > > > tells you what really happened. > > > > Here is the complete Panic Log. Please help me to analyze this problem. > > > panic(cpu 0 caller 0x001A7BED): Kernel trap at 0x346e9f78, type > > 14=page fault, registers: > > CR0: 0x8001003b, CR2: 0x349d9a00, CR3: 0x00ff9000, CR4: 0x00000660 > > EAX: 0x349d9a00, EBX: 0x349d9a00, ECX: 0x00508444, EDX: 0xffffffff > > CR2: 0x349d9a00, EBP: 0x344b75b8, ESI: 0x00000000, EDI: 0x3471afa0 > > EFL: 0x00010206, EIP: 0x346e9f78, CS: 0x00000008, DS: 0x00000010 > > Error code: 0x00000000 > > CR2 is 0x349d9a00. That's the offending address. Notice that this > address is also found in registers EBX and EAX. > > > Backtrace, Format - Frame : Return Address (4 potential args on stack) > > 0x344b73c8 : 0x12b0e1 (0x455670 0x344b73fc 0x133238 0x0) > > 0x344b7418 : 0x1a7bed (0x45ea20 0x346e9f78 0xe 0x45e1d4) > > 0x344b74f8 : 0x19e517 (0x344b7510 0x7fb4bb0 0x344b75b8 0x346e9f78) > > 0x344b7508 : 0x346e9f78 (0xe 0x48 0x10 0x1a0010) > > 0x344b75b8 : 0x346ea13d (0x349d9a00 0x0 0x22db6 0x344b75ec) > > 0x344b75d8 : 0x346eacb2 (0x349d9a00 0x0 0x347096cc 0x34709684) > > 0x344b7628 : 0x346f65ab (0x349e8a58 0x34a35600 0x0 0x1) > > 0x344b76b8 : 0x346f6ca7 (0x18000 0x0 0x3470ca28 0x349e8a18) > > 0x344b7728 : 0x346f412d (0x34a0ec00 0xb 0x3470bf60 0x347083d0) > > 0x344b7758 : 0x346e668e (0x344b7cc8 0x344b7cf8 0x34708298 0x34708284) > > 0x344b77a8 : 0x346e898e (0x344b7cf8 0x344b7cf8 0x0 0x34a35600) > > 0x344b7d18 : 0x1f183b (0x344b7d34 0x0 0x1 0x344b7ddc) > > 0x344b7d68 : 0x1e11b6 (0xaa41c70 0x62853f0 0x344b7f48 0x0) > > 0x344b7df8 : 0x1e1334 (0x453c964 0x344b7e1c 0x0 0x63614265) > > 0x344b7f78 : 0x3da847 (0x5cb0060 0x453c860 0x453c8a4 0x0) > > 0x344b7fc8 : 0x19ea34 (0xb1e39a0 0x0 0x1a10b5 0xb1e39a0) > > This is the backtrace. The first value in each line is the stack > frame, the next is the address. The top three addresses are standard > for any panic on Intel, they are the routines panic, which is called > by kernel_trap, which is called by trap_from_kernel. This is a > typical sequence for any page fault. The fourth line from the top is > the interesting line. It's code in your kext. How can I tell? I > look at the "Kernel loadable modules in backtrace" information > (someday that will say "kernel extensions in backtrace") > > > Kernel loadable modules in backtrace (with dependencies): > > com.yourcompany.kext.mydriver(1.0.0d1)@0x346e5000->0x34725fff > > 0x346e9f78 is 0x4f78 from the start of your kext at 0x346e5000. The > offending address in CR2, 0x349d9a00, is 0x2f4a00 from the start of > your kext. I notice that you've passed this address in from other > routines in your kext (the first argument on each of the two previous > backtrace lines is 0x349d9a00). > > What else can I tell? Not much. You're running 10.5.1: > > > Mac OS version: > > 9B18 > > on a Mac Book Pro > > > System model name: MacBookPro2,2 (Mac-F42187C8) > > Your best bet to debug this further is to use two machines. Generate > symbols by setting the DWARF with dSYM option in your Xcode project. > The command > cd build/Development > kextload -z -n -a com.yourcompany.kext.mydriver@0x346e5000 -s . ./mydriver.kext > should generate the appropriate symbol files. On a host (debugging) > machine, download the 10.5.1 Kernel Debug Kit and mount it. Panic the > target > > gdb /Volumes/KernelDebugKit/mach_kernel > (gdb) source /Volumes/KernelDebugKit/kgmacros > (gdb) add-kext mydriver.kext > (gdb) kdp-reattach {target IP address} # replace this with an actual IP address > (gdb) paniclog # should be the same as the panic you've reported > (gdb) bt # should show you symbols in your code > (gdb) frame 4 # to get to the offending stack frame > (gdb) list # to see the code > > Good luck. > _______________________________________________ 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: Page Fault Kernel Panic on Leopard
by Brian Bechtel 11 Dec '07

11 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=YpbOOkrZPRaQICX320Y4YPLYEekkNMo+QHf3xjBxNes=; b=twBUkJ/qG0x5MV0g1nGxIstUbUcmBe9KKMq9Eb9m0Wh+8AQj9gLkAUe19BGKMmoRSI003XbBeaxFs2JdhTMqGlV3kLxDCzqs9gMY4Ejr1a40zPCV31u8pyea99Wk9QFhmLUx28yO8+PqqGFf9H4oa7Zo84cWOwgrUSaau3W/Fgk= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PpYHitZH6HBKXgr3y5jiys47NHM/DRG8B66ra6ndJgIA/61iENpPzZ8VMlTzygyKBXzM0pHwnembjoqzRwB3FExd7Ae8VgyqnKWzn8AhHWX7+h32+bKAddna9QhfsL4gwC6nanFVjiV+MUcXqr4XHLjs+Vnzb/OdGGOjUVLxlUg= On Dec 11, 2007 5:48 AM, JanakiRam <johnyatforums(a)gmail.com> wrote: > Hi Brian, > > Thanks for the initial response. > > > Why not post the rest of the panic log? That's the information that > > tells you what really happened. > > Here is the complete Panic Log. Please help me to analyze this problem. > panic(cpu 0 caller 0x001A7BED): Kernel trap at 0x346e9f78, type > 14=page fault, registers: > CR0: 0x8001003b, CR2: 0x349d9a00, CR3: 0x00ff9000, CR4: 0x00000660 > EAX: 0x349d9a00, EBX: 0x349d9a00, ECX: 0x00508444, EDX: 0xffffffff > CR2: 0x349d9a00, EBP: 0x344b75b8, ESI: 0x00000000, EDI: 0x3471afa0 > EFL: 0x00010206, EIP: 0x346e9f78, CS: 0x00000008, DS: 0x00000010 > Error code: 0x00000000 CR2 is 0x349d9a00. That's the offending address. Notice that this address is also found in registers EBX and EAX. > Backtrace, Format - Frame : Return Address (4 potential args on stack) > 0x344b73c8 : 0x12b0e1 (0x455670 0x344b73fc 0x133238 0x0) > 0x344b7418 : 0x1a7bed (0x45ea20 0x346e9f78 0xe 0x45e1d4) > 0x344b74f8 : 0x19e517 (0x344b7510 0x7fb4bb0 0x344b75b8 0x346e9f78) > 0x344b7508 : 0x346e9f78 (0xe 0x48 0x10 0x1a0010) > 0x344b75b8 : 0x346ea13d (0x349d9a00 0x0 0x22db6 0x344b75ec) > 0x344b75d8 : 0x346eacb2 (0x349d9a00 0x0 0x347096cc 0x34709684) > 0x344b7628 : 0x346f65ab (0x349e8a58 0x34a35600 0x0 0x1) > 0x344b76b8 : 0x346f6ca7 (0x18000 0x0 0x3470ca28 0x349e8a18) > 0x344b7728 : 0x346f412d (0x34a0ec00 0xb 0x3470bf60 0x347083d0) > 0x344b7758 : 0x346e668e (0x344b7cc8 0x344b7cf8 0x34708298 0x34708284) > 0x344b77a8 : 0x346e898e (0x344b7cf8 0x344b7cf8 0x0 0x34a35600) > 0x344b7d18 : 0x1f183b (0x344b7d34 0x0 0x1 0x344b7ddc) > 0x344b7d68 : 0x1e11b6 (0xaa41c70 0x62853f0 0x344b7f48 0x0) > 0x344b7df8 : 0x1e1334 (0x453c964 0x344b7e1c 0x0 0x63614265) > 0x344b7f78 : 0x3da847 (0x5cb0060 0x453c860 0x453c8a4 0x0) > 0x344b7fc8 : 0x19ea34 (0xb1e39a0 0x0 0x1a10b5 0xb1e39a0) This is the backtrace. The first value in each line is the stack frame, the next is the address. The top three addresses are standard for any panic on Intel, they are the routines panic, which is called by kernel_trap, which is called by trap_from_kernel. This is a typical sequence for any page fault. The fourth line from the top is the interesting line. It's code in your kext. How can I tell? I look at the "Kernel loadable modules in backtrace" information (someday that will say "kernel extensions in backtrace") > Kernel loadable modules in backtrace (with dependencies): > com.yourcompany.kext.mydriver(1.0.0d1)@0x346e5000->0x34725fff 0x346e9f78 is 0x4f78 from the start of your kext at 0x346e5000. The offending address in CR2, 0x349d9a00, is 0x2f4a00 from the start of your kext. I notice that you've passed this address in from other routines in your kext (the first argument on each of the two previous backtrace lines is 0x349d9a00). What else can I tell? Not much. You're running 10.5.1: > Mac OS version: > 9B18 on a Mac Book Pro > System model name: MacBookPro2,2 (Mac-F42187C8) Your best bet to debug this further is to use two machines. Generate symbols by setting the DWARF with dSYM option in your Xcode project. The command cd build/Development kextload -z -n -a com.yourcompany.kext.mydriver@0x346e5000 -s . ./mydriver.kext should generate the appropriate symbol files. On a host (debugging) machine, download the 10.5.1 Kernel Debug Kit and mount it. Panic the target gdb /Volumes/KernelDebugKit/mach_kernel (gdb) source /Volumes/KernelDebugKit/kgmacros (gdb) add-kext mydriver.kext (gdb) kdp-reattach {target IP address} # replace this with an actual IP address (gdb) paniclog # should be the same as the panic you've reported (gdb) bt # should show you symbols in your code (gdb) frame 4 # to get to the offending stack frame (gdb) list # to see the code Good luck. _______________________________________________ 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: Page Fault Kernel Panic on Leopard
by JanakiRam 11 Dec '07

11 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=CvpEsnQKbHJc+YebNG6PoK2jG10h6zlbO5RV8VAB9TM=; b=Pa3a5OBhyIpsCaxsLGYSERO9Qr8kI+LmEIrWU9PF4/QUF1FI72xfZXaSV+VwbFk3Wxnl8oGWvwc2r87DqKhqqgQuuxYMJTiCEOiMg1tRJ0benyYktgCAo1ajvh4tOAstwlg5Xy5MqDuoHs05cENyhhEee90P9OH8XBfXk2zQr+o= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gZSD6wddeFX/zy363ffdi9qU9hPnENp1jqFdpJpRMrTyjRUpO1aQBYzMDDIY+i/oe7iJ58UaNVqU6f3mjwSljfuvGrd4GvYpT85yt7A8++9HC58EhUJ9QuZOcxw2ITdWyj4evl8z/DHJVs5s8Pr06S8ruqDDDWr3Kp/bPdqGsP4= Hi Brian, Thanks for the initial response. > Why not post the rest of the panic log? That's the information that > tells you what really happened. Here is the complete Panic Log. Please help me to analyze this problem. panic(cpu 0 caller 0x001A7BED): Kernel trap at 0x346e9f78, type 14=page fault, registers: CR0: 0x8001003b, CR2: 0x349d9a00, CR3: 0x00ff9000, CR4: 0x00000660 EAX: 0x349d9a00, EBX: 0x349d9a00, ECX: 0x00508444, EDX: 0xffffffff CR2: 0x349d9a00, EBP: 0x344b75b8, ESI: 0x00000000, EDI: 0x3471afa0 EFL: 0x00010206, EIP: 0x346e9f78, CS: 0x00000008, DS: 0x00000010 Error code: 0x00000000 Backtrace, Format - Frame : Return Address (4 potential args on stack) 0x344b73c8 : 0x12b0e1 (0x455670 0x344b73fc 0x133238 0x0) 0x344b7418 : 0x1a7bed (0x45ea20 0x346e9f78 0xe 0x45e1d4) 0x344b74f8 : 0x19e517 (0x344b7510 0x7fb4bb0 0x344b75b8 0x346e9f78) 0x344b7508 : 0x346e9f78 (0xe 0x48 0x10 0x1a0010) 0x344b75b8 : 0x346ea13d (0x349d9a00 0x0 0x22db6 0x344b75ec) 0x344b75d8 : 0x346eacb2 (0x349d9a00 0x0 0x347096cc 0x34709684) 0x344b7628 : 0x346f65ab (0x349e8a58 0x34a35600 0x0 0x1) 0x344b76b8 : 0x346f6ca7 (0x18000 0x0 0x3470ca28 0x349e8a18) 0x344b7728 : 0x346f412d (0x34a0ec00 0xb 0x3470bf60 0x347083d0) 0x344b7758 : 0x346e668e (0x344b7cc8 0x344b7cf8 0x34708298 0x34708284) 0x344b77a8 : 0x346e898e (0x344b7cf8 0x344b7cf8 0x0 0x34a35600) 0x344b7d18 : 0x1f183b (0x344b7d34 0x0 0x1 0x344b7ddc) 0x344b7d68 : 0x1e11b6 (0xaa41c70 0x62853f0 0x344b7f48 0x0) 0x344b7df8 : 0x1e1334 (0x453c964 0x344b7e1c 0x0 0x63614265) 0x344b7f78 : 0x3da847 (0x5cb0060 0x453c860 0x453c8a4 0x0) 0x344b7fc8 : 0x19ea34 (0xb1e39a0 0x0 0x1a10b5 0xb1e39a0) Backtrace continues... Kernel loadable modules in backtrace (with dependencies): com.yourcompany.kext.mydriver(1.0.0d1)@0x346e5000->0x34725fff BSD process name corresponding to current thread: myprocess Mac OS version: 9B18 Kernel version: Darwin Kernel Version 9.1.0: Wed Oct 31 17:46:22 PDT 2007; root:xnu-1228.0.2~1/RELEASE_I386 System model name: MacBookPro2,2 (Mac-F42187C8) _______________________________________________ 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: Sparse files on Mac
by Anton Altaparmakov 11 Dec '07

11 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hi, Hi folks, Correct. UFS, ZFS, and others, however, do. Best regards, Anton -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/ _______________________________________________ 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 11 Dec 2007, at 00:00, Terry Lambert wrote: On Dec 8, 2007, at 1:51 AM, Anton Altaparmakov wrote: On 8 Dec 2007, at 09:33, Damir Dezeljin wrote: I have an non strictly kernel related question; however, I guess you'll be able to point me to the right resources. I developed a KEXT and I though of using sparse files functionality in user space for implementing some internal logic. I tried creating a sparse file using the same set of commands I usually use on Linux, but I found out I just create a normal file: ---- ftruncate(fd, 0); ftruncate(fd, 4*1024*1024*1024); ---- Now I'm wondering if sparse files are supported on the default file system used on OS 10.4 desktop (as I know, the HFS is used)? If yes, what I'm doing wrong? HFS/HFS+ do not support sparse files. Additionally I'm wondering if is it possible to get some kind of 'holes table' as it's on Windows -> so, let suppose the sparse file has some data on an offset of 1 GB, some on 1.7 GB and so on. As far as I know, this isn't possible on Linux, but I'm sure it is on Windows. As there is no sparse support this is not relevant. You can get allocation information using the fcntl F_LOG2PHYS (see the fcntl man page) but that is quite a cumbersome interface. Also note that it will (at least on Leopard have not checked Tiger) return RANDOM JUNK for file systems supporting sparse files. Radar is down for maintenance at the moment or I would file a bug report immediately! Which FS are you talking about? For UFS, I see zero filled pages being returned, which is per the spec.. Are you sure this is not a bug specific to the FS you were testing on? The FS is more or less required to fake this up for any sparse areas, and if it doesn't, it's broken (not to mention a security issue, if it's returning random data from the disk). You misunderstood. Read the fcntl man page, the bit about F_LOG2PHYS. That returns a structure: struct log2phys { u_int32_t l2p_flags; /* unused so far */ off_t l2p_contigbytes; /* unused so far */ off_t l2p_devoffset; /* bytes into device */ }; And the l2p_devoffset contains random junk when F_LOG2PHYS is called for a sparse block. The bug is in the fcntl F_LOG2PHYS implementation in the kernel. If you want the gory details I described it in the Radar I filed: <rdar://problem/5637597>. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Sparse files on Mac
by Damir Dezeljin 11 Dec '07

11 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=N6WjTJuiOfGHoo9fE7PK/8gdY8s06qHOwM5JGyu2hi4=; b=ZW1M3Plk4cwPmWhj+DTf1e+ZPlS4cU7xcppSRhIXLDQoThyo3sqcEJFd6JtAve3ihBIob8gSOz2rr/YNeNcVBfIkrc+t7UzXw/W4QHJ+5q3N/6zSUQErhM6EX2oXX8csab0y8xfgnJrVjcU21pVNGoi8pa9l/4ST1TIbyaLyKJY= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=S3+7urslROuIDqtJLLj0ETOjf+3nGVXl9to4wQhPbOcRbh7kFUUN9dIx/qfqrqEPdxRqAcffzjj3aq4eOpyQT0zpkEkrf8sezvOg1iCwgaLyuLcj+T5iwmOHgTvC46HEJIsRm+f50z7C2t7waXCKr0XLyQWaGbUGPOO/IREu9gc= _______________________________________________ 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: clear_wait() using thread address
by Vishal Shetye 11 Dec '07

11 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:x-mimeole:in-reply-to; bh=Ff85z0tIXsLGP+wdJUKZxkQxJdvKgXADCg10spRcdsw=; b=q45/GKTbZePvF4YxlpjDKYa8whre/+7qr3H/MfUGi7K055y6sODo8tl4GbI21GAJoL/7hNhCRRUMyZVmqUrompmlBKddId8MMPLySoygtpQbxdE9jBHI/9V4Cwa2W+ncuEUTeQWyDRUVsW1ajaz/rJ4tmWxZuIzeyU70DLcicTg= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:x-mimeole:in-reply-to; b=kVKMPv07gsIyFScN4E9hxB2zXVWMtauoJb0APiTYnkZz4/A4zxHTQVTBzHTCWf2Ype7K4fQ5SYiSgPrai2yyBCyt+fIiTMDAmUL/B3ecakIbtg/gumUTFxbDTDLeCtdQNm/JXmhHvdkWqLwaE5T2szvF6frQRMr/lRn8evCora0= Thread-index: Acg7evfUCdPiJUBpTmKsfSQyj1aeEwAOOaBg Hi > How are you assuring that the thread wasn't already awoken and already > terminated itself (in case of a process termination, system shutdown, > etc...) I didn't find any function for getting thread state (like sleeping). For now I just do a proc_find() and assume true return value = thread sleeping (bad assumption). Please suggest alternative??? > More importantly, are you really intending to wake the thread from any > wait it might be performing - even ones unrelated to the condition > that (you think) the thread might be waiting on? It is always better > to post the specific condition than to try and determine and then > blast a particular thread. I dropped wait_queue/clear_wait(). Now I use msleep()/thread_wakeup_prim() so that I wake up thread sleeping on particular condition. Thanks vishal _______________________________________________ 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