On 23 févr. 07, at 23:56, Ilya Shar wrote:
Sure. At first I was hitting unsupported mach syscalls, so I modified darwin-user/syscall.h according to /Developer/SDKs/MacOSX10.3.9.sdk/usr/include/mach/syscall_sw.h : $ diff syscall.c syscall.c.orig 458,465d457 < case -33: < DPRINTF("semaphore_signal_trap(0x%x)\n", arg1); < ret = semaphore_signal_trap(arg1); < break; < case -34: < DPRINTF("semaphore_signal_all_trap(0x%x)\n", arg1); < ret = semaphore_signal_all_trap(arg1); < break; 471,474d462 < case -37: < DPRINTF("semaphore_wait_signal_trap(0x%x, 0x%x)\n", arg1, arg2); < ret = semaphore_wait_signal_trap(arg1,arg2); < break;
cvs diff -u would be easier to read for me. (or diff -u). You could send this patch to the qemu-devel, that would be cool.
With this Sfari went past the unsupported call -33 and now stops in call -61 (syscall_thread_switch). Can I just modify syscalls.c in a similar way to fix it?
Yes you can!
But a really alarming thing happens before it gets there. If my ethernet cable is not plugged in, cmpxchg8b write to a nonwritable page brings my system down. I suppose it happens in somewhere in the drivers.
Ouch! I have noticed the same: qemu can trigger bugs really easily at the kernel level :( Could you explain how you know that cmpxchg8b is the key to our problem? Also qemu signal handlers might be overridden by some mach calls, that could explain the problem you are encountering. We need to work on this.
Pierre. _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel