Re: imac g4 dont boot
On Jan 2, 2009, at 9:44, "Carlos A. M. dos Santos" wrote: On Fri, Jan 2, 2009 at 3:33 AM, lazaax - wrote: hi, hackers, i need a help with a imac g4,i put the power cable and i push the power botton to turn on the mac and it makes a sound at start but the porblem is that dont boot, and keep like panic o somthing like that, i want to try install freebsd to this mac o restore the sistema mac that was installed, thanks people.. If you don't have FreeBSD installed on the machine then this is not a FreeBSD-related problem. At least not yet. :-) I suggest you to ask for help on at a Mac-specific forums, instead of asking at freebsd-hackers. The purpose of this list is discussing FreeBSD hacking and development. It is not for general user support. You will likely get better results asking at freebsd-questions. The purpose of each list is shown here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources.html#ERESOURCES-MAIL -- cd /usr/ports/sysutils/life make clean Asking on p...@freebsd.org would probably be more appropriate as it's a ppc based mac and the install directions vary. Cheers, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: imac g4 dont boot
On Fri, Jan 2, 2009 at 3:33 AM, lazaax - wrote: > hi, hackers, > i need a help with a imac g4,i put the power cable > and i push the power botton to turn on the mac and it makes a sound at > start but the porblem is that dont boot, and keep like panic o > somthing like that, i want to try install freebsd to this mac o > restore the sistema mac that was installed, > > thanks people.. If you don't have FreeBSD installed on the machine then this is not a FreeBSD-related problem. At least not yet. :-) I suggest you to ask for help on at a Mac-specific forums, instead of asking at freebsd-hackers. The purpose of this list is discussing FreeBSD hacking and development. It is not for general user support. You will likely get better results asking at freebsd-questions. The purpose of each list is shown here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources.html#ERESOURCES-MAIL -- cd /usr/ports/sysutils/life make clean ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD kernel Debugging tools for Virtual Memory Module
On Thu, Jan 01, 2009 at 06:27:44PM -0800, Kamlesh Patel wrote: > I am working on Virtual Memory parts of FreeBSD OS. My Problem is, whenever i > modify little code of vmpage.c file i need to build the whole kernel to check > the modification and i even am not able to debug the kernel code. > > Could anyone please inform me kernel Debugging tools for FreeBSD OS? First, you need to recompile source you change for sure :-) But you have not rebuild all other files all the time. You need to add to your /etc/src.conf (or /etc/make.conf for 6.x and earlier): MODULES_WITH_WORLD=yes This will skip rebuilding of all modules during 'make buildkernel' but you MUST to copy all modules from /boot/kernel to /boot/modules (all files other than /boot/kernel/kernel*) if you do this. Otherwise, you'll lose modules and system may not boot due to missing vital modules like acpi.ko Then, if you do not change kernel config file, recompile your changes with command (only second time and then): cd /usr/src; make NO_KERNELDEPEND=yes NO_KERNELCLEAN=yes buildkernel So, your rebuild time changes drastically: no modules rebuild, no other sources rebuild other that you touched last time. It will relink previously compiled object code with your changes only, that's way much quicker. Reinstall kernel and reboot. Second, you should use some kind of virtual machine (like qemu from ports) to speedup your development cycle even more: install the system into virtual machine and you'll need not another box to debug the kernel and need not rebuild your development box. Test your changes with the system installed into VM and reboot it only. Use ddb or kgdb already noted here. Eugene Grosbein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
bsd.obj.mk does not set CANONICALOBJDIR correctly when TARGET_ARCH and MAKEOBJDIRPREFIX are set
In working on cross-platform support for mergemaster I came across the
following problem. I set MAKEOBJDIRPREFIX to be that of the temproot
environment, which works fine when you do not specify a TARGET_ARCH.
When you do specify TARGET_ARCH there is a conflict between
src/Makefile.inc1 and share/mk/bsd.obj.mk. The former does this:
.if ${MACHINE} == ${TARGET} && !defined(CROSS_BUILD_TESTING)
OBJTREE=${MAKEOBJDIRPREFIX}
.else
OBJTREE=${MAKEOBJDIRPREFIX}/${TARGET}
.endif
however the latter does this:
.if defined(MAKEOBJDIRPREFIX)
CANONICALOBJDIR:=${MAKEOBJDIRPREFIX}${.CURDIR}
.else
CANONICALOBJDIR:=/usr/obj${.CURDIR}
.endif
When trying to install the stuff in src/etc/sendmail install(1) cannot
find the file because it is built in /obj but it's looking for it
in /obj/$target
The simplest fix I found was to do the following in bsd.obj.mk:
Index: bsd.obj.mk
===
--- bsd.obj.mk (revision 186676)
+++ bsd.obj.mk (working copy)
@@ -43,7 +43,7 @@
.include
.if defined(MAKEOBJDIRPREFIX)
-CANONICALOBJDIR:=${MAKEOBJDIRPREFIX}${.CURDIR}
+CANONICALOBJDIR:=${OBJTREE}${.CURDIR}
.else
CANONICALOBJDIR:=/usr/obj${.CURDIR}
.endif
However I would be happy with any solution that makes it work. It's
trivial to test with 'mergemaster -i -D -A arm'
Doug
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD kernel Debugging tools for Virtual Memory Module
>ddb and kgdb are two useful and often indispensable tools for kernel > debugging on FBSD. ddb won't allow you source level debugging, kgdb will, > but you'll need an extra machine. If the code you are debugging doesn't depend on specific hardware, one option is to run FreeBSD (with the kernel being debugged) under qemu and run kgdb on the host FreeBSD. Something like In Window1 $ qemu -s freebsd-disk-img ... In Window2 $ cd $ kgdb kernel.debug (gdb) target remote localhost:1234 (gdb) detach Ending remote debugging. (gdb) q $ Note: I have not tried this recently but it should work. > AFAIK, if you are modifying the kernel source directly there is no option > but to recompile all the changed and dependent files. Well... there used to be a debugger called ups with a builtin C interpreter. It allowed you to add code at run time. This was quite handy when you wanted to temporarily patch things up and continue debugging or set conditional breakpoints or insert assertion verification code on the fly. The C interpreter is worth adding to gdb but I am not sure if any of ups code can be reused. See http://ups.sourceforge.net/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
