Log execve syscall in 64bits kernel?

sysent[SYS_execve] = (void*) new_execve;
can't work.
Could you tell me how to do? Thanks.

I've been having exactly the same error on my Mac Pro over the past 2-3 weeks. At first, I thought the problem might be the new Apple Keyboard or even bad memory, but after searching these forums I found this thread: http://discussions.apple.com/thread.jspa?threadID=1001797&tstart=0
The last message in the thread points to an Apple discussion list which narrows the problem down to a serious bug in the Java 1.5 JRE for Mac OS X. This deadlock appears to happen when there are too many socket connections. I went about further narrowing this down by shutting down all desktop applications and leaving my system running for 24 hours without any kernel panics. I then launched each of my my "Login Items" and ran them one by one for 30 minutes.
For me, the problem seems to be with Azureus, which is in my Login Items. It usually causes the kernel panic within 10-20 minutes of having been launched. I realized that the problem started after I upgraded Azureus from 2.5.0.4 to the latest 3.0.x (without the VUZE content layer) a few weeks ago. I verified this by downgrading back to the 2.5.0.4 version and it has been running for 48 hours without any panics.
Hope this helps.

Similar Messages

All future MacBook with 10.7 Lion will be set to 64bit kernel by default always ?

Dear Apple and Mac Expert,
Actually I hope Apple can answer this if possible or someone can redirect me to any Apple post ?
I learned that right from 10.7 Lion available, the default kernel mode is always set to 64bit no matter installed in MacBook White or Pro. I am wondering is it same for all future MacBook Air and Pro that come with 10.7 Lion will be set to 64bit kernel by default??
I really need a confirmation on this to support my future plan.
Appreciate Apple can answer this or someone can help.
Thanks in advanced!

Apple typically does not answer questions here. Further, your question invites speculation about future product releases, which is specifically forbidden in the Terms of Use for these forums.
That having been said, Apple usually looks forward, not back. Once they remove something it is usually gone forever. Witness the floppy drive disappearing in the late 1990s.
Best of luck.

Macbook pro 3.1 with 64bit kernel. when??

hi all,
there's already 10.6.2. and still no chance of using it 64bit on a macbook pro 3.1 (which, by all means, is a completely decent computer that should run in 64bit like a charm). so the question is: when can we expect a firmware update to fix this issue? i certainly hope before 10.7..
i know there are a couple of hackarounds, but (like many others, i suppose) i would feel considerably more comfortable with an official solution.
howerver, if there's any news on this, just post it here.
cheers, boris

well, that's not correct. i did quite a lot of research in the last couple of months. i am also familiar with the article you linked to. the mbp 3.1 actually has a 64bit efi as well as a 64bit cpu. apple already stated elsewhere, that the problem is only related to the firmware. there are a bunch of hacks around enabling the mbp 3.1 for the 64bit kernel and extensions. this wouldn't be the case, if the problem was a hardware issue as you suggest. i actually had an apple support guy on the phone a while ago, who said that they were aware of the problem and working on an update. i was just wondering if that would be happening in the foreseeable future. i considered applying one of these hacks, but as i mentioned i'd favor a clean official solution.

Are there any benefits in booting to 64bit kernel?

What are the benefits (if any) in booting the 64bit kernel by holding the "4" and "6" keys? As I understand it, the 64bit apps work just fine when in the default 32bit kernel. So what advantages and disadvantages are there in booting into 64bit kernel?

