Re: Benchmark [Re: [Call For Testing] VirtualBox for FreeBSD! take 4]
Hello, Usually I cannot usually launch VirtualBox even by root. A workaround is that invoking and killing VirtualBox many times for me. After some tries I can launch... maybe this workaround helps (as user, not as root): 1. Launch VirtualBox. 2. If it fails open top(1) 3. In top(1) you should see 2(!) processes VirtualBox 4. Kill one of them 5. The other one should start This works for me in 9 out of 10 times and is much more comfortable than killing and restarting the whole programm many times. -- Homepage: www.yamagi.org Jabber: yam...@yamagi.org GnuPG/GPG:0xEFBCCBCB pgpgEmVc5Uear.pgp Description: PGP signature
Re: MAKE_JOBS_UNSAFE (some more ports)
Hi David and * thanks for your patch, I verified and committed. Best, From: Ion-Mihai Tetcu ite...@freebsd.org Subject: Re: MAKE_JOBS_UNSAFE (some more ports) Date: Sat, 06 Jun 2009 02:39:42 +0300 On Sat, 06 Jun 2009 08:26:01 +0900 (JST) Maho NAKATA cha...@mac.com wrote: From: Ion-Mihai Tetcu ite...@freebsd.org Subject: Re: MAKE_JOBS_UNSAFE (some more ports) Date: Sat, 06 Jun 2009 01:38:18 +0300 On Sat, 06 Jun 2009 07:25:35 +0900 (JST) Maho NAKATA cha...@mac.com wrote: thanks for raising as PR :) http://www.freebsd.org/cgi/query-pr.cgi?pr=135262 Some support has been committed by Pav, can you please check his commit and adjust OOo ports to make use of it? I just checked Pav's commit and I checked David's newest patch, and his patch seems to make use of Pav's support. Cool :) This way I could have all OOo ports tested on-commit on QAT ;-) Yes, really appreciated. Up until now two OOo commits would busy QAT for half a day; with this changes committed it's two hours or less :-) -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect FreeBSD committer - ite...@freebsd.org, PGP Key ID 057E9F8B493A297B pgpAPb9DlmlgE.pgp Description: PGP signature
Two VirtualBox processes and do not launch VirtualBox: kill one of them.
From: Yamagi Burmeister li...@yamagi.org Subject: Re: Benchmark [Re: [Call For Testing] VirtualBox for FreeBSD! take 4] Date: Sat, 06 Jun 2009 09:20:42 +0200 Hello, Usually I cannot usually launch VirtualBox even by root. A workaround is that invoking and killing VirtualBox many times for me. After some tries I can launch... maybe this workaround helps (as user, not as root): 1. Launch VirtualBox. 2. If it fails open top(1) 3. In top(1) you should see 2(!) processes VirtualBox 4. Kill one of them 5. The other one should start This works for me in 9 out of 10 times and is much more comfortable than killing and restarting the whole programm many times. Hi Yamagi-san, This workaround works well for me. Many thanks!! Best, -- Nakata Maho http://accc.riken.jp/maho/ , http://ja.openoffice.org/ Nakata Maho's PGP public keys: http://accc.riken.jp/maho/maho.pgp.txt pgpizULyuKBQv.pgp Description: PGP signature
Re: Benchmark
From: Scott Long sco...@samsco.org Subject: Re: Benchmark [Re: [Call For Testing] VirtualBox for FreeBSD! take 4] Date: Sat, 06 Jun 2009 00:44:24 -0600 Maho NAKATA wrote: I did a benchmark with Virtualbox: My environment: * Core 2 Quad, q6...@3ghz * Windows XP s...@host s...@vbox with GuestAddon * http://crystalmark.info/software/CrystalMark/ CrystalMark 2004R3 * Sapphire X1650 * VBOX is running on FBSD7.2-REL/amd64 using http://people.freebsd.org/~miwi/vbox/virtualbox_5.tgz * Running with fullscreen mode 1280x1024 32bit Here is the result - host(4CPU) host(1CPU) vbox(1CPU) Mark 173047 9092586496 ALU 50985 1349313060 FPU 63746 1512615323 MEM 21822 2558216516 HDD 9336933130600(*) GDI 15153 15195 5127 D2D 59975998 5108 OGL 62006200 762 - (*)somehow lot faster I don't know how to use two CPUs, even changing setting doesn't change. Usually I cannot usually launch VirtualBox even by root. A workaround is that invoking and killing VirtualBox many times for me. After some tries I can launch... thanks I take it that you're running freebsd on the bare metal in your 4CPU and 1CPU tests, and running WinXP on the bare metal in the vbox test? yes. If so, are you using ATA disks and the ATA driver for all instances I use SATA for host machine and ATA as VirtualBox machine. of FreeBSD? If so, then the lack of NCQ in the FreeBSD ATA driver would explain the HDD test result. I see similar results with VMWare. Ok, I see Thanks for your clarification. Best, -- Nakata Maho http://accc.riken.jp/maho/ , http://ja.openoffice.org/ Nakata Maho's PGP public keys: http://accc.riken.jp/maho/maho.pgp.txt pgp7gW12ck5jl.pgp Description: PGP signature
what does this mean?
1. Running the csup(1)http://www.freebsd.org/cgi/man.cgi?query=csupsektion=1command later will download and apply all the recent changes to your Ports Collection, except actually rebuilding the ports for your own system. -- regards, Dan Hirsch Linked-In: http://www.linkedin.com/in/danhirsch1 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: request for exp-run, comments: eliminate USE_X_PREFIX
Dmitry Marakasov píše v so 06. 06. 2009 v 07:13 +0400: * Pav Lucistnik (p...@freebsd.org) wrote: The experimental run is nearly over, so far 15 failures found and sent in separate mails. Once you have next iteration of the patch, I'll be happy to run it again. Here's it: http://people.freebsd.org/~amdmi3/xprefix_obliterate.1.patch Thank you, queued. Also I forgot to mention that this is better to be run on i386, as many ports depend on xview which is i386-only. i386 is operated by erwin@ so try talking to him. But I must warn you that i386 run will take about a week, due to much older hardware we have available for it. -- Pav Lucistnik p...@oook.cz p...@freebsd.org Quantum physics was developed in the 1930's, as a result of a bet between Albert Einstein and Niels Bohr, to see who could come up with the most ridiculous theory and still have it published. signature.asc Description: Toto je digitálně podepsaná část zprávy
Re: request for exp-run, comments: eliminate USE_X_PREFIX
* Pav Lucistnik (p...@freebsd.org) wrote: Also I forgot to mention that this is better to be run on i386, as many ports depend on xview which is i386-only. i386 is operated by erwin@ so try talking to him. But I must warn you that i386 run will take about a week, due to much older hardware we have available for it. Ah, ok then, I'll try to run as many as possible in my tinderbox. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: request for exp-run, comments: eliminate USE_X_PREFIX
On Sat, Jun 06, 2009 at 05:36:26PM +0200, Pav Lucistnik wrote: Also I forgot to mention that this is better to be run on i386, as many ports depend on xview which is i386-only. i386 is operated by erwin@ so try talking to him. But I must warn you that i386 run will take about a week, due to much older hardware we have available for it. And there are two other builds in queue before you, so it will take a while. Let me know if can do it without pointyhat or amd64, otherwise we'll schedule it as soon as possible. -erwin -- Erwin Lansing http://droso.org Prediction is very difficult especially about the futureer...@freebsd.org pgpJgHqAEFJ50.pgp Description: PGP signature
Re: MAKE_JOBS_UNSAFE (some more ports)
On Thursday 21 May 2009 13:56:46 Pav Lucistnik wrote: On Thu, 21 May 2009 12:05:22 +0200, David Naylor wrote The following ports failed to build on my system (with a quad core) and FORCE_MAKE_JOBS set. They did success to build once I added MAKE_JOBS_UNSAFE=yes to their Makefile's. Marked in CVS, thank you! I believe java/jdk* should be marked as unsafe. They define their own do-build targets (and don't use _MAKE_JOBS) so no functional change. I've checked jdk16 with `make MAKE_ARGS=-j4` and build fails. I've found the following ports that are UNSAFE: audio/cdparanoia (under heavy load) devel/dbus-qt4 (under heavy load) java/openjdk6 Is there any effort to mark ports as MAKE_JOBS_SAFE: is it desired for ports that are successful with FORCE_MAKE_JOBS to be reported? Yes, I believe they should be reported. Here are all the ports that compile with -DFORCE_MAKE_JOBS, do not have MAKE_JOBS_* set and do not define a do-build target: (NOTE: FORCE_MAKE_JOBS=yes is in make.conf for all builds) # for i in `pkg_info -oqa`; do cd /usr/ports/$i; if [ -z `make -V MAKE_JOBS_SAFE -V MAKE_JOBS_UNSAFE` -a -z `grep do-build Makefile`]; then echo $i; fi; done | sort [ See attached for output ] Regards, David P.S. Is anyone interested in a list of ports that do not compile under tmpfs? accessibility/atk accessibility/linux-f8-atk accessibility/qt4-accessible archivers/cabextract archivers/libzip archivers/p5-Archive-Zip archivers/p5-Compress-Bzip2 archivers/p5-Compress-Raw-Zlib archivers/p5-Compress-Zlib archivers/p5-IO-Compress-Base archivers/p5-IO-Compress-Zlib archivers/p5-PerlIO-gzip archivers/p5-PerlIO-via-Bzip2 archivers/rpm archivers/unrar archivers/unzip archivers/zip astro/cfitsio astro/libnova audio/aacgain audio/amarok-kde4 audio/faac audio/faad audio/flac audio/gsm audio/lame audio/liba52 audio/libamrnb audio/libamrwb audio/libao audio/libcddb audio/libgpod audio/libid3tag audio/libmad audio/libmikmod audio/libmodplug audio/libmtp audio/libmusicbrainz audio/libofa audio/libogg audio/libtunepimp audio/libvorbis audio/madplay audio/mp3gain audio/normalize audio/sdl_mixer audio/speex audio/taglib audio/vorbis-tools audio/vorbisgain audio/wavpack comms/gnokii converters/fribidi converters/p5-MIME-Base64 databases/db46 databases/gdbm databases/mysql51-client databases/mysql51-server databases/py-bsddb databases/py-qt4-sql databases/qt4-mysql-plugin databases/qt4-sql databases/qt4-sqlite3-plugin databases/rrdtool databases/sqlite3 devel/ORBit2 devel/apache-ant devel/autoconf-wrapper devel/autoconf213 devel/autoconf262 devel/automake-wrapper devel/automake110 devel/automake14 devel/automake15 devel/automake19 devel/bison devel/boost-python devel/clanlib devel/cmake devel/dbus devel/dbus-glib devel/dbus-qt4 devel/desktop-file-utils devel/eric4 devel/gamin devel/gccmakedep devel/gconf2 devel/gettext devel/gio-fam-backend devel/glib12 devel/glib20 devel/gmake devel/gnome-vfs devel/imake devel/kdesvn-kde4 devel/libIDL devel/libcheck devel/libdaemon devel/libexecinfo devel/libglade2 devel/libical devel/libltdl15 devel/liboil devel/libpci devel/libpciaccess devel/libpthread-stubs devel/libstatgrab devel/libtool15 devel/libvolume_id devel/m4 devel/makedepend devel/newfile devel/nspr devel/p5-Algorithm-Annotate devel/p5-Algorithm-Diff devel/p5-App-CLI devel/p5-BFD devel/p5-Class-Accessor devel/p5-Class-Autouse devel/p5-Class-Data-Inheritable devel/p5-Data-Hierarchy devel/p5-Data-UUID devel/p5-ExtUtils-CBuilder devel/p5-ExtUtils-ParseXS devel/p5-File-Temp devel/p5-File-chdir devel/p5-FreezeThaw devel/p5-Getopt-Long devel/p5-IO-Digest devel/p5-IO-Pager devel/p5-IPC-Run3 devel/p5-Locale-Maketext devel/p5-Locale-Maketext-Lexicon devel/p5-Locale-Maketext-Simple devel/p5-Locale-gettext devel/p5-Log-Log4perl devel/p5-Module-Build devel/p5-Path-Class devel/p5-PathTools devel/p5-PerlIO-eol devel/p5-PerlIO-via-dynamic devel/p5-PerlIO-via-symlink devel/p5-Regexp-Shellish devel/p5-SVN-Dump devel/p5-SVN-Mirror devel/p5-SVN-Simple devel/p5-Storable devel/p5-Term-ReadKey devel/p5-Time-Progress devel/p5-TimeDate devel/p5-UNIVERSAL-require devel/p5-VCP-autrijus devel/p5-prefork devel/p5-version devel/patch devel/pcre devel/pkg-config devel/popt devel/py-astng devel/py-dbus devel/py-logilab-common devel/py-qt4-assistant devel/py-qt4-core devel/py-qt4-dbus devel/py-qt4-designer devel/py-qt4-designerplugin devel/py-qt4-help devel/py-qt4-qscintilla2 devel/py-qt4-script devel/py-qt4-test devel/py-sip devel/pylint devel/qca devel/qmake4 devel/qscintilla2 devel/qt4 devel/qt4-assistant devel/qt4-assistant-adp devel/qt4-corelib devel/qt4-designer devel/qt4-help devel/qt4-libqtassistantclient devel/qt4-linguist devel/qt4-makeqpf devel/qt4-moc devel/qt4-porting devel/qt4-qdbusviewer devel/qt4-qt3support devel/qt4-qtestlib devel/qt4-qvfb devel/qt4-rcc devel/qt4-script devel/qt4-uic devel/qt4-uic3 devel/sdl12 devel/subversion devel/t1lib devel/xorg-macros devel/yasm dns/libidn emulators/wine ftp/curl ftp/wget
Re: emulators/kqemu-kmod-devel: Exec format error
In article 20090604211814.d065d4a7.dge...@afflictions.org you write: kqemu-kmod-devel is failing to load for me: - # kldload kqemu kldload: can't load kqemu: Exec format error # - Weird. Anything in dmesg? It's been about a month since I last used qemu, and my kernel is -CURRENT from 2009/05/19. Because I'd upgraded my kernel since last using qemu, I re-compiled kqemu-kmod-devel, which upgraded me from 1.4.0.p1_2 to 1.4.0.p1_3, and now I can't load kqemu. I don't see anything in UPDATING, nor have I changed anything that might affect the build (make.conf is still the same). I've since completely removed my kqemu install, and re-installed it, but that hasn't helped. Something else I've missed? You say your kernel is -CURRENT from 2009/05/19, is your userland also in sync with that? What do ident /usr/include/sys/param.h grep define.__FreeBSD_version /usr/include/sys/param.h say? Btw I just built the port in 8.0-HEAD-20090605-JPSNAP/i386 and was able to kldload it just fine. (Didn't test whether it actually runs since this is in a vm already, tho I'd be surprised if not...) HTH, Juergen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: emulators/kqemu-kmod-devel: Exec format error
Thus spake Juergen Lock n...@jelal.kn-bremen.de [Sat, 6 Jun 2009 19:11:13 +0200 (CEST)]: : kqemu-kmod-devel is failing to load for me: : : - : # kldload kqemu : kldload: can't load kqemu: Exec format error : # : - : : Weird. Anything in dmesg? Agreed. And nope, nothing in dmesg. : It's been about a month since I last used qemu, and my kernel is -CURRENT from 2009/05/19. Because I'd upgraded my kernel since last using qemu, I re-compiled kqemu-kmod-devel, which upgraded me from 1.4.0.p1_2 to 1.4.0.p1_3, and now I can't load kqemu. : : I don't see anything in UPDATING, nor have I changed anything that might affect the build (make.conf is still the same). I've since completely removed my kqemu install, and re-installed it, but that hasn't helped. : : Something else I've missed? : : You say your kernel is -CURRENT from 2009/05/19, is your userland also : in sync with that? What do : ident /usr/include/sys/param.h : grep define.__FreeBSD_version /usr/include/sys/param.h : say? My userland's rarely out-of-sync; unless I'm chasing down a specific bug, or expect the kernel won't last very long, I always update userland as well. FWIW, I updated kernel and userland yesterday, and kqemu loads fine now. shrug ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: MAKE_JOBS_UNSAFE (some more ports)
On Sat, 6 Jun 2009 18:05:14 +0200 David Naylor naylor.b.da...@gmail.com wrote: P.S. Is anyone interested in a list of ports that do not compile under tmpfs? Me. -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect FreeBSD committer - ite...@freebsd.org, PGP Key ID 057E9F8B493A297B signature.asc Description: PGP signature
Ports with duplicate LATEST_LINKS
Dear port maintainers, The following list includes ports maintained by you that have duplicate LATEST_LINK values. They should either be modified to use a unique LATEST_LINK or suppressed using NO_LATEST_LINK, to avoid overwriting each other in the packages/Latest directory. If your ports conflict with ports maintained by another person, please coordinate your efforts with them. Thanks, Erwin Annoying Reminder Guy III Lansing LATEST_LINK PORTNAME MAINTAINER == emulators/linux_base-f7 b...@freebsd.org emulators/linux_base-f8 b...@freebsd.org emulators/linux_base-fc6 b...@freebsd.org emulators/linux_base-f10 emulat...@freebsd.org emulators/linux_base-f9 emulat...@freebsd.org cvsup-without-guinet/cvsup bzeeb+freebsdpo...@zabbadoz.net cvsup-without-guinet/cvsup-without-gui bzeeb+freebsdpo...@zabbadoz.net dcd net-p2p/dcda...@freebsd.org dcd audio/dcd g...@freebsd.org deco archivers/deco ke...@freebsd.org deco misc/deco r...@freebsd.org freeciv-nox11games/freeciv m...@freebsd.org freeciv-nox11games/freeciv-nox11m...@freebsd.org ghostscript7-nox11 print/ghostscript7 doc...@freebsd.org ghostscript7-nox11 print/ghostscript7-nox11 doc...@freebsd.org ghostscript8-nox11 print/ghostscript8 doc...@freebsd.org ghostscript8-nox11 print/ghostscript8-nox11 doc...@freebsd.org mod_jk-ap2 www/mod_jk gir...@freebsd.org mod_jk-ap2 www/mod_jk-apache2 gir...@freebsd.org mpc audio/mpc po...@mark.reidel.info mpc math/mpc wenhep...@gmail.com ocaml-notk lang/ocaml-nox11 po...@freebsd.org ocaml-notk lang/ocaml s...@freebsd.org p5-FuzzyOcr mail/p5-FuzzyOcr-devel ismail.yeni...@endersys.com.tr p5-FuzzyOcr mail/p5-FuzzyOcr po...@freebsd.org ploticus-nox11 math/ploticus lini...@freebsd.org ploticus-nox11 math/ploticus-nox11po...@freebsd.org py25-wxPythonx11-toolkits/py-wxPython26 n...@nelson.name py25-wxPythonx11-toolkits/py-wxPython28 n...@nelson.name py25-wxPython-common x11-toolkits/py-wxPython26-common n...@nelson.name py25-wxPython-common x11-toolkits/py-wxPython28-common n...@nelson.name py25-wxPython-unicode x11-toolkits/py-wxPython26-unicode n...@nelson.name py25-wxPython-unicode x11-toolkits/py-wxPython28-unicode n...@nelson.name ssh2-nox11 security/ssh2 mar...@freebsd.org ssh2-nox11 security/ssh2-nox11mar...@freebsd.org Total: 35 ports ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Ports with duplicate LATEST_LINKS
On Fri, 5 Jun 2009 14:40:09 GMT Erwin Lansing er...@freebsd.org mentioned: Dear port maintainers, The following list includes ports maintained by you that have duplicate LATEST_LINK values. They should either be modified to use a unique LATEST_LINK or suppressed using NO_LATEST_LINK, to avoid overwriting each other in the packages/Latest directory. If your ports conflict with ports maintained by another person, please coordinate your efforts with them. ocaml-notk lang/ocaml-nox11 po...@freebsd.org ocaml-notk lang/ocaml s...@freebsd.org ^^ Hi! I think there was some error in generating this list. How does this happened that the PKGNAME of lang/ocaml became ocaml-notk? It gets set to ocaml-notk only if WITHOUT_TK is defined. -- Stanislav Sedov ST4096-RIPE pgp92MvmwUsxG.pgp Description: PGP signature
Re: [Call For Testing] VirtualBox for FreeBSD!
Good evening everyone. Earlier today, I finished a VBox build on a fresh system. After the build succeeded, I 'kldload /boot/modules/vboxdrv.ko' which caused a panic. The machine runs a GENERIC kernel with KDB and KDB_UNATTENDED added -- no other changes. -- The machine -- FreeBSD orion 7.2-STABLE FreeBSD 7.2-STABLE #1 r193481: Sat Jun 6 10:22:25 EDT 2009 r...@orion:/usr/obj/usr/src/sys/ORION i386 -- Snippet from 'dmesg' -- FreeBSD 7.2-STABLE #0 r193481: Fri Jun 5 01:55:06 EDT 2009 r...@orion:/usr/obj/usr/src/sys/ORION Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz (2217.69-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6fd Stepping = 13 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe39dSSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x2010NX,LM AMD Features2=0x1LAHF Cores per package: 2 real memory = 2128793600 (2030 MB) avail memory = 2073436160 (1977 MB) ACPI APIC Table: INTEL DG33FB FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 -- The panic -- orion# kgdb kernel.debug /var/crash/vmcore.0 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... Unread portion of the kernel message buffer: !!Assertion Failed!! Expression: cMillies != RT_INDEFINITE_WAIT Location : /usr/home/gbarber/virtualbox/virtualbox/work/virtualbox-2.2.2r19980/ src/VBox/Runtime/r0drv/freebsd/semevent-r0drv-freebsd.c(212) rtSemEventWait Fatal trap 3: breakpoint instruction fault while in kernel mode cpuid = 1; apic id = 01 instruction pointer = 0x20:0xc5e180be stack pointer = 0x28:0xe7a73c08 frame pointer = 0x28:0xe7a73c34 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= IOPL = 0 current process = 1838 (TIMER) trap number = 3 panic: breakpoint instruction fault cpuid = 1 Uptime: 6h58m4s Physical memory: 2017 MB Dumping 180 MB: 165 149 133 117 101 85 69 53 37 21 5 Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from /boot/kerne l/coretemp.ko.symbols...done. done. Loaded symbols for /boot/kernel/coretemp.ko Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/ac pi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko #0 doadump () at pcpu.h:196 196 __asm __volatile(movl %%fs:0,%0 : =r (td)); (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc07e45a7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc07e48b2 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0ae6d83 in trap_fatal (frame=0xe7a73bc8, eva=0) at /usr/src/sys/i386/i386/trap.c:939 #4 0xc0ae7bdc in trap (frame=0xe7a73bc8) at /usr/src/sys/i386/i386/trap.c:726 #5 0xc0acc05b in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #6 0xc5e180be in rtSemEventWait (EventSem=0xc5d2a110, cMillies=4294967295, fInterruptible=false) at /usr/home/gbarber/virtualbox/virtualbox/work/virtualbox-2.2.2r19980/src/V Box/Runtime/r0drv/freebsd/semevent-r0drv-freebsd.c:212 #7 0xc5e181b0 in RTSemEventWait (EventSem=0xc5d2a110, cMillies=4294967295) at /usr/home/gbarber/virtualbox/virtualbox/work/virtualbox-2.2.2r19980/src/V Box/Runtime/r0drv/freebsd/semevent-r0drv-freebsd.c:240 #8 0xc5e157f1 in rtTimerThread (Thread=0xc5d2b990, pvUser=0xc5d2be90) at /usr/home/gbarber/virtualbox/virtualbox/work/virtualbox-2.2.2r19980/src/V Box/Runtime/generic/timer-generic.cpp:238 #9 0xc5e1a6c0 in rtThreadMain (pThread=0xc5d2b990, NativeThread=3316025600, pszThreadName=0xc5d2b9d0 TIMER) at /usr/home/gbarber/virtualbox/virtualbox/work/virtualbox-2.2.2r19980/src/V Box/Runtime/common/misc/thread.cpp:635 #10 0xc5e26ee7 in rtThreadNativeMain (pvThreadInt=0xc5d2b990) at /usr/home/gbarber/virtualbox/virtualbox/work/virtualbox-2.2.2r19980/src/V Box/Runtime/r0drv/freebsd/thread2-r0drv-freebsd.c:112 ---Type return to continue, or q return to quit--- #11 0xc07bdbc9 in fork_exit (callout=0xc5e26ec0 rtThreadNativeMain, arg=0xc5d2b990, frame=0xe7a73d38) at /usr/src/sys/kern/kern_fork.c:811 #12 0xc0acc0d0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264 (kgdb) Any thoughts? If needed, I will test patches. -- Glen Barber ___
Re: Automatically generate symlinks for virtual categories.
Newest version's Makefile is attached.
--
Eitan Adler
Security is increased by designing for the way humans actually behave.
-Jakob Nielsen
# New ports collection makefile for: symlink
# Date created:Fri Jun 05 2009
# Whom:Eitan Adler eitanadlerl...@gmail.com
#
# $FreeBSD$
#
PORTNAME= symlink
PORTVERSION=4
CATEGORIES= ports-mgmt
MASTER_SITES= http://isis.poly.edu/~eitan/files/
DISTNAME= auto-symlink-virtual-${PORTVERSION}.sh
EXTRACT_SUFX=
MAINTAINER= eitanadlerl...@gmail.com
COMMENT=Automatically generate symlinks for virtual categories
NO_BUILD= yes
EXTRACT_ONLY= # nada
PLIST_FILES=bin/${PORTNAME}
do-install:
${INSTALL_SCRIPT} ${DISTDIR}/${DISTNAME} ${PREFIX}/bin/${PORTNAME}
.include bsd.port.mk
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
porting dash (the shell)
if gcc -DBSD=1 -DSMALL -DSHELL -DGLOB_BROKEN -DFNMATCH_BROKEN -DIFS_BROKEN -D__COPYRIGHT\(x\)= -D__RCSID\(x\)= -D_DIAGASSERT\(x\)= -I. -I. -I.. -include ../config.h -g -O2 -Wall -MT exec.o -MD -MP -MF .deps/exec.Tpo \ -c -o exec.o `test -f 'exec.c' || echo './'`exec.c; \ then mv -f .deps/exec.Tpo .deps/exec.Po; \ else rm -f .deps/exec.Tpo; exit 1; \ fi exec.c: In function 'find_command': exec.c:317: error: storage size of 'statb' isn't known exec.c:326: warning: implicit declaration of function 'stat64' exec.c:317: warning: unused eitan 'statb' gmake[3]: *** [exec.o] Error 1 gmake[3]: Leaving directory `/home/eitan/dash-0.5.1/src' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/eitan/dash-0.5.1/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/eitan/dash-0.5.1' gmake: *** [all] Error 2 -- Eitan Adler Security is increased by designing for the way humans actually behave. -Jakob Nielsen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: porting dash (the shell)
Boris Kochergin wrote: Eitan Adler wrote: if gcc -DBSD=1 -DSMALL -DSHELL -DGLOB_BROKEN -DFNMATCH_BROKEN -DIFS_BROKEN -D__COPYRIGHT\(x\)= -D__RCSID\(x\)= -D_DIAGASSERT\(x\)= -I. -I. -I.. -include ../config.h -g -O2 -Wall -MT exec.o -MD -MP -MF .deps/exec.Tpo \ -c -o exec.o `test -f 'exec.c' || echo './'`exec.c; \ then mv -f .deps/exec.Tpo .deps/exec.Po; \ else rm -f .deps/exec.Tpo; exit 1; \ fi exec.c: In function 'find_command': exec.c:317: error: storage size of 'statb' isn't known exec.c:326: warning: implicit declaration of function 'stat64' exec.c:317: warning: unused eitan 'statb' gmake[3]: *** [exec.o] Error 1 gmake[3]: Leaving directory `/home/eitan/dash-0.5.1/src' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/eitan/dash-0.5.1/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/eitan/dash-0.5.1' gmake: *** [all] Error 2 stat64() and the statb structure appear to be some kind of Linuxisms. FreeBSD's stat() doesn't have any trouble with file sizes of over 2 GiB, so try replacing the stat64() call with stat() and the statb structure with a stat structure. -Boris After doing a global search and replace of stat64 to stat I get: mystring.c: In function 'single_quote': mystring.c:164: warning: implicit declaration of function 'strchrnul' mystring.c:164: error: invalid operands to binary - mystring.c:169: warning: implicit declaration of function 'mempcpy' mystring.c:169: warning: incompatible implicit declaration of built-in function 'mempcpy' -- Eitan Adler Security is increased by designing for the way humans actually behave. -Jakob Nielsen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: porting dash (the shell)
Eitan Adler wrote: if gcc -DBSD=1 -DSMALL -DSHELL -DGLOB_BROKEN -DFNMATCH_BROKEN -DIFS_BROKEN -D__COPYRIGHT\(x\)= -D__RCSID\(x\)= -D_DIAGASSERT\(x\)= -I. -I. -I.. -include ../config.h -g -O2 -Wall -MT exec.o -MD -MP -MF .deps/exec.Tpo \ -c -o exec.o `test -f 'exec.c' || echo './'`exec.c; \ then mv -f .deps/exec.Tpo .deps/exec.Po; \ else rm -f .deps/exec.Tpo; exit 1; \ fi exec.c: In function 'find_command': exec.c:317: error: storage size of 'statb' isn't known exec.c:326: warning: implicit declaration of function 'stat64' exec.c:317: warning: unused eitan 'statb' gmake[3]: *** [exec.o] Error 1 gmake[3]: Leaving directory `/home/eitan/dash-0.5.1/src' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/eitan/dash-0.5.1/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/eitan/dash-0.5.1' gmake: *** [all] Error 2 stat64() and the statb structure appear to be some kind of Linuxisms. FreeBSD's stat() doesn't have any trouble with file sizes of over 2 GiB, so try replacing the stat64() call with stat() and the statb structure with a stat structure. -Boris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
