Re: libnetgraph compilation problem
On Mon, Jan 09, 2006 at 08:49:27PM +0100, Frederic Praca wrote: > Hello and happy new year, > I still got the same problem that is described there > (http://docs.freebsd.org/cgi/mid.cgi?1706.84.247.145.210.1132137934.squirrel > ). > My uname is : > FreeBSD coruscant.dnsalias.net 6.0-STABLE FreeBSD 6.0-STABLE #0: Wed > Jan 4 21:41:20 CET 2006 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CORUSCANT i386 > > Any idea ? > Do you have ccache stuff in /etc/make.conf? Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgp6KwkaZuRBR.pgp Description: PGP signature
fbsd6 and mbufs
Absolute BSD, in the Tweaking Kernel Performance section of chapter 4, recommends increasing the number of mbufs for high network servers, by setting the NMBCLUSTERS option in the kernel. Is this still a good idea/possible in 6 stable, and if so is there a sysctl variable for it, or does it still need to be done in a custom kernel? Thanks Jeff ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fbsd6 and mbufs
Jeffrey Williams wrote: > > Is this still a good idea/possible in 6 stable, and if so is there > a sysctl variable for it, or does it still need to be done in a > custom kernel? perhaps kern.ipc.nmbclusters is what you're looking for. - Nick. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fbsd6 and mbufs
Yep, thank you sir you are a scholar and gentleman - Jeff Nicklas B. Westerlund wrote: Jeffrey Williams wrote: Is this still a good idea/possible in 6 stable, and if so is there a sysctl variable for it, or does it still need to be done in a custom kernel? perhaps kern.ipc.nmbclusters is what you're looking for. - Nick. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: recent rc changes
Charles Sprickman wrote:
Hello,
I recently made the jump to -stable from 6.0 on a box that I'm looking to
bring into production as soon as 6.1 hits. Everything seems fine so far
but for one issue that I am guessing is related to the rc changes in
-stable.
This host has two jails, both started via the rc.conf method, ie:
# jail stuff - general
jail_enable="YES"
jail_list="somejail somejail2"
jail_socket_unixiproute_only="YES"
jail_sysvipc_allow="NO"
# jail stuff - per jail settings
# jail 1 - shell
jail_jail1_rootdir="/jails/somejail"
jail_jail1_hostname="somejail.bway.net"
jail_jail1_ip="216.220.x.x"
jail_jail1_exec_start="/bin/sh /etc/rc"
jail_jail1_exec_stop="/bin/sh /etc/rc.shutdown"
jail_jail1_devfs_enable="YES"
jail_jail1_fdescfs_enable="NO"
jail_jail1_procfs_enable="NO"
jail_jail1_mount_enable="NO"
jail_jail1_devfs_ruleset="devfsrules_jail"
Since the upgrade, I've noticed that none of the ports-installed services
in each jail start up. For example, both jails have apache2 and
mysql40-server installed. Everything in /usr/local/etc/rc.d within each
jail looks correct, and the startup flags are set in each jail's rc.conf.
They start fine if I login to the jail and run the scripts, but do not
start at boot.
See the thread "FreeBSD Port: sysutils/smartmontools (more RCng
problems)" in -ports, particularly the posts by Doug Barton. It sounds
like the same problem. I used his fix to get a couple of daemons to
start at boot which had stopped doing so after u/g to 6.0.
-- quote Doug Barton
Ok, I installed this port and tested it myself, and the problem is the
hard coded value of smartd_enable at the top of the script. For reasons
I don't quite understand yet, hard coding the value in the script
affects the boot-time operation of the script differently than on the
command line.
The good news is that the fix is simple:
Index: smartd.sh
===
RCS file: /home/pcvs/ports/sysutils/smartmontools/files/smartd.sh,v
retrieving revision 1.5
diff -u -r1.5 smartd.sh
--- smartd.sh 18 Nov 2005 11:46:38 - 1.5
+++ smartd.sh 6 Jan 2006 23:36:35 -
@@ -13,8 +13,8 @@
#
# DO NOT CHANGE THESE DEFAULT VALUES HERE
#
-smartd_enable="NO"
-smartd_pidfile="/var/run/smartd.pid"
+smartd_enable=${smartd_enable:-NO}
+smartd_pidfile=${smartd_pidfile:-/var/run/smartd.pid}
. %%RC_SUBR%%
-- quote Doug Barton
HTH
Regards,
Mark
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ifconfig hidessid not hiding SSID on 802.11b with PRISM 2.5 based card
I have set hidessid option to an Intersil PRISM 2.5 based cart, acting as hostap, and the ssid stills gets broadcasted, aparently. Other FreeBSD systems and the Windows software supplied by the vendor can find the SSID while scanning. I would like to know if hidessid should hide it in ordinary scans like those ones, and how to test it better to see if ssid stills broadcasted in the beacons, if it is possible (say, any debug option or tool). Thanks! -- Patrick Tracanelli ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
SATA RAID Controller (PCIe)
Hi, Are there any SATA RAID card controller for PCI Express bus working with FreeBSD 6.0-STABLE? Paulo. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SHA1_Update() produces wrong results for large buffers
On Tue, Jan 10, 2006 at 02:10:33PM +1100, Peter Jeremy wrote:
> I get this on 7-current as well. Copying the relevant bits from libmd
> and compiling it myself, I get the same behaviour. The fact that this
> exits virtually instantly strongly suggests that it is broken (rather
> than the shared version). My initial guess is that an operation on
> the length is overflowing 32 bits. Unfortunately, the asm is rather
> opaque - it was auto-generated by a perl script that doesn't seem to
> included in the repository. (There is a sha1-586.pl in openssl but
> it generates different code).
Yes, the SHA1 implementation in libmd.a is very similar to the one
found in libcrypto.a, the former is just much older.
SHA1_Update as provided by libcrypto.a has no problems with large
buffers. Here's a slightly modified test program (attached), now
compatible with -lcrypto:
gcc sha1test.c -o sha1test.ssl-static -lcrypto -static
gcc sha1test.c -o sha1test.md-shared -lmd
gcc sha1test.c -o sha1test.md-static -lmd -static
dd if=/dev/zero bs=32M count=48 of=test-1.5G
for i in ssl-static md-{shared,static}; do ./sha1test.$i test-1.5G; done
a957f01b1a92366c7b72296cb24eb84f42ed06e4
a957f01b1a92366c7b72296cb24eb84f42ed06e4
747cd7172ce7737d1735cf936c0d69ce0f733fcd
According to this page:
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libmd/i386/
our version of `sha.S' is 6 years old, whereas `sha1-586.pl' as
found in the openssl cvs tree has underwent many changes since
then:
http://cvs.openssl.org/rlog?f=openssl/crypto/sha/asm/sha1-586.pl
> As far as I can determine, the asm code (sha1_block_x86) is designed
> to process an integral number of SHA1 blocks of input, leaving the
> remainder to be processed in the C code. Using the debugger, the
> asm code is not looping when passed 1610612736 (1.5G) - which explains
> the rapid exit and incorrect result.
Yes, thanks for the additional info.
It looks like some parts of libmd should be either fixed/brought
in sync with the openssl cvs, or marked as deprecated.
Peter & Simon, thanks for confirming the test results.
--
Pavel Gorshkov
#include
#include
#include
#include
#include
#include
#include
#include
int main(int argc, char **argv) {
int fd, i;
struct stat st;
SHA_CTX ctx;
unsigned char *buf, digest[20];
char hexdigest[41];
if (argc < 2 || stat(argv[1], &st) < 0 || (fd=open(argv[1], O_RDONLY)) < 0)
exit(1);
if ((buf = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0)) ==
MAP_FAILED)
exit(1);
SHA1_Init(&ctx);
SHA1_Update(&ctx, buf, st.st_size);
SHA1_Final(digest, &ctx);
for (i = 0; i < 20; ++i)
sprintf(hexdigest + 2*i, "%02x", digest[i]);
puts(hexdigest);
if (st.st_size)
munmap(buf, st.st_size);
close(fd);
return 0;
}
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SATA RAID Controller (PCIe)
At 09:24 AM 10/01/2006, Paulo Fragoso wrote: Hi, Are there any SATA RAID card controller for PCI Express bus working with FreeBSD 6.0-STABLE? I have been using the Areca cards on a couple of production boxes with good results so far. They work out of the box with FreeBSD 5.4 and above. http://www.areca.com.tw/products/html/pciE-sata.htm They are nice and fast and have a decent cli and web interface to them. The drivers are in the tree. See the man pages for arcmsr [ns6b]# ./cli "vsf info" # Name Raid# Level Capacity Ch/Id/Lun State === 1 ARC-1210-VOL#001 Raid0+1 240.0GB 00/00/00 Normal === GuiErrMsg<0x00>: Success. [ns6b]# ./cli "hw info" The Hardware Monitor Information === Fan#1 Speed (RPM) : 2772 HDD #1 Temp. : 30 HDD #2 Temp. : 30 HDD #3 Temp. : 30 HDD #4 Temp. : 29 === GuiErrMsg<0x00>: Success. [ns6b]# ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: recent rc changes
Charles Sprickman wrote: Hello, I recently made the jump to -stable from 6.0 on a box that I'm looking to bring into production as soon as 6.1 hits. Everything seems fine so far but for one issue that I am guessing is related to the rc changes in -stable. For rc.conf in the jails, try changing the value of early_late_divider to NETWORKING and let us know if that fixes it for you. Someone else has tested that solution successfully, and I'm behind on adding that hint to the rc man page. Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: recent rc changes
On Tue, Jan 10, 2006 at 10:34:16AM -0800, Doug Barton wrote: > Charles Sprickman wrote: > >Hello, > > > >I recently made the jump to -stable from 6.0 on a box that I'm looking > >to bring into production as soon as 6.1 hits. Everything seems fine so > >far but for one issue that I am guessing is related to the rc changes in > >-stable. > > For rc.conf in the jails, try changing the value of early_late_divider to > NETWORKING and let us know if that fixes it for you. Someone else has > tested that solution successfully, and I'm behind on adding that hint to > the rc man page. You definitly have to change things somehow in the jail case because local scripts won't run until after early_late_divider shows up on the list and in the jail case, the default never shows up. Possible solutions include: - Remove nojail from mountcrit* (should be harmless unless there's a bogus fstab installed). - Add some magic to /etc/defaults/rc.conf to set early_late_divider appropriatly in the jail case. - Put the split code in rcorder controlled by upto and after flags. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpwQZIO5ujbG.pgp Description: PGP signature
Re: ifconfig hidessid not hiding SSID on 802.11b with PRISM 2.5 based card
On Tuesday 10 January 2006 16:02, Patrick Tracanelli wrote: > I have set hidessid option to an Intersil PRISM 2.5 based cart, acting > as hostap, and the ssid stills gets broadcasted, aparently. Other > FreeBSD systems and the Windows software supplied by the vendor can find > the SSID while scanning. > > I would like to know if hidessid should hide it in ordinary scans like > those ones, and how to test it better to see if ssid stills broadcasted > in the beacons, if it is possible (say, any debug option or tool). > > Thanks! I think that for SSID hiding to work there is a need for the firmware on the card to support this. (at least on Prism2/2.5 hardware) Maybe your firmware does not support ssid hiding. You can try to update it. hth, --niki ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[5.4] getting stuck in nfs_rcvlock()
I'm regularly running into a situation on 5.4 (current as of a few weeks ago) where a multi-threaded process comes to a screeching halt due to a vnode lock dependency chain. In other words, many of the threads have various vnodes locked and are trying to acquire another. When you chase down to the end of it, the one thread that's not waiting for a vnode lock is asleep in nfs_rcvlock(). A typical traceback is: Tracing pid 380 tid 100274 td 0xc5e9c600 sched_switch(c5e9c600,0,2) at sched_switch+0x143 mi_switch(2,0) at mi_switch+0x1ba thread_suspend_check(1) at thread_suspend_check+0x181 sleepq_catch_signals(c70bdda4,0,0,100,c6779a80) at sleepq_catch_signals+0xe9 msleep(c70bdda4,0,153,c08cd4ae,0) at msleep+0x239 nfs_rcvlock(c6cb2300) at nfs_rcvlock+0x63 nfs_reply(c6cb2300,0,f,0,18) at nfs_reply+0x18 nfs_request(c814b948,c6b72700,3,c5e9c600,c51e1780) at nfs_request+0x2f1 nfs_lookup(eba4b9d8) at nfs_lookup+0x53d lookup(eba4bbd4,81a4,c5e9c600,0,c5bb9000) at lookup+0x2cf namei(eba4bbd4) at namei+0x285 vn_open_cred(eba4bbd4,eba4bcd4,180,c51e1780,27) at vn_open_cred+0x5b vn_open(eba4bbd4,eba4bcd4,180,27,c7c71318) at vn_open+0x1e kern_open(c5e9c600,888a406,0,602,180) at kern_open+0xeb open(c5e9c600,eba4bd04,3,0,296) at open+0x18 syscall(80a002f,2f,bdfc002f,8099200,180) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (5, FreeBSD ELF32, open), eip = 0x48108bcb, esp = 0xbe9cedbc, ebp = 0xbe9cede8 --- The obvious interpretation is a non-responding nfs server. However, no complaints of that sort are being generated by the client that's showing the hang. I've chased all sorts of herrings, red or otherwise, and have not yet come up with a good explanation, let alone a fix. It's almost like the request is never getting transmitted. One promising line was that some debug writes showed retransmits being suppressed due to the congestion avoidance window being too small and never opening back up. However, while artificially opening it helped a little bit on throughput, it didn't make the hang go away. An additional data point is that the vnode that the hanging request is referencing is for a directory that we're in the process of creating a file in. There is always at least one other thread from the same process waiting on the vnode to become free so it can create its own file in the same directory. Unfortunately, the application is rather unwieldy to try to split up into multiple processes to see if it's somehow related to threads rather than nfs per se. Does this sort of problem sound at all familiar to anyone? Any help will be greatly appreciated. I'm running out of hair to pull Dworkin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
gvinum/vinum on 6.0
Howdy. I took 6.0 for a test drive today and was disappointed to find that vinum/gvinum are still in disarray. For example there is a man page for vinum, but only a gvinum binary. gvinum help still lists lots of old vinum commands that are not implemented in gvinum. Lots of basic things I try from the gvinum prompt just tell me "not yet supported". But most importantly, gvinum configuration (at least for a raid-5 plex) still doesn't persist across a reboot :( Has anyone had success with software Raid-5 under freebsd 6.0 ? If so, how did you do it? I've been forced, rather unhappily, to stick with 4.x and some early 5.x releases b/c vinum is critical for me... Any advice would be greatly appreciated. Brian Szymanski Software and Systems Developer Media Matters for America [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gvinum/vinum on 6.0
Hi, On Tue, Jan 10, 2006 at 10:38:29PM -0500, Brian Szymanski wrote: > I took 6.0 for a test drive today and was disappointed to find that > vinum/gvinum are still in disarray. For example there is a man page for > vinum, but only a gvinum binary. gvinum help still lists lots of old vinum > commands that are not implemented in gvinum. Lots of basic things I try > from the gvinum prompt just tell me "not yet supported". Hmm. There is a manpage in 6-STABLE. And there are a few things that don't work but I wouldn't call it "lots". > But most importantly, gvinum configuration (at least for a raid-5 plex) > still doesn't persist across a reboot :( That's a bug; I think it might be related to compiling gvinum in the kernel as opposed to loading it from /boot/loader.conf. I also think there is a fix already commited to 6-STABLE. > Has anyone had success with software Raid-5 under freebsd 6.0 ? If so, how > did you do it? I'm succesfully running gvinum RAID-5 on two plexes on the same machine since 6.0-RC3 or thereabouts. I just used the same procedure I used to setup volumes with "regular" vinum. I did not try to migrate volumes however, I started from scratch and restored my data. > I've been forced, rather unhappily, to stick with 4.x and some early 5.x > releases b/c vinum is critical for me... Any advice would be greatly > appreciated. Two things: - contact Lukas Ertl <[EMAIL PROTECTED]> and/or send PRs with any problems that you encounter. He is very responsive, especially when you send in detailed problem reports. - try 6-STABLE instead of 6.0-RELEASE. It might not be useful for you in production, but at least you get a manpage, and the disappearing volume bug might be fixed. If not, you can try option 1. HTH, --Stijn -- My server has more fans than Britney. -- Steve Warwick, from a posting at [EMAIL PROTECTED] pgp5kIkXdmBsq.pgp Description: PGP signature