I suspect the primary reason for providing a 64 bit kernel, but booting a 32 bit kernel, is so that 3rd party developers can write and test their 64 bit drivers. And so that users that like living on the bleeding edge can boot into 64 bit mode and be beta testers for those 64 bit drivers.
Also some of the Mac Pros are capable of holding huge amounts of RAM, and when the amount of RAM starts to get very large (32GB'ish), then the kernel needs a larger address space to manage all the virtual page tables that much RAM requires.
But every benchmark posted where the benchmark was running against a 32 and 64 bit kernel, gave results that were essentially the same. The larger improvement in performance came from running the benchmark as a 64 bit application, and not from the address space used by the kernel.
Eventually the next 18 month RAM doubling cycle will come to pass, and Apple wants to be ready with well debugged 64 bit kernels that have a full complement of 64 bit 3rd party drivers, so that Mac Pros and maybe even some other future Macs models have a kernel that easily manages huge physical RAM installation.
However, today, I consider the 64 bit kernel more for developers and bleeding edge users.
Use your 64 bit (or 46 bit) kernels with care

Practical approach to using 64bit kernel and 32bit userspace?

I want to run a 64bit kernel on 32bit userspace. I know there are some out there who claim it's only bad and slowing down the transition to full blown 64bit systems. That may be, but for me and for this particular computer, I need to do this.
I have tried it on my work laptop and there are no problems whatsoever: On my plain vanilla 32bit install I downloaded and installed the current 64bit kernel (after carefully backing up the current one). No problems anywhere, so far.
However, for this other machine, I need to have a sane solution for the long run. What about kernel updates? When a new kernel is released, pacman is going to want to install the 32bit one instead of the 64bit version I want to use. I don't suppose there is a way to "tag" the kernel package to be x86_64 instead of i686, or something to that effect?
I'd be happy to hear your thoughts on this.

hw-tph wrote:
flamelab wrote:put kernel26 in HoldPkg and each time it wants to be updated, install the 64bit one.
According to pacman.conf(5), HoldPkg only seems to have any effect when attempting to remove a package:
pacman.conf(5) wrote:HoldPkg = package ...
If a user tries to --remove a package that's listed in HoldPkg, pacman will ask for confirmation before proceeding.
I'll go with the local repository route.
Well, I have pacman on HoldPkg, and I thought that HoldPkg makes the package manager to ask for a package to be installed before the others. It seems that I'm wrong

Safely installing 64bit kernel with 32bit userland

I'm happily running a 64bit kernel with 32bit userland, but I was wondering whether there is any way to let pacman allow me to install the 64bit kernel (manually downloaded) without me needing to edit pacman.conf. I sometimes forget to set the arch to i686 again causing me to install 64bit packages.
If there is no such option, I'll script something for myself, but I wanted to be sure I didn't miss something (maybe an undocumented option?).

I have the Architecture line commented out of my pacman.conf, but that is because I am too lazy to upgrade the kernel using --arch. That and I use "i686" in my mirror url and am fairly sure I will never change it to x86_64 by accident...
Anyway, these are the changes I made to /etc/inittab. Just added linux32 in lots of places.
# -8 options fixes umlauts problem on login
c1:2345:respawn:linux32 /sbin/agetty -8 38400 tty1 linux
c2:2345:respawn:linux32 /sbin/agetty -8 38400 tty2 linux
c3:2345:respawn:linux32 /sbin/agetty -8 38400 tty3 linux
c4:2345:respawn:linux32 /sbin/agetty -8 38400 tty4 linux
c5:2345:respawn:linux32 /sbin/agetty -8 38400 tty5 linux
c6:2345:respawn:linux32 /sbin/agetty -8 38400 tty6 linux
# Hypervisor Virtual Console for Xen and KVM
#h0:2345:respawn:/sbin/agetty -8 38400 hvc0 linux
ca::ctrlaltdel:/sbin/shutdown -t3 -r now
# Example lines for starting a login manager
#x:5:respawn:/usr/bin/xdm -nodaemon
#x:5:respawn:/usr/sbin/gdm -nodaemon
#x:5:respawn:/usr/bin/kdm -nodaemon
#x:5:respawn:linux32 /usr/bin/slim >& /dev/null
x:5:respawn:linux32 /usr/sbin/lxdm >& /dev/null
Do that, and you will never know that you are running an x86_64 kernel and can keep Architecture=auto if you wish.

64bit kernel with 32bit userspace + pacman integration

There have been quite some questions about this topic. Sometimes leading even leading to frustration.
Luckily, a nice writeup was made here with a nice addition to integrate this nicely here.
Since there is no 32bit PAE kernel distributed by ArchLinux, using a 64bit kernel to enable NX is the only option. But since it only has 1G of memory, I do not wish to install a 64bit userspace + 32bit multilib.
However, the *exact* steps have been quite a guess (and there is no wiki). That is why I'm writing this down.
Let's start with the main configuration: pacman.conf
We need to comment out the Architecture stanza. It's funky. Why? Because it actually has two unrelated purposes:
As a documented feature, it provides protection against installing incorrect packages from another architecture
The undocumented feature is the fact that it's literal value is used to replace '$arch' variables in repo URL's
#Architecture = auto
Syncing your local repo's just broke as '$arch' is no longer defined (try it now). I ditched /etc/pacman.d/mirrorlist and did this with my remote repo URL's:
# custom repo for 64bit kernel
[x86_64-kernel]
Server = file:///home/$user/x86_64-kernel/
[core]
Server = http://ftp.nluug.nl/pub/os/Linux/distr/archlinux/core/os/i686
[extra]
Server = http://ftp.nluug.nl/pub/os/Linux/distr/archlinux/extra/os/i686
[community]
Server = http://ftp.nluug.nl/pub/os/Linux/distr/archlinux/community/os/i686
Notice the new custom repo at the top of the file. Adapt your pacman.conf to contain this custom repo as well. Make sure you place it before the [core] repo or whatever other repo is providing your current kernel. The order matters.
Furthermore, I rewrote the configuration file to not depend on variable substitution. One could argue that substituting $repo was unnecessary, but that does not really matter.
Second, we setup the repository as a normal user. This can be done by a regular user in a safe way since the packages are all signed. So tampering with packages will not work. You could even dedicate a cron script with a dedicated user to this purpose (which is overkill).
mkdir /home/$user/x86_64-kernel/
Third, we use a small script to handle this custom repo. We place it at /home/$user/x86_64-kernel.sh . Subsitute the variable R_REPO with your favorite ArchLinux mirror. Make sure this URL points to a 64bit core repository.
#!/bin/bash
set -e
set -o pipefail
L_REPO=/home/$user/x86_64-kernel/
R_REPO=http://ftp.nluug.nl/pub/os/Linux/distr/archlinux/core/os/x86_64/
cd "$L_REPO"
wget -nv "$R_REPO"/core.db -O core.db
DESC=$(tar -tf core.db | grep '^linux-[0-9.-]*/desc$' | tail -n1)
KERNELPKG=$(tar -xf core.db "$DESC" -O | grep -A1 '^%FILENAME%$' | tail -n1)
if ! [[ -f "$KERNELPKG" ]]; then
wget -nv "$R_REPO"/"$KERNELPKG"
wget -nv "$R_REPO"/"$KERNELPKG".sig
repo-add -q x86_64-kernel.db.tar.gz "$KERNELPKG"
fi
Now we are in fact done with the configuration. Substiture $user for your current user in all the sections and do the following:
# create repo, this script also updates it when newer 64bit kernels arrive
user $ bash /home/$user/x86_64-kernel.sh
# update pacman's database
root # pacman -Syy
# install 64bit kernel
root # pacman -S linux
Pacman will be able to update this kernel as long as you run x86_64-kernel.sh every once in a while. I put it in XFCE session startup to run at each session login. You could do this with cron as well.
I tested what hapenned if something went wrong with this repo. Pacman handles this very nicely actually. If you delete the repository, it will complain but not immediatly install the 32bit kernel given you have a 64bit already installed with this repo.
A final note: If you build a lot of packages you could run into trouble. Someone in the forums made a good suggestion about that here -> ("init=linux32 /usr/lib/systemd/..."). This is a nice system-wide way to trick your buildsystem into believing it's a 32bit machine. This is sometimes required. I don't use as I don't have a problem with it. But keep this in mind.
EDIT: Fixed update script to overwrite core.db and not create new ones like core.db.n .
Last edited by Rexilion (2014-02-01 15:41:29)

That is nice. Pity I did not know about this earlier. However, my method allows me to stick with the official packages. Thanks though!

Logging in Results in Constant Kernel Panics after 10.5- 10.6 Upgrade

My Mac Pro w/ dual 2.8GHz Intel CPUs has been purring along just fine for the past year or so until yesterday. Yesterday I decided to upgrade from OS X 10.5.8 to 10.6.4. Since then I have been unable to work on my Mac. Shortly after login, I get a kernel panic and have to power off the machine. Its doesn't matter what account I log in with either.
The one thing that does work consistently is if I boot up in safe mode. I don't get a kernel panic but the system does run rather slowly.
I have tried clearing PRAM but that didn't make any difference. When I log in normally (ie; not in safe mode) I get a kernel panic within 10-30 seconds.
Can someone help me isolate what is going on between booting in safe mode vs not. I'd much rather isolate the problem and fix it rather than just reload the OS (and everything else I've got configured on the system).
Thanks in advance for any help!
Ken Rahaim
Digital Asset Management Branch
Smithsonian Institution

