Re: Virtualbox
Ian FREISLICH wrote: Has anyone managed to make Virtualbox work on 9-Current? Since installing 3.1.2-OSE VMs, all brand new, abort on startup. The last part of the log seems pertinent: 00:00:15.481 !!Assertion Failed!! 00:00:15.481 Expression: paPages[i].Phys !=3D 0 paPages[i].Phys !=3D NIL_RTHCPHYS !(paPages[i].Phys PAGE_OFFSET_MASK) 00:00:15.481 Location : /usr/ports/emulators/virtualbox-ose/work/VirtualBox-3.1.2_OSE/src/VBox /VMM/MMHyper.cpp(610) int MMR3HyperMapPages(VM*, void*, RTR0PTR, size_t, const SUPPAGE*,=20 const char*, RTGCPTR64*) 00:00:15.482 i=3D0x0 Phys=3D Heap Just wanted to report that -CURRENT compiled yesterday and Virtuabox compiled last night work. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32
On 7 April 2010 23:49, John Baldwin j...@freebsd.org wrote: On Tuesday 06 April 2010 11:24:21 am Nathan Whitehorn wrote: pluknet wrote: Hi, the interesting part for me is how to properly assert now a value of e.g. KINFO_PROC_SIZE varying on err.. different COMPAT_FREEBSD32 arches (say, FreeBSD would have _kern_proc FreeBSD32 compat layer for top/ps/). Probably the cleanest thing would be to set KINFO_PROC_SIZE in machine/proc.h instead of where it is now, and then also define a KINFO_PROC32_SIZE or something in the same place. Also, that would be a really nice feature. Yes, I think this sounds like the best approach. Something quick not clean (well, it passes universe) attached. So, don't shoot me, please ;-). It's unclear how to convert those mips o32/n32/o64/n64 though. I had to make definitions out of _KERNEL visibility as far as sys/proc.h is included from sys/user.h in !_KERNEL only too. -- wbr, pluknet KINFO_PROC_SIZE_md.diff Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Does makeoptions WITH_CTF=yes actually work?
Quoting Navdeep Parhar npar...@gmail.com (from Wed, 14 Apr 2010 11:35:40 -0700): On Wed, Apr 14, 2010 at 01:23:42PM +0200, Alexander Leidinger wrote: Quoting Navdeep Parhar npar...@gmail.com (from Wed, 14 Apr 2010 02:31:30 -0700): On Wed, Apr 14, 2010 at 1:58 AM, Alexander Leidinger netch...@freebsd.org wrote: Quoting Navdeep Parhar npar...@gmail.com (from Wed, 14 Apr 2010 01:33:29 -0700): I read the UPDATING entry that accompanied r206082 and added WITH_CTF=yes to my kernel config, hoping to get CTF information in the kernel and all modules. No luck. It appears that NO_CTF remains set to 1 inspite of the undef NO_CTF in various .mk files and ctfconvert never runs. This is the output I get in my kernel build directory: ---snip--- # make -V NO_CTF -V WITH_CTF yes Can you also try a makeoptions WITH_CTF=yes in your KERNCONF The above one is with WITH_CTF in my kernel config, but this was generated manually with cd /sys/i386/conf; config CONF; cd ../compile/CONF; make -V... and see if the results are as expected? How was r206082 tested? I'm trying to figure out the differences, if any, between your build setup and mine. I made a buildworld with and without WITH_CTF in src.conf to confirm that it works (no installkernel, as the world is known to be not useable with CTF), and I did a lot of tests by hand as above (config;make). Have you or anyone else ever used buildkernel successfully with makeoptions WITH_CTF=yes in the conf file? Something as simple as this does not work for me: - pristine sources in /usr/src, empty /usr/obj, no /etc/make.conf, no /etc/src.conf - add makeoptions WITH_CTF=yes in sys/amd64/conf/GENERIC - make buildkernel in /usr/src I can reproduce what you see. Somewhere NO_CTF is feed to the build of the kernel. I will have a look from where this comes. Until then I suggest to compile the kernel by hand (if you want to make use of the CTF stuff) instead of using buildkernel. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 I attribute my success to intelligence, guts, determination, honesty, ambition, and having enough money to buy people with those qualities. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32
On Thursday 15 April 2010 6:06:24 am pluknet wrote: On 7 April 2010 23:49, John Baldwin j...@freebsd.org wrote: On Tuesday 06 April 2010 11:24:21 am Nathan Whitehorn wrote: pluknet wrote: Hi, the interesting part for me is how to properly assert now a value of e.g. KINFO_PROC_SIZE varying on err.. different COMPAT_FREEBSD32 arches (say, FreeBSD would have _kern_proc FreeBSD32 compat layer for top/ps/). Probably the cleanest thing would be to set KINFO_PROC_SIZE in machine/proc.h instead of where it is now, and then also define a KINFO_PROC32_SIZE or something in the same place. Also, that would be a really nice feature. Yes, I think this sounds like the best approach. Something quick not clean (well, it passes universe) attached. So, don't shoot me, please ;-). It's unclear how to convert those mips o32/n32/o64/n64 though. I had to make definitions out of _KERNEL visibility as far as sys/proc.h is included from sys/user.h in !_KERNEL only too. Just one suggestion: don't make KINFO_PROC32 #define depenedent on COMPAT_FREEBSD32. It should just be always defined. I think that is the approach Nathan used for the 32-bit ELF machine type. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32
On 04/15/10 08:13, John Baldwin wrote: On Thursday 15 April 2010 6:06:24 am pluknet wrote: On 7 April 2010 23:49, John Baldwinj...@freebsd.org wrote: On Tuesday 06 April 2010 11:24:21 am Nathan Whitehorn wrote: pluknet wrote: Hi, the interesting part for me is how to properly assert now a value of e.g. KINFO_PROC_SIZE varying on err.. different COMPAT_FREEBSD32 arches (say, FreeBSD would have _kern_proc FreeBSD32 compat layer for top/ps/). Probably the cleanest thing would be to set KINFO_PROC_SIZE in machine/proc.h instead of where it is now, and then also define a KINFO_PROC32_SIZE or something in the same place. Also, that would be a really nice feature. Yes, I think this sounds like the best approach. Something quick not clean (well, it passes universe) attached. So, don't shoot me, please ;-). It's unclear how to convert those mips o32/n32/o64/n64 though. I had to make definitions out of _KERNEL visibility as far as sys/proc.h is included fromsys/user.h in !_KERNEL only too. Just one suggestion: don't make KINFO_PROC32 #define depenedent on COMPAT_FREEBSD32. It should just be always defined. I think that is the approach Nathan used for the 32-bit ELF machine type. I agree. There's no harm in making it a global definition. You also need a KINFO_PROC32 for ia64, which also implements i386 compatibility. Other than that, the patch looks good to me. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32
On 15 April 2010 17:41, Nathan Whitehorn nwhiteh...@freebsd.org wrote: On 04/15/10 08:13, John Baldwin wrote: On Thursday 15 April 2010 6:06:24 am pluknet wrote: On 7 April 2010 23:49, John Baldwinj...@freebsd.org wrote: On Tuesday 06 April 2010 11:24:21 am Nathan Whitehorn wrote: pluknet wrote: Hi, the interesting part for me is how to properly assert now a value of e.g. KINFO_PROC_SIZE varying on err.. different COMPAT_FREEBSD32 arches (say, FreeBSD would have _kern_proc FreeBSD32 compat layer for top/ps/). Probably the cleanest thing would be to set KINFO_PROC_SIZE in machine/proc.h instead of where it is now, and then also define a KINFO_PROC32_SIZE or something in the same place. Also, that would be a really nice feature. Yes, I think this sounds like the best approach. Something quick not clean (well, it passes universe) attached. So, don't shoot me, please ;-). It's unclear how to convert those mips o32/n32/o64/n64 though. I had to make definitions out of _KERNEL visibility as far as sys/proc.h is included fromsys/user.h in !_KERNEL only too. Just one suggestion: don't make KINFO_PROC32 #define depenedent on COMPAT_FREEBSD32. It should just be always defined. I think that is the approach Nathan used for the 32-bit ELF machine type. I agree. There's no harm in making it a global definition. You also need a KINFO_PROC32 for ia64, which also implements i386 compatibility. Other than that, the patch looks good to me. -Nathan Thanks for your suggestions. -- wbr, pluknet KINFO_PROC_SIZE_md.2.diff Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Call for testers: SiS190/191 Fast/Gigabit ethernet controller
On Tue, Feb 16, 2010 at 01:29:50PM -0800, Pyun YongHyeon wrote: Hi, I had been working on sge(4) to commit the driver to tree. If you have one of these controllers please give it try and let me know how it goes on your box. I'm interested in both success and failure report. Please see more information on the following URL. http://people.freebsd.org/~yongari/sge/README.txt FYI: driver committed to HEAD. Thanks. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
HP, IBM and Supermicro Servers Compatibility.
Hi. I want to know if the IBM, HP or Supermicro Servers are compatible with FreeBSD OS. Could you send me a hardware compatibility list with compatible servers? Thank you. Juanito Caue Cassemiro Técnico em Informática INFO2001 - IARA CRISTINA DA SILVA MEIRELLES ARARAQUARA (16)3331-7727 0800-8912360 Skype: juanitocc_2001 MSN: juanitocc_2...@hotmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Cross compilling kernel i386/amd64 is failed
I get error in same point when I try compile amd64 current GENERIC on i386 machine. Svn revision is 206597 Error at src/sys/amd64/amd64/genassym.c:1: code model 'kernel' not supported in the 32 bit mode. how to cross compile it? PS: I build only kernel at this point. Should I rebuild whole world to build kernel? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Cross compilling kernel i386/amd64 is failed
on 16/04/2010 01:27 Arseny Nasokin said the following: I get error in same point when I try compile amd64 current GENERIC on i386 machine. Svn revision is 206597 Error at src/sys/amd64/amd64/genassym.c:1: code model 'kernel' not supported in the 32 bit mode. how to cross compile it? PS: I build only kernel at this point. Should I rebuild whole world to build kernel? kernel-toolchain See build(7) -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Cross compilling kernel i386/amd64 is failed
On 16 Apr 2010, at 03:03, Andriy Gapon a...@icyb.net.ua wrote: on 16/04/2010 01:27 Arseny Nasokin said the following: I get error in same point when I try compile amd64 current GENERIC on i386 machine. Svn revision is 206597 Error at src/sys/amd64/amd64/genassym.c:1: code model 'kernel' not supported in the 32 bit mode. how to cross compile it? PS: I build only kernel at this point. Should I rebuild whole world to build kernel? kernel-toolchain See build(7) Thanks, I'll create bug with patch -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Malloc_init: Bad Malloc type Magic
Hi All, I have update my Freebsd Box to 8.0 last nigth. When i reboot it, i received this error message. Panic: malloc_init: bad malloc type magic CPUID = 0 I can't anymore boot my box... I try to make un upgrade with Freebsd 8.0 CDROM to correct the situation, obviously that didnt work. I re-install the whole / (with CDROM Network ) on the box, that not correct the situation... Some one experiment this issue... My Laptop work with Freebsd 7.2, but can't boot after a freebsd-update to 8.0 Thanks all for your help PS; The box is a DELL Inspiron ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Malloc_init: Bad Malloc type Magic
On 16 April 2010 04:53, Francis Provencher francisp...@gmail.com wrote: Hi All, I have update my Freebsd Box to 8.0 last nigth. When i reboot it, i received this error message. Panic: malloc_init: bad malloc type magic CPUID = 0 I can't anymore boot my box... You most likely faced with this (from src/UPDATING): 1.594 rwatson 428: 20090419: 429:The layout of struct malloc_type, used by modules to register new 430:memory allocation types, has changed. Most modules will need to 431:be rebuilt or panics may be experienced. 432:Bump __FreeBSD_version to 800081. If you have 3th-party modules from FreeBSD 7, it's time to rebuild them. -- wbr, pluknet ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
