Re: xl(4) polling
On 5/10/05, Rob [EMAIL PROTECTED] wrote: Interestingly: HZ=1000 is apparently a problem with the xl devices (3Com 3c905B-TX), but not with the rl devices (RealTek 8139). What could cause that difference? Could a difference in buffer size on the LAN card cause this? Yes. GigE cards tend to have larger packet buffers, but that certainly doesn't solve all the problems. I've been having some problems with the em cards in particular (fxp I've had no problems with) as no matter what I've tried tuning (tcprecvspace, HZ, polling knobs) I've been seeing packet loss of about 0.5%. That doesn't seem like much, but it's an awful lot to the couple thousand users behind it. Anyways, HZ=1000 shouldn't be a CPU problem on anything faster than a 500MHz-ish processor. There are also a few lightly documented sysctls that might be useful to play with that do things like poll during the idle loop (actual usefullness in any particular case may be void in your area, many will enter, few will win). -- Jon Simola Systems Administrator ABC Communications ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xl(4) polling
On 5/11/2005 11:14, Rob wrote: When I have to put up a new FreeBSD box, I start from 100 and start beefing up the number until I find a good balance. Hmmm, how do you find a good balance ? Network access speed vs. lost connections.? Yes. The access times during the top load period and the average load period helps me to decide the ideal value. Also its worthwhile to adjust the values: sysctl -a | grep nmbcluster They determine the number of buffers available for storing network connections. Interestingly: HZ=1000 is apparently a problem with the xl devices (3Com 3c905B-TX), but not with the rl devices (RealTek 8139). What could cause that difference? Could a difference in buffer size on the LAN card cause this? Highly possible. But it also depends on the sysctl values I mentioned above. Regards S. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.4-RELEASE is now available
On Mon, May 09, 2005 at 05:04:58PM -0400, Ken Smith wrote.. The Release Engineering Team is happy to announce the availability of FreeBSD 5.4-RELEASE, the latest release of the FreeBSD Stable development branch. Since FreeBSD 5.3-RELEASE in November 2004 we have made many improvements in functionality, stability, performance, and device driver support for some hardware, as well as dealt with known security issues and made many bugfixes. For a complete list of new features, known problems, and late-breaking news, please see the release notes and errata list, available here: http://www.FreeBSD.org/releases/5.4R/relnotes.html http://www.FreeBSD.org/releases/5.4R/errata.html FreeBSD 5.4 will become an Errata Branch. In addition to Security fixes other well-tested fixes to basic functionality will be committed to the RELENG_5.4 branch after the release. Both Security Advisories and Errata Notices are announced on the freebsd-announce@freebsd.org mailing list. It is expected there will be at least one more release from the RELENG_5 branch, most likely two. The current plans are for the RELENG_6 branch to be created within the next few months, and an initial 6.0-RELEASE will be made a few months afterwards. There will be a 5.5-RELEASE following a few months after the 6.0-RELEASE. For more information about FreeBSD release engineering activities, please see: http://www.FreeBSD.org/releng/ Dedication -- The FreeBSD 5.4 Release is dedicated to the memory of Cameron Grant. Cameron was an active FreeBSD Developer and principal architect of the sound driver subsystem despite his physical handicap. His is a superb example of human spirit dominating over adversity. Cameron was an inspiration to those who met him; he will be fondly remembered and sorely missed. Availability FreeBSD 5.4-RELEASE supports the i386, amd64, ia64, pc98, sparc64, and alpha architectures and can be installed directly over the net, using bootable media, or copied to a local NFS/FTP server. Distributions for all architectures except alpha are available now. The distribution for alpha should become available within the next day or two. Alpha is now also available. CD Image Checksums -- MD5 (5.4-RELEASE-alpha-bootonly.iso) = f9c54aa9fb1ca861f3d343bb3b8378b9 MD5 (5.4-RELEASE-alpha-disc1.iso) = 18294d25be50b06bdd645c5800bd4e94 MD5 (5.4-RELEASE-alpha-disc2.iso) = 2d6a4ebfbdaa34f80a1457dc0041e946 enjoy, Wilko -- Wilko Bulte [EMAIL PROTECTED] pgpG5YHBhPBTv.pgp Description: PGP signature
Re: Creating a mini install disk, for particular needs
On Wed, May 11, 2005 at 12:56:07AM +0100, Chris Phillips wrote: I am trying to find a suitable alternative to our crappy, solid-state, thin client boxes (because they are so awfully unreliable the manufacturer has also gone down the tubes). We need a fairly painless way, to roll out a fresh install onto some random i386 hardware we have lying around (there's a plentiful supply), for any new users, who require a basic functioning GUI, with access to graphical email client, web browser 'rdesktop' (for the windows applications, that they are all hooked on). You may also try to use your PCs as thin clients. Check out http://www.thinbsd.org/ , it is a small FreeBSD based system to create X11 or Windows terminals. (Don't be afraid by the release dates, the project is not dead). What I'd love to be able to do, is to create a FreeBSD (it's my favorite) CD, that contains all that I need for these basic systems. Either, set up so that the install is automated, with just the minimal of setup, or so that it's got all the packages that I want can all be installed straight off the CD (perhaps by choosing the All Packages option). Is what I've described actually possible? There are informations to script the install process in sysinstall(8) I had to install FreeBSD and Linux on dozens of workstations before and found out the CD thing was not the most practicable way. I ended up doing a fairly complete install on a master machine and cloning it via PXE booting and dd (disks were identicals). Check out this paper for a similar technique: http://www.pix.net/software/pxeboot/archive/SANE.pdf -- Francois Tigeot ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xl(4) polling
--- Subhro [EMAIL PROTECTED] wrote: On 5/11/2005 8:04, Rob wrote: All computers are running 5-Stable, as of May 10. All, but PC1 with fxp, use polling, with: options DEVICE_POLLING options HZ=1000 1000 IMHO seems a bit too heavy. Try something lower. Same problem. Ssh-tunnel connection is also disrupted with HZ=100. May I conclude that the HZ value is not the culprit? Or should I try once again with HZ=10? kern.ipc.nmbclusters is 4928 for this PC. Is that good or bad? sysctl -a | grep -i polling gives following: kern.polling.burst: 150 kern.polling.each_burst: 5 kern.polling.burst_max: 150 kern.polling.idle_poll: 0 kern.polling.poll_in_trap: 0 kern.polling.user_frac: 50 kern.polling.reg_frac: 20 kern.polling.short_ticks: 0 kern.polling.lost_polls: 6 kern.polling.pending_polls: 0 kern.polling.residual_burst: 0 kern.polling.handlers: 0 kern.polling.enable: 0 kern.polling.phase: 0 kern.polling.suspect: 6 kern.polling.stalled: 0 kern.polling.idlepoll_sleeping: 1 118kern.polling.enable: 118xl0: flags=18843UP,BROADCAST,RUNNING,SIMPLEX, MULTICAST,POLLING mtu 1500 118 options=49RXCSUM,VLAN_MTU,POLLING 118xl1: flags=18843UP,BROADCAST,RUNNING,SIMPLEX, MULTICAST,POLLING mtu 1500 118 options=49RXCSUM,VLAN_MTU,POLLING I actually doubt whether the default values of these sysctl variables would cause the problem. Regards, Rob. __ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xl(4) polling
On 5/11/2005 13:13, Rob wrote: --- Subhro [EMAIL PROTECTED] wrote: On 5/11/2005 8:04, Rob wrote: All computers are running 5-Stable, as of May 10. All, but PC1 with fxp, use polling, with: options DEVICE_POLLING options HZ=1000 1000 IMHO seems a bit too heavy. Try something lower. Same problem. Ssh-tunnel connection is also disrupted with HZ=100. May I conclude that the HZ value is not the culprit? Or should I try once again with HZ=10? 100 should be fine. 10 would be a bit too much overkill. kern.ipc.nmbclusters is 4928 for this PC. Is that good or bad? What is the purpose of the box? Give a description of the network traffic. sysctl -a | grep -i polling gives following: kern.polling.burst: 150 kern.polling.each_burst: 5 kern.polling.burst_max: 150 kern.polling.idle_poll: 0 kern.polling.poll_in_trap: 0 kern.polling.user_frac: 50 kern.polling.reg_frac: 20 kern.polling.short_ticks: 0 kern.polling.lost_polls: 6 kern.polling.pending_polls: 0 kern.polling.residual_burst: 0 kern.polling.handlers: 0 kern.polling.enable: 0 kern.polling.phase: 0 kern.polling.suspect: 6 kern.polling.stalled: 0 kern.polling.idlepoll_sleeping: 1 118kern.polling.enable: 118xl0: flags=18843UP,BROADCAST,RUNNING,SIMPLEX, MULTICAST,POLLING mtu 1500 118 options=49RXCSUM,VLAN_MTU,POLLING 118xl1: flags=18843UP,BROADCAST,RUNNING,SIMPLEX, MULTICAST,POLLING mtu 1500 118 options=49RXCSUM,VLAN_MTU,POLLING Did you use any strange CFLAGS like -O3 or -f* compile time options when you built the system? Regards S. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xl(4) polling
--- Subhro [EMAIL PROTECTED] wrote: On 5/11/2005 13:13, Rob wrote: --- Subhro [EMAIL PROTECTED] wrote: On 5/11/2005 8:04, Rob wrote: All computers are running 5-Stable, as of May 10. All, but PC1 with fxp, use polling, with: options DEVICE_POLLING options HZ=1000 1000 IMHO seems a bit too heavy. Try something lower. Same problem. Ssh-tunnel connection is also disrupted with HZ=100. May I conclude that the HZ value is not the culprit? Or should I try once again with HZ=10? 100 should be fine. 10 would be a bit too much overkill. kern.ipc.nmbclusters is 4928 for this PC. Is that good or bad? What is the purpose of the box? Give a description of the network traffic. This is a lab in the Chemistry department; the box in question is a dual-homed gateway to eight other PCs in the lab. The box has a tight firewall, and runs an apache server and an SSH server. On the private network, the box also runs as a DHCP server, Samba server and NTP server. OS = 5-Stable. The other PCs in the lab are two FreeBSD PCs and various flavours of Windows. Did you use any strange CFLAGS like -O3 or -f* compile time options when you built the system? No. My /etc/make.conf has: CFLAGS= -O -pipe NOPROFILE=true NO_PF=true kern.polling.enable: 0 Force this to be 1. Damn I should have noted it earlier I took this printout after I changed the value to 0. Of course it is 1 when I test the polling, but when I noticed that the ssh-tunnel connection problem persisted, I changed it to 0; so that my ssh-tunnel connection is not randomly closed :). Thanks for your elaborate help! Rob. __ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xl(4) polling
Subhro wrote: ... In Device Polled systems, the NIC does not generate any interrupt at all. Instead whenever the packets arrive at a Network interface, they are captured and put into a queue. The kernel scheduler checks the quese at regular intervals and processes the packets which are waiting. This interval is adjusted by the options HZ=x kernel option. If the value of x is very high, there may eb two scenarios. In the first scenario, the queue may fill up and subsequent packets are dropped. In this case retransmission of the packets are required. In the second scenario, the packets would be held up for excessive long times which defeats the entire purpose of Device Polling. If the value of x is very low, the scheduler would check the queue frequently and would again defeat the entire idea of Device Polling. It's the other way around. Large values indicate larger polling frequency thus amounting to more checks. Or at least the name of the option would suggest that anyway. -- Tuomo ... I can walk on water, but I stagger on alcohol ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Creating a mini install disk, for particular needs
On Wed, 11 May 2005, Chris Phillips wrote: We need a fairly painless way, to roll out a fresh install onto some random i386 hardware we have lying around (there's a plentiful supply), for any new users, who require a basic functioning GUI, with access to graphical email client, web browser 'rdesktop' (for the windows applications, that they are all hooked on). What I'd love to be able to do, is to create a FreeBSD (it's my favorite) CD, that contains all that I need for these basic systems. Either, set up so that the install is automated, with just the minimal of setup, or so that it's got all the packages that I want can all be installed straight off the CD (perhaps by choosing the All Packages option). Is what I've described actually possible? Would anyone be willing or able, to guide me toward a good resource that I can get reading? It would be very cool, if I could do this for our company. More bums on seats, for FreeBSD :) Chris, If you do want install CD (the other posters so far have looked at thin-client stuff), you might want to check out FreeSBIE and its customisation scripts. It's very straightforward to build a custom CD with things like RDesktop, and comes with a built-in installer (although it does require some extra work to get things like the source and ports trees). www.freesbie.org Cheers, David Adam [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: RAID 1 with Adaptec SATA 1210SA + FreeBSD 5.4 + ata mkIII OK
Gheorghe Ardelean wrote: Hi Soeren, I have to thank you for the work you put in the ata driver. Thanks! After patching the 5.4 sources with the new ata mkIII (http://people.freebsd.org/~sos/ATA) I am able to use the RAID 1 with my Adaptec SATA 1210SA. Good :) let me know if you run into problems with it! -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: State of gvinum RELENG_5 or RELENG_5_4 ?!
On Tue, May 10, 2005 at 11:24:12AM -0600, secmgr wrote: Gabor Esperon wrote: How reliable is the gmirror subsystem? gmirror seems fine as best as I can tell. I've been running it for a few months on sata drives. I had gmirror running on two IDE drives for system and two SATA drives for user data. That was RELENG_5_3. When one of the SATA drives broke (later I got errors like ad4: FAILURE - READ_DMA status=51READY,DSC,ERROR on fscking) the whole system just stopped. I could switch consoles but nothing else. Nothing in the logs either. I believe it had lost all it's file systems. After power cycling, both mirrors were found but marked as broken. Gmirror chose the defective SATA disk as the intact one and started rebuilding the mirror from that - but fscking the mirror failed, obviously, so I ended up with one disk that was broken, but marked intact by gmirror and one disk the other way round. I had to erase the gmirror metadata on the intact disk to get it to work again. I'd say gmirror will save your data but it won't save you from some downtime... Greetings, Peter -- Peter Orlowski Institut für Theoretische Physik Technische Universität Berlin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xl(4) polling
On Wed, May 11, 2005 at 12:43:09AM -0700, Rob wrote: I actually doubt whether the default values of these sysctl variables would cause the problem. No. Can you observe the broken IP/TCP/UDP checksums? netstat -ss -f inet |grep -w bad Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpaHREDnXL0R.pgp Description: PGP signature
Re: freebsd-stable Digest, Vol 109, Issue 6
Hi, i think the setting of HZ has nothing to do with DEVICE_POLLING at once. So the Documentation say's DEVICE_POLLING is an Other way to get the Packets from the Ethernet. I have setted HZ=2000 on all my machines, equal if the Processor is an PI 200MHz or an PIII 866MHz In fact this setting gave me the best results on: PI200 w/o MMX PI200 w/ MMX AMDK6-300 AMDK6-450 PIII 866 Athlon XP2000+ All Machines i have used with xL devies like 3C905B, Cyclone and the other 3C905's. Only difference between the real Problem and my Enviroments is i use only RELENG_4 (i be a little pedantic and konservative with stability and performance). greetings Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FW: FreeBSD 5.4-RELEASE is now available
I'm sorry... But where is miniinst.iso? ;) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
SCHED_ULE with SMP broke libpthread/libthr on 5.4-RELEASE
**Using SCHED_ULE on SMP/HT machine broke applications which use libpthread/libthr, probably at context switching between threads... The applications simply hang and they aren't killable (kill -9 pid don't work).. Usually this also break kernel shutdown (can't flush some inodes or blocks)... This is very big problem for people who want use mysql_server on SMP machines... On FreeBSD 5.4-RC3 this don't happend... Details at http://www.freebsd.org/cgi/query-pr.cgi?pr=threads/80887 -- best regards steve at home.pl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange top(1) output
On Tue, 2005-05-10 at 18:26 +0300, Giorgos Keramidas wrote: On 2005-05-10 10:41, Andre Guibert de Bruet [EMAIL PROTECTED] wrote: On Tue, 10 May 2005, Skip Ford wrote: PID USERNAME THR PRI NICE SIZERES STATETIME WCPUCPU COMM AND 1352 skip 1 960 18968K 16276K select 0:21 0.00% 0.00% Xor 691 skip 1 80 4784K 3940K wait 0:08 0.00% 0.00% mut 684 skip 1 960 2336K 1948K select 0:07 0.00% 0.00% scr 667 root 1 40 24268K 23196K accept 0:06 0.00% 0.00% per 580 root 1 200 22896K 21948K pause0:04 0.00% 0.00% per 447 root 1 960 2864K 1724K select 0:02 0.00% 0.00% ntp What is the length of the longest username that you have on your system? Ah, yes! Good thought. This could affect the width of the USERNAME column and push everything too far to the right. If this is the case, I'd probably vote for optionally limiting the length of the username column to, say, 8 columns at most. I would also vote for limiting it to 8 characters. Even with longer usernames, I suspect 8 characters will be enough to identify particular users (and if it's not there is always they UID view). Doing this would also allow us to eliminate the nasty code in src/usr.bin/top/machine.c which causes top to be unusable on a machine with a significant number of user accounts. See http://lists.freebsd.org/pipermail/freebsd-stable/2005-April/014275.html for details. Gavin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCHED_ULE with SMP broke libpthread/libthr on 5.4-RELEASE
On Mi, 11.05.2005, 14:34, Steven Jurczyk sagte: **Using SCHED_ULE on SMP/HT machine broke applications which use libpthread/libthr, probably at context switching between threads... The applications simply hang and they aren't killable (kill -9 pid don't work).. Usually this also break kernel shutdown (can't flush some inodes or blocks)... right! I have the same problem. My Kernel is basicly a GENERIC with SMP and ULE added (4BSD removed). ([EMAIL PROTECTED] ~)$ uname -a FreeBSD siteop-8.mobile.rz 5.4-STABLE FreeBSD 5.4-STABLE #7: Wed May 11 12:03:35 CEST 2005 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/SITEOP-8 i386 This is very big problem for people who want use mysql_server on SMP machines... indeed. The MySQL server won't start and is not killable. I had to switch back to SCHED_4BSD :-/ I would be available for testing packages, as this machine is not in production. it's a dual xeon 2,8 ... you can find detailed information about it at: http://unixoid.de/freebsd/dmesg.xeon :) best regards, Marian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xl(4) polling
Sorry for my wrong posting Hi, i think the setting of HZ has nothing to do with DEVICE_POLLING at once. So the Documentation say's DEVICE_POLLING is an Other way to get the Packets from the Ethernet. I have setted HZ=2000 on all my machines, equal if the Processor is an PI 200MHz or an PIII 866MHz In fact this setting gave me the best results on: PI200 w/o MMX PI200 w/ MMX AMDK6-300 AMDK6-450 PIII 866 Athlon XP2000+ All Machines i have used with xL devies like 3C905B, Cyclone and the other 3C905's. Only difference between the real Problem and my Enviroments is i use only RELENG_4 (i be a little pedantic and konservative with stability and performance). greetings Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
save-entropy errors on jail after update to 5.4-RELEASE
I updated my box and a jail that runs inside this box to 5.4-RELEASE yesterday. After it, I'm receiving emails from this jail with error messages about /usr/libexec/save-entropy I'm receiving messages like this: mv: /var/db/entropy/saved-entropy.7: No such file or directory mv: /var/db/entropy/saved-entropy.5: No such file or directory override r operator/operator for /var/db/entropy/saved-entropy.5? (y/n [n]) not overwritten override r operator/operator for /var/db/entropy/saved-entropy.4? (y/n [n]) not overwritten override r operator/operator for /var/db/entropy/saved-entropy.3? (y/n [n]) not overwritten override r operator/operator for /var/db/entropy/saved-entropy.2? (y/n [n]) not overwritten here is the files inside the jail: [EMAIL PROTECTED]:~ sudo ls -l /var/db/entropy/ total 16 -r 1 operator operator 2048 May 11 10:33 saved-entropy.1 -r 1 operator operator 2048 May 11 10:33 saved-entropy.2 -r 1 operator operator 2048 May 11 10:22 saved-entropy.3 -r 1 operator operator 2048 May 11 10:22 saved-entropy.4 -r 1 operator operator 2048 May 11 10:11 saved-entropy.5 -r 1 operator operator 2048 May 11 10:11 saved-entropy.6 -r 1 operator operator 2048 May 11 10:00 saved-entropy.7 -r 1 operator operator 2048 May 11 10:00 saved-entropy.8 Anybody could help me to fix it? thanks in advance -- Renato Botelho ICQ: 54596223 AIM: RBGargaBR ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
kernel build problem
dear all, im having trouble compiling kernel on 5.3 , i did a `make depend` and `make`. The following is the error that i got, i might have missed a module i guess... cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I../../.. -I../../../contrib/dev/acpica -I../../../contrib/altq -I../../../contrib/ipfilter -I../../../contrib/pf -I../../../contrib/dev/ath -I../../../contrib/dev/ath/freebsd -I../../../contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror vers.c linking kernel umass.o(.text+0x1b73): In function `umass_cam_attach_sim': : undefined reference to `cam_simq_alloc' umass.o(.text+0x1bc4): In function `umass_cam_attach_sim': : undefined reference to `cam_sim_alloc' umass.o(.text+0x1bd3): In function `umass_cam_attach_sim': : undefined reference to `cam_simq_free' umass.o(.text+0x1bf5): In function `umass_cam_attach_sim': : undefined reference to `xpt_bus_register' umass.o(.text+0x1c21): In function `umass_cam_rescan_callback': : undefined reference to `xpt_free_path' umass.o(.text+0x1c94): In function `umass_cam_rescan': : undefined reference to `xpt_periph' umass.o(.text+0x1ca3): In function `umass_cam_rescan': : undefined reference to `xpt_create_path' umass.o(.text+0x1cbf): In function `umass_cam_rescan': : undefined reference to `xpt_setup_ccb' umass.o(.text+0x1cdc): In function `umass_cam_rescan': : undefined reference to `xpt_action' umass.o(.text+0x1dda): In function `umass_cam_detach_sim': : undefined reference to `xpt_bus_deregister' umass.o(.text+0x1df6): In function `umass_cam_detach_sim': : undefined reference to `cam_sim_free' umass.o(.text+0x1e4d): In function `umass_cam_action': : undefined reference to `xpt_done' umass.o(.text+0x1ec4): In function `umass_cam_action': : undefined reference to `xpt_done' umass.o(.text+0x1ee5): In function `umass_cam_action': : undefined reference to `xpt_done' umass.o(.text+0x1f76): In function `umass_cam_action': : undefined reference to `xpt_done' umass.o(.text+0x204a): In function `umass_cam_action': : undefined reference to `xpt_done' umass.o(.text+0x208e): more undefined references to `xpt_done' follow umass.o(.text+0x2254): In function `umass_cam_action': : undefined reference to `cam_calc_geometry' umass.o(.text+0x225c): In function `umass_cam_action': : undefined reference to `xpt_done' umass.o(.text+0x226d): In function `umass_cam_action': : undefined reference to `xpt_done' umass.o(.text+0x227e): In function `umass_cam_action': : undefined reference to `xpt_done' umass.o(.text+0x22ec): In function `umass_cam_cb': : undefined reference to `xpt_done' umass.o(.text+0x23db): In function `umass_cam_cb': : undefined reference to `xpt_done' umass.o(.text+0x23ff): more undefined references to `xpt_done' follow fdc.o(.text+0xf33): In function `fdc_worker': : undefined reference to `isa_dmadone' fdc.o(.text+0x199b): In function `fdc_worker': : undefined reference to `isa_dmastart' fdc.o(.text+0x1d08): In function `fdc_worker': : undefined reference to `isa_dmadone' fdc.o(.text+0x2cd4): In function `fdc_detach': : undefined reference to `isa_dma_release' fdc.o(.text+0x2ead): In function `fdc_attach': : undefined reference to `isa_dma_acquire' fdc.o(.text+0x2eca): In function `fdc_attach': : undefined reference to `isa_dmainit' fdc_acpi.o(.text+0x1d6): In function `fdc_acpi_attach': : undefined reference to `fdc_isa_alloc_resources' ppc.o(.text+0xff7): In function `ppcintr': : undefined reference to `isa_dmadone' ppc.o(.text+0x11b3): In function `ppc_write': : undefined reference to `isa_dmastart' ppc.o(.text+0x1214): In function `ppc_write': : undefined reference to `isa_dmadone' ppc.o(.text+0x1963): In function `ppc_attach': : undefined reference to `isa_dma_acquire' ppc.o(.text+0x1976): In function `ppc_attach': : undefined reference to `isa_dmainit' sio.o(.text+0x62a): In function `sioprobe': : undefined reference to `isa_irq_pending' sio.o(.text+0x7fa): In function `sioprobe': : undefined reference to `isa_irq_pending' sio.o(.text+0x81c): In function `sioprobe': : undefined reference to `isa_irq_pending' sio.o(.text+0x856): In function `sioprobe': : undefined reference to `isa_irq_pending' *** Error code 1 Stop in /usr/src/sys/i386/compile/kernel_opt. thanks in advance, ananth.g ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Use PCMCIA instead of CardBus?
On Tuesday 10 May 2005 16:15, Warner Losh wrote: I have no idea what you are asking for. Let me restate my original dilemma. My laptop can only use my WLAN card when it's configured as a 16-bit PCMCIA device and not as a 32-bit CardBus device. In NetBSD, this can be accomplished by typing boot -c at its loader prompt and typing disable cbb* to disable the cbb (CardBus) drivers, which leaves the pcic (PCMCIA) drivers to correctly configure the card. After doing this, the card works exactly as hoped. Similarly, I can get the same effect under Linux by disabling the 32-bit CardBus support option; the end result is a happily working WLAN card. However, commenting out device cbb in my FreeBSD kernel results in a non-working setup. By that, I mean that the card's lights never flicker as it's being inserted (as it would do under NetBSD and Linux when it's being probed). In fact, I get no debugging information at all, whether from /var/log/messages or via dmesg. Any ideas where I could go from here? -- Kirk Strauser pgpzjrRmiDCkK.pgp Description: PGP signature
Re: kernel build problem
Content of kernel config please ? It's look like wrong option in config. dear all, im having trouble compiling kernel on 5.3 , i did a `make depend` and `make`. The following is the error that i got, i might have missed a module i guess... cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I../../.. -I../../../contrib/dev/acpica -I../../../contrib/altq -I../../../contrib/ipfilter -I../../../contrib/pf -I../../../contrib/dev/ath -I../../../contrib/dev/ath/freebsd -I../../../contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror vers.c linking kernel umass.o(.text+0x1b73): In function `umass_cam_attach_sim': : undefined reference to `cam_simq_alloc' umass.o(.text+0x1bc4): In function `umass_cam_attach_sim': : undefined reference to `cam_sim_alloc' umass.o(.text+0x1bd3): In function `umass_cam_attach_sim': : undefined reference to `cam_simq_free' umass.o(.text+0x1bf5): In function `umass_cam_attach_sim': : undefined reference to `xpt_bus_register' umass.o(.text+0x1c21): In function `umass_cam_rescan_callback': : undefined reference to `xpt_free_path' umass.o(.text+0x1c94): In function `umass_cam_rescan': : undefined reference to `xpt_periph' umass.o(.text+0x1ca3): In function `umass_cam_rescan': : undefined reference to `xpt_create_path' umass.o(.text+0x1cbf): In function `umass_cam_rescan': : undefined reference to `xpt_setup_ccb' umass.o(.text+0x1cdc): In function `umass_cam_rescan': : undefined reference to `xpt_action' umass.o(.text+0x1dda): In function `umass_cam_detach_sim': : undefined reference to `xpt_bus_deregister' umass.o(.text+0x1df6): In function `umass_cam_detach_sim': : undefined reference to `cam_sim_free' umass.o(.text+0x1e4d): In function `umass_cam_action': : undefined reference to `xpt_done' umass.o(.text+0x1ec4): In function `umass_cam_action': : undefined reference to `xpt_done' umass.o(.text+0x1ee5): In function `umass_cam_action': : undefined reference to `xpt_done' umass.o(.text+0x1f76): In function `umass_cam_action': : undefined reference to `xpt_done' umass.o(.text+0x204a): In function `umass_cam_action': : undefined reference to `xpt_done' umass.o(.text+0x208e): more undefined references to `xpt_done' follow umass.o(.text+0x2254): In function `umass_cam_action': : undefined reference to `cam_calc_geometry' umass.o(.text+0x225c): In function `umass_cam_action': : undefined reference to `xpt_done' umass.o(.text+0x226d): In function `umass_cam_action': : undefined reference to `xpt_done' umass.o(.text+0x227e): In function `umass_cam_action': : undefined reference to `xpt_done' umass.o(.text+0x22ec): In function `umass_cam_cb': : undefined reference to `xpt_done' umass.o(.text+0x23db): In function `umass_cam_cb': : undefined reference to `xpt_done' umass.o(.text+0x23ff): more undefined references to `xpt_done' follow fdc.o(.text+0xf33): In function `fdc_worker': : undefined reference to `isa_dmadone' fdc.o(.text+0x199b): In function `fdc_worker': : undefined reference to `isa_dmastart' fdc.o(.text+0x1d08): In function `fdc_worker': : undefined reference to `isa_dmadone' fdc.o(.text+0x2cd4): In function `fdc_detach': : undefined reference to `isa_dma_release' fdc.o(.text+0x2ead): In function `fdc_attach': : undefined reference to `isa_dma_acquire' fdc.o(.text+0x2eca): In function `fdc_attach': : undefined reference to `isa_dmainit' fdc_acpi.o(.text+0x1d6): In function `fdc_acpi_attach': : undefined reference to `fdc_isa_alloc_resources' ppc.o(.text+0xff7): In function `ppcintr': : undefined reference to `isa_dmadone' ppc.o(.text+0x11b3): In function `ppc_write': : undefined reference to `isa_dmastart' ppc.o(.text+0x1214): In function `ppc_write': : undefined reference to `isa_dmadone' ppc.o(.text+0x1963): In function `ppc_attach': : undefined reference to `isa_dma_acquire' ppc.o(.text+0x1976): In function `ppc_attach': : undefined reference to `isa_dmainit' sio.o(.text+0x62a): In function `sioprobe': : undefined reference to `isa_irq_pending' sio.o(.text+0x7fa): In function `sioprobe': : undefined reference to `isa_irq_pending' sio.o(.text+0x81c): In function `sioprobe': : undefined reference to `isa_irq_pending' sio.o(.text+0x856): In function `sioprobe': : undefined reference to `isa_irq_pending' *** Error code 1 Stop in /usr/src/sys/i386/compile/kernel_opt. thanks in advance, ananth.g ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___
Re: Use PCMCIA instead of CardBus?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 11 May 2005, Kirk Strauser wrote: On Tuesday 10 May 2005 16:15, Warner Losh wrote: I have no idea what you are asking for. Let me restate my original dilemma. My laptop can only use my WLAN card when it's configured as a 16-bit PCMCIA device and not as a 32-bit CardBus device. In NetBSD, this can be accomplished by typing boot -c at its loader prompt and typing disable cbb* to disable the cbb (CardBus) drivers, which leaves the pcic (PCMCIA) drivers to correctly configure the card. After doing this, the card works exactly as hoped. Similarly, I can get the same effect under Linux by disabling the 32-bit CardBus support option; the end result is a happily working WLAN card. However, commenting out device cbb in my FreeBSD kernel results in a non-working setup. By that, I mean that the card's lights never flicker as it's being inserted (as it would do under NetBSD and Linux when it's being probed). In fact, I get no debugging information at all, whether from /var/log/messages or via dmesg. Any ideas where I could go from here? You should take a look into src/sys/i386/conf/OLDCARD change the appropriate lines in you kernel configuration and rebuild your kernel. Hope that is what you are searching for.. Joerg - -- The beginning is the most important part of the work. -Plato -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCghaJSPOsGF+KA+MRAuoDAJ0UcPuJJaCjm2ATNM4n/5tS1lKorwCfeDvA 6Xin6+TqW0pK8GQ6rlD3sTk= =2oKa -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel build problem
i have attached my config file. regrds, ananth.g Sergey S. Ropchan wrote: Content of kernel config please ? It's look like wrong option in config. dear all, im having trouble compiling kernel on 5.3 , i did a `make depend` and `make`. The following is the error that i got, i might have missed a module i guess... cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I../../.. -I../../../contrib/dev/acpica -I../../../contrib/altq -I../../../contrib/ipfilter -I../../../contrib/pf -I../../../contrib/dev/ath -I../../../contrib/dev/ath/freebsd -I../../../contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror vers.c linking kernel umass.o(.text+0x1b73): In function `umass_cam_attach_sim': : undefined reference to `cam_simq_alloc' umass.o(.text+0x1bc4): In function `umass_cam_attach_sim': : undefined reference to `cam_sim_alloc' umass.o(.text+0x1bd3): In function `umass_cam_attach_sim': : undefined reference to `cam_simq_free' umass.o(.text+0x1bf5): In function `umass_cam_attach_sim': : undefined reference to `xpt_bus_register' umass.o(.text+0x1c21): In function `umass_cam_rescan_callback': : undefined reference to `xpt_free_path' umass.o(.text+0x1c94): In function `umass_cam_rescan': : undefined reference to `xpt_periph' umass.o(.text+0x1ca3): In function `umass_cam_rescan': : undefined reference to `xpt_create_path' umass.o(.text+0x1cbf): In function `umass_cam_rescan': : undefined reference to `xpt_setup_ccb' umass.o(.text+0x1cdc): In function `umass_cam_rescan': : undefined reference to `xpt_action' umass.o(.text+0x1dda): In function `umass_cam_detach_sim': : undefined reference to `xpt_bus_deregister' umass.o(.text+0x1df6): In function `umass_cam_detach_sim': : undefined reference to `cam_sim_free' umass.o(.text+0x1e4d): In function `umass_cam_action': : undefined reference to `xpt_done' umass.o(.text+0x1ec4): In function `umass_cam_action': : undefined reference to `xpt_done' umass.o(.text+0x1ee5): In function `umass_cam_action': : undefined reference to `xpt_done' umass.o(.text+0x1f76): In function `umass_cam_action': : undefined reference to `xpt_done' umass.o(.text+0x204a): In function `umass_cam_action': : undefined reference to `xpt_done' umass.o(.text+0x208e): more undefined references to `xpt_done' follow umass.o(.text+0x2254): In function `umass_cam_action': : undefined reference to `cam_calc_geometry' umass.o(.text+0x225c): In function `umass_cam_action': : undefined reference to `xpt_done' umass.o(.text+0x226d): In function `umass_cam_action': : undefined reference to `xpt_done' umass.o(.text+0x227e): In function `umass_cam_action': : undefined reference to `xpt_done' umass.o(.text+0x22ec): In function `umass_cam_cb': : undefined reference to `xpt_done' umass.o(.text+0x23db): In function `umass_cam_cb': : undefined reference to `xpt_done' umass.o(.text+0x23ff): more undefined references to `xpt_done' follow fdc.o(.text+0xf33): In function `fdc_worker': : undefined reference to `isa_dmadone' fdc.o(.text+0x199b): In function `fdc_worker': : undefined reference to `isa_dmastart' fdc.o(.text+0x1d08): In function `fdc_worker': : undefined reference to `isa_dmadone' fdc.o(.text+0x2cd4): In function `fdc_detach': : undefined reference to `isa_dma_release' fdc.o(.text+0x2ead): In function `fdc_attach': : undefined reference to `isa_dma_acquire' fdc.o(.text+0x2eca): In function `fdc_attach': : undefined reference to `isa_dmainit' fdc_acpi.o(.text+0x1d6): In function `fdc_acpi_attach': : undefined reference to `fdc_isa_alloc_resources' ppc.o(.text+0xff7): In function `ppcintr': : undefined reference to `isa_dmadone' ppc.o(.text+0x11b3): In function `ppc_write': : undefined reference to `isa_dmastart' ppc.o(.text+0x1214): In function `ppc_write': : undefined reference to `isa_dmadone' ppc.o(.text+0x1963): In function `ppc_attach': : undefined reference to `isa_dma_acquire' ppc.o(.text+0x1976): In function `ppc_attach': : undefined reference to `isa_dmainit' sio.o(.text+0x62a): In function `sioprobe': : undefined reference to `isa_irq_pending' sio.o(.text+0x7fa): In function `sioprobe': : undefined reference to `isa_irq_pending' sio.o(.text+0x81c): In function `sioprobe': : undefined reference to `isa_irq_pending' sio.o(.text+0x856): In function `sioprobe': : undefined reference to `isa_irq_pending' *** Error code 1 Stop in /usr/src/sys/i386/compile/kernel_opt. thanks in advance, ananth.g ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list
Re: xl(4) polling
--- Ruslan Ermilov [EMAIL PROTECTED] wrote: On Wed, May 11, 2005 at 12:43:09AM -0700, Rob wrote: I actually doubt whether the default values of these sysctl variables would cause the problem. No. Can you observe the broken IP/TCP/UDP checksums? netstat -ss -f inet |grep -w bad Argh, just found out that it is not the polling. Even without the polling, the ssh-tunnel connection gets disrupted, although not as frequent as with the polling. Possibly, the polling makes the problem more visible, but it not the culprit. My apologies for the noise. I don't know yet exactly what it is. I use a script to test whether the ssh-tunnel is still alive; if not, then the tunnel is renewed. This script has worked like a charm for almost 6 months. Don't know what's has changed in the meantime. Also, four PCs are part of this ssh-tunnel, which makes it rather complex to pin-point the problem :(. Anyway, that's my problem. Most important: the xl polling seems OK. Meanwhile I have learned a lot more about what polling actually is! Thanks, Rob. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PostgreSQL in FreeBSD jails
Dag-Erling Smørgrav wrote: Marc G. Fournier [EMAIL PROTECTED] writes: 'k, I've been doing multiple since 7.2 on the same machine, all on the same port, all different IPs, all on 4.x servers ... have never had an issue with crashes (its pretty much my most stable 4.x server) ... It was never possible. 8.0 has a hack to detect and avoid shared memory collisions, but I think it will still have problems with semaphores. I have no idea why it works (or seems to work) for you; it never did for anyone else. DES Maybe he's runing pjd@ 's privipc patch? http://lists.freebsd.org/pipermail/freebsd-arch/2003-June/000926.html Cheers, m. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xl(4) polling
On Wed, May 11, 2005 at 07:30:05AM -0700, Rob wrote: Argh, just found out that it is not the polling. Even without the polling, the ssh-tunnel connection gets disrupted, although not as frequent as with the polling. Possibly, the polling makes the problem more visible, but it not the culprit. My apologies for the noise. I don't know yet exactly what it is. I use a script to test whether the ssh-tunnel is still alive; if not, then the tunnel is renewed. This script has worked like a charm for almost 6 months. Don't know what's has changed in the meantime. Also, four PCs are part of this ssh-tunnel, which makes it rather complex to pin-point the problem :(. Anyway, that's my problem. Most important: the xl polling seems OK. Meanwhile I have learned a lot more about what polling actually is! I very much appreciate the feedback like this one. Often people just shut up after their problem is solved. Thank you! Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpTsWg1MBY0Z.pgp Description: PGP signature
Re: Creating a mini install disk, for particular needs
Am 11. Mai 2005 um 00:56:07 +0100 schrieb Chris Phillips: We need a fairly painless way, to roll out a fresh install onto some random i386 hardware we have lying around (there's a plentiful supply), for any new users, who require a basic functioning GUI, with access to graphical email client, web browser 'rdesktop' (for the windows applications, that they are all hooked on). Look at http://www.pcbsd.org/ also. I did just for fun the installation of http://ftp.plusline.de/pcbsd/PCBSD-0.6-x86.iso and I'm very impressed. A small, but working KDE Desktop out of the box (FreeBSD 5.3, KDE 3.4) without any huzzle. Start the (graphical!!) installer and get yourself a mug of coffee (or what else you prefere). Liebe Grüße, Nora. [EMAIL PROTECTED] IM-NETZ Neue Medien, Berlin http://www.im-netz.de/ WWW von Frauen für Frauen, Hamburg http://www.w4w.net/ Lesbian Computer Networks, Helsinki http://www.sappho.net/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel build problem
Le 11 mai 2005 à 16:28, Ananth.G a écrit : i have attached my config file. regrds, ananth.g Sergey S. Ropchan wrote: Content of kernel config please ? It's look like wrong option in config. dear all, im having trouble compiling kernel on 5.3 , i did a `make depend` and `make`. The following is the error that i got, i might have missed a module i guess... cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested- externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual-fformat-extensions -std=c99 -nostdinc -I- - I. -I../../.. -I../../../contrib/dev/acpica -I../../../contrib/ altq -I../../../contrib/ipfilter -I../../../contrib/pf -I../../../ contrib/dev/ath -I../../../contrib/dev/ath/freebsd -I../../../ contrib/ngatm -D_KERNEL -include opt_global.h -fno-common - finline-limit=8000 --param inline-unit-growth=100 --param large- function-growth=1000 -mno-align-long-strings -mpreferred-stack- boundary=2 -ffreestanding -Werror vers.c linking kernel snip bunch of lines fdc_acpi.o(.text+0x1d6): In function `fdc_acpi_attach': : undefined reference to `fdc_isa_alloc_resources' ppc.o(.text+0xff7): In function `ppcintr': : undefined reference to `isa_dmadone' ppc.o(.text+0x11b3): In function `ppc_write': : undefined reference to `isa_dmastart' ppc.o(.text+0x1214): In function `ppc_write': : undefined reference to `isa_dmadone' ppc.o(.text+0x1963): In function `ppc_attach': : undefined reference to `isa_dma_acquire' ppc.o(.text+0x1976): In function `ppc_attach': : undefined reference to `isa_dmainit' sio.o(.text+0x62a): In function `sioprobe': : undefined reference to `isa_irq_pending' sio.o(.text+0x7fa): In function `sioprobe': : undefined reference to `isa_irq_pending' sio.o(.text+0x81c): In function `sioprobe': : undefined reference to `isa_irq_pending' sio.o(.text+0x856): In function `sioprobe': : undefined reference to `isa_irq_pending' *** Error code 1 Stop in /usr/src/sys/i386/compile/kernel_opt. # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # snip irrelevant parts # Bus support. Do not remove isa, even if you have no isa slots #deviceisa #deviceeisa devicepci I'm no expert in FreeBSD kernel, but it seems the compile stops on a isa-related error, and that you removed device isa even if the config file told you not to. :) Putting back device isa should cure it. -- See you!!! PAIG Chong Woo. E-Mail : [EMAIL PROTECTED] ICQ : 1305386 Page web : http://www.valken.org --- The historian is a prophet in reverse. Friedrich von Schlegel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
em and bge driver MPSAFE?
Hi, Perhaps lame to ask, But are the em and bge driver MPSAFE? I couldn't find notes about being mpsafe in the man pages of these drivers? Bye, Mipam. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: kernel build problem
i have attached my config file. regrds, ananth.g this looks like an issue (cut/pasted from kernel config file). Isa is required, no? # Bus support. Do not remove isa, even if you have no isa slots #device isa #device eisa device pci ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: save-entropy errors on jail after update to 5.4-RELEASE
Renato Botelho wrote: I updated my box and a jail that runs inside this box to 5.4-RELEASE yesterday. After it, I'm receiving emails from this jail with error messages about /usr/libexec/save-entropy I'm receiving messages like this: mv: /var/db/entropy/saved-entropy.7: No such file or directory mv: /var/db/entropy/saved-entropy.5: No such file or directory override r operator/operator for /var/db/entropy/saved-entropy.5? (y/n [n]) not overwritten override r operator/operator for /var/db/entropy/saved-entropy.4? (y/n [n]) not overwritten override r operator/operator for /var/db/entropy/saved-entropy.3? (y/n [n]) not overwritten override r operator/operator for /var/db/entropy/saved-entropy.2? (y/n [n]) not overwritten here is the files inside the jail: [EMAIL PROTECTED]:~ sudo ls -l /var/db/entropy/ total 16 -r 1 operator operator 2048 May 11 10:33 saved-entropy.1 -r 1 operator operator 2048 May 11 10:33 saved-entropy.2 -r 1 operator operator 2048 May 11 10:22 saved-entropy.3 -r 1 operator operator 2048 May 11 10:22 saved-entropy.4 -r 1 operator operator 2048 May 11 10:11 saved-entropy.5 -r 1 operator operator 2048 May 11 10:11 saved-entropy.6 -r 1 operator operator 2048 May 11 10:00 saved-entropy.7 -r 1 operator operator 2048 May 11 10:00 saved-entropy.8 Anybody could help me to fix it? thanks in advance I suspect this happens because of concurrent access to /dev/random from multiple save-entropy scripts launched exactly as the same time by jailed cron daemons. I got rid of those emails by putting entropy_dir=NO into rc.conf of all jails. I'm not shure, is this secure? Also consider enabling cron time jitter for jailed crons, by putting something like this into jail rc.conf: cron_flags=-J10 -- Alexander Rusinov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Use PCMCIA instead of CardBus?
On Wednesday 11 May 2005 09:28, Joerg Pulz wrote: You should take a look into src/sys/i386/conf/OLDCARD change the appropriate lines in you kernel configuration and rebuild your kernel. I appreciate the suggestion, but pcic(4) includes this less-than-promising statement: BUGS This does not work at all at the moment. I'll give it a shot anyway, though, and pray for out-of-date man pages. :-) -- Kirk Strauser pgphrMwiFdebe.pgp Description: PGP signature
Re: PTHREAD_INVARIANTS in 5.x
On Tue, 10 May 2005, Mikhail Teterin wrote: = As we were counting down to 5.3-RELEASE, I noticed, that all = threading libraries still compile with PTHREAD_INVARIANTS. My = suggestion to have this = fixed was shutdown as not enough time = was left for testing the 5.3. = Can we have these things turned off NOW, so that, at least, 5.5 = stands a chance? Thanks! = = What makes you think there is a measurable performance impact with = them on? Interesting... Are you implying, the debugging code makes no difference, or are genuinly asking? Both. There are additional steps in the code, that are only done when the define is on. Does not look like much in libthr, but c_r's uthread/uthread_mutex.c seems quite affected, for example. And you know it, of course... c_r is deprecated, so I've no interest in that. My only concern is with libthr and libpthread. = Regardless, it would first need to be in -current, not -stable. I thought, the debugging features (WITNESS INVARIANTS) are always on in -current, but are turned off in -stable for maximum performance. Is that no longer true? They've never been off in -current. You'd have to show turning them off causes no harm. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xl(4) polling
On 5/11/2005 13:57, Tuomo Latto wrote: Subhro wrote: ... In Device Polled systems, the NIC does not generate any interrupt at all. Instead whenever the packets arrive at a Network interface, they are captured and put into a queue. The kernel scheduler checks the quese at regular intervals and processes the packets which are waiting. This interval is adjusted by the options HZ=x kernel option. If the value of x is very high, there may eb two scenarios. In the first scenario, the queue may fill up and subsequent packets are dropped. In this case retransmission of the packets are required. In the second scenario, the packets would be held up for excessive long times which defeats the entire purpose of Device Polling. If the value of x is very low, the scheduler would check the queue frequently and would again defeat the entire idea of Device Polling. It's the other way around. Large values indicate larger polling frequency thus amounting to more checks. Or at least the name of the option would suggest that anyway. Silly me :(. I meant something, typed something else. Its indeed the other way round. Thanks to everyone who pointed this out. Regards S. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel build problem
On May 11, 2005 07:28 am, Ananth.G wrote: i have attached my config file. Read the comments in your config file. You'll quickly notice that you have removed the isa device (which is needed for PS/2, serial, parallel ports, etc), and that you have umass enabled, but disabled the needed scbus and da devices. Dont' just blindly comment things out. Read the comments in the config file, and in the NOTES files. -- Freddie Cash [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: State of gvinum RELENG_5 or RELENG_5_4 ?!
Peter Orlowski wrote: On Tue, May 10, 2005 at 11:24:12AM -0600, secmgr wrote: Gabor Esperon wrote: How reliable is the gmirror subsystem? gmirror seems fine as best as I can tell. I've been running it for a few months on sata drives. I had gmirror running on two IDE drives for system and two SATA drives for user data. That was RELENG_5_3. When one of the SATA drives broke (later I got errors like ad4: FAILURE - READ_DMA status=51READY,DSC,ERROR on fscking) the whole system just stopped. I could switch consoles but nothing else. Nothing in the logs either. I believe it had lost all it's file systems. After power cycling, both mirrors were found but marked as broken. Gmirror chose the defective SATA disk as the intact one and started rebuilding the mirror from that - but fscking the mirror failed, obviously, so I ended up with one disk that was broken, but marked intact by gmirror and one disk the other way round. I had to erase the gmirror metadata on the intact disk to get it to work again. I'd say gmirror will save your data but it won't save you from some downtime... Greetings, Peter What steps did you take to the gmirror the disk so you could get your data back? At this point, I'm thinking that as far as S/W RAID goes in FreeBSD, the R is pretty meaningless jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Creating a mini install disk, for particular needs
Many thanks to all who have responded! I have plenty to investigate now. Kind Regards, Chris Phillips Nora Etukudo wrote: Am 11. Mai 2005 um 00:56:07 +0100 schrieb Chris Phillips: We need a fairly painless way, to roll out a fresh install onto some random i386 hardware we have lying around (there's a plentiful supply), for any new users, who require a basic functioning GUI, with access to graphical email client, web browser 'rdesktop' (for the windows applications, that they are all hooked on). Look at http://www.pcbsd.org/ also. I did just for fun the installation of http://ftp.plusline.de/pcbsd/PCBSD-0.6-x86.iso and I'm very impressed. A small, but working KDE Desktop out of the box (FreeBSD 5.3, KDE 3.4) without any huzzle. Start the (graphical!!) installer and get yourself a mug of coffee (or what else you prefere). Liebe Grüße, Nora. [EMAIL PROTECTED] IM-NETZ Neue Medien, Berlin http://www.im-netz.de/ WWW von Frauen für Frauen, Hamburg http://www.w4w.net/ Lesbian Computer Networks, Helsinki http://www.sappho.net/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Scanned for viruses by MailDefender Scanned for viruses by MailDefender ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PostgreSQL in FreeBSD jails
On Wed, 11 May 2005, Marton Kenyeres wrote: Dag-Erling Smørgrav wrote: Marc G. Fournier [EMAIL PROTECTED] writes: 'k, I've been doing multiple since 7.2 on the same machine, all on the same port, all different IPs, all on 4.x servers ... have never had an issue with crashes (its pretty much my most stable 4.x server) ... It was never possible. 8.0 has a hack to detect and avoid shared memory collisions, but I think it will still have problems with semaphores. I have no idea why it works (or seems to work) for you; it never did for anyone else. DES Maybe he's runing pjd@ 's privipc patch? http://lists.freebsd.org/pipermail/freebsd-arch/2003-June/000926.html Nope, stock 4.11 kernel from Tue Feb 15 21:36:53 AST 2005 ... sorry ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCHED_ULE with SMP broke libpthread/libthr on 5.4-RELEASE
Seems the 4+ cpu crash fix might have broken it at a guess since RC4 onwards it broke, I am interested in how this goes as I was planning on upgrading a SMP box to 5.4 and ULE this month. Have you guys tried this without SMP? Chris On 5/11/05, Marian Hettwer [EMAIL PROTECTED] wrote: On Mi, 11.05.2005, 14:34, Steven Jurczyk sagte: **Using SCHED_ULE on SMP/HT machine broke applications which use libpthread/libthr, probably at context switching between threads... The applications simply hang and they aren't killable (kill -9 pid don't work).. Usually this also break kernel shutdown (can't flush some inodes or blocks)... right! I have the same problem. My Kernel is basicly a GENERIC with SMP and ULE added (4BSD removed). ([EMAIL PROTECTED] ~)$ uname -a FreeBSD siteop-8.mobile.rz 5.4-STABLE FreeBSD 5.4-STABLE #7: Wed May 11 12:03:35 CEST 2005 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/SITEOP-8 i386 This is very big problem for people who want use mysql_server on SMP machines... indeed. The MySQL server won't start and is not killable. I had to switch back to SCHED_4BSD :-/ I would be available for testing packages, as this machine is not in production. it's a dual xeon 2,8 ... you can find detailed information about it at: http://unixoid.de/freebsd/dmesg.xeon :) best regards, Marian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
IPF 4.1.8
Hi I`ve tried to import IPF 4.1.8 into freebsd-stable (5.4). It's first time I tried something similar. Problem is, that the kernel fails to compile (it needs somewhere 3 parameters, but gets only 2... or what). I followed the readme for freebsd-5. Any help ? Jan Sebosik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCHED_ULE with SMP broke libpthread/libthr on 5.4-RELEASE
On 05/11/05 18:28, Chris wrote: On 5/11/05, Marian Hettwer [EMAIL PROTECTED] wrote: On Mi, 11.05.2005, 14:34, Steven Jurczyk sagte: **Using SCHED_ULE on SMP/HT machine broke applications which use libpthread/libthr, probably at context switching between threads... The applications simply hang and they aren't killable (kill -9 pid don't work).. Usually this also break kernel shutdown (can't flush some inodes or blocks)... right! I have the same problem. My Kernel is basicly a GENERIC with SMP and ULE added (4BSD removed). ([EMAIL PROTECTED] ~)$ uname -a FreeBSD siteop-8.mobile.rz 5.4-STABLE FreeBSD 5.4-STABLE #7: Wed May 11 12:03:35 CEST 2005 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/SITEOP-8 i386 This is very big problem for people who want use mysql_server on SMP machines... indeed. The MySQL server won't start and is not killable. I had to switch back to SCHED_4BSD :-/ I would be available for testing packages, as this machine is not in production. it's a dual xeon 2,8 ... you can find detailed information about it at: http://unixoid.de/freebsd/dmesg.xeon :) Seems the 4+ cpu crash fix might have broken it at a guess since RC4 onwards it broke, I am interested in how this goes as I was planning on upgrading a SMP box to 5.4 and ULE this month. Have you guys tried this without SMP? From the sched_ule(4) man page: BUGS As an experimental scheduler, sched_ule is not enabled by default due to a number of known issues, including weak performance with several known workloads, and reports of instability. Deployment of sched_ule in production environments should be done cautiously. The less well-known 5.4 Open Issues page (http://www.freebsd.org/releases/5.4R/todo.html) speaks to this as well: Many improvements have been made to the ULE scheduler in 6-CURRENT. These should be merged back to 5.4. The merging is done but ULE is still known to cause panics for some people, especially on SMP systems. Try it with extreme caution. In other words, ULE is known to not be stable and will remain so until someone fixes it. -- Jonathan Noack | [EMAIL PROTECTED] | OpenPGP: 0x991D8195 signature.asc Description: OpenPGP digital signature
Re: SCHED_ULE with SMP broke libpthread/libthr on 5.4-RELEASE
On Thu, May 12, 2005 at 12:28:14AM +0100, Chris wrote: Seems the 4+ cpu crash fix might have broken it at a guess since RC4 onwards it broke, I am interested in how this goes as I was planning on upgrading a SMP box to 5.4 and ULE this month. Have you guys tried this without SMP? Guys..ULE is known to be broken. Don't be surprised when you encounter panics. Kris pgpGdLcdG44wz.pgp Description: PGP signature
only Swiss Rolex please.
Daily News - Rolex watches online http://honeysuckle.q67.net/replica/vron/envelopes.html Wishlist : Rolex or Cartier or Breitling ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PTHREAD_INVARIANTS in 5.x
On 05/11/05 09:55, Daniel Eischen wrote:
On Tue, 10 May 2005, Mikhail Teterin wrote:
= As we were counting down to 5.3-RELEASE, I noticed, that all
= threading libraries still compile with PTHREAD_INVARIANTS. My
= suggestion to have this = fixed was shutdown as not enough time
= was left for testing the 5.3.
= Can we have these things turned off NOW, so that, at least, 5.5
= stands a chance? Thanks!
=
= What makes you think there is a measurable performance impact with
= them on?
Interesting... Are you implying, the debugging code makes no difference,
or are genuinly asking?
Both.
There are additional steps in the code, that are only done when
the define is on. Does not look like much in libthr, but c_r's
uthread/uthread_mutex.c seems quite affected, for example. And you know
it, of course...
c_r is deprecated, so I've no interest in that. My only concern
is with libthr and libpthread.
I agree.
= Regardless, it would first need to be in -current, not -stable.
I thought, the debugging features (WITNESS INVARIANTS) are always on in
-current, but are turned off in -stable for maximum performance. Is that
no longer true?
They've never been off in -current. You'd have to show turning
them off causes no harm.
I checked out _PTHREADS_INVARIANTS for libthr and libpthread on CURRENT.
As far as I can tell, all but one of the defines under
_PTHREADS_INVARIANTS are ASSERTs; they check for a condition and if it
is false result in a fatal error. These should be very visible if they
are being tripped. Only MUTEX_INIT_LINK actually *does* something. It
is defined in src/lib/libpthread/thread/thr_mutex.c at lines 43-46 and
in src/lib/libthr/thread/thr_mutex.c at lines 44-47:
#define MUTEX_INIT_LINK(m) do {\
(m)-m_qe.tqe_prev = NULL; \
(m)-m_qe.tqe_next = NULL; \
} while (0)
I'm not sure what impact removing this explicit initialization would
have. If we're not seeing fatal errors, everything else is just slowing
us down. Assuming we feel our thread implementations are production
worthy, we should disable these checks for releases. That is, unless I
am missing something...
Anyone know any good thread tests to run to determine what performance
impact this is having?
--
Jonathan Noack | [EMAIL PROTECTED] | OpenPGP: 0x991D8195
signature.asc
Description: OpenPGP digital signature
Re: PTHREAD_INVARIANTS in 5.x
On Wed, 11 May 2005, Jonathan Noack wrote:
I checked out _PTHREADS_INVARIANTS for libthr and libpthread on CURRENT.
As far as I can tell, all but one of the defines under
_PTHREADS_INVARIANTS are ASSERTs; they check for a condition and if it
is false result in a fatal error. These should be very visible if they
are being tripped. Only MUTEX_INIT_LINK actually *does* something. It
is defined in src/lib/libpthread/thread/thr_mutex.c at lines 43-46 and
in src/lib/libthr/thread/thr_mutex.c at lines 44-47:
#define MUTEX_INIT_LINK(m) do {\
(m)-m_qe.tqe_prev = NULL; \
(m)-m_qe.tqe_next = NULL; \
} while (0)
I'm not sure what impact removing this explicit initialization would
have. If we're not seeing fatal errors, everything else is just slowing
us down. Assuming we feel our thread implementations are production
worthy, we should disable these checks for releases. That is, unless I
am missing something...
I wrote the darn things, and they are useful in that they can
provide useful information if there are bugs and also for
detecting if the application is linked to multiple thread
libraries. For the init links macro, it is only used when
the mutex is initialized and on unlock. It's two instructions.
The others are also just a couple of instructions and shouldn't
be called often.
This is way overblown and they're other areas for much
better optimizations than worrying about a couple of
instructions. Perhaps if it were called _PTHREAD_ROBUST
instead of _PTHREAD_INVARIANTS, noone would notice ;-)
That's the last I'll say. re@ can do whatever they want
with my blessing.
--
DE
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PTHREAD_INVARIANTS in 5.x
On 05/11/05 21:53, Daniel Eischen wrote:
On Wed, 11 May 2005, Jonathan Noack wrote:
I checked out _PTHREADS_INVARIANTS for libthr and libpthread on CURRENT.
As far as I can tell, all but one of the defines under
_PTHREADS_INVARIANTS are ASSERTs; they check for a condition and if it
is false result in a fatal error. These should be very visible if they
are being tripped. Only MUTEX_INIT_LINK actually *does* something. It
is defined in src/lib/libpthread/thread/thr_mutex.c at lines 43-46 and
in src/lib/libthr/thread/thr_mutex.c at lines 44-47:
#define MUTEX_INIT_LINK(m) do {\
(m)-m_qe.tqe_prev = NULL; \
(m)-m_qe.tqe_next = NULL; \
} while (0)
I'm not sure what impact removing this explicit initialization would
have. If we're not seeing fatal errors, everything else is just slowing
us down. Assuming we feel our thread implementations are production
worthy, we should disable these checks for releases. That is, unless I
am missing something...
I wrote the darn things, and they are useful in that they can
provide useful information if there are bugs and also for
detecting if the application is linked to multiple thread
libraries. For the init links macro, it is only used when
the mutex is initialized and on unlock. It's two instructions.
The others are also just a couple of instructions and shouldn't
be called often.
This is way overblown and they're other areas for much
better optimizations than worrying about a couple of
instructions. Perhaps if it were called _PTHREAD_ROBUST
instead of _PTHREAD_INVARIANTS, noone would notice ;-)
So I *was* missing something: the Big Picture. Detecting if an
application is linked to multiple thread libraries is definitely a keeper.
When I see your name in an email, the hash that is my brain returns
threads guy. Your previous responses to this topic (which my brain
referenced as authoritative) seemed to indicate that you weren't sure
and further investigation was necessary, so I looked into it. Sorry if
I misunderstood that.
That's the last I'll say. re@ can do whatever they want
with my blessing.
Fair enough.
--
Jonathan Noack | [EMAIL PROTECTED] | OpenPGP: 0x991D8195
signature.asc
Description: OpenPGP digital signature
Re: Experimental ttwwakeup() panic patch
Sorry for the late reply on this. On Fri, 6 May 2005, Ed Maste wrote: On Wed, May 04, 2005 at 08:54:23PM -0700, Doug White wrote: http://people.freebsd.org/~dwhite/tty.c.20050503.patch This patch has been committed and exists as rev 1.228.2.4 of src/sys/kern/tty.c. Please let me know if this fixes the panic for you, or causes new problems :) For what it's worth, I've come across a similar crash during a test that repeatedly ssh'd into the machine. This was while opening a pty, not using serial console. The symptoms seem similar; my tty struct has a struct knlist with a null struct mtx *. I haven't yet investigated in great detail or tried the patch. I just wanted to offer this as another data point. Although kgdb gets confused during the backtrace (frames 7 and 8) the tf_eip is a cmpxchg in knote(). This is a problem mlaier and I may have fixed, at least against -CURRENT. It appears that the process group alias in struct tty is accessed without locking and its changing out from under us. Give this a try: http://people.freebsd.org/~mlaier/tty.t_pgrp.diff It compiles but I haven't actually booted a kernel with it, so YMMV. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: twa0: INFO: (0x04: 0x000c): Background initialize started: unit=0
On Mon, 9 May 2005, Marc G. Fournier wrote: Ya, this looks like it might be a problem ... server just crashed, and fsck is once more dog slow, and I suspect its in the 'initialization mode' again ... Looking at the following that I've also found, things appear to be pointing to ACPI as the 'trigger' ... does anyone else have any experiences with these cards? This is normal for twa and twe cards with recent firmware. If it detects an unclean shutdown it will schedule a unit verify. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCHED_ULE with SMP broke libpthread/libthr on 5.4-RELEASE
Chris wrote: Seems the 4+ cpu crash fix might have broken it at a guess since RC4 onwards it broke, I am interested in how this goes as I was planning on upgrading a SMP box to 5.4 and ULE this month. Have you guys tried this without SMP? Yes. pthreads applications under SCHED_ULE but without SMP works OK... PS. Please remeber that SCHED_ULE with SMP brokes also 10 utils compiled with pthreads in base system (host, dig, nslookup - all DNS stuff). -- best regards steve at home.pl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