Ken Rahaim wrote:
My Mac Pro w/ dual 2.8GHz Intel CPUs has been purring along just fine for the past year or so until yesterday. Yesterday I decided to upgrade from OS X 10.5.8 to 10.6.4. Since then I have been unable to work on my Mac. Shortly after login, I get a kernel panic and have to power off the machine. Its doesn't matter what account I log in with either.
The one thing that does work consistently is if I boot up in safe mode. I don't get a kernel panic but the system does run rather slowly.
Once booted into safe mode, launch the Console utility, and look under the various items (such as ~/Library/Logs) for a CrashReport or kernel panic item. (Sorry I can't be more specific. I haven't had a kernel panic on this Mac.) Look in each of those for a log file that might explain the problem.
If you can't find such a log file, I'd look in /Library/Extensions to see if there are any items that might be incompatible.

Cant boot into 64bit Kernel on a Unibody 13" Macbook (late 2008)

Hi
I've just upgraded to Snow Leopard (which went flawlessly) but I wanted to try out the 64-bit.
Using terminal the following command ioreg -l -p IODeviceTree | grep firmware-abi I receive "firmware-abi" = <" and System Profiler, both say 64bit isn't supported.
This is a Unibody late 2008 Macbook (13"). I've tried every which way apart from messing with the EFI (which I have no idea about).
Also I upgraded the OS so it wasn't a fresh install, I don't know if this affects anything?
Thank you in advice to anyone that can shed some light on this
Cheers

There's an update over at netkas.org which provides instructions on how to enable the 64-bit kernel in Snow Leopard for the Unibody MacBooks, which seem to be inhibited in booting up with this capability due to an artificial restriction in the Boot.efi:
http://netkas.org/?p=189#comments
The procedure involves downloading a modified Boot.efi file and entering some commands in Terminal.
However, I haven't been able to get it to work on my Unibody MacBook because after entering the final command in Terminal:
"sudo bless −−folder /System/Library/CoreServices/ \
−−file /System/Library/CoreServices/boot64.efi"
I receive a "No Volume specified" error message.
If anyone can get this to work on their systems I would be grateful for some help. It seems you can't simply copy and paste the commands given in the blog but need to manually enter "--" within the last command. I'm not sure if the proper entry consists of two dashes, one after the other, or the "¨" key which is located directly below the "!" on my (Swiss German) keyboard.

System.log contains multiple occurrences of "kernel[0]: disk1s9: ioctl('"

In investigating some possibly unrelated issues, I noticed that my system.log contains multiple instances of the following item, sometimes many of them quite close together:
Dec 14 13:09:17 Walkers-G4 kernel[0]: disk1s9: ioctl('
I've determined that disk1s9 is my boot drive. This entry looks like there ought to be something after "ioctl('", but there isn't.
At any rate, these don't look normal to me. Should be I be concerned?

There were no responses, and this article is old, so I'm marking it as "solved" so as to no clog up my "questions" queries. Sigh.

Can't enable 64bit kernel mode on my MBP

I typed the command "system_profiler SPHardwareDataType | grep "Model Identifier" | cut -d: -f2" and it shown that my mbp is MacBookPro3,1 and then I typed "ioreg -l -p IODeviceTree | grep firmware-abi", the terminal said that is " | | "firmware-abi" = <"NO". and I checked the Extensions, there are also many NOs on that list, What is that problem? I know that EFI-64 could enable 64bit Snow Leopard but how come my mbp can't?
Please help me, thank you!

A 64-bit chip and 64-bit EFI do not guarantee running the 64-bit kernel. In fact very few Macs can run the kernel. My four month old Mac mini cannot boot into 64-bit. Apple to date has disabled the 64-bit kernel for all MacBooks and the Mac mini.
This is the rule
A 32-bit processor can only run 32-bit stuff.
A 64-bit processor can run 32-bit and 64-bit stuff.
(stuff can be system, kernel, applications, drivers, etc)
So you need a 64-bit processor to run 64-bit anything
On a 64-bit processor:
A 32-bit Kernel can run both 32 and 64 bit applications.
A 64-bit Kernel can run both 32 and 64 bit applications.
A 32-bit Kernel can load only 32-bit kexts (kernel extensions).
A 64-bit Kernel can load only 64-bit kexts (kernel extensions).
Marcus Winter
Here is the list.
Dah•veed

System.log filling up with: mbp kernel[0]: dp events: 0x04

Dec 21 17:09:52 mbp kernel[0]: dp events: 0x04
This line seems to repeat 5 or 6 times per minute, filling system.log.
Looks like it started Dec 19th. I don't see any obvious unusual thing I did at that time.
Any ideas?
Thanks, jeff

Although Apple has not fixed this yet, I have learned some interesting things. While on the phone with Apple, they had me run a Data Capture program to collect info about my system to send back to them.
While running the application, I had Console open so I could look at the system log. To my surprise, after running this application, the repeating dp events: 0x04 completely stopped and the mouse cursor behaved normally. The mouse continued to behave normally until I put the computer to sleep and woke it up again.
In summary:
1) The dp events: 0x04 messages are present when the mouse skips and not present when it doesn't. This seems like proof that the muliple writes to the system log are what make the cursor skip.
2) Running Capture Data.app (from the Apple tech) runs a handful of scripts that not only capture data, but also kills the dp events for some reason.
I have verified this four different times and reported my findings to the Apple tech I was speaking to.
Can anyone else who receive the data capture program from Apple give this a shot? Just have Console open and look at your system log before, during, and after running the program. Perhaps you'll see as I did that the dp events go away and your mouse works right (at least until sleep).

