Re: AHCI Driver on ICH7 (27c08086) Chipset
Ali Mashtizadeh wrote: > I have a new motherboard with an ICH7 chipset (G41) and the ata driver > recognizes it as ATA_I82801GB_S1 (PCI ID 27c08086), but this card does > not seem to work with the AHCI. Can anyone point me to why this is the > case? I really need NCQ working for this machine. Most of ICH7 chipsets (especially on cheap boards) do not support AHCI mode. Only ICH7R and ICH7M do, if BIOS is so kind to enable it. -- Alexander Motin ___ 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"
Newbie question: kernel image a dynamically linked binary?
Hello List, I'm a newbie and coming from Linux background, and am trying to learn FreeBSD now. The first thing I find a little confusing is that the final FreeBSD kernel image is shown as a DYNAMICALLY LINKED binary: $ $ pwd /boot/kernel $ $ file kernel kernel: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked (uses shared libs), not stripped $ How can the kernel image use shared libraries? And which ones does it use, if any? Also, I cannot find out the libraries the image uses using the traditional ldd command: $ ldd kernel kernel: kernel: signal 6 $ Can some please throw some light? Thanks, Dan ___ 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: AHCI Driver on ICH7 (27c08086) Chipset
Ali Mashtizadeh wrote: > Hi Everyone, > > I have a new motherboard with an ICH7 chipset (G41) and the ata driver > recognizes it as ATA_I82801GB_S1 (PCI ID 27c08086), but this card does > not seem to work with the AHCI. Can anyone point me to why this is the > case? I really need NCQ working for this machine. http://www.intel.com/support/chipsets/imst/sb/cs-012304.htm In short: ICH7R and ICH7M both have AHCI support but ICH7 does not. 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"
Re: Newbie question: kernel image a dynamically linked binary?
On Thu, 1 Apr 2010 15:53:50 +0530 Daniel Rodrick wrote: > Hello List, > > I'm a newbie and coming from Linux background, and am trying to learn > FreeBSD now. The first thing I find a little confusing is that the > final FreeBSD kernel image is shown as a DYNAMICALLY LINKED binary: > > $ > $ pwd > /boot/kernel > $ > $ file kernel > kernel: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), > dynamically linked (uses shared libs), not stripped > $ > > How can the kernel image use shared libraries? And which ones does it > use, if any? > > Also, I cannot find out the libraries the image uses using the > traditional ldd command: > > $ ldd kernel > kernel: > kernel: signal 6 > $ > > Can some please throw some light? > file is confused. FreeBSD uses a monolithic kernel and no shared libraries are involved. However, it is possible to dynamically load modules using kldload. See the appropriate man page. -- Gary Jennejohn ___ 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: Newbie question: kernel image a dynamically linked binary?
Hi,
Please don't crosspost to many lists. This topic is probably
suitable for hackers@ but not for the other lists.
Daniel Rodrick wrote:
> I'm a newbie and coming from Linux background, and am trying to learn
> FreeBSD now. The first thing I find a little confusing is that the
> final FreeBSD kernel image is shown as a DYNAMICALLY LINKED binary:
>
> $
> $ pwd
> /boot/kernel
> $
> $ file kernel
> kernel: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD),
> dynamically linked (uses shared libs), not stripped
> $
>
> How can the kernel image use shared libraries? And which ones does it
> use, if any?
>
> Also, I cannot find out the libraries the image uses using the
> traditional ldd command:
>
> $ ldd kernel
> kernel:
> kernel: signal 6
> $
ldd works by actually executing the binary with a special
flag for rtld(1). Compare:
$ ldd /bin/sh
/bin/sh:
libedit.so.7 => /lib/libedit.so.7 (0x280a8000)
libncurses.so.8 => /lib/libncurses.so.8 (0x280bd000)
libc.so.7 => /lib/libc.so.7 (0x280fc000)
$ LD_TRACE_LOADED_OBJECTS=1 /bin/sh
libedit.so.7 => /lib/libedit.so.7 (0x280a8000)
libncurses.so.8 => /lib/libncurses.so.8 (0x280bd000)
libc.so.7 => /lib/libc.so.7 (0x280fc000)
Of course you cannot execute the kernel (only the boot loader
knows how to load and boot the kernel), so ldd fails on the
kernel.
But you can use objdump(1) to list dynamic dependencies.
$ objdump -p /bin/sh | grep NEEDED
NEEDED libedit.so.7
NEEDED libncurses.so.8
NEEDED libc.so.7
$ objdump -p /boot/kernel/kernel | grep NEEDED
NEEDED hack.So
As far as I know, the kernel and all kernel modules need to
be dynamic binaries so the kernel linker works, which is
required for dynamically loading kernel modules.
So what is that "hack.So" object? It's just a dummy that's
required for technical reasons. You can see the details in
/sys/conf/kern.post.mk which contains this paragraph:
# This is a hack. BFD "optimizes" away dynamic mode if there are no
# dynamic references. We could probably do a '-Bforcedynamic' mode like
# in the a.out ld. For now, this works.
HACK_EXTRA_FLAGS?= -shared
hack.So: Makefile
:> hack.c
${CC} ${HACK_EXTRA_FLAGS} -nostdlib hack.c -o hack.So
rm -f hack.c
> Can some please throw some light?
I hope I did. :-)
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
"Unix gives you just enough rope to hang yourself --
and then a couple of more feet, just to be sure."
-- Eric Allman
___
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: Newbie question: kernel image a dynamically linked binary?
On Thursday 01 April 2010 6:23:50 am Daniel Rodrick wrote:
> Hello List,
>
> I'm a newbie and coming from Linux background, and am trying to learn
> FreeBSD now. The first thing I find a little confusing is that the
> final FreeBSD kernel image is shown as a DYNAMICALLY LINKED binary:
>
> $
> $ pwd
> /boot/kernel
> $
> $ file kernel
> kernel: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD),
> dynamically linked (uses shared libs), not stripped
> $
>
> How can the kernel image use shared libraries? And which ones does it
> use, if any?
>
> Also, I cannot find out the libraries the image uses using the
> traditional ldd command:
>
> $ ldd kernel
> kernel:
> kernel: signal 6
> $
>
> Can some please throw some light?
It's a hack that is used so that the kernel linker is able to link in kernel
modules that are built as shared objects. The kernel is mostly built from
static objects, but a single dynamic object (that is empty) is linked in:
# This is a hack. BFD "optimizes" away dynamic mode if there are no
# dynamic references. We could probably do a '-Bforcedynamic' mode like
# in the a.out ld. For now, this works.
HACK_EXTRA_FLAGS?= -shared
hack.So: Makefile
:> hack.c
${CC} ${HACK_EXTRA_FLAGS} -nostdlib hack.c -o hack.So
rm -f hack.c
--
John Baldwin
___
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: Fwd: mkuzip and/or geom_uzip changes?
On Wednesday 31 March 2010 6:32:09 pm Tim Judd wrote: > Hi All, > > Just starting to see if I can find other reports. You all probably > have had the "more than one pair of eyes looking at a thing is better > than my eyes alone." This is why I'm writing now, as I'm starting the > discovery. > > Let me background this a little bit. I only started looking into this > because mkuzip and it's counterpart, geom_uzip are throwing errors on > FreeBSD8 i386 > > > scenario (/etc/src.conf in effect, removing *LOTS* of stuff with knobs): > make DESTDIR=/home/small8 installworld installkernel distribution > mv /home/small8/boot /home/small8-boot/ > makefs -t ffs /home/small8/usr.img /home/small8/usr/ > mkuzip -o /home/small8/usr.uzip /home/small8/usr.img [*] > chflags -R noschg /home/small8/usr/* > rm -rf /home/small8/usr/* /home/small8/usr.img > ee /home/small8/etc/rc.d/mountcritlocal > [**] > makefs -t ffs /home/small8-boot/mfsroot /home/small8/ > gzip --best /home/small8-boot/mfsroot > ee /home/small8-boot/boot/loader.conf > [***] > rm /home/small8-boot/boot/kernel/*.symbols > gzip --best /home/small8-boot/boot/kernel/kernel > mkisofs -U -J -r -V "FreeBSD8" -b boot/cdboot -no-emul-boot > -iso-level 4 -o /home/small8.iso /home/small8-boot/ > > > [*]: mkuzip inserts a script header that is broken. module name it's > searching for may have been renamed? > [**]: Edited mountcritlocal to mount the usr.uzip file as by using the > above script header, throws errors > [***]: added zlib and geom_uzip modules to load to the boot image, to > satisfy the script header's requirements. > > OK, the above scenario creates about a 33MB usr.uzip, and a 68MB iso. > Small enough to apparently fit into the undocumented 50 or 100MB size > limit of mfs_root module BTW, you can raise this limit by changing NKPT. > The problem: > mkuzip generates a few lines as a script in the head of the > resulting *.uzip file. Two problems... > 1) the module it queries for is geom_uzip (kldstat -m $m), but > FreeBSD8 names the geom_uzip module (i guess, internally) as g_uzip. > mkuzip's generated image will never find the module if they're not > named the same. It is g_uzip even in 7: DECLARE_GEOM_CLASS(g_uzip_class, g_uzip); MODULE_DEPEND(g_uzip, zlib, 1, 1, 1); This has probably just been broken from the start. If it used 'kldstat -n' then it might work. Well, it probably works (modulo a warning) by accident as it doesn't hurt to kldload an already-loaded module. Note though that it assumes the raw usr.img is an ISO image, not a UFS filesystem. > 2) even with geom_uzip module and it's dependency zlib loaded, i don't > get a mdconfig node '/dev/md?.uzip' to appear. > > It's been forever since I touched uzip, so I have to ask. Do you have a md0 device at all? I think you want to hack the script to do something like this: disk=`mdconfig -af /path/to/usr.img` mount -r /dev/$disk.uzip /usr -- John Baldwin ___ 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: Fwd: mkuzip and/or geom_uzip changes?
On Thursday 01 April 2010 8:38:38 am John Baldwin wrote: > > 2) even with geom_uzip module and it's dependency zlib loaded, i don't > > get a mdconfig node '/dev/md?.uzip' to appear. > > > > It's been forever since I touched uzip, so I have to ask. > > Do you have a md0 device at all? I think you want to hack the script to do > something like this: > > disk=`mdconfig -af /path/to/usr.img` > mount -r /dev/$disk.uzip /usr To clarify, I would hack this into an /etc rc script, not in the script embedded into the uzip image. -- John Baldwin ___ 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: Fwd: mkuzip and/or geom_uzip changes?
On 4/1/10, John Baldwin wrote: > On Wednesday 31 March 2010 6:32:09 pm Tim Judd wrote: >> Hi All, >> >> Just starting to see if I can find other reports. You all probably >> have had the "more than one pair of eyes looking at a thing is better >> than my eyes alone." This is why I'm writing now, as I'm starting the >> discovery. >> >> Let me background this a little bit. I only started looking into this >> because mkuzip and it's counterpart, geom_uzip are throwing errors on >> FreeBSD8 i386 >> >> >> scenario (/etc/src.conf in effect, removing *LOTS* of stuff with knobs): >> make DESTDIR=/home/small8 installworld installkernel distribution >> mv /home/small8/boot /home/small8-boot/ >> makefs -t ffs /home/small8/usr.img /home/small8/usr/ >> mkuzip -o /home/small8/usr.uzip /home/small8/usr.img >> [*] >> chflags -R noschg /home/small8/usr/* >> rm -rf /home/small8/usr/* /home/small8/usr.img >> ee /home/small8/etc/rc.d/mountcritlocal >> [**] >> makefs -t ffs /home/small8-boot/mfsroot /home/small8/ >> gzip --best /home/small8-boot/mfsroot >> ee /home/small8-boot/boot/loader.conf >> [***] >> rm /home/small8-boot/boot/kernel/*.symbols >> gzip --best /home/small8-boot/boot/kernel/kernel >> mkisofs -U -J -r -V "FreeBSD8" -b boot/cdboot -no-emul-boot >> -iso-level 4 -o /home/small8.iso /home/small8-boot/ >> >> >> [*]: mkuzip inserts a script header that is broken. module name it's >> searching for may have been renamed? >> [**]: Edited mountcritlocal to mount the usr.uzip file as by using the >> above script header, throws errors >> [***]: added zlib and geom_uzip modules to load to the boot image, to >> satisfy the script header's requirements. >> >> OK, the above scenario creates about a 33MB usr.uzip, and a 68MB iso. >> Small enough to apparently fit into the undocumented 50 or 100MB size >> limit of mfs_root module > > BTW, you can raise this limit by changing NKPT. I'm sorry, I'm not sure what you're referring to when you are telling me this. > >> The problem: >> mkuzip generates a few lines as a script in the head of the >> resulting *.uzip file. Two problems... >> 1) the module it queries for is geom_uzip (kldstat -m $m), but >> FreeBSD8 names the geom_uzip module (i guess, internally) as g_uzip. >> mkuzip's generated image will never find the module if they're not >> named the same. > > It is g_uzip even in 7: > > DECLARE_GEOM_CLASS(g_uzip_class, g_uzip); > MODULE_DEPEND(g_uzip, zlib, 1, 1, 1); > > This has probably just been broken from the start. If it used 'kldstat -n' > then it might work. Well, it probably works (modulo a warning) by accident > as > it doesn't hurt to kldload an already-loaded module. Note though that it > assumes the raw usr.img is an ISO image, not a UFS filesystem. > >> 2) even with geom_uzip module and it's dependency zlib loaded, i don't >> get a mdconfig node '/dev/md?.uzip' to appear. >> >> It's been forever since I touched uzip, so I have to ask. > > Do you have a md0 device at all? I think you want to hack the script to do > something like this: I double check at home tonight, but I don't remember any additional md devices, since I'm running from an MFS_ROOT, i get md0, but that's all. I definately do not get any /dev/md?.uzip files. No .uzips show up. > > disk=`mdconfig -af /path/to/usr.img` > mount -r /dev/$disk.uzip /usr > > -- > John Baldwin > I noted it defaulted to cd9660 too. I hadn't gotten to debugging that point, since I never get a devnode of .uzip I'll follow up tonight. ___ 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: Compiling kernel with gcc43 [SOLVED]
Mario Lobo wrote: > [...] > It's compiling right now. > > I'll post my findings and impressions on results and performance right after > the next reboot. So, how is it going? Any benchmarks yet? I'm curious if the new gcc version will really make a significant difference. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." -- Doug Gwyn ___ 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: Compiling kernel with gcc43 [SOLVED]
On Thursday 01 April 2010 15:27:41 Oliver Fromme wrote: > Mario Lobo wrote: > > [...] > > It's compiling right now. > > > > I'll post my findings and impressions on results and performance right > > after the next reboot. > > So, how is it going? Any benchmarks yet? I'm curious > if the new gcc version will really make a significant > difference. I would love to see the /etc/make.conf, /etc/src.conf and /etc/libmap.conf files that were used for the build. I have tried compiling in VBox a current kernel and world, but it usually just bombs out for me. I would like to give this a go as well. Peg ___ 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: Fwd: mkuzip and/or geom_uzip changes?
On Thursday 01 April 2010 10:48:07 am Tim Judd wrote: > On 4/1/10, John Baldwin wrote: > > On Wednesday 31 March 2010 6:32:09 pm Tim Judd wrote: > >> Hi All, > >> > >> Just starting to see if I can find other reports. You all probably > >> have had the "more than one pair of eyes looking at a thing is better > >> than my eyes alone." This is why I'm writing now, as I'm starting the > >> discovery. > >> > >> Let me background this a little bit. I only started looking into this > >> because mkuzip and it's counterpart, geom_uzip are throwing errors on > >> FreeBSD8 i386 > >> > >> > >> scenario (/etc/src.conf in effect, removing *LOTS* of stuff with knobs): > >> make DESTDIR=/home/small8 installworld installkernel distribution > >> mv /home/small8/boot /home/small8-boot/ > >> makefs -t ffs /home/small8/usr.img /home/small8/usr/ > >> mkuzip -o /home/small8/usr.uzip /home/small8/usr.img > >> [*] > >> chflags -R noschg /home/small8/usr/* > >> rm -rf /home/small8/usr/* /home/small8/usr.img > >> ee /home/small8/etc/rc.d/mountcritlocal > >> [**] > >> makefs -t ffs /home/small8-boot/mfsroot /home/small8/ > >> gzip --best /home/small8-boot/mfsroot > >> ee /home/small8-boot/boot/loader.conf > >> [***] > >> rm /home/small8-boot/boot/kernel/*.symbols > >> gzip --best /home/small8-boot/boot/kernel/kernel > >> mkisofs -U -J -r -V "FreeBSD8" -b boot/cdboot -no-emul-boot > >> -iso-level 4 -o /home/small8.iso /home/small8-boot/ > >> > >> > >> [*]: mkuzip inserts a script header that is broken. module name it's > >> searching for may have been renamed? > >> [**]: Edited mountcritlocal to mount the usr.uzip file as by using the > >> above script header, throws errors > >> [***]: added zlib and geom_uzip modules to load to the boot image, to > >> satisfy the script header's requirements. > >> > >> OK, the above scenario creates about a 33MB usr.uzip, and a 68MB iso. > >> Small enough to apparently fit into the undocumented 50 or 100MB size > >> limit of mfs_root module > > > > BTW, you can raise this limit by changing NKPT. > > > I'm sorry, I'm not sure what you're referring to when you are telling me this. If you increase NKPT (look in /sys/i386/conf/NOTES on a recent stable) you can use a larger mfs root. > >> 2) even with geom_uzip module and it's dependency zlib loaded, i don't > >> get a mdconfig node '/dev/md?.uzip' to appear. > >> > >> It's been forever since I touched uzip, so I have to ask. > > > > Do you have a md0 device at all? I think you want to hack the script to do > > something like this: > > I double check at home tonight, but I don't remember any additional md > devices, since I'm running from an MFS_ROOT, i get md0, but that's > all. > > I definately do not get any /dev/md?.uzip files. No .uzips show up. You will not get the uzip device until you create the md device via mdconfig -af. > > disk=`mdconfig -af /path/to/usr.img` > > mount -r /dev/$disk.uzip /usr That's why I think you need to add this to a script in /etc. You could perhaps put the mount line in /etc/fstab, but you need to invoke mdconfig to create md1. At that point you should get the md1.uzip device automatically. -- John Baldwin ___ 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: Fwd: mkuzip and/or geom_uzip changes?
On 4/1/10, John Baldwin wrote: > On Thursday 01 April 2010 10:48:07 am Tim Judd wrote: >> On 4/1/10, John Baldwin wrote: >> > On Wednesday 31 March 2010 6:32:09 pm Tim Judd wrote: >> >> Hi All, >> >> >> >> Just starting to see if I can find other reports. You all probably >> >> have had the "more than one pair of eyes looking at a thing is better >> >> than my eyes alone." This is why I'm writing now, as I'm starting the >> >> discovery. >> >> >> >> Let me background this a little bit. I only started looking into this >> >> because mkuzip and it's counterpart, geom_uzip are throwing errors on >> >> FreeBSD8 i386 >> >> >> >> >> >> scenario (/etc/src.conf in effect, removing *LOTS* of stuff with >> >> knobs): >> >> make DESTDIR=/home/small8 installworld installkernel distribution >> >> mv /home/small8/boot /home/small8-boot/ >> >> makefs -t ffs /home/small8/usr.img /home/small8/usr/ >> >> mkuzip -o /home/small8/usr.uzip /home/small8/usr.img >> >> [*] >> >> chflags -R noschg /home/small8/usr/* >> >> rm -rf /home/small8/usr/* /home/small8/usr.img >> >> ee /home/small8/etc/rc.d/mountcritlocal >> >> [**] >> >> makefs -t ffs /home/small8-boot/mfsroot /home/small8/ >> >> gzip --best /home/small8-boot/mfsroot >> >> ee /home/small8-boot/boot/loader.conf >> >> [***] >> >> rm /home/small8-boot/boot/kernel/*.symbols >> >> gzip --best /home/small8-boot/boot/kernel/kernel >> >> mkisofs -U -J -r -V "FreeBSD8" -b boot/cdboot -no-emul-boot >> >> -iso-level 4 -o /home/small8.iso /home/small8-boot/ >> >> >> >> >> >> [*]: mkuzip inserts a script header that is broken. module name it's >> >> searching for may have been renamed? >> >> [**]: Edited mountcritlocal to mount the usr.uzip file as by using the >> >> above script header, throws errors >> >> [***]: added zlib and geom_uzip modules to load to the boot image, to >> >> satisfy the script header's requirements. >> >> >> >> OK, the above scenario creates about a 33MB usr.uzip, and a 68MB iso. >> >> Small enough to apparently fit into the undocumented 50 or 100MB size >> >> limit of mfs_root module >> > >> > BTW, you can raise this limit by changing NKPT. >> >> >> I'm sorry, I'm not sure what you're referring to when you are telling me >> this. > > If you increase NKPT (look in /sys/i386/conf/NOTES on a recent stable) you > can use a larger mfs root. > >> >> 2) even with geom_uzip module and it's dependency zlib loaded, i don't >> >> get a mdconfig node '/dev/md?.uzip' to appear. >> >> >> >> It's been forever since I touched uzip, so I have to ask. >> > >> > Do you have a md0 device at all? I think you want to hack the script to >> > do >> > something like this: >> >> I double check at home tonight, but I don't remember any additional md >> devices, since I'm running from an MFS_ROOT, i get md0, but that's >> all. >> >> I definately do not get any /dev/md?.uzip files. No .uzips show up. > > You will not get the uzip device until you create the md device via > mdconfig -af. And that was one of my troubleshooting attempts the other night. Instead of relying on a (misdone) embedded script, I tried mdconfig -at vnode -f; and a mdconfig -af;. If I recall, they create a md? node, but not a md?.uzip node. No joy, I have been trying to grep source files seeing what might be the problem of creating the md?.uzip, but I still haven't found the code that does it. Can you duplicate the issue? I haven't gotten into trying to rebuild world (without the src.conf exclusions). I might be able to attempt that tonight. Thanks for your time, Mr. Baldwin. > >> >disk=`mdconfig -af /path/to/usr.img` >> >mount -r /dev/$disk.uzip /usr > > That's why I think you need to add this to a script in /etc. You could > perhaps put the mount line in /etc/fstab, but you need to invoke mdconfig > to create md1. At that point you should get the md1.uzip device > automatically. That above script wouldn't give a devnode /dev/md?.uzip. it's being run manually at a single-user mode and it doesn't create the /dev/md?.uzip node. I will be doing all this this evening when I get home. > > -- > John Baldwin > ___ 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: Compiling kernel with gcc43 [SOLVED]
On Thu, Apr 1, 2010 at 6:27 PM, Oliver Fromme wrote: > Mario Lobo wrote: > > [...] > > It's compiling right now. > > > > I'll post my findings and impressions on results and performance right > after > > the next reboot. > > So, how is it going? Any benchmarks yet? I'm curious > if the new gcc version will really make a significant > difference. > I'm not as worried about performance as I am about compatibilty. Various software suites have started using newer GCCisms in their code. One example I can give from the top of my head is Wt (www.webtoolkit.eu), which compiles with 4.4, but not with 4.2. I shamefully haven't dug any deeper to check which particular syntactical construct offended 4.2. Yes, one might say, after all it's the upstream developers who ought to make sure their software compiles on FreeBSD, but some aditional overhead on the shoulders of our port maintainers should be expected. > Best regards > Oliver > > -- > Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. > Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: > secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- > chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart > > FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd > > "UNIX was not designed to stop you from doing stupid things, > because that would also stop you from doing clever things." > -- Doug Gwyn > ___ > 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" > -- Good, fast & cheap. Pick any two. ___ 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: Fwd: mkuzip and/or geom_uzip changes?
On Thursday 01 April 2010 1:14:30 pm Tim Judd wrote: > On 4/1/10, John Baldwin wrote: > > On Thursday 01 April 2010 10:48:07 am Tim Judd wrote: > >> On 4/1/10, John Baldwin wrote: > >> > On Wednesday 31 March 2010 6:32:09 pm Tim Judd wrote: > >> >> Hi All, > >> >> > >> >> Just starting to see if I can find other reports. You all probably > >> >> have had the "more than one pair of eyes looking at a thing is better > >> >> than my eyes alone." This is why I'm writing now, as I'm starting the > >> >> discovery. > >> >> > >> >> Let me background this a little bit. I only started looking into this > >> >> because mkuzip and it's counterpart, geom_uzip are throwing errors on > >> >> FreeBSD8 i386 > >> >> > >> >> > >> >> scenario (/etc/src.conf in effect, removing *LOTS* of stuff with > >> >> knobs): > >> >> make DESTDIR=/home/small8 installworld installkernel distribution > >> >> mv /home/small8/boot /home/small8-boot/ > >> >> makefs -t ffs /home/small8/usr.img /home/small8/usr/ > >> >> mkuzip -o /home/small8/usr.uzip /home/small8/usr.img > >> >> [*] > >> >> chflags -R noschg /home/small8/usr/* > >> >> rm -rf /home/small8/usr/* /home/small8/usr.img > >> >> ee /home/small8/etc/rc.d/mountcritlocal > >> >> [**] > >> >> makefs -t ffs /home/small8-boot/mfsroot /home/small8/ > >> >> gzip --best /home/small8-boot/mfsroot > >> >> ee /home/small8-boot/boot/loader.conf > >> >> [***] > >> >> rm /home/small8-boot/boot/kernel/*.symbols > >> >> gzip --best /home/small8-boot/boot/kernel/kernel > >> >> mkisofs -U -J -r -V "FreeBSD8" -b boot/cdboot -no-emul-boot > >> >> -iso-level 4 -o /home/small8.iso /home/small8-boot/ > >> >> > >> >> > >> >> [*]: mkuzip inserts a script header that is broken. module name it's > >> >> searching for may have been renamed? > >> >> [**]: Edited mountcritlocal to mount the usr.uzip file as by using the > >> >> above script header, throws errors > >> >> [***]: added zlib and geom_uzip modules to load to the boot image, to > >> >> satisfy the script header's requirements. > >> >> > >> >> OK, the above scenario creates about a 33MB usr.uzip, and a 68MB iso. > >> >> Small enough to apparently fit into the undocumented 50 or 100MB size > >> >> limit of mfs_root module > >> > > >> > BTW, you can raise this limit by changing NKPT. > >> > >> > >> I'm sorry, I'm not sure what you're referring to when you are telling me > >> this. > > > > If you increase NKPT (look in /sys/i386/conf/NOTES on a recent stable) you > > can use a larger mfs root. > > > >> >> 2) even with geom_uzip module and it's dependency zlib loaded, i don't > >> >> get a mdconfig node '/dev/md?.uzip' to appear. > >> >> > >> >> It's been forever since I touched uzip, so I have to ask. > >> > > >> > Do you have a md0 device at all? I think you want to hack the script to > >> > do > >> > something like this: > >> > >> I double check at home tonight, but I don't remember any additional md > >> devices, since I'm running from an MFS_ROOT, i get md0, but that's > >> all. > >> > >> I definately do not get any /dev/md?.uzip files. No .uzips show up. > > > > You will not get the uzip device until you create the md device via > > mdconfig -af. > > And that was one of my troubleshooting attempts the other night. > Instead of relying on a (misdone) embedded script, I tried mdconfig > -at vnode -f; and a mdconfig -af;. If I recall, they create a md? > node, but not a md?.uzip node. > > > No joy, I have been trying to grep source files seeing what might be > the problem of creating the md?.uzip, but I still haven't found the > code that does it. Does it create a /dev/md1 device? -- John Baldwin ___ 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: Newbie question: kernel image a dynamically linked binary?
Dag-Erling Smørgrav writes: > File is right. The kernel contains relocation entries so kernel modules > can be linked against it. "relocation entries" is possibly not the right term, someone with better knowledge of ELF will have to correct me. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Dynamic ticks in FreeBSD
Tsuyoshi Ozawa writes: > Julian Elischer writes: > > Who are you? and what have you done with DES? > Sorry [...] Never mind, Julian was making a joke at my expense. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Newbie question: kernel image a dynamically linked binary?
Gary Jennejohn writes: > Daniel Rodrick writes: > > $ file kernel > > kernel: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), > > dynamically linked (uses shared libs), not stripped > file is confused. FreeBSD uses a monolithic kernel and no shared > libraries are involved. However, it is possible to dynamically load > modules using kldload. See the appropriate man page. File is right. The kernel contains relocation entries so kernel modules can be linked against it. "monolithic" means something else entirely. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Dynamic ticks in FreeBSD
Julian Elischer writes: > Who are you? and what have you done with DES? I gave him a week off... DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Fwd: mkuzip and/or geom_uzip changes?
On 4/1/10, John Baldwin wrote: > On Thursday 01 April 2010 1:14:30 pm Tim Judd wrote: >> On 4/1/10, John Baldwin wrote: >> > On Thursday 01 April 2010 10:48:07 am Tim Judd wrote: >> >> On 4/1/10, John Baldwin wrote: >> >> > On Wednesday 31 March 2010 6:32:09 pm Tim Judd wrote: >> >> >> Hi All, >> >> >> >> >> >> Just starting to see if I can find other reports. You all probably >> >> >> have had the "more than one pair of eyes looking at a thing is >> >> >> better >> >> >> than my eyes alone." This is why I'm writing now, as I'm starting >> >> >> the >> >> >> discovery. >> >> >> >> >> >> Let me background this a little bit. I only started looking into >> >> >> this >> >> >> because mkuzip and it's counterpart, geom_uzip are throwing errors >> >> >> on >> >> >> FreeBSD8 i386 >> >> >> >> >> >> >> >> >> scenario (/etc/src.conf in effect, removing *LOTS* of stuff with >> >> >> knobs): >> >> >> make DESTDIR=/home/small8 installworld installkernel distribution >> >> >> mv /home/small8/boot /home/small8-boot/ >> >> >> makefs -t ffs /home/small8/usr.img /home/small8/usr/ >> >> >> mkuzip -o /home/small8/usr.uzip /home/small8/usr.img >> >> >> [*] >> >> >> chflags -R noschg /home/small8/usr/* >> >> >> rm -rf /home/small8/usr/* /home/small8/usr.img >> >> >> ee /home/small8/etc/rc.d/mountcritlocal >> >> >> [**] >> >> >> makefs -t ffs /home/small8-boot/mfsroot /home/small8/ >> >> >> gzip --best /home/small8-boot/mfsroot >> >> >> ee /home/small8-boot/boot/loader.conf >> >> >> [***] >> >> >> rm /home/small8-boot/boot/kernel/*.symbols >> >> >> gzip --best /home/small8-boot/boot/kernel/kernel >> >> >> mkisofs -U -J -r -V "FreeBSD8" -b boot/cdboot -no-emul-boot >> >> >> -iso-level 4 -o /home/small8.iso /home/small8-boot/ >> >> >> >> >> >> >> >> >> [*]: mkuzip inserts a script header that is broken. module name >> >> >> it's >> >> >> searching for may have been renamed? >> >> >> [**]: Edited mountcritlocal to mount the usr.uzip file as by using >> >> >> the >> >> >> above script header, throws errors >> >> >> [***]: added zlib and geom_uzip modules to load to the boot image, >> >> >> to >> >> >> satisfy the script header's requirements. >> >> >> >> >> >> OK, the above scenario creates about a 33MB usr.uzip, and a 68MB >> >> >> iso. >> >> >> Small enough to apparently fit into the undocumented 50 or 100MB >> >> >> size >> >> >> limit of mfs_root module >> >> > >> >> > BTW, you can raise this limit by changing NKPT. >> >> >> >> >> >> I'm sorry, I'm not sure what you're referring to when you are telling >> >> me >> >> this. >> > >> > If you increase NKPT (look in /sys/i386/conf/NOTES on a recent stable) >> > you >> > can use a larger mfs root. >> > >> >> >> 2) even with geom_uzip module and it's dependency zlib loaded, i >> >> >> don't >> >> >> get a mdconfig node '/dev/md?.uzip' to appear. >> >> >> >> >> >> It's been forever since I touched uzip, so I have to ask. >> >> > >> >> > Do you have a md0 device at all? I think you want to hack the script >> >> > > to >> >> > do >> >> > something like this: >> >> >> >> I double check at home tonight, but I don't remember any additional md >> >> devices, since I'm running from an MFS_ROOT, i get md0, but that's >> >> all. >> >> >> >> I definately do not get any /dev/md?.uzip files. No .uzips show up. >> > >> > You will not get the uzip device until you create the md device via >> > mdconfig -af. >> >> And that was one of my troubleshooting attempts the other night. >> Instead of relying on a (misdone) embedded script, I tried mdconfig >> -at vnode -f; and a mdconfig -af;. If I recall, they create a md? >> node, but not a md?.uzip node. >> >> >> No joy, I have been trying to grep source files seeing what might be >> the problem of creating the md?.uzip, but I still haven't found the >> code that does it. > > Does it create a /dev/md1 device? If I remember, it does. I will be double checking these details tonight. In about 2 hrs or so. > > -- > John Baldwin > ___ 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: Fwd: mkuzip and/or geom_uzip changes?
On 4/1/10, John Baldwin wrote: > On Wednesday 31 March 2010 6:32:09 pm Tim Judd wrote: >> Hi All, >> >> Just starting to see if I can find other reports. You all probably >> have had the "more than one pair of eyes looking at a thing is better >> than my eyes alone." This is why I'm writing now, as I'm starting the >> discovery. >> >> Let me background this a little bit. I only started looking into this >> because mkuzip and it's counterpart, geom_uzip are throwing errors on >> FreeBSD8 i386 >> >> >> scenario (/etc/src.conf in effect, removing *LOTS* of stuff with knobs): >> make DESTDIR=/home/small8 installworld installkernel distribution >> mv /home/small8/boot /home/small8-boot/ >> makefs -t ffs /home/small8/usr.img /home/small8/usr/ >> mkuzip -o /home/small8/usr.uzip /home/small8/usr.img >> [*] >> chflags -R noschg /home/small8/usr/* >> rm -rf /home/small8/usr/* /home/small8/usr.img >> ee /home/small8/etc/rc.d/mountcritlocal >> [**] >> makefs -t ffs /home/small8-boot/mfsroot /home/small8/ >> gzip --best /home/small8-boot/mfsroot >> ee /home/small8-boot/boot/loader.conf >> [***] >> rm /home/small8-boot/boot/kernel/*.symbols >> gzip --best /home/small8-boot/boot/kernel/kernel >> mkisofs -U -J -r -V "FreeBSD8" -b boot/cdboot -no-emul-boot >> -iso-level 4 -o /home/small8.iso /home/small8-boot/ >> >> >> [*]: mkuzip inserts a script header that is broken. module name it's >> searching for may have been renamed? >> [**]: Edited mountcritlocal to mount the usr.uzip file as by using the >> above script header, throws errors >> [***]: added zlib and geom_uzip modules to load to the boot image, to >> satisfy the script header's requirements. >> >> OK, the above scenario creates about a 33MB usr.uzip, and a 68MB iso. >> Small enough to apparently fit into the undocumented 50 or 100MB size >> limit of mfs_root module > > BTW, you can raise this limit by changing NKPT. > >> The problem: >> mkuzip generates a few lines as a script in the head of the >> resulting *.uzip file. Two problems... >> 1) the module it queries for is geom_uzip (kldstat -m $m), but >> FreeBSD8 names the geom_uzip module (i guess, internally) as g_uzip. >> mkuzip's generated image will never find the module if they're not >> named the same. > > It is g_uzip even in 7: > > DECLARE_GEOM_CLASS(g_uzip_class, g_uzip); > MODULE_DEPEND(g_uzip, zlib, 1, 1, 1); > > This has probably just been broken from the start. If it used 'kldstat -n' > then it might work. Well, it probably works (modulo a warning) by accident > as > it doesn't hurt to kldload an already-loaded module. Note though that it > assumes the raw usr.img is an ISO image, not a UFS filesystem. > >> 2) even with geom_uzip module and it's dependency zlib loaded, i don't >> get a mdconfig node '/dev/md?.uzip' to appear. >> >> It's been forever since I touched uzip, so I have to ask. > > Do you have a md0 device at all? I think you want to hack the script to do > something like this: > > disk=`mdconfig -af /path/to/usr.img` > mount -r /dev/$disk.uzip /usr > > -- > John Baldwin > booted single-user md0 is the mfs_root here is the manual attachment of an mdconfig... # mdconfig -af /usr.uzip WARNING: opening backing store: /usr.uzip readonly md1.uzip: block size (24) should be a multiple of 512. md1 # ls /dev/md1* /dev/md1 # ___ 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: Fwd: mkuzip and/or geom_uzip changes?
On 4/1/10, Tim Judd wrote: > On 4/1/10, John Baldwin wrote: >> On Wednesday 31 March 2010 6:32:09 pm Tim Judd wrote: >>> Hi All, >>> >>> Just starting to see if I can find other reports. You all probably >>> have had the "more than one pair of eyes looking at a thing is better >>> than my eyes alone." This is why I'm writing now, as I'm starting the >>> discovery. >>> >>> Let me background this a little bit. I only started looking into this >>> because mkuzip and it's counterpart, geom_uzip are throwing errors on >>> FreeBSD8 i386 >>> >>> >>> scenario (/etc/src.conf in effect, removing *LOTS* of stuff with knobs): >>> make DESTDIR=/home/small8 installworld installkernel distribution >>> mv /home/small8/boot /home/small8-boot/ >>> makefs -t ffs /home/small8/usr.img /home/small8/usr/ >>> mkuzip -o /home/small8/usr.uzip /home/small8/usr.img >>> [*] >>> chflags -R noschg /home/small8/usr/* >>> rm -rf /home/small8/usr/* /home/small8/usr.img >>> ee /home/small8/etc/rc.d/mountcritlocal >>> [**] >>> makefs -t ffs /home/small8-boot/mfsroot /home/small8/ >>> gzip --best /home/small8-boot/mfsroot >>> ee /home/small8-boot/boot/loader.conf >>> [***] >>> rm /home/small8-boot/boot/kernel/*.symbols >>> gzip --best /home/small8-boot/boot/kernel/kernel >>> mkisofs -U -J -r -V "FreeBSD8" -b boot/cdboot -no-emul-boot >>> -iso-level 4 -o /home/small8.iso /home/small8-boot/ >>> >>> >>> [*]: mkuzip inserts a script header that is broken. module name it's >>> searching for may have been renamed? >>> [**]: Edited mountcritlocal to mount the usr.uzip file as by using the >>> above script header, throws errors >>> [***]: added zlib and geom_uzip modules to load to the boot image, to >>> satisfy the script header's requirements. >>> >>> OK, the above scenario creates about a 33MB usr.uzip, and a 68MB iso. >>> Small enough to apparently fit into the undocumented 50 or 100MB size >>> limit of mfs_root module >> >> BTW, you can raise this limit by changing NKPT. >> >>> The problem: >>> mkuzip generates a few lines as a script in the head of the >>> resulting *.uzip file. Two problems... >>> 1) the module it queries for is geom_uzip (kldstat -m $m), but >>> FreeBSD8 names the geom_uzip module (i guess, internally) as g_uzip. >>> mkuzip's generated image will never find the module if they're not >>> named the same. >> >> It is g_uzip even in 7: >> >> DECLARE_GEOM_CLASS(g_uzip_class, g_uzip); >> MODULE_DEPEND(g_uzip, zlib, 1, 1, 1); >> >> This has probably just been broken from the start. If it used 'kldstat >> -n' >> then it might work. Well, it probably works (modulo a warning) by >> accident >> as >> it doesn't hurt to kldload an already-loaded module. Note though that it >> assumes the raw usr.img is an ISO image, not a UFS filesystem. >> >>> 2) even with geom_uzip module and it's dependency zlib loaded, i don't >>> get a mdconfig node '/dev/md?.uzip' to appear. >>> >>> It's been forever since I touched uzip, so I have to ask. >> >> Do you have a md0 device at all? I think you want to hack the script to >> do >> something like this: >> >> disk=`mdconfig -af /path/to/usr.img` >> mount -r /dev/$disk.uzip /usr >> >> -- >> John Baldwin >> > > > > booted single-user > md0 is the mfs_root > > here is the manual attachment of an mdconfig... > # mdconfig -af /usr.uzip > WARNING: opening backing store: /usr.uzip readonly > md1.uzip: block size (24) should be a multiple of 512. > md1 > # ls /dev/md1* > /dev/md1 > # > Forgot the kldstat, which was obviously omitted # kldstat Id Refs Address Size Name 1 5 0xc040 b6e060 kernel 2 1 0xc0f6f000 3ffc geom_uzip.ko 3 2 -xc0f73000 ac20 zlib.ko ___ 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"
