Re: Cross compilling kernel i386/amd64 is failed
on 16/04/2010 04:19 Arseny Nasokin said the following: > > > On 16 Apr 2010, at 03:03, Andriy Gapon 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 Please don't create any new bugs, bug reports are welcome though :-) BTW, what do you want to report? >> >> -- >> Andriy Gapon -- 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: Malloc_init: Bad Malloc type Magic
On 16 April 2010 04:53, Francis Provencher 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"
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: Cross compilling kernel i386/amd64 is failed
On 16 Apr 2010, at 03:03, Andriy Gapon 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"
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"
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: HP, IBM and Supermicro Servers Compatibility.
Juanito Cassemiro wrote: 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? It depends on server model, not on manufacturer in general. I have some IBM, HP, Supermicro and Sun servers in production. But it does not mean all IBM / HP / SM servers will work. You can see more on Hardware Notes http://www.freebsd.org/releases/7.3R/hardware.html http://www.freebsd.org/releases/8.0R/hardware.html Miroslav Lachman ___ 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"
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"
Re: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32
On 15 April 2010 17:41, Nathan Whitehorn 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 Baldwin 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 >>> is included from 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: 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 Baldwin 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 is included from 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 Thursday 15 April 2010 6:06:24 am pluknet wrote: > On 7 April 2010 23:49, John Baldwin 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 > is included from 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: Does "makeoptions WITH_CTF=yes" actually work?
Quoting Navdeep Parhar (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 (from Wed, 14 Apr 2010 02:31:30 -0700): >On Wed, Apr 14, 2010 at 1:58 AM, Alexander Leidinger > wrote: >>Quoting Navdeep Parhar (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 7 April 2010 23:49, John Baldwin 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 is included from 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: 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"