Log troubleshooting: dyld shared region (kernel)?

ok this is maybe too technical for the ADF, but while trying to eliminate conflicts with SL, I'm spending a fair amount of time looking at the system/console logs.
Getting a lot of these sorts of messages:
9/15/09 9:14:44 AM kernel Locum (map: 0x103f070c) triggered DYLD shared region unnest for map: 0x103f070c, region 0x7fff84c00000->0x7fff84e00000. While not abnormal for debuggers, this increases system memory footprint until the target exits.
9/15/09 9:15:45 AM kernel Safari (map: 0x103f070c) triggered DYLD shared region unnest for map: 0x103f070c, region 0x7fff82c00000->0x7fff82e00000. While not abnormal for debuggers, this increases system memory footprint until the target exits.
Any idea what that's all about?

Hey guys, try this.
Safe Boot is a special way to start up in Mac OS X 10.2 or later when troubleshooting. Safe Mode is the state Mac OS X is in after a Safe Boot. To perform a Safe Boot, hold the Shift key as your Mac starts up.
A Safe Boot deletes the dynamic loader shared cache but takes more time to boot and after you login to the desktop, wait about 5 min before you reboot again.
Good Luck.
Buzz

Can the current versions of Mac mini load a 64bit kernel

I wanting to get a Mac Mini as developer test machine and wanted to know if the current version will load 64 bit kernel. I know they are Core 2 Duo.
Thanks.

