Re: FreeBSD Crash without Errors, Warnings, or Panics
Paul Saab wrote: The amr driver was not MPSAFE in 5.4 (i think) so you would not have run into these problems. You should be able to just take the driver from RELENG_6 and use it on a released branch. If it doesn't compile, let me know and I'll generate you a tarball or diff that will work. We had major issues with amr at work until Scott Long and I (mostly Scott) helped iron out the stability issues with amr. You should either run RELENG_6 or take the driver from RELENG_6 and use that. You'll get the added benefit of being able to use the Linux management tools (megarc) to see the status of your raid. Presumably this change will make it into 6.1 and is already in the betas/RCs? I'm confused by the megarc comment. There is a port of megarc in the ports which appears to work under 5.4 already, though I've only used it for simple reporting. I've seen references to Scott and your work on improving the driver which uses the same phrase "Linux management tools" but have no real idea what that refers to. Are there tools beyond megarc which now work? If so, any pointers much appreciated. --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Per CPU cpu-statistics under SMP
On Thu, Apr 13, 2006 at 10:20:40AM -0400, John Baldwin wrote: > On Wednesday 12 April 2006 17:50, Marco van Tol wrote: > > Hi there, > > > > My apologies if this is the wrong list to ask this kind of question. > > I would appreciate a pointer to the correct list if it is please. :) > > > > I noticed in the code for gkrellm /usr/ports/sysutils/gkrellm2 that SMP > > per-cpu statistics were not yet supported under FreeBSD, and decided to > > check whether I could add that. (I'm running a (dual-core) Athlon64 X2 > > with FreeBSD 6.1-PRERELEASE) > > I can't find sample code and/or documentation on how to acquire that > > information from the kernel. [...] > > Is there an interface under FreeBSD to acquire the necessary per-cpu > > statistics? > > They don't exist currently. I have a patch to make the stats per-CPU > for performance reasons (though it only helps out on systems with lots > of CPUs (like 10) and hurts on systems with fewer CPUs (like 4)). It > doesn't include a sysctl to get the per-CPU stats, but I could add one. OK, that I could use to get started on the code for adding per-CPU stats to gkrellm under FreeBSD. Is the patch against FreeBSD CURRENT? Then if the per-CPU stats code hits the STABLE trunk, it's likely to be only a few changes to what I did perhaps. Or am I running a bit to far ahead here? :) Is the patch in available your home area on www.freebsd.org? Thanks! Marco -- A male gynecologist is like an auto mechanic who never owned a car. - Carrie Snow ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: linker mysteries
>>> On Thu, 13 Apr 2006 23:12:24 +0200,
>>> Jeremie Le Hen <[EMAIL PROTECTED]> wrote:
jeremie> If I comment out the variable assignements :
jeremie> % .if !defined(NO_CRYPT) && !defined(NO_OPENSSL)
jeremie> % #CFLAGS+=-DWITH_SSL
jeremie> % #DPADD= ${LIBSSL} ${LIBCRYPTO}
jeremie> % #LDADD= -lssl -lcrypto
jeremie> % .endif
jeremie>
jeremie> The resulting linker command is now :
jeremie> % /usr/bin/ld -V -Bshareable -o libfetch.so.4 /usr/lib/crti.o
/usr/lib/crtbeginS.o -L/usr/lib -x -soname libfetch.so.4 file.So http.So ftp.So
common.So fetch.So -lgcc_pic -lgcc_pic /usr/lib/crtendS.o /usr/lib/crtn.o
jeremie>
jeremie> As you can see, we don't have "-lssl -lcrypto" any more. However,
ldd(1)
jeremie> still says that libfetch.so is linked against those libraries :
jeremie> % jarjarbinks# ldd libfetch.so
jeremie> % libfetch.so:
jeremie> % libssl.so.4 => /usr/lib/libssl.so.4 (0x2c72e000)
jeremie> % libcrypto.so.4 => /lib/libcrypto.so.4 (0x2cd74000)
jeremie>
jeremie> Only linking addresses change, but they do at every compilation.
jeremie>
jeremie> I would be glad if someone could explain why this happens.
Makefile of libfetch includes
.include
at last line, and, you can see /usr/share/mk/bsd.lib.mk includes
bsd.libnames.mk
this makefile has
.if defined(LDFLAGS) && !empty(LDFLAGS:M-static)
.if !defined(NO_KERBEROS) && !defined(NOCRYPT) &&
!defined(NO_OPENSSL)
LIBPAM+=${LIBKRB5} ${LIBASN1} ${LIBCRYPTO} ${LIBCRYPT} \
${LIBROKEN} ${LIBCOM_ERR}
MINUSLPAM+= -lkrb5 -lasn1 -lcrypto -lcrypt -lroken -lcom_err
.endif
LIBPAM+=${LIBRADIUS} ${LIBTACPLUS} ${LIBCRYPT} \
${LIBUTIL} ${LIBOPIE} ${LIBMD}
MINUSLPAM+= -lradius -ltacplus -lcrypt \
-lutil -lopie -lmd
So, if you wouldn't like to do with -lssl and -lcrypto,
define NO_CRYPTO and NO_OPENSSL appropriately. e.g. in make.conf.
---
Tomo
pgp9uppu4VZNd.pgp
Description: PGP signature
Re: Per CPU cpu-statistics under SMP
On Friday 14 April 2006 06:38, Marco van Tol wrote: > On Thu, Apr 13, 2006 at 10:20:40AM -0400, John Baldwin wrote: > > On Wednesday 12 April 2006 17:50, Marco van Tol wrote: > > > Hi there, > > > > > > My apologies if this is the wrong list to ask this kind of question. > > > I would appreciate a pointer to the correct list if it is please. :) > > > > > > I noticed in the code for gkrellm /usr/ports/sysutils/gkrellm2 that SMP > > > per-cpu statistics were not yet supported under FreeBSD, and decided to > > > check whether I could add that. (I'm running a (dual-core) Athlon64 X2 > > > with FreeBSD 6.1-PRERELEASE) > > > I can't find sample code and/or documentation on how to acquire that > > > information from the kernel. > > [...] > > > > Is there an interface under FreeBSD to acquire the necessary per-cpu > > > statistics? > > > > They don't exist currently. I have a patch to make the stats per-CPU > > for performance reasons (though it only helps out on systems with lots > > of CPUs (like 10) and hurts on systems with fewer CPUs (like 4)). It > > doesn't include a sysctl to get the per-CPU stats, but I could add one. > > OK, that I could use to get started on the code for adding per-CPU stats to > gkrellm under FreeBSD. Is the patch against FreeBSD CURRENT? > > Then if the per-CPU stats code hits the STABLE trunk, it's likely to be only > a few changes to what I did perhaps. Or am I running a bit to far ahead > here? :) > > Is the patch in available your home area on www.freebsd.org? An early one but it doesn't export the data to userland yet. I need to figure out what interface to use for that. I could have the cp_time sysctl just include the CPU arrays after the global array and key off the passed in length to determine if they should be included or not. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Missing dependencies on shared libraries
Hi, I found that ldd doesn't report libc as a dependency on most (all?) libraries: pato> ldd /usr/lib/libfetch.so /usr/lib/libfetch.so: libssl.so.3 => /usr/lib/libssl.so.3 (0x4816a000) libcrypto.so.3 => /lib/libcrypto.so.3 (0x48198000) does anyone know why? -- La prueba mas fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Missing dependencies on shared libraries
On Fri, 14 Apr 2006, Victor Balada Diaz wrote: Hi, I found that ldd doesn't report libc as a dependency on most (all?) libraries: pato> ldd /usr/lib/libfetch.so /usr/lib/libfetch.so: libssl.so.3 => /usr/lib/libssl.so.3 (0x4816a000) libcrypto.so.3 => /lib/libcrypto.so.3 (0x48198000) does anyone know why? AFAIK, it's being worked on. It's not just libc either, -pthread also has to start linking to libpthread. -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Missing dependencies on shared libraries
On Fri, Apr 14, 2006 at 02:41:06PM -0400, Daniel Eischen wrote: > On Fri, 14 Apr 2006, Victor Balada Diaz wrote: > > >Hi, > >I found that ldd doesn't report libc as a dependency on most (all?) > >libraries: > > > >pato> ldd /usr/lib/libfetch.so > >/usr/lib/libfetch.so: > > libssl.so.3 => /usr/lib/libssl.so.3 (0x4816a000) > > libcrypto.so.3 => /lib/libcrypto.so.3 (0x48198000) > > > >does anyone know why? > > AFAIK, it's being worked on. It's not just libc either, -pthread > also has to start linking to libpthread. Thanks for your fast reply. I'm trying to create a dependency in some libraries, but it does have the same problem as the libc. Is there any way to workaround it? -- La prueba mas fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Missing dependencies on shared libraries
On Fri, 14 Apr 2006, Victor Balada Diaz wrote: On Fri, Apr 14, 2006 at 02:41:06PM -0400, Daniel Eischen wrote: On Fri, 14 Apr 2006, Victor Balada Diaz wrote: Hi, I found that ldd doesn't report libc as a dependency on most (all?) libraries: pato> ldd /usr/lib/libfetch.so /usr/lib/libfetch.so: libssl.so.3 => /usr/lib/libssl.so.3 (0x4816a000) libcrypto.so.3 => /lib/libcrypto.so.3 (0x48198000) does anyone know why? AFAIK, it's being worked on. It's not just libc either, -pthread also has to start linking to libpthread. Thanks for your fast reply. I'm trying to create a dependency in some libraries, but it does have the same problem as the libc. Is there any way to workaround it? Well, you can always try adding -lc. -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Missing dependencies on shared libraries
On Fri, Apr 14, 2006 at 03:20:41PM -0400, Daniel Eischen wrote: > On Fri, 14 Apr 2006, Victor Balada Diaz wrote: > > >On Fri, Apr 14, 2006 at 02:41:06PM -0400, Daniel Eischen wrote: > >>On Fri, 14 Apr 2006, Victor Balada Diaz wrote: > >> > >>>Hi, > >>>I found that ldd doesn't report libc as a dependency on most (all?) > >>>libraries: > >>> > >>>pato> ldd /usr/lib/libfetch.so > >>>/usr/lib/libfetch.so: > >>> libssl.so.3 => /usr/lib/libssl.so.3 (0x4816a000) > >>> libcrypto.so.3 => /lib/libcrypto.so.3 (0x48198000) > >>> > >>>does anyone know why? > >> > >>AFAIK, it's being worked on. It's not just libc either, -pthread > >>also has to start linking to libpthread. > > > >Thanks for your fast reply. > > > >I'm trying to create a dependency in some libraries, but it does > >have the same problem as the libc. Is there any way to workaround it? > > Well, you can always try adding -lc. I tried, but it doesn't work. ldd continues to tell me that libc is not a dependency, but if i use objdump -p it does appear as NEEDED. -- La prueba mas fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
grep out of memory error
Hi, not sure that I'm in the right mailing list here, but I got myselft the 6.1-RC1 amd64 iso yesterday and installed it. I've got a minimum system running and just 10 minutes ago, I ran a 'grep' command and it returned an "out of memory" error. The command run was: grep -d recurse sasl /* The error caused: swap_pager: out of swap space swap_pager_getswapspace(16): failed HOSTNAME kernel: pid 618 (grep), uid 0, was killed: out of swap space Killed Not sure, but this seems a bit odd; I've got one GB of RAM and 512M of swap space allocated. Running top beside the command gives you a nice view of what's happening: All of the RAM is used up almost instantly and the the swap space. All in all, in about 3 seconds, I get that out of memory error. Again, I'm not an expert in these matters, but it seems odd that grep needs more than 1.5GB to grep (even if it's recursive from the root dir). Does anyone else experience that problem as well? Thanks, Dragos ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: grep out of memory error
On Sat, Apr 15, 2006 at 12:16:23PM +1000, Dragos Ionita wrote: > Hi, > > not sure that I'm in the right mailing list here, but I got myselft > the 6.1-RC1 amd64 iso yesterday and installed it. > > I've got a minimum system running and just 10 minutes ago, I ran a > 'grep' command and it returned an "out of memory" error. > > The command run was: > > grep -d recurse sasl /* > > The error caused: > > swap_pager: out of swap space > swap_pager_getswapspace(16): failed > HOSTNAME kernel: pid 618 (grep), uid 0, was killed: out of swap space > Killed > > Not sure, but this seems a bit odd; I've got one GB of RAM and 512M > of swap space allocated. > > Running top beside the command gives you a nice view of what's > happening: All of the RAM is used up almost instantly and the the > swap space. All in all, in about 3 seconds, I get that out of memory > error. > > Again, I'm not an expert in these matters, but it seems odd that grep > needs more than 1.5GB to grep (even if it's recursive from the root > dir). > > Does anyone else experience that problem as well? It's probably grepping /dev/zero, which is an exercise in futility. Kris pgpllMMMuLUBD.pgp Description: PGP signature
User mounting take 2
Based on feedback I received on my initial diff, I took another crack at user mounting. To address Robert's concerns, I drop the setuid permissions until needed. Therefore, all permission checks are now done in the kernel. The same is true for umount(8). silby asked for wildcard support. To handle that, I added glob support to both the fs_file and fs_spec fstab components (via fnmatch(3)), and also added a special %u pattern that can be used to represent the current user (i.e. the user running mount(8)). This effectively allows the following in /etc/fstab: //[EMAIL PROTECTED]/homes/home/%u/smb_homesmbfsrw,noauto,user0 0 Then, a user could just run, for example: mount /home/marcus/smb_home And their SMB home directory would get mounted (~/.nsmbrc is also respected). Additionally, something like the following is also possible: /dev/acd0/home/*/cdromcd9660 ro,noauto,user0 0 Same mount command works here: mount /home/marcus/cdrom Wildcards can also be mixed and matched. Finally, in testing this, I found a problem with smbfs, msdosfs, and ntfs relating to the statfs(2) f_flags field. smbfs always set this to 0, msdosfs didn't set this at all, and ntfs set this to all flags (not just those visible to statfs(2)). By fixing this, umount(8) works properly on relative paths to user mount points for those three file systems. http://www.marcuscom.com/downloads/usermount.diff Comments? Joe -- Joe Marcus Clarke FreeBSD GNOME Team :: [EMAIL PROTECTED] FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome signature.asc Description: This is a digitally signed message part