Thanks. Just placed an order in for two minis.
Also check out this link for more on the topic:
http://support.apple.com/kb/HT3770

Installing a 64bit kernel and 32bit userland.

Starting from Leonidas, Fedora will start installing a x64 kernel on compatible hardware, even when installing a 32-bit OS.
This should allow the kernel to better handle memory as the kernel no longer has to worry about low memory, high memory, etc...
Link http://fedoraproject.org/wiki/Features/ … ureSupport
It should be possible to do this under Arch, No ?

now come the issues. i have some problems building packages while running this kernel.
/etc/makepkg.conf
# ARCHITECTURE, COMPILE FLAGS
CARCH="i686"
CHOST="i686-pc-linux-gnu"
#-- Exclusive: will only run on -march=i686
# -march (or -mcpu) builds exclusively for an architecture
# -mtune optimizes for an architecture, but builds for whole processor family
CFLAGS="-march=i686 -mtune=native -Os -pipe -fomit-frame-pointer"
CXXFLAGS="-march=i686 -mtune=native -Os -pipe -fomit-frame-pointer"
#-- Make Flags: change this for DistCC/SMP systems
MAKEFLAGS="-j3"
Firefox fails with:
/home/eb/pkg/firefox/src/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_x86_64_linux.cpp:181: error: invalid register name for 'a4'
/home/eb/pkg/firefox/src/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_x86_64_linux.cpp:182: error: invalid register name for 'a5'
make[9]: *** [xptcinvoke_x86_64_linux.o] Error 1
make[9]: *** Waiting for unfinished jobs....
{standard input}: Assembler messages:
{standard input}:7: Error: bad register name `%rbp'
{standard input}:8: Error: bad register name `%rsp'
{standard input}:9: Error: bad register name `%rsp'
{standard input}:10: Error: bad register name `%rdi'
{standard input}:11: Error: bad register name `%rsi'
{standard input}:12: Error: bad register name `%rdx'
{standard input}:13: Error: bad register name `%rcx'
{standard input}:14: Error: bad register name `%r8'
{standard input}:15: Error: bad register name `%r9'
{standard input}:16: Error: bad register name `%rbp)'
{standard input}:17: Error: bad register name `%rbp)'
{standard input}:18: Error: bad register name `%rbp)'
{standard input}:19: Error: bad register name `%rbp)'
{standard input}:20: Error: bad register name `%rbp)'
{standard input}:21: Error: bad register name `%rbp)'
{standard input}:22: Error: bad register name `%rbp)'
{standard input}:23: Error: bad register name `%rbp)'
{standard input}:24: Error: bad register name `%rbp)'
{standard input}:25: Error: bad register name `%rbp)'
{standard input}:27: Error: bad register name `%rbp)'
make[9]: *** [xptcstubs_x86_64_linux.o] Error 1
qt fails with:
main.cpp:1: sorry, unimplemented: 64-bit mode not compiled in
make: *** [property.o] Error 1
make: *** Waiting for unfinished jobs....
make: *** [main.o] Error 1
make: *** [project.o] Error 1
Any idea why the building process seems not to care about the arch set in makepkg.conf and if it could be possible to fix that?
TIA

Log execve syscall in 64bits kernel?

Similar Messages

Maybe you are looking for