Re: My kernel panics suck
* William D. Colburn (Schlake) [100702 12:19] wrote: > I got my new 8-stable system up, and now I just have recurrent disk > controller failures. The machine can't stay more than about ten > minutes before it panics into a hung kernel, or simple reboots. > Unfortunately, I know the root cause of the panics. If my computer is > sitting on the table, then the kernel doesn't panic. If the computer > is sitting on the desk, then it panics like mad. The table is wooden, > the desk is metal. Of course, I'm also changing power too. On the > table, I use a wall outlet, while on the desk I use my Smart UPS. > Unfortunately, you can't really help me with this. I'm just writing > in out of the hope that I'll get some sympathy for this problem. Everyone knows the best place to run FreeBSD is under your desk: ~ % gcc -v Using built-in specs. Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you
Robert, reviews of sorecv_drgram: /* XXXRW: sbwait() may not be as happy without sblock(). */ error = sbwait(&so->so_rcv); Does not need XXX, sbwait waits for data, it's not really related to sblock(). remove comment. The variable orig_resid can be removed, I think the purpose of it is to to restart blocking in the "generic sorecv" case, in your code you only set it, you never reference it. -Alfred * Robert Watson <[EMAIL PROTECTED]> [080806 23:37] wrote: > > On Wed, 6 Aug 2008, Alfred Perlstein wrote: > > >* David G Lawrence <[EMAIL PROTECTED]> [080805 11:37] wrote: > >>>The thrust of this change is to replace the mutexes protecting the inpcb > >>>and inpcbinfo data structures with read-write locks (rwlocks). These > >> > >> That's really cool and directly affects my current work project. I'm > >>developing (have developed, actually) a multi-threaded, 5000+ member > >>VoIP/SIP conferencing server called Nconnect. It a primarily UDP > >>application running on FreeBSD 7. This generates and receives about > >>250,000 UDP packets a second, with 200 byte packets, resulting in about > >>400Mbps of traffic in each direction. The current bottleneck is the > >>kernel UDP processing. It should be possible to scale to 1+ members > >>if kernel UDP processing had optimal concurrency. > >> Anyway, thumbs up (and not for the middle-eastern meaning :-)) - I'm > >>looking forward to the MFC. > > > >David, one thing I noticed was that it appears that UDP sockets are > >serialized for copyout. > > > >Mainly that the socket is sblock()'d while the uiomove happens. > > > >I was trying to figure out a way to bypass this somehow. Perhaps just > >dequeuing and unlocking, the copyout after dropping the sblock. > > > >If there's some error, then requeue or discard the packet. > > > >I'll have to think about it. > > Or you can use the soreceive_dgram implementation in 8.x, which I will at > some point MFC once I'm comfortable it doesn't contain any serious bugs. > > Robert N M Watson > Computer Laboratory > University of Cambridge -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Apache-worker stuck at 100% CPU
* Ivan Voras <[EMAIL PROTECTED]> [080915 16:05] wrote: > 2008/9/13 Alfred Perlstein <[EMAIL PROTECTED]>: > > >> Yes, it's multithreaded apache. This did help somewhat - when I show > >> threads in top > >> I see that it's not actually stuck in umtxn - there's one thread that > >> consumes the CPU and it's apparently always running (in state CPUx). > >> > >> PID USERNAME PRI NICE SIZERES STATE C TIME WCPU COMMAND > >> 7212 www 1030 30340K 7932K CPU2 2 444:23 99.02% httpd > >> > >> I'm currently upgrading the system to 7-STABLE, to see if it helps. > > It didn't help. Exactly the same symptom happened again. It looks like > it happens a few days after the last system reboot. After it happens > the first time, restarting Apache immediately produces one such > "stuck" thread - it looks like some system state gets corrupted over > time. > > >> How do I pick what thread to backtrace in gdb? > > > > i think the command is 'info threads' or 'show > > threads' then i think you just type > > 'thread FOO' to select the thread. > > Both commands don't work / don't exist. Any others? > > (background: apache22-worker port, no mod_php, on 7.0 and 7-STABLE > suddenly gets stuck at 100% CPU; the same setup worked on 6-STABLE. > I'm looking for ideas) I'm sorry, I really can't help at this point other than to look through the documents myself to figure out how to do a backtrace/select threads. Give it a shot, and let us know and we can go further. Apologies, -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Apache-worker stuck at 100% CPU
* Ivan Voras <[EMAIL PROTECTED]> [080916 02:12] wrote: > 2008/9/16 Alfred Perlstein <[EMAIL PROTECTED]>: > > * Ivan Voras <[EMAIL PROTECTED]> [080915 16:05] wrote: > > >> >> How do I pick what thread to backtrace in gdb? > >> > > >> > i think the command is 'info threads' or 'show > >> > threads' then i think you just type > >> > 'thread FOO' to select the thread. > >> > >> Both commands don't work / don't exist. Any others? > >> > >> (background: apache22-worker port, no mod_php, on 7.0 and 7-STABLE > >> suddenly gets stuck at 100% CPU; the same setup worked on 6-STABLE. > >> I'm looking for ideas) > > > > I'm sorry, I really can't help at this point other than to look > > through the documents myself to figure out how to do a backtrace/select > > threads. > > > > Give it a shot, and let us know and we can go further. > > Sorry, I should have been more verbose - "info threads" should work > but it doesn't - I can attach and get threads from a "regular" > multithreaded process, but when yesterday when I attached to the stuck > process, I couldn't get the list of threads. I'll try again the next > time it gets stuck and try to provide more information. If it happens again, you could try sending it a SIGABRT or SEGV and then trying to diagnose the core dump. Or try using gcore to generate a coredump and debug that. -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ssh to FreeBSD 4 systems: xmalloc: zero size
* Craig Rodrigues <[EMAIL PROTECTED]> [080924 09:42] wrote: > Hi, > > I have received no feedback about this problem. > Can someone apply the patch to SSH to fix the regression > which I mentioned earlier? Hey Craig, if no one replies by next week, please just apply the patch, it's pretty critical that FreeBSD be able to talk ssh to other machines out there. -Alfred > -- > Craig Rodrigues > [EMAIL PROTECTED] > > > On Mon, Sep 15, 2008 at 10:17:04PM +, Craig Rodrigues wrote: > > Hi, > > > > I can confirm that this patch solves my problem: > > > > https://bugzilla.mindrot.org/attachment.cgi?id=1554 > > > > That patch is part of this ssh bug: > > > > https://bugzilla.mindrot.org/show_bug.cgi?id=1496 > > > > Can we get this fix into FreeBSD before the 7.1 RELEASE? > > > > Thanks. > > -- > > Craig Rodrigues > > [EMAIL PROTECTED] > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Request for testing - top 3.8b1 in the base system
* Edwin Groothuis <[EMAIL PROTECTED]> [080927 23:04] wrote: > I have made an update for the top(1) utility in the FreeBSD base > system to get it from the 3.5b12 version to the 3.8b1 version. Hey Edwin, any chance you have the time to add to top(1) a flag that will restrict top(1) to only view a certain pid or list of pids? This would be really helpful in the threaded view to watch a single process. -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: trying to track down UFS "dup alloc" message on iSCSI
Hey Andrew, can you instrument the IO code a bit? It's possible that the iscsi stack is returning an error that UFS isn't catching. Or it's possible that iscsi stack is failing to return an error and just dropping the data packet. That could mean that UFS is assuming that the write is going through, but isn't either because it's not catching the error, or that iscsi is lying to it. -Alfred * Andrew Snow <[EMAIL PROTECTED]> [081002 22:28] wrote: > > > I am playing with an iSCSI device on FreeBSD client running UFS2 on the > device over a LAN. Everything works well until I reboot the iSCSI > server - the client pauses for a minute or so then continues working > after iSCSI server comes back. No I/O errors are reported. Everything > seems to work fine for a little while! > > But shortly afterwards, I get a panic with the message > > panic: ffs_valloc: dup alloc > > > It seems related to the length of the delay the iSCSI device is paused - > restarting the iSCSI target daemon process doesn't cause the problem but > rebooting the whole target box does cause it. > > 1. Could this be related to the patch Matt Dillon created years ago > which I found here? > > http://leaf.dragonflybsd.org/mailarchive/bugs/2005-01/msg00093.html > > > 2. Can anyone think of any other reason this might happen? I know I am > stretching UFS to the limits here, expecting it to pause and restart > after more than a minute of locked disk :-) However, since all I/O > eventually complete successfully and no errors are reported, I find it > suspicious. > > > Cheers > > - Andrew > > > ps. running latest iSCSI code 2.1 on latest 7-STABLE box. > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fxp performance with POLLING
* Bartosz Stec <[EMAIL PROTECTED]> [081003 07:23] wrote: > Hello again :) > > With POLLING enabled I experience about 10%-25% performance drop when > copying files over network. Tested with both SAMBA and NFS. Is it normal? > >FreeBSD 7.1-PRERELEASE #0: Sat Sep 6 01:52:12 CEST 2008 >fxp0: port 0xc800-0xc83f mem >0xe1021000-0xe1021fff irq 20 at device 8.0 on pci1 > ># ifconfig fxp0 >fxp0: flags=9843 >metric 0 mtu 1500 >options=8 >ether 00:20:ed:42:87:13 >inet 192.168.0.2 netmask 0xff00 broadcast 192.168.0.255 >media: Ethernet autoselect (100baseTX ) >status: active > > BTW overall SAMBA performance still sucks on 7.1-pre as much as on > RELENG_5 ...:( - 7.5 MB/s peak. 7.5MB is 75% effeciency of a 100mbit card. Not amazing, but not "sucks". Where do you see faster performance? Between windows machines on the same hardware or linux server? -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: System hanging during dump
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [081015 12:00] wrote: > > Perhaps a 'show locks' with an 8-CURRENT kernel with WITNESS enabled > will shed light on the problem? As most of the filesystem locking > doesn't use lockmgr in 7-STABLE, it would be silent with that kernel. I might be wrong here, but I think it's actually that lockmgr in 7.x isn't watched by witness (but it is in 8.x) is why you can only see this warnings in 8.x. (In other words, filesystems use lockmgr in just about every version of FreeBSD back to 2.x or before.) -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: confirming bugs is bad behavior, etc.
Jo, I'm trying to get FreeBSD to consider not supporting another "6.4" or "5.5" as both seems to have some of the problems you're describing due to a the next gen -stable being out for so long sucking away developer time. As a user, what do you think about this? I hate to force users to upgrade, but I also hate to potentially be falsly advertising "stability" when there might not be enough maintainers to keep that true. Thoughts? -Alfred * Jo Rhett <[EMAIL PROTECTED]> [081201 12:28] wrote: > On Dec 1, 2008, at 11:59 AM, George V. Neville-Neil wrote: > >I have mostly stayed away from these threads because they've often > >devolved into unproductive finger pointing. > > > >Please leave the hyperbole out of your posts, or at least attempt to > >cut it back. People on these lists are working quite hard to solve > >problems for the whole of the FreeBSD community and your posts, such > >as this one, are not helping us to move forward. > > > My posts have always been directed at solving very real, operational > problems with using FreeBSD on server platforms, which is exactly the > stated goal for freebsd. I have always offered not only problems, but > resources to help test or evaluate the issues, and serious > considerations for ways to improve the process. > > Yes, you're right. Threads I start about real problems always devolve > into unproductive finger pointing. That would be the freebsd > developers attacking the reporter for identifying a real, operational > problem. Take a look at the posts of the FreeBSD developers, and view > for yourself the unprofessional attacks and personal insults hurled by > them at people who are simply trying to get real problems resolved. > > And yet, instead of asking your developers to stop violating the > posted rules of the mailing list, you are asking a bug reporter who > simply informed another bug reporter that their problem was both > widespread and not limited to USB devices to stop posting to the > list. Because god knows that "yes we saw it too and it's widely > reported" is bad behavior. Much worse that personal attacks which are > strictly against the list rules. > > Yes, I'm sure that the personal attacks really do help drive freebsd > development forward. Much more so than me bringing resources and > actually testing things does. > > Now that Core has clearly spoken their mind on this issue, by refusing > to ask freebsd developers to avoid violating the list charter and then > publicly calling out someone for just saying "yeah, it's a widely > reported problem" ... leaves any doubt that positive change is going > to happen here. > > Your request is accepted. I'm unsubscribing now. > > -- > Jo Rhett > Net Consonance : consonant endings by net philanthropy, open source > and other randomness > > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Process stuck in STOP state
* Lin Jui-Nan Eric [081223 09:17] wrote: > > Dear listers, > > > > Our FreeBSD Server uses NFS to access PHP files on NetApp, then serve > > them with apache 2.2 (worker MPM + php fastcgi mode). > Sorry. we use -STABLE now. > > event# uname -a > FreeBSD event 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #1: Thu Dec 4 > 01:45:42 CST 2008 r...@event:/usr/obj/usr/src/sys/KERNEL amd64 > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" It'd be good if you could get to ddb and do a "show all" or "threads" and get all threads backtrace to see what's happening. thank you, -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Process stuck in STOP state
* Lin Jui-Nan Eric [081225 02:44] wrote: > Hi, > > We have done a textdump, located here: http://aqua.pixnet.tw/~jnlin/textdump/ > Thank you! Is NFS working when this happens? Can you run lsof too? It would be really good to get a backtrace from all processes, there's a ddb command to do this. -Alfred > > On Wed, Dec 24, 2008 at 11:07 AM, Alfred Perlstein wrote: > > * Lin Jui-Nan Eric [081223 09:17] wrote: > >> > Dear listers, > >> > > >> > Our FreeBSD Server uses NFS to access PHP files on NetApp, then serve > >> > them with apache 2.2 (worker MPM + php fastcgi mode). > >> Sorry. we use -STABLE now. > >> > >> event# uname -a > >> FreeBSD event 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #1: Thu Dec 4 > >> 01:45:42 CST 2008 r...@event:/usr/obj/usr/src/sys/KERNEL amd64 > >> ___ > >> freebsd-stable@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > > > It'd be good if you could get to ddb and do a "show all" > > or "threads" and get all threads backtrace to see what's happening. > > > > thank you, > > -- > > - Alfred Perlstein > > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mydns-mysql starts before mysql has finished starting
Hey Mikael, Thank you for your feedback. To find out a port's maintainer, you can look into the makefile under CVS: http://www.freebsd.org/cgi/cvsweb.cgi/ports/dns/mydns/Makefile It looks to be: MAINTAINER= a...@freebsd.org If you don't a get a response from this developer, then try the generic "po...@freebsd.org" address. As far as fixing the problem, I think a trick might be to do something like this: while /etc/rc.d/mysql status = up && mydns == exit failure ... You might want to fork off the process to do this so if mysql hangs then your startup script doesn't hang the boot sequence waiting for it.. -Alfred * Mikael Bak [090117 11:38] wrote: > Hi list, > > This is my first post to this list. > I'm not exactly new to freebsd but I have used GNU/Linux more. > > Last week I installed my first FreeBSD 7.1 machine. A base system with > only mc, mysql and mydns-mysql packages. I installed all from pre > compiled packages, not from ports. > > When I reboot the machine the mysql server is not finished starting > before mydns tries to start, so it fails leaving me with a not working > DNS server. I have to manually start mydns-mysql. > > As a very ugly fix I have edited the startup script for mydns-mysql and > added a 10 sec delay. > > I wonder what else I can do. Should I perhaps contact the port > maintainer? How do I reach him/her? > > TIA, > Mikael Bak > Budapest, Hungary > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: NFS writes calling FSYNC and ASYNC not consistent
Apologies for being terse, in a hurry here. 1) -o async doesn't work with NFS, don't use that. 2) how big are the text versus binary files? 3) how are you copying them over nfs? I suspect, (could be wrong of course) that the ascii files are a lot smaller than the binary files, so what's happening is that for binary files, the client is issuing write-behind async, however for ascii files its issuing the writes at close time which will force the sync flag. -Alfred * Brent Jones [090128 19:38] wrote: > Hello FreeBSD users, > I am running into some performance problems with NFSv3/v4 mounts. > I have a Sun X4540 running OpenSolaris 2008.11 with ZFS exporting NFS shares > The NFS clients are a FreeBSD 6.3 32 bit, quad core xeon with 4GB ram > and a FreeBSD 7.1 32bit with same hardware. > > The issue I am seeing, is that for certain file types, the FreeBSD NFS > client will either issue an ASYNC write, or an FSYNC. > However, NFSv3 and v4 both support "safe" ASYNC writes in the TCP > versions of the protocol, so that should be the default. > Issuing FSYNC's for every compete block transmitted adds substantial > overhead and slows everything down. > > The two test files I have that can reproduce this data are a file > created by 'dump' which is just binary data: > > $ file testbinery > testbinery: data > > ASCII text file from a Maildir format: > > $ file ascittest > ascittest: ASCII mail text > > My NFS mount command lines I have tried to get all data to ASYNC write: > > $ mount_nfs -3T -o async 192.168.0.19:/pdxfilu01/obsmtp /mnt/obsmtp/ > $ mount_nfs -3T 192.168.0.19:/pdxfilu01/obsmtp /mnt/obsmtp/ > $ mount_nfs -4TL 192.168.0.19:/pdxfilu01/obsmtp /mnt/obsmtp/ > > Here is an excerpt from a snoop from the binary data file: > > $ snoop rpc nfs > > obsmtp02.local -> pdxfilu01NFS C ACCESS3 FH=57D3 > (read,lookup,modify,extend,delete,execute) >pdxfilu01 -> obsmtp02.local NFS R ACCESS3 OK (read,modify,extend) > obsmtp02.local -> pdxfilu01NFS C LOOKUP3 FH=BB85 testbinery >pdxfilu01 -> obsmtp02.local NFS R LOOKUP3 OK FH=57D3 > obsmtp02.local -> pdxfilu01NFS C ACCESS3 FH=57D3 > (read,lookup,modify,extend,delete,execute) >pdxfilu01 -> obsmtp02.local NFS R ACCESS3 OK (read,modify,extend) > obsmtp02.local -> pdxfilu01NFS C SETATTR3 FH=57D3 >pdxfilu01 -> obsmtp02.local NFS R SETATTR3 OK > obsmtp02.local -> pdxfilu01NFS C WRITE3 FH=57D3 at 0 for 32768 (ASYNC) >pdxfilu01 -> obsmtp02.local NFS R WRITE3 OK 32768 (ASYNC) > obsmtp02.local -> pdxfilu01NFS C WRITE3 FH=57D3 at 582647808 for > 32768 (ASYNC) >pdxfilu01 -> obsmtp02.local NFS R WRITE3 OK 32768 (ASYNC) > obsmtp02.local -> pdxfilu01NFS C WRITE3 FH=57D3 at 592871424 for > 32768 (ASYNC) >pdxfilu01 -> obsmtp02.local NFS R WRITE3 OK 32768 (ASYNC) > obsmtp02.local -> pdxfilu01NFS C WRITE3 FH=57D3 at 605421568 for > 32768 (ASYNC) >pdxfilu01 -> obsmtp02.local NFS R WRITE3 OK 32768 (ASYNC) > > > And on and on.. it will acheive near full wire-speed, about 110MB/sec > during the copy > > > Here is the same snoop, only copying the ASCII mail file: > > $ snoop rpc nfs > >obsmtp02.local -> pdxfilu01NFS C LOOKUP3 FH=BB85 ascittest >pdxfilu01 -> obsmtp02.local NFS R LOOKUP3 No such file or directory > obsmtp02.local -> pdxfilu01NFS C LOOKUP3 FH=BB85 ascittest >pdxfilu01 -> obsmtp02.local NFS R LOOKUP3 No such file or directory > obsmtp02.local -> pdxfilu01NFS C CREATE3 FH=BB85 (UNCHECKED) ascittest >pdxfilu01 -> obsmtp02.local NFS R CREATE3 OK FH=69D3 > obsmtp02.local -> pdxfilu01NFS C WRITE3 FH=69D3 at 0 for 32768 (FSYNC) >pdxfilu01 -> obsmtp02.local NFS R WRITE3 OK 32768 (FSYNC) > obsmtp02.local -> pdxfilu01NFS C WRITE3 FH=69D3 at 32768 for 32768 (FSYNC) >pdxfilu01 -> obsmtp02.local NFS R WRITE3 OK 32768 (FSYNC) > obsmtp02.local -> pdxfilu01NFS C WRITE3 FH=69D3 at 65536 for 32768 (FSYNC) >pdxfilu01 -> obsmtp02.local NFS R WRITE3 OK 32768 (FSYNC) > > > And so on. I've reproduced this with several files, and the only > difference between tests is the file type. > Is the FreeBSD NFS client requesting FSYNC or ASYNC depending on the > file type/contents? > If so, is there a tuneable setting to make all write ASYNC? > Otherwise, FSYNC'ing for every block written over NFS will cause so > many IOPS on the NFS server, that performance will degrade severely. > > Testing with an OpenSolaris 2008.11 client will issue ASYNC writes for > any file type, if mounted with NFSv3 of NFSv4 (TCP). > > Any ideas? > > Thanks in advance! > > -- >
Re: Sudden mbuf demand increase and shortage under the load
* Maxim Sobolev [100215 04:49] wrote: > Hi, > > Our company have a FreeBSD based product that consists of the numerous > interconnected processes and it does some high-PPS UDP processing > (30-50K PPS is not uncommon). We are seeing some strange periodic > failures under the load in several such systems, which usually evidences > itself in IPC (even through unix domain sockets) suddenly either > breaking down or pausing and restoring only some time later (like 5-10 > minutes). The only sign of failure I managed to find was the increase of > the "requests for mbufs denied" in the netstat -m and number of total > mbuf clusters (nmbclusters) raising up to the limit. Hey Maxim Can you run a process to dump sysctl -a every second or so and mark the time when you did it? Other monitoring things would probably be helpful as well (netstat -m) in a timed log format. vmstat -i? (interrupts storm?) Perhaps ps output (showing interrupt threads, etc) would be good toknow perhaps some ithreads went off into the weeds... Any console messages of note? A few people have suggested that there may be too many packets on the outgoing interface, I think there should be a limit to the number of packets queued for outgoing and probably counters to show how many were dropped due to overflow of the outgoing queue. You should be able to check these counters to see what is going on. If the driver is broken and never drops outgoing packets when the card's queue is full, then those counters should be 0. I hope this helps. -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Highpoint drivers on 7.0
* Eirik ?verby <[EMAIL PROTECTED]> [080125 12:53] wrote: > Hi all, > > did anyone try the Highpoint RocetRaid drivers (hptmv6.ko) on 7-RC1 or > later? I'm considering upgrading one of my servers here, but I need to > know if my RAID-controller will work after reinstall.. > > A shame HPT doesn't release the driver to the community... I would try the following: 1. get 7.x source tree. 2. make buildworld && make buildkernel 3. mv /boot/kernel /boot/kernel6 4. make installkernel 5. reboot, boot with "-s" 6. mount your filesystems, do some io testing. If everything looks well, you can then make installworld and hopefully things proceed safely. -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Analysis of disk file block with ZFS checksum error
* Joe Peterson <[EMAIL PROTECTED]> [080208 14:58] wrote:
> Mark Day wrote:
> > Based on the subset of data you posted, the bad data looks like ASCII
> > text.
> > The bad data from offset a to a000f is:
> >
> > ${138AFE{@
> > @$$}1
> >
> > The bad data from offset af6c1 to af6c8 is:
> >
> > 392A9}@
> >
> > I don't recognize the content beyond that, but I'd guess that somehow
> > the
> > contents of some other file managed to overwrite that portion of the bad
> > file. As for how that happened, I don't know. But if someone
> > recognizes
> > where the bad content came from, that might be a clue.
>
>
> Gary/Mark,
>
> Good eye! Yes, it indeed does appear to be ASCII. I *thought*
> something in the repetition when I originally did an od -a looked
> interesting.
>
> I dumped the whole bad section as a string, and here's (partly) what I get:
>
> ${138AFE{@
> @$$}138AFE}@
>
> @$${138AFF{@
> [A3:^80(^91^2146F)]
> @$$}138AFF}@
>
> @$${138B00{@
Looks like terminal output/codes that have been stripped...
-Alfred
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dual Core Xeon / i386 install w/ more than 4gb of RAM
* Kevin K <[EMAIL PROTECTED]> [080219 14:40] wrote: > I have a box that we recently installed 16GB of RAM on. The box is i386 > FreeBSD 6.2. It only recognizes 4gb. > > > > I am currently recompiling the kernel to support options PAE (KERNCONF=PAE) > in order to see this. I understand this is still considered a Beta > implementation ,and this is a production box. > > > > Does anyone have any alternative solutions that would provide a more > reliable environment other than PAE? Besideds PAE some people have mentioned running an amd64 system. One thing to consider is that PAE in 6-stable (6.3 and beyond) is considered very stable, so if you can't make the jump to amd64 system because you'd have to recompile too much, you might have luck updating sources to 6-stable and trying that kernel, then installing 6.3 userland. good luck, -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dual Core Xeon / i386 install w/ more than 4gb of RAM
* Tom Samplonius <[EMAIL PROTECTED]> [080219 23:00] wrote: > > ----- "Alfred Perlstein" <[EMAIL PROTECTED]> wrote: > > > > > > > Does anyone have any alternative solutions that would provide a > > more > > > reliable environment other than PAE? > > > > Besideds PAE some people have mentioned running an amd64 system. > > > > One thing to consider is that PAE in 6-stable (6.3 and beyond) > > is considered very stable, so if you can't make the jump to amd64 > > system because you'd have to recompile too much, you might have luck > > updating sources to 6-stable and trying that kernel, then installing > > 6.3 userland. > > Is PAE really that stable? I thought it was fairly unpolished, mainly > because PAE is seen as a weak kludge implemented by Intel because they all > thought we would all be using Itanium's by now. Intel reversed their folly > pretty quickly, adopted the x86-64 extensions as-is from AMD, and pushed them > onto every piece of silicon they make. The 6-stable (6.3 and beyond) has been in use at Yahoo and other sites for quite some time. > I also really don't know how anyone would properly use 16GB of RAM under > PAE anyways? Each process is going to limited to just under 4GB. The kernel > memory space can't be bigger than 4GB either, so forget about a huge disk > cache. Actually this is incorrect, the kernel can use physical memory outside of its address space as cache, so you can get more than 4GB of cache. > And is there some really stability fear about FreeBSD on x86-64? Seems > just the same as i386. It's fine, people are just suggesting that the person upgrade to -stable (not stay at 6.2) and are concerned that reinstalling the machine as amd64 might be too much of a move. -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fsck_ufs: cannot alloc 94208 bytes for inoinfo
* Olivier Mueller <[EMAIL PROTECTED]> [080226 14:32] wrote: > Hello, > > "fsck_ufs: cannot alloc 94208 bytes for inoinfo" > > This is what I get after about one hour while trying a fsck on a large > (1.4TB) partition "broken" since a power outage. > > HW: HP DL380G5, under freebsd 6.1/i386, with 1GB of RAM and: > > da0: Fixed Direct Access SCSI-4 device > da0: 135.168MB/s transfers > da0: 1430488MB (2929640988 512 byte sectors: 255H 63S/T 65535C) > > Mounting with option -f (force) seems to work, so I guess there is > still hope :) > > > Now I added this to the /boot/loader.conf: > kern.maxdsiz="1073741824" # 1GB > kern.dfldsiz="1073741824" # 1GB > and I'm trying the fsck again, but I'm not sure it will help. > > Would you maybe have other suggestions? See "limit/ulimit" to make sure you're giving the fsck process unlimited data size. you can also likely safely increase the maxdsiz to 1.5GB and still be ok, just make sure to turn on swapping. -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7 buildworld error
* Derek Taylor <[EMAIL PROTECTED]> [080229 18:33] wrote: > I csup'ed to RELENG_7_0 (from RELENG_6_3) yesterday and have been > having problems building world. After about 10 minutes of building, > I get the error: cc1: out of memory allocating 97582896 bytes > > I have put the full output at > <http://www.personal.psu.edu/det135/freebsd.buildworld.20080229>. > > Someone suggested that I might have a ulimit problem, but that looks > ok to me: > $ ulimit -a > core file size (blocks, -c) unlimited > data seg size (kbytes, -d) 524288 > file size (blocks, -f) unlimited > max locked memory (kbytes, -l) unlimited > max memory size (kbytes, -m) unlimited > open files (-n) 11095 > pipe size(512 bytes, -p) 1 > stack size (kbytes, -s) 65536 > cpu time (seconds, -t) unlimited > max user processes (-u) 5547 > virtual memory (kbytes, -v) unlimited > > Any ideas? I can provide more information at request. Object directory clean? -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Approaching the limit on PV entries
* Ivan Voras <[EMAIL PROTECTED]> [080311 08:46] wrote: > During heavy postgresql load (pgbench), /var/log/messages registers > (multiple times) the following message: > > "Approaching the limit on PV entries, consider increasing either the > vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl" > > I'm increasing both, but no matter what I increase them to, after a > short time they again get increased by the system (???). > > The values are currently: > > vm.pmap.shpgperproc: 1134 > vm.pmap.pv_entry_max: 800 > > But the last sysctl setting, verified by retrieving it from my shell > command line history, is that I set vm.pmap.shpgperproc to 800. > > Is this normal, and what are the common settings for these values? The > machine is 2x4-core, currently 4 GB RAM (which will increase to at least > 6 GB), amd64, running postgresql, php and apache. > try setting: sysctl kern.ipc.shm_use_phys=1 -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re[2]: The Design and Implementation of the FreeBSD Operating System
* Daniel Gerzo <[EMAIL PROTECTED]> [080314 16:58] wrote: > Hello mv, > > Friday, March 14, 2008, 6:59:39 PM, you wrote: > > > Hello Marc, > > > Does "yes it is" mean the book is > > > - still relevant; or > > > - a second edition is coming soon. > > > As a newbie I'm also interested in this book. Assuming the second > > edition covers FreeBSD 7 or 8, I would rather wait for it rather than > > purchase the first edition. > > +1; Waiting is likely going to be a while, also, waiting pushes the number of sales down so that the likelyhood of the book being funded is lower. Get the current book, it's worth it. the next one will be worth it too. > > -- > Best regards, > Danielmailto:[EMAIL PROTECTED] > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
timeout/untimeout race conditions/crash [patch]
We think we tracked down a defect in timeout/untimeout in
FreeBSD.
We have reduced the problem to the following scenario:
2+ cpu system, one cpu is running softclock at the same time
another thread is running on another cpu which makes use of
timeout/untimeout.
CPU 0 is running "softclock"
CPU 1 is running "driver" with Giant held.
softclock: mtx_lock_spin(&callout_lock)
softclock: CACHES the callout structure's fields.
softclock: sees that it's a CALLOUT_LOCAL_ALLOC
softclock: executes this code:
if (c->c_flags & CALLOUT_LOCAL_ALLOC) {
c->c_func = NULL;
c->c_flags = CALLOUT_LOCAL_ALLOC;
SLIST_INSERT_HEAD(&callfree, c,
c_links.sle);
curr_callout = NULL;
} else {
NOTE: that c->c_func has been set to NULL and curr_callout
is also NULL.
softclock: mtx_unlock_spin(&callout_lock)
driver: calls untimeout(), the following sequence happens:
mtx_lock_spin(&callout_lock);
if (handle.callout->c_func == ftn && handle.callout->c_arg == arg)
callout_stop(handle.callout);
mtx_unlock_spin(&callout_lock);
NOTE: untimeout() sees that handle.callout->c_func is not set
to the function so it does NOT call callout_stop(9)!
driver: free's backing structure for c->c_arg.
softclock: executes callout.
softclock: likely crashes at this point due to access after free.
I have a patch I'm trying out here, but I need feedback on it.
The way the patch works is to treat CALLOUT_LOCAL_ALLOC (timeout/untimeout)
callouts the same as ~CALLOUT_LOCAL_ALLOC allocs, and moves the
freelist manipulation to the end of the callout dispatch.
Some light testing seems to have the system work.
We are doing some testing in-house to also make sure this works.
Please provide feedback.
See attached delta.
--
- Alfred Perlstein
Index: kern_timeout.c
===
RCS file: /cvs/ncvs/src/sys/kern/kern_timeout.c,v
retrieving revision 1.97.2.2
diff -u -r1.97.2.2 kern_timeout.c
--- kern_timeout.c 26 Sep 2005 19:49:12 - 1.97.2.2
+++ kern_timeout.c 15 Mar 2008 02:28:48 -
@@ -241,17 +241,8 @@
c_arg = c->c_arg;
c_mtx = c->c_mtx;
c_flags = c->c_flags;
-if (c->c_flags & CALLOUT_LOCAL_ALLOC) {
- c->c_func = NULL;
- c->c_flags = CALLOUT_LOCAL_ALLOC;
- SLIST_INSERT_HEAD(&callfree, c,
- c_links.sle);
- curr_callout = NULL;
-} else {
- c->c_flags =
- (c->c_flags & ~CALLOUT_PENDING);
- curr_callout = c;
-}
+c->c_flags &= ~CALLOUT_PENDING;
+curr_callout = c;
curr_cancelled = 0;
mtx_unlock_spin(&callout_lock);
if (c_mtx != NULL) {
@@ -310,6 +301,12 @@
mtx_unlock(c_mtx);
mtx_lock_spin(&callout_lock);
done_locked:
+if (c->c_flags & CALLOUT_LOCAL_ALLOC) {
+ c->c_func = NULL;
+ c->c_flags = CALLOUT_LOCAL_ALLOC;
+ SLIST_INSERT_HEAD(&callfree, c,
+ c_links.sle);
+}
curr_callout = NULL;
if (wakeup_needed) {
/*
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: timeout/untimeout race conditions/crash [patch]
* John Baldwin <[EMAIL PROTECTED]> [080317 09:43] wrote: > > This is not a bug. Don't use untimeout(9) as it is not guaranteed to be > reliable. Instead, use callout_*(). Your patch doesn't solve any races as > the driver detach routine needs to use callout_drain() and not just > callout_stop/untimeout anyways. Fix your broken drivers. I understand that some old Giant locked code can issue timeout/untimeout without Giant held, which would certainly cause this issue to happen and is uncorrectable, however, this is with completely Giant locked code. We are not trying to use timeout(9) for mpsafe code, this is old code and relies upon Giant. Giant locked code should be timeout/untimeout safe. As explained in my email, there exists a condition where the Giant locked code can have a timer fire even though proper Giant locking is observed. For a Giant locked subsystem, one should be able to have the following code work: mtx_lock(&Giant); /* formerly spl higher than softclock */ untimeout(&func, arg, &sc->handle); free(sc); mtx_unlock(&Giant); /* formerly splx() */ Normally splsoftclock would completely block the timeout from firing and this sort of code would be safe. It is no longer safe due to a BUG in the way that Giant is used. Please reread the original mail to better understand the synopsis of the problem. thank you, -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about file system checks
* Marian Hettwer <[EMAIL PROTECTED]> [080327 06:55] wrote: > > On Thu, 27 Mar 2008 13:39:55 +, Matthew Seaman > <[EMAIL PROTECTED]> wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: RIPEMD160 > > > > Jared Carlson wrote: > >> Hi I have a question about startup scripts for BSD distributions. > >> Can you turn off the file system check that occurs every 30 boots, > >> etc? I recall this being the case on a BSD platform, although my Mac > >> OS X doesn't (to my knowledge) do a file system check that often at > >> all. > > > > You are thinking of the Linux ext2/ext3 filesystem. > > > Although this is OT, does anybody have a clue why ext2/ext3 filesystems > behave like that? > I wouldn't like to trust a filesystem which thinks a fsck is worth it, > although it always was a clean shutdown. > Any clue?! :) "linux" :) -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about file system checks
* Ivan Voras <[EMAIL PROTECTED]> [080328 14:51] wrote: > Matthew Seaman wrote: > >Ivan Voras wrote: > > >>1. UFS+gjournal looses the least, but it's also the slowest. > >>2. UFS+SU had no truncated files or files of unexpected length > >>(apparently it just looses the file that would end up in this state) > >>3. XFS and JFS end up with a *huge* number of files that are truncated > >>or of unexpected length (40%-50%!) > >>4. In no case has any of the above file systems gone completely > >>corrupted or lost any of the files/directories not being updated. > >>5. ZFS on FreeBSD was the fastest, in the sense of creating the most > >>files during this benchmark (though speed was not the target for this > >>benchmark so this is a low-quality observation), closely followed by > >>JFS and XFS. > >>6. ZFS crashed the kernel at least once. > >> > > > >Hmmm in many ways a corrupt or truncated file is a worse outcome > >than a completely missing file -- at least if the file has gone away > >you know you've got to do something to fix it. A damaged file could > >end up silently causing weird behavioural effects and (by the law of > >natural cussedness) it is almost bound not to be tracked down until the > >day after the last good copy on the backup tapes gets overwritten... > > > >How do the different filesystems compare if you total all lost, damaged > >or truncated files? > > The only things that happen are that XFS and JFS get disproportionally > bad numbers and that ext3 gets almost identically bad results with > UFS+SU. Overall ratios remain approximately the same. > > To put this into perspective, for total "bad" files this means that, > e.g. UFS+SU created 2 files, of which 750 were in some way "bad", > and ZFS created 46000 files, of which 900 were bad (so percentage is in > favour of ZFS). JFS created 43000 files of which 2 were of wrong > size, but only 45 were completely lost. How bad this is depends, of > course on what is done with the file system. > > A big surprise for me was that Windows' NTFS did very good, though it > was the slowest in most other tests (which are smarter and probably use > fsync a lot), it managed to create 32000 files and have only 121 "bad" > in some way. > I know this sounds pretty awful, but honestly any file modified within an hour and not fsync'd being "lost" is not really a bad thing. It's pretty much "the unix way" that only fsync'd files/directories or file modified more than several minutes ago are safe. -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gjournal....
* Karl Denninger <[EMAIL PROTECTED]> [080329 20:10] wrote: > Hi folks; > > Wondering about the various pros and cons of using the "gjournal" GEOM > provider... and if you can "promote" and existing system using it, or > whether you need to build something anew. > > The scenario is a fairly busy and large system with PostgreSQL database data > on it. The data is currently on a 2-disk gmirror pair to provide data > safety in the event of a disk failure. > > I am using softupdates right now. > > If I'm reading the docs correctly, I can't put gjournal in use on the > existing filesystem, and need to effectively build a new disk structure then > copy over the data onto it. > > Can you boot from a gjournal'd root? > > Ideas please, pros and cons of the various alternatives, etc. thanks! > If you're using a database then it shouldn't matter what meta data provider you use "all that much" with the exception of temporary tables. Basically, SU and gjournal both provide for meta data consistency, something that a database rarely needs as it rarely creates/deletes files often. -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gjournal....
* Karl Denninger <[EMAIL PROTECTED]> [080330 09:17] wrote: > On Sun, Mar 30, 2008 at 02:06:17AM -0700, Alfred Perlstein wrote: > > > > If you're using a database then it shouldn't matter what meta data > > provider you use "all that much" with the exception of temporary > > tables. > > > > Basically, SU and gjournal both provide for meta data consistency, > > something that a database rarely needs as it rarely creates/deletes > > files often. > > > > I'm looking at this more from a performance standpoint. > > Is there a performance advantage to using gjournal over a "normal" UFS/UFS2 > filesystem with softupdates? I think that SU will be faster, but that's just a semi-educated guess. -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NFS and /etc/exports
* Robert Blayzor <[EMAIL PROTECTED]> [080414 06:07] wrote: > On Apr 14, 2008, at 7:02 AM, Nawfal bin Mohmad Rouyan wrote: > >I'm using TCP and the entry in /etc/fstab on all clients is as below: > > > >build:/usr/ports/usr/ports nfs > >tcp,intr,nfsv3,-w=32768,-r=32768,rw,noauto 0 0 > >build:/usr/src /usr/srcnfs > >tcp,intr,nfsv3,-w=32768,-r=32768,rw,noauto 0 0 > >build:/usr/obj /usr/objnfs > >tcp,intr,nfsv3,-w=32768,-r=32768,rw,noauto 0 0 > > > > Are -r and -w really needed/useful for TCP mounts? yes. > > -- > Robert Blayzor, BOFH > INOC, LLC > [EMAIL PROTECTED] > http://www.inoc.net/~rblayzor/ > > Mac OS X. Because making Unix user-friendly is easier than debugging > Windows. > > > > > > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NFS and /etc/exports
* Robert Blayzor <[EMAIL PROTECTED]> [080414 17:04] wrote: > On Apr 14, 2008, at 7:28 PM, Alfred Perlstein wrote: > > > >>Are -r and -w really needed/useful for TCP mounts? > > > >yes. > > > Really? Please explain then, because the mount_nfs man page > contradicts this... The documentation you cite is only relevant for UDP mounts. Basically, making the read/write size larger will allow more data to be sent with each RPC which reduces the uh, overhead. :) -Alfred > > "Set the read data size to the specified value. It should nor- > mally be a power of 2 greater than or equal to 1024. This should > be used for UDP mounts when the ``fragments dropped due to > timeout'' value is getting large while actively using a mountpoint." > > and > > "Set the write data size to the specified value. Ditto the comments > w.r.t. > the -r option, but using the ``fragments dropped due to timeout'' > value on > the server instead of the client. Note that both the -r and -w > options should > only be used as a last ditch effort at improving performance when > mounting servers > that do not support TCP mounts." > > > -- > Robert Blayzor, BOFH > INOC, LLC > [EMAIL PROTECTED] > http://www.inoc.net/~rblayzor/ > > Mac OS X. Because making Unix user-friendly is easier than debugging > Windows. > > > > > > > _______ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NFS and /etc/exports
* Dan Nelson <[EMAIL PROTECTED]> [080414 20:24] wrote:
> In the last episode (Apr 14), Alfred Perlstein said:
> > * Robert Blayzor <[EMAIL PROTECTED]> [080414 06:07] wrote:
> > > On Apr 14, 2008, at 7:02 AM, Nawfal bin Mohmad Rouyan wrote:
> > > >I'm using TCP and the entry in /etc/fstab on all clients is as below:
> > > >
> > > >build:/usr/ports/usr/ports nfs
> > > >tcp,intr,nfsv3,-w=32768,-r=32768,rw,noauto 0 0
> > > >build:/usr/src /usr/srcnfs
> > > >tcp,intr,nfsv3,-w=32768,-r=32768,rw,noauto 0 0
> > > >build:/usr/obj /usr/objnfs
> > > >tcp,intr,nfsv3,-w=32768,-r=32768,rw,noauto 0 0
> > >
> > > Are -r and -w really needed/useful for TCP mounts?
> >
> > yes.
>
> This is interesting: according to mountnfs() in nfs_vfsops.c, those are
> already the kernel defaults:
>
> if ((argp->flags & NFSMNT_NFSV3) && argp->sotype == SOCK_STREAM) {
> nmp->nm_wsize = nmp->nm_rsize = NFS_MAXDATA;
> } else {
> nmp->nm_wsize = NFS_WSIZE;
> nmp->nm_rsize = NFS_RSIZE;
> }
>
> $ grep nfs_maxdata /sys/nfs/*
> /sys/nfs/nfsproto.h:#define NFS_MAXDATA 32768
>
> But it looks like /sbin/mount_nfs always overrides them to NFS_WSIZE
> and NFS_RSIZE (both 8K) in its nfsdefargs struct.
Yeah, not sure what to make of this. :)
Using packet size greater than 8k for UDP mounts can really make
your life miserable because a single dropped IP packet will
force retransmit of the whole packet.
In my experience when using TCP it's really good to go to 32k.
--
- Alfred Perlstein
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Some odd behaviour of vmstat and vmtotal...
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [080430 18:13] wrote: > Howdy, > > In deploying 7.0 at work we were finding a persistent problem when > running "vmstat 1" on systems. The problem shows up as a 10ms "pause" > in processing, usually packet stamping and forwarding by a user level > process. This is due to the fact that vmstat calls the vmtotal() > routine which in turn does a whole lot of locking. The vmtotal call > locks and walks the VM object list twice in a mark and sweep > operation. > > So, the question is, "What is the right way to fix this?" I could > remove the locking since the O_ACTIVE bit is not used by any other > routine besides vmtotal, but I'm not too happy about that. > > The relevant code can be found in src/sys/vm/vm_meter.c in vmtotal(). > > Thoughts? Can you _really_ remove the locking? I don't think that would be safe if the list is being manipulated, but I haven't checked. Typically one uses a sentinal to get around such problems. Basically insert a dummy object that no one should touch other than you, then drop the lock periodically and insert it into the list, then resume. -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Interrupt storm with shared interrupt on digi(4)
* John Baldwin <[EMAIL PROTECTED]> [080604 11:12] wrote: > On Tuesday 03 June 2008 03:04:18 pm Peter Jeremy wrote: > > BTW, your MUA's list-reply configuration don't recognize that > > freebsd-stable@ and stable@ are aliases. > > Yes, kmail is broken and the authors refuse to fix it. It happens on reply > to > a foo@ e-mail (it changes the 'To' to 'freebsd-foo@' because of the List-Id > header and leaves foo@ in the 'CC' field). Note that there isn't anything in > the List headers that says that foo@ is an alias for [EMAIL PROTECTED] I > just > wish I could turn off the List-Id crap and use plain old reply-to-all, but > that is where the kmail developers disagree. wtf.why not just have a checkbox to toggle the behavior? -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Interrupt storm with shared interrupt on digi(4)
* John Baldwin <[EMAIL PROTECTED]> [080605 07:58] wrote: > On Thursday 05 June 2008 02:19:31 am Alfred Perlstein wrote: > > * John Baldwin <[EMAIL PROTECTED]> [080604 11:12] wrote: > > > On Tuesday 03 June 2008 03:04:18 pm Peter Jeremy wrote: > > > > BTW, your MUA's list-reply configuration don't recognize that > > > > freebsd-stable@ and stable@ are aliases. > > > > > > Yes, kmail is broken and the authors refuse to fix it. It happens on > > > reply to > > > a foo@ e-mail (it changes the 'To' to 'freebsd-foo@' because of the > > > List-Id > > > header and leaves foo@ in the 'CC' field). Note that there isn't > > > anything in > > > the List headers that says that foo@ is an alias for [EMAIL PROTECTED] I > > > just > > > wish I could turn off the List-Id crap and use plain old reply-to-all, > > > but > > > that is where the kmail developers disagree. > > > > wtf.why not just have a checkbox to toggle the behavior? > > That was my request (and I found at least 2 other open bugs for the same issue > when I looked again yesterday). The developers reply was "an option is not an > option". Did you try sending him email with forged headers a few times with List-Id set to something embarassing? What's his email? I'll do it. -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: challenge: end of life for 6.2 is premature with buggy 6.3
Y'know, I've been sort of skimming this thread, and I think a lot of this time could be better spent by just looking at the PRs and giving the original poster tips and encouragement for providing the information needed by FreeBSD to solve his problems. Really... -Alfred * Mike Edenfield <[EMAIL PROTECTED]> [080605 18:04] wrote: > Paul Schmehl wrote: > >I think that's an unfair characterization. He stated that he had > >noted numerous bugs in 6.3 (submitted PRs) that he perceived affected > >him personally and so he chose not to update to 6.3. He then asked if > >6.2 couldn't be extended farther. That seems like a reasonable > >question to ask. A simple, professional answer would have settled the > >matter quickly. > > Part of the problem is that a few of us (including myself) *have* looked > for the PRs he referenced and can't find them. There are only three > critical PR's opened on the hardware devices he mentioned that are filed > specifically against version 6.3: one each for bge, gmirror, and 3ware. > Of those, one of them appears to be sporadic, one of them appears to be > specific to a particular obscure BIOS, and one of them involved a > specific dual-card setup on a specific type of motherboard. And none of > those *specifically* say that they cannot be reproduced on 6.2 -- one of > them is actually filed against version 5 through 7. Since we also know > very little about the specific hardware setup of the OP, it's impossible > to determine if these are, in fact, the PRs he's looking at, or if he's > actually looking at other less-critical PRs that may need to be bumped > up to critical, or if they're misfiled, or who knows what. > > In short, the problem reports that the OP is looking at are not > immediately obvious to someone who doesn't already know what they are, > and he's not doing himself any favors by insisting that everyone else > "already knows" about these problems. If he's seen these bug reports, > presumably he knows what their PR #'s are, or at the very least the > description of the bugs, and it would be many many times faster for him > to just say so than continue to insist that other people read his mind. > > --Mike > > _______ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: challenge: end of life for 6.2 is premature with buggy 6.3
* Jo Rhett <[EMAIL PROTECTED]> [080607 14:37] wrote: > > Mike, could you do me a favor and provide me with a set of words that > will make what I am trying to say on this topic clear? I keep saying > the same thing over and over again and nobody is hearing me, so could > you perhaps help me translate this? > > These are the raw issues without any friendly wording. > > 1. Bugs in 6.3 that are patched aren't available in any other -RELEASE. Jo, sorry to jump in here, but what are these bugs that you are concerned about? Can you give specific PR#s? Can you confirm that these bugs are still issues? > 2. Bugs in 6.3 outstanding that don't affect 6.2 This is a bit of a stretch honestly, there may be bugs in 6.3 that are also in 6.2, however they have only been reported in 6.3 because of time. > 3. Overall amount of bugs. See previous. > 4. Difference in code base between 6.3 and 6-STABLE is > than 6.2 and > 6.3 Well, that's good! (or should be, see below.) > These combine to produce a release which will never be "stable" for > production needs. Let's not go there. Let's work with what we have. In theory people should only be pushing bugfixes and drivers in the -stable series, however sometimes changes are made for performance too when the risk is "low". Larger changesets in the later versions of -stable for a particular major release is to be expected as the number of users migrating from the previous major release (5.x) start to come over. > Obviously the FreeBSD team(s) involved have to make choices. Perhaps > there's nothing we can do to improve it other than work on the > specific bugs. But does it hurt to ask why 6.2 was dropped so fast? > What the real cost of supporting 6.2 until 6.4 ships is? I can understand your upset, I have been there, I found that later versions of 5.x had regressions for me that forced me to decide to either downgrade to 5.3 or go to 6.x. You may need to stick to 6.2 and keep a local set of patches (this is much easier now with svn and svk). OR you can try 7.x. The fact of the matter is that as an individual you have many options: 1) work to figure out why 6.3 (or -stable) isn't working. 2) stick with 6.2 with your own mods. 3) try 7-stable. Trust me, I know you've been pretty frustrated by this thread, but from my experience you're not going to get what you want, but you may get what you need (if you take my advice). best of luck, -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7.1 and BIND exploit
t over the fact that this "HOWTO" is 47 pages long: > http://www.nlnetlabs.nl/dnssec_howto/ > > Let's not forget this packet flow diagram, which is quite legible and > easy to understand: > http://www.nlnetlabs.nl/dnssec_howto/dnspktdemo.png > > > Once you implement DNSSEC you *must* generate keys every 30 days. So, I > > think, if you're going to enable it by default, there needs to be a > > script in periodic that will do all the magic to change keys every 30 > > days. Maybe put vars in /etc/rc.conf to override the default key lengths > > and other portions of the commands that could change per installation. > > I believe you're talking about re-signing the zones. The duration is > adjustable, but 30 days appears to be what the documentation and howto > site defaults to/recommends using: > > http://www.isc.org/sw/bind/arm95/man.dnssec-signzone.html > http://www.nlnetlabs.nl/dnssec_howto/#x1-240002.4 > > > But until root is signed, it's not worth it for those of us who don't > > have dedicated staff doing dns only. > > Bingo. > > -- > | Jeremy Chadwickjdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Upcoming ABI Breakage in RELENG_7
* Ken Smith <[EMAIL PROTECTED]> [080729 08:47] wrote: > > Normally the FreeBSD Project tries very hard to avoid ABI breakage in > "Stable Branches". However occasionally the fix for a bug can not be > implemented without ABI breakage, and it is decided that the fix > warrants the impact of the ABI breakage. We have one of those > situations coming along for RELENG_7 (what will become FreeBSD 7.1). > The ABI breakage should only impact kernel modules that are not part of > the baseline system (those will be patched by the MFC) which deal with > advisory locks. As such the impact should not cause many people > problems. > > The work that will be MFCed fixes issues with filesystem advisory locks, > and moves the advisory locks list from filesystem-private data > structures into the vnode structure. > > The MFC will be done by Kostantin Belousov some time this coming Friday > (August 1st, 2008) if you have concerns and want to watch for it. Ken, Can you point at a cvs/svn log or two that details the change and why? Everyone else: For those confused about what ABI breakage means: It means that you'll need to recompile your kernel modules and potentially your system utilities that access kernel data structures to display statistics. It seems like in this particular case you won't need to recompile, but it's a good idea just to be safe to recompile kernel, world and any third party kernel modules you have. thank you, -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you
* David G Lawrence <[EMAIL PROTECTED]> [080805 11:37] wrote: > > The thrust of this change is to replace the mutexes protecting the inpcb > > and inpcbinfo data structures with read-write locks (rwlocks). These > >That's really cool and directly affects my current work project. I'm > developing (have developed, actually) a multi-threaded, 5000+ member VoIP/SIP > conferencing server called Nconnect. It a primarily UDP application running > on FreeBSD 7. This generates and receives about 250,000 UDP packets a second, > with 200 byte packets, resulting in about 400Mbps of traffic in each > direction. The current bottleneck is the kernel UDP processing. It should > be possible to scale to 1+ members if kernel UDP processing had optimal > concurrency. >Anyway, thumbs up (and not for the middle-eastern meaning :-)) - I'm > looking forward to the MFC. David, one thing I noticed was that it appears that UDP sockets are serialized for copyout. Mainly that the socket is sblock()'d while the uiomove happens. I was trying to figure out a way to bypass this somehow. Perhaps just dequeuing and unlocking, the copyout after dropping the sblock. If there's some error, then requeue or discard the packet. I'll have to think about it. -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
tmpfs nfs exports?
Hey folks, any reason why not to include the following patch in 9.1? It
would be nice to have tmpfs be exportable.
I'm good to commit it, I can also wait until post 9.1.
$ svn diff
Index: .
===
--- .(revision 242331)
+++ .(working copy)
Property changes on: .
___
Modified: svn:mergeinfo
Merged /head:r234346
Index: sys
===
--- sys(revision 242331)
+++ sys(working copy)
Property changes on: sys
___
Modified: svn:mergeinfo
Merged /head/sys:r234346
Index: sys/fs
===
--- sys/fs(revision 242331)
+++ sys/fs(working copy)
Property changes on: sys/fs
___
Modified: svn:mergeinfo
Merged /head/sys/fs:r234346
Index: sys/fs/tmpfs/tmpfs.h
===
--- sys/fs/tmpfs/tmpfs.h(revision 242331)
+++ sys/fs/tmpfs/tmpfs.h(working copy)
@@ -387,6 +387,9 @@
* tmpfs_pool.c. */
uma_zone_ttm_dirent_pool;
uma_zone_ttm_node_pool;
+
+/* Read-only status. */
+inttm_ronly;
};
#define TMPFS_LOCK(tm) mtx_lock(&(tm)->allnode_lock)
#define TMPFS_UNLOCK(tm) mtx_unlock(&(tm)->allnode_lock)
Index: sys/fs/tmpfs/tmpfs_vfsops.c
===
--- sys/fs/tmpfs/tmpfs_vfsops.c(revision 242331)
+++ sys/fs/tmpfs/tmpfs_vfsops.c(working copy)
@@ -82,6 +82,10 @@
NULL
};
+static const char *tmpfs_updateopts[] = {
+"from", "export", NULL
+};
+
/*
- */
static int
@@ -193,10 +197,13 @@
return (EINVAL);
if (mp->mnt_flag & MNT_UPDATE) {
-/* XXX: There is no support yet to update file system
- * settings. Should be added. */
-
-return EOPNOTSUPP;
+/* Only support update mounts for certain options. */
+if (vfs_filteropt(mp->mnt_optnew, tmpfs_updateopts) != 0)
+return (EOPNOTSUPP);
+if (vfs_flagopt(mp->mnt_optnew, "ro", NULL, 0) !=
+((struct tmpfs_mount *)mp->mnt_data)->tm_ronly)
+return (EOPNOTSUPP);
+return (0);
}
vn_lock(mp->mnt_vnodecovered, LK_SHARED | LK_RETRY);
@@ -269,6 +276,7 @@
tmpfs_node_ctor, tmpfs_node_dtor,
tmpfs_node_init, tmpfs_node_fini,
UMA_ALIGN_PTR, 0);
+tmp->tm_ronly = (mp->mnt_flag & MNT_RDONLY) != 0;
/* Allocate the root node. */
error = tmpfs_alloc_node(tmp, VDIR, root_uid,
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: tmpfs nfs exports?
Thanks all. I will fix up the merge step and commit.
Sent from my iPhone
On Oct 30, 2012, at 5:00 AM, Konstantin Belousov wrote:
> On Tue, Oct 30, 2012 at 02:38:16AM -0700, Alfred Perlstein wrote:
>> Hey folks, any reason why not to include the following patch in 9.1? It
>> would be nice to have tmpfs be exportable.
>>
>> I'm good to commit it, I can also wait until post 9.1.
> It is too late for 9.1. Patch is fine for stable/9, but you merged at
> the wrong point. Merge at sys/, not at the root of the sources.
>
>>
>> $ svn diff
>> Index: .
>> ===
>> --- .(revision 242331)
>> +++ .(working copy)
>>
>> Property changes on: .
>> ___
>> Modified: svn:mergeinfo
>>Merged /head:r234346
>> Index: sys
>> ===
>> --- sys(revision 242331)
>> +++ sys(working copy)
>>
>> Property changes on: sys
>> ___
>> Modified: svn:mergeinfo
>>Merged /head/sys:r234346
>> Index: sys/fs
>> ===
>> --- sys/fs(revision 242331)
>> +++ sys/fs(working copy)
>>
>> Property changes on: sys/fs
>> ___
>> Modified: svn:mergeinfo
>>Merged /head/sys/fs:r234346
>> Index: sys/fs/tmpfs/tmpfs.h
>> ===
>> --- sys/fs/tmpfs/tmpfs.h(revision 242331)
>> +++ sys/fs/tmpfs/tmpfs.h(working copy)
>> @@ -387,6 +387,9 @@
>> * tmpfs_pool.c. */
>> uma_zone_ttm_dirent_pool;
>> uma_zone_ttm_node_pool;
>> +
>> +/* Read-only status. */
>> +inttm_ronly;
>> };
>> #define TMPFS_LOCK(tm) mtx_lock(&(tm)->allnode_lock)
>> #define TMPFS_UNLOCK(tm) mtx_unlock(&(tm)->allnode_lock)
>> Index: sys/fs/tmpfs/tmpfs_vfsops.c
>> ===
>> --- sys/fs/tmpfs/tmpfs_vfsops.c(revision 242331)
>> +++ sys/fs/tmpfs/tmpfs_vfsops.c(working copy)
>> @@ -82,6 +82,10 @@
>> NULL
>> };
>>
>> +static const char *tmpfs_updateopts[] = {
>> +"from", "export", NULL
>> +};
>> +
>> /*
>> - */
>>
>> static int
>> @@ -193,10 +197,13 @@
>> return (EINVAL);
>>
>> if (mp->mnt_flag & MNT_UPDATE) {
>> -/* XXX: There is no support yet to update file system
>> - * settings. Should be added. */
>> -
>> -return EOPNOTSUPP;
>> +/* Only support update mounts for certain options. */
>> +if (vfs_filteropt(mp->mnt_optnew, tmpfs_updateopts) != 0)
>> +return (EOPNOTSUPP);
>> +if (vfs_flagopt(mp->mnt_optnew, "ro", NULL, 0) !=
>> +((struct tmpfs_mount *)mp->mnt_data)->tm_ronly)
>> +return (EOPNOTSUPP);
>> +return (0);
>> }
>>
>> vn_lock(mp->mnt_vnodecovered, LK_SHARED | LK_RETRY);
>> @@ -269,6 +276,7 @@
>> tmpfs_node_ctor, tmpfs_node_dtor,
>> tmpfs_node_init, tmpfs_node_fini,
>> UMA_ALIGN_PTR, 0);
>> +tmp->tm_ronly = (mp->mnt_flag & MNT_RDONLY) != 0;
>>
>> /* Allocate the root node. */
>> error = tmpfs_alloc_node(tmp, VDIR, root_uid,
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: tmpfs nfs exports?
On 10/30/12 8:31 AM, Dan Nelson wrote: In the last episode (Oct 30), jb said: Alfred Perlstein mu.org> writes: Hey folks, any reason why not to include the following patch in 9.1? It would be nice to have tmpfs be exportable. I'm good to commit it, I can also wait until post 9.1. ... How do you identify tmpfs ? With fsid ? Since nfs server is stateless, are these exports identical ? export /tmp, reboot, export /tmp What about /tmp on tmpfs ? export /tmp, reboot, export /tmp I wanted to do the exact same thing a few years ago. I patched mdmfs and the startup scripts to allow for an fsid value to be passed to mdmfs on every reboot. That works for the filesystem itself, but then you have to contend with the random NFS generation number on every inode. I decided it wasn't worth the trouble at that point. If you really want an exportable /tmp, just live with the fact that you'll get ESTALE errors on all clients when you reboot the server. Maybe giving the root inode a constant generation number is all that's needed, since I suppose most clients that have mounted the server don't actually have any open filehandles. Ah, that is troublesome. This fix is really just for benchmarking nfs without hitting disk and other very temporary measures. It would be nice to make root inode predictable in some manner. -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: No buffer space available / tcp_inpcb value
How much memory is in this machine? maxsockets is in turn clipped by "nmbclusters" which is in turn clipped by "maxusers" which is limited to 384 MAXIMUM unless you're running -CURRENT. On 10/30/12 10:05 AM, Navdeep Parhar wrote: On 10/30/12 06:21, Adam Strohl wrote: Hey -STABLE, I've got a client who we've setup a FreeBSD cluster for with about a dozens servers, all behind two front end proxies/LBs/firewalls which also act as NAT gateways for the internal servers. On the active front end proxy we've started seeing "fatal: socket: No buffer space available" errors during high-peak times. I can see in vmstat -z that this is what is getting denied: ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP tcp_inpcb: 392, 32770, 19398, 13372,1449734621,6312858, 0 We've got a lot of the other values bumped, and it appears to be this input limit that is getting hit. There are no other non-zero FAILed counters except 64 and 128 buckets which I believe are normal. I cannot seem to find the sysctl (or equiv) that controls this limit though, or even what it is. Anyone know? kern.ipc.maxsockets controls this limit. See in_pcbinfo_init() for details. Regards, Navdeep ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: thread taskq / unp_gc() using 100% cpu and stalling unix socket IPC
On 11/13/12 4:41 PM, Markus Gebert wrote: On 13.11.2012, at 19:30, Markus Gebert wrote: To me it looks like the unix socket GC is triggered way too often and/or running too long, which uses cpu and worse, causes a lot of contention around the unp_list_lock which in turn causes delays for all processes relaying on unix sockets for IPC. I don't know why the unp_gc() is called so often and what's triggering this. I have a guess now. Dovecot and relayd both use unix sockets heavily. According to dtrace uipc_detach() gets called quite often by dovecot closing unix sockets. Each time uipc_detach() is called unp_gc_task is taskqueue_enqueue()d if fds are inflight. in uipc_detach(): 682 if (local_unp_rights) 683 taskqueue_enqueue(taskqueue_thread, &unp_gc_task); We use relayd in a way that keeps the source address of the client when connecting to the backend server (transparent load balancing). This requires IP_BINDANY on the socket which cannot be set by unprivileged processes, so relayd sends the socket fd to the parent process just to set the socket option and send it back. This means an fd gets transferred twice for every new backend connection. So we have dovecot calling uipc_detach() often and relayd making it likely that fds are inflight (unp_rights > 0). With a certain amount of load this could cause unp_gc_task to be added to the thread taskq too often, slowing everything unix socket related down by holding global locks in unp_gc(). I don't know if the slowdown can even cause a negative feedback loop at some point by inreasing the chance of fds being inflight. This would explain why sometimes the condition goes away by itself and sometimes requires intervention (taking load away for a moment). I'll look into a way to (dis)prove all this tomorrow. Ideas still welcome :-). A couple of ideas: 1) convert the taskqueue to a callout, but only allow one to be queued at a time. set the granularity. 2) I think you only need to actually run garbage collection on the off-chance that you pass unix file descriptors, otherwise you can get away with refcounting. It's hard for me to express the exact logic needed for this though. I think you would need some way to simply do refcounting until there was a unix socket descriptor in flight, then switch to gc. Either that or make a sysctl that allows you administratively deny passing of unix descriptors and just use refcounting. Or just use Adrian's hack. :) -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: thread taskq / unp_gc() using 100% cpu and stalling unix socket IPC
On Nov 14, 2012, at 2:42 AM, Markus Gebert wrote: > > On 14.11.2012, at 04:30, Alfred Perlstein wrote: > >> A couple of ideas: > > Thanks. > >> 1) convert the taskqueue to a callout, but only allow one to be queued at a >> time. set the granularity. > > I think Konstantin's patch is going in this direction. Yes. Looks good. > > >> 2) I think you only need to actually run garbage collection on the >> off-chance that you pass unix file descriptors, otherwise you can get away >> with refcounting. > > Hm, isn't that whats done currently? gc is only scheduled if fds are inflight > while uipc_detach() is called. > It looks to me as if it runs the gc when ANY type are in flight. If you added refcounting then you could trust the refcounting so long as no unix sockets were in flight as its only the unix sockets that can cause cycles in a refcount based graph. > >> It's hard for me to express the exact logic needed for this though. I >> think you would need some way to simply do refcounting until there was a >> unix socket descriptor in flight, then switch to gc. Either that or make a >> sysctl that allows you administratively deny passing of unix descriptors and >> just use refcounting. > > > > Markus > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: bge on the new Mac Mini
Often that is all that is needed. It's worth a shot and reporting back. Do you know how to update the table in the driver, rebuild/install kernel and check? -Alfred On 11/16/12 7:30 AM, Richard Kuhns wrote: Hi all, Over the last month or so I've installed FreeBSD 9 (-stable) on several Mac Minis via the memstick image; they seem to be pretty good little boxes for things like offsite secondary nameservers, for example, and they're easily replaced in case of problems. However, the newest minis have slightly different hardware, and FreeBSD can't find the built-in NIC. pciconf -lv on the new mini shows it as none3@pci0:1:0:0: class=0x02 card=0x168614e4 chip=0x168614e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' class = network subclass = ethernet The previous edition mini (that works) reports bge0@pci0:2:0:0:class=0x02 card=0x16b414e4 chip=0x16b414e4 rev=0x10 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme BCM57765 Gigabit Ethernet PCIe' class = network subclass = ethernet Is there a chance that adding the new card/chip info to the current driver would allow it to work? I'll be happy to test and report back. I'm afraid I'm not familiar enough with hardware at that level to figure out the patch myself. Thanks! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: bge on the new Mac Mini
On 11/16/12 8:27 AM, Richard Kuhns wrote: On 11/16/12 11:20, Gary Palmer wrote: On Fri, Nov 16, 2012 at 10:54:00AM -0500, Richard Kuhns wrote: On 11/16/12 10:41, Alfred Perlstein wrote: Often that is all that is needed. It's worth a shot and reporting back. Do you know how to update the table in the driver, rebuild/install kernel and check? -Alfred I'm afraid not. I grepped for the hex value reported on the one that works (chip=0x16b414e4), but I couldn't find it in its entirety, 16b4, or 14e4. So I don't know what to add :-( I don't have any problem with rebuilding and installing a new kernel, though. 14e4 is the ID for Broadcom 16b4 is the ID for BCM57765, a NetXtreme Desktop/Mobile chip http://www.broadcom.com/support/ethernet_nic/determine_driver.php has a list of the BCM PCI ID values There is a (frequently incomplete) database of user reported PCI values at http://www.pcidatabase.com. It has the BCM ID (14e4), but not your chip Linux uses the tg3 driver for that chipset apparently, but I think thats a general dumping ground for a lot of Broadcom products. Not sure what the appropriate FreeBSD driver to add the ID code to would be. Regards, Gary Sorry, I should have been more clear. I grepped for those values in /usr/src/sys/dev/bge/*, since that's the driver that's used on the older minis. I assume that's where the table is that Alfred mentioned; I just don't know what to add to it. Here's a cool trick you can do. 1) make a backup of your /boot/kernel directory: mv /boot/kernel /boot/kernel.good (now you can boot to a known good kernel if you blow things up) 2) hack a few drivers to add the PCI id. 3) now build a kernel WITHOUT most of the nic drivers. 4) reboot with this kernel 5) try loading/unloading the various drivers you suspect will be compatible until it either works or you get tired. :) Eventually you'll find the change that works. Go look at commit logs to see how others have added PCI ids to the drivers. It's usually in a table or under a simple "if" statement. It honestly won't take you that long, probably a few hours of head scratching. -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Where do I purchace an unlock code to build a custom kernel?
hrm.. Isn't k7 i386? -alfred On 11/23/12 11:23 PM, Chris H wrote: Sorry, that _should_ have read: RELENG_8 Greetings, I've been running a RELENG_* box for some time now. I recently slipped the same CD into an older AMD k7 box, and performed an install && cvsup. I then promptly cd /usr/src/sys/amd64/conf && cp GENERIC CUSTOM. edited CUSTOM to taste, cd /usr/src && make buildworld; wait _hours_. Then performed: make buildkernel KERNCONF=CUSTOM which produced ERROR: Missing kernel configuration files. Stop in /usr/src. *** Error code 1 Stop in /usr/src. Looks like I got bit by: 20100502: The config(8) command has been updated to maintain compatibility with config files from 8.0-RELEASE. You will need a new version of config to build kernels (this version can be used from 8.0-RELEASE forward). The buildworld target will generate it, so following the instructions in this file for updating will work glitch-free. Merely doing a make buildkernel without first doing a make buildworld (or kernel-toolchain), or attempting to build a kernel using traidtional methods will generate a config version warning, indicating you should update. So I performed: make kernel-toolchain, and tried again. STILL no joy. So I tried: To build a kernel - If you are updating from a prior version of FreeBSD (even one just a few days old), you should follow this procedure. It is the most failsafe as it uses a /usr/obj tree with a fresh mini-buildworld, make kernel-toolchain make -DALWAYS_CHECK_MAKE buildkernel KERNCONF=YOUR_KERNEL_HERE make -DALWAYS_CHECK_MAKE installkernel KERNCONF=YOUR_KERNEL_HERE STILL no joy. Looks like I need to purchase a special kernel unlock key to build a kernel. :( Thank you for all your time, and consideration. --Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: nullfs changes MFC
By combining vop_settext/unset/get into a single call with parameters "op" and &out (for gettext) you can reduce 3 new vops into a single vop. The same can be done for write count vops. This will allow you to preserve kbi by reducing the vop additions to 2. Sent from my iPhone On Dec 7, 2012, at 5:01 PM, Konstantin Belousov wrote: > Hi, > I am going to merge latest batch of the nullfs improvements into > stable/9. This will bring up significant performance enchancements due > to use of the shared locks for lookups if the lower layer supports it, > much better caching on the nullfs layer, and proper handling of the text > segments on the nullfs. Also, it should improve the error recovery and > some corner cases with locking. > > Unfortunately, the merge would break KBI for VFS, since it needs 5 new > VOP slots, and only three spares are left. We already are very liberal > with the VFS KBI, so I do not feel that the merge is not acceptable, due > to the benefits it brings to the nullfs. > > The merge is available at > http://people.freebsd.org/~kib/misc/nullfs_9.1.patch ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Will we get a RELEASE-9.1 for Christmas?
My prediction is 9.1 will be released the last day of Hanukkah and I will tell you why: When I was a kid sometimes I would ask my patients to give me one big gift for Hanukkah instead of a small present each day. This would mean I would have to wait until the final day though. My assumption is that my Jewish mother has told re@ & core@ of this preference and they are just setting up to surprise the members of the tribe with one big gift. So everyone please hold onto your dreidels! Sent from my iPhone On Dec 9, 2012, at 6:04 AM, Eitan Adler wrote: > On 9 December 2012 08:48, Jakub Lach wrote: >> This is good answer for end users, not so much when >> somebody is genuinely concerned if there were some >> unforeseen issues. > > Agreed. Companies need predictability. > > FWIW: The ports tree is open now (ports branch was tagged). The 9.1.0 > src branch was tagged already. I'd expect to be released *very* > shortly (before Christmas), although I don't know an exact date. > > > > -- > Eitan Adler > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Does / Is anyone maintaining CVS for FreeBSD?
On 12/31/12 12:40 PM, Chris H wrote: | I'm sorry, but the exporter scripts were always a stopgap. That's what I was afraid I would hear. Recently, I was informed by SF.NET, that my account would be upgraded, and all the projects I have, which all use CVS, would be "upgraded" to SVN (which renders them useless). When I asked why, they told me because CVS was so old. To which I stated: Indeed, CVS is _quite_ old, and so is TCP/IP. Yet no one can seem live without it. Sigh... IM(NS)HO; SVN is an inferior RCS created so Windows users wouldn't feel left out. Are there _any_ CVS servers/trunks/tree's left? If so, how _current_ are they? Thanks again for taking the time to reply, Chris. All the best. You still really haven't come forward with a concrete reason besides "my workflow" and "my scripts". Svn is a *near* drop in replacement for CVS. If instead of complaining and taking up bandwidth on the lists about old tech, you instead asked about how to move your archaic setup forward then someone would likely step forward and lend you a hand. The project's goal is to support a large user base and the developers in a manner that works with our resources. Supporting CVS (a 2nd gen VCS) while we have been on a 3rd gen (svn) and are finally looking into a 4th gen (git) is just unfair. If you took a few minutes you'd fine the svn command set intuitive and a simple switch over from CVS. -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Does / Is anyone maintaining CVS for FreeBSD?
There are arguments on both sides; some (perhaps you) feel SVN has/ provides more options, others (maybe myself) feel the same can be accomplished with CVS, and that migration only causes more initial (and unnecessary) overhead. I'll leave it at that. :) Chris, I think you've gotten to your NYE jubilations a bit early. Sure the same can be accomplished by CVS, the same way a mission to the moon could be accomplished with enough black powder and a sailing ship. It just won't be a pleasant trip. Go finish whatever you're drinking and have a great 2013. When you wake up, go crack a book on SVN and you'll only be living in 2007. -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Does / Is anyone maintaining CVS for FreeBSD?
On 12/31/12 7:32 PM, Kimmo Paasiala wrote: On Tue, Jan 1, 2013 at 3:21 AM, Alfred Perlstein wrote: There are arguments on both sides; some (perhaps you) feel SVN has/ provides more options, others (maybe myself) feel the same can be accomplished with CVS, and that migration only causes more initial (and unnecessary) overhead. I'll leave it at that. :) Chris, I think you've gotten to your NYE jubilations a bit early. Sure the same can be accomplished by CVS, the same way a mission to the moon could be accomplished with enough black powder and a sailing ship. It just won't be a pleasant trip. Go finish whatever you're drinking and have a great 2013. When you wake up, go crack a book on SVN and you'll only be living in 2007. -Alfred Anyone who has had the "pleasure" of being an admin charge of a CVS repository will not want to go back to it after discovering what SVN and GIT have to offer. Just my 2c Agreed. Several of our developers used to put in quite a bit of time into CVS "repo copies" and other such tasks. I do not know the weight of such things these days, but I haven't seen much traffic about them. I'm hoping the SVN reduced them quite a bit. We had some people who would be much more beneficial kernel work, instead doing repository surgery on a regular basis for people. Glad that is over. -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Does / Is anyone maintaining CVS for FreeBSD?
On 1/1/13 6:55 AM, Eitan Adler wrote: On 1 January 2013 02:54, Derek Kulinski wrote: That said I would totally understand you being upset if FreeBSD would decide to switch to git, since despite its benefits that is a huge change, and would definitely be hard for people to adjust. Just In Case: FreeBSD has no plans to switch to get in either the short or long term. We will however offer git repositories and first-class cousins via git.freebsd.org and github. Are you sure? Most of the diffs developers have been handing me lately are of the form a/path b/path so I think they are mostly using git behind the scenes. -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Does / Is anyone maintaining CVS for FreeBSD?
On 1/1/13 12:19 PM, Eitan Adler wrote: On 1 January 2013 15:17, Alfred Perlstein wrote: On 1/1/13 6:55 AM, Eitan Adler wrote: On 1 January 2013 02:54, Derek Kulinski wrote: That said I would totally understand you being upset if FreeBSD would decide to switch to git, since despite its benefits that is a huge change, and would definitely be hard for people to adjust. Just In Case: FreeBSD has no plans to switch to get in either the short or long term. We will however offer git repositories and first-class cousins via git.freebsd.org and github. Are you sure? Most of the diffs developers have been handing me lately are of the form a/path b/path so I think they are mostly using git behind the scenes. Yes. I use git behind the scenes as well. However, so far as I am aware, there are no plans in either the short or long terms to *convert upstream* to git. Yes... no plans at all. -Alfred http://www.youtube.com/watch?v=fRamB30E9mU ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Does / Is anyone maintaining CVS for FreeBSD?
On 1/1/13 12:51 PM, Derek Kulinski wrote: Hello Alfred, Tuesday, January 1, 2013, 12:17:17 PM, you wrote: Just In Case: FreeBSD has no plans to switch to get in either the short or long term. We will however offer git repositories and first-class cousins via git.freebsd.org and github. Are you sure? Most of the diffs developers have been handing me lately are of the form a/path b/path so I think they are mostly using git behind the scenes. One of nice things about git is that it can work with many popular SCM schemes. So you can have a cake and eat it too. People who like git can just check in the repo to their local disks and work on it using git features without forcing rest of the developers to use git. There apparently is also freebsd git repo that allows to do it, but you can connect it straight to svn (or even cvs). "git-svn" is somewhat problematic: http://wiki.freebsd.org/GitWorkflow -> "Using git-svn (FreeBSD committers only)" -> Things to keep in mind: * Never git merge branches, unless you know what you're doing. * Always git rebase your work on top of master, then git svn dcommit can push the top commits to svn. * Always double-check with git svn dcommit -n to see what would happen. * While you can use git add for new files just fine, you won't be able to push those upstream, you can however use the patch, apply it to some subversion checkout and do the commit there. This is a shortcoming of our very own Subversion hacks, but hey, it's better than nothing! * While git-svn now allows you to set svn:mergeinfo when committing, this is so fragile that the FreeBSD projects discourages its use. Please use svn(1) for merging, sorry. It's very poor (at least according to the wiki). Seems like you can't do much except pull a patch from git, apply to subversion and then commit upstream. Eck... I'm hoping this gets better. -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Does / Is anyone maintaining CVS for FreeBSD?
On 1/1/13 9:30 PM, Doug Hardie wrote: On 1 January 2013, at 21:16, Chris H wrote: On 1 January 2013 15:17, Alfred Perlstein wrote: On 1/1/13 6:55 AM, Eitan Adler wrote: On 1 January 2013 02:54, Derek Kulinski wrote: That said I would totally understand you being upset if FreeBSD would decide to switch to git, since despite its benefits that is a huge change, and would definitely be hard for people to adjust. Just In Case: FreeBSD has no plans to switch to get in either the short or long term. We will however offer git repositories and first-class cousins via git.freebsd.org and github. Are you sure? Most of the diffs developers have been handing me lately are of the form a/path b/path so I think they are mostly using git behind the scenes. Yes. I use git behind the scenes as well. However, so far as I am aware, there are no plans in either the short or long terms to *convert upstream* to git. Thank God! I'd hate to think that after unwinding years accumulated CVS process, to rewind it for SVN, only to have to do it again for GIT, just seems a bit masochistic. Is the cvs code going away? I ask because I maintain a number of local CVS repositories of code for which I am the only developer/maintainer. I also use grep on the repositories to find sections of code previously created and removed for future use. I can't bill my clients for conversion to SVN so that cost I would have to eat. I am not particularly thrilled about having to do so. I don't need most of the CVS features. About all I do is check in. Occasionally I botch up a module enough that I delete it and recover it from CVS. I don't use branches or tags. Not sure I understand your question, you will be able to continue to use CVS from ports if you need the CVS binary. If you want FreeBSD to continue to export the FreeBSD project code in CVS form, that may be over or ending soon. -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Does / Is anyone maintaining CVS for FreeBSD?
On 1/2/13 8:05 AM, Derek Kulinski wrote: Eitan Adler wrote: On 2 January 2013 06:26, Chris Rees wrote: To clarify, no-one wants to remove CVS completely, the suggestion was to move it out of the base system. As the developer responsible for this: CVS will be removed from base. It already exists as a port in devel/cvs Will svn be added to the base? Not long ago I run into an issue when trying to downgrade my system to 9.0. After I noticed how majority of ports were broken due to changes in the libc I decided to back out by fetching 9.1 release just to learn that svn does not work as well. There were a lot of dependencies I decided to use portupgrade which required me to recompile ruby. After that it was a lot of compiling (for example Apache because apr was broken). Having svn in the base would save tons of time in my situation. Sorry, you needed to fetch 9.0 packages then*. Putting all of that in base is not likely to happen. * I wish doing this was somewhat more intuitive/easy -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: watchdogs
On 2/20/13 11:36 AM, Eugene M. Zheganin wrote: Hi. I have a bunch of FreeBSDs that hangs (and I really want to do something to fight this). May be it's the zfs or may be it's the pf (I also have a bunch of really stable ones, so it's hard to isolate and tell). Since 9.x hang more often I suppose it's pf. I use ichwd.ko and watchdogd to reboot a machine when it hangs. It works pretty well; I'm also working on a various WITNESS/INVARIANTS stuff and I'm trying to report it to gnats, but obviously it would be much nicer if the system would panic and leave some debuggable core after a hang (so far I don't have any, so I can only guess). I've read about software watchdog in kernel and I doesn'y quite understand: it's said that kernel software watchdog is able to panic when a deadlock occurs. Can this be achieved with ichwd ? Another one: as far as I understand ichwd reboots my machine on a hardware level, right ? So am I right saying that software watchdog can be, in theory, also deadlocked, thus, being kinda less reliable solution ? Yes all your assumptions are correct. There is an 'enhanced watchdog' branch that I am working on that offers a "pre-watchdog timeout panic". However since this is done via the software you may not get your pre-timeout panic and only have a reboot. Later revisions may include facilities for generating NMI to trigger panic/logs and the followed by a hard reset by external hardware. Perhaps ichwd offers ability to send NMI? Let me check sources. -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: watchdogs
On 2/22/13 8:47 AM, Mark Atkinson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/20/2013 11:36, Eugene M. Zheganin wrote: Hi. I have a bunch of FreeBSDs that hangs (and I really want to do something to fight this). May be it's the zfs or may be it's the pf (I also have a bunch of really stable ones, so it's hard to isolate and tell). Since 9.x hang more often I suppose it's pf. I use ichwd.ko and watchdogd to reboot a machine when it hangs. It works pretty well; I'm also working on a various WITNESS/INVARIANTS stuff and I'm trying to report it to gnats, but obviously it would be much nicer if the system would panic and leave some debuggable core after a hang (so far I don't have any, so I can only guess). I've read about software watchdog in kernel and I doesn'y quite understand: it's said that kernel software watchdog is able to panic when a deadlock occurs. Can this be achieved with ichwd ? Another one: as far as I understand ichwd reboots my machine on a hardware level, right ? So am I right saying that software watchdog can be, in theory, also deadlocked, thus, being kinda less reliable solution ? I just want to /metoo that I have 32bit/i386 box running zfs, pf and - -current that is hardlocking randomly (usually has an uptime for a few days to a couple weeks). SW_WATCHDOG won't fire when it locks so it must be locking pretty fast. I just noticed that ichwd will load on this box, so I'll try that instead, but now I'm wondering if the SW_WATCHDOG kernel will interfere or rather if watchdogd is smart enough to handle both? watchdog(4) will arm all watchdogs. watchdogd uses watchdog(4) so yes, both watchdogs (SW_WATCHDOG & ichwd) should be armed. This box used to occasionally panic on the ZFS stack panic so I did the KSTACK_PAGES=4 change to the kernel and now it just hardlocks. I'm not saying they are related. Interesting. What is the default for KSTACK_PAGES? Btw, from all I've heard less than 4GB ram + ZFS == you're gonna have a bad time. There are supposedly some ways to make it somewhat reliable by disabling certain features, but I don't know the tricks off hand. -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
status of autotuning freebsd for 9.2
Andre, Are you going to have time to MFC things from -current for auto-tuning -stable before 9.2? I fear (maybe unnecessarily?) that we are about to ship yet another release that can't do basic 10gigE when sufficient memory exists. If you don't have time, then let me know and I'll see what I can do. -- Alfred Perlstein VP Software Engineering, iXsystems ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: status of autotuning freebsd for 9.2
On 7/7/13 1:34 AM, Andre Oppermann wrote: On 07.07.2013 08:32, Alfred Perlstein wrote: Andre, Are you going to have time to MFC things from -current for auto-tuning -stable before 9.2? I simply ran out of time on Friday and MFCing such a big change requires more testing. I fear (maybe unnecessarily?) that we are about to ship yet another release that can't do basic 10gigE when sufficient memory exists. There was some debate with myself whether such a behavior changing MFC would be appropriate for a mid-stream stable release. I guess yes, though a number of people who currently set the parameters manually would have to remove their tuning settings. If you don't have time, then let me know and I'll see what I can do. Can you help me with with testing? Yes. Please give me your proposed changes and I'll stand up a machine and give feedback. -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: status of autotuning freebsd for 9.2
On 7/11/13 12:44 AM, Andre Oppermann wrote: On 08.07.2013 16:37, Andre Oppermann wrote: On 07.07.2013 20:24, Alfred Perlstein wrote: On 7/7/13 1:34 AM, Andre Oppermann wrote: Can you help me with with testing? Yes. Please give me your proposed changes and I'll stand up a machine and give feedback. http://people.freebsd.org/~andre/mfc-autotuning-20130708.diff Any feedback from testers on this? The MFC window is closing soon. This week has been pretty intense. I've sent out a request to the team to apply this patch to as many machines as possible. I'm going to talk to the rest of the FreeNAS team about it as well shortly. -- Alfred Perlstein VP Software Engineering, iXsystems ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: status of autotuning freebsd for 9.2
Andre, Peter what about i386? Ever since I touched this Peter has been worried about i386 and said we've broken the platform. I'm going to boot some vms but maybe we ought to get some testing from Peter on i386? Sent from my iPhone On Jul 11, 2013, at 5:47 AM, Andre Oppermann wrote: > On 11.07.2013 11:08, Steven Hartland wrote: >> - Original Message - From: "Andre Oppermann" >> >>> On 08.07.2013 16:37, Andre Oppermann wrote: >>>> On 07.07.2013 20:24, Alfred Perlstein wrote: >>>>> On 7/7/13 1:34 AM, Andre Oppermann wrote: >>>>>> Can you help me with with testing? >>>>> Yes. Please give me your proposed changes and I'll stand up a machine >>>>> and give feedback. >>>> >>>> http://people.freebsd.org/~andre/mfc-autotuning-20130708.diff >>> >>> Any feedback from testers on this? The MFC window is closing soon. >> >> Few things I've noticed most of which look like issues against the original >> patch and not the MFC but worth mentioning. >> >> 1. You've introduced a new tunable kern.maxmbufmem which is autosized but >> doesnt seem to be exposed via a sysctl so it looks like there is no way >> to determine what its actually set to? > > Good point. I've made it global and exposed as kern.ipc.maxmbufmem (RDTUN). > >> 2. There's a missmatch between the tuneable kern.ipc.nmbufs in tunable_mbinit >> and the sysctl kern.ipc.nmbuf i.e. no 's'. > > That's a typo, fixed. > >> 3. Should kern.maxmbufmem be kern.ipc.maxmbufmem to sit along side all of >> the other sysctls? > > Yes, see above. > >> 4. style issues: >> * @@ -178,11 +202,13 @@ >> ... >> if (newnmbjumbo9 > nmbjumbo9&& > > Thanks. All fixed in r253204. > >> Finally out of interest what made us arrive at the various defaults for each >> type as it looks like the ratios have changed? > > Before it was an arbitrary mess. Mbufs were not limited at all and the others > to some random multiple of maxusers with the net limit ending up at some > 25,000 > mbuf clusters by default. > > Now default overall limit is set at 50% of all available min(physical, > kmem_map) > memory to prevent mbufs from monopolizing kernel memory and leave some space > for > other kernel structures and buffers as well as user-space programs. It can be > raised to 3/4 of available memory by the tunable. > > 2K and 4K (page size) mbuf clusters can each go up to 25% of this mbuf memory. > The former is dominantly used on the receive path and the latter in the send > path. > 9K and 16K jumbo mbuf clusters can each go up to 12.5% of mbuf memory. They > are > only used in the receive path if large jumbo MTUs on a network interface are > active. > Both are special in that their memory is contiguous in KVM and physical > memory. > This becomes problematic due to memory fragmentation after a short amount of > heavy > system use. I hope to deprecate them for 10.0. Network interfaces should > use 4K > clusters instead and chain them together for larger packets. All modern NICs > support that. Only the early and limited DMA engines without scatter-gather > capabilities required contiguous physical memory. They are long gone by now. > > The limit for mbufs itselfs is 12.5% of mbuf memory and should be at least as > many as the sum of the cluster types. Each cluster requires an mbuf to which > it is attached. > > Two examples on the revised mbuf sizing limits: > > 1GB KVM: > 512MB limit for mbufs > 419,430 mbufs >65,536 2K mbuf clusters >32,768 4K mbuf clusters > 9,709 9K mbuf clusters > 5,461 16K mbuf clusters > > 16GB RAM: > 8GB limit for mbufs > 33,554,432 mbufs >1,048,576 2K mbuf clusters > 524,288 4K mbuf clusters > 155,344 9K mbuf clusters > 87,381 16K mbuf clusters > > These defaults should be sufficient for even the most demanding network loads. > > For additional information see: > > http://svnweb.freebsd.org/changeset/base/243631 > > -- > Andre > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: status of autotuning freebsd for 9.2
Andre, we have a number of people running this patch in the following configurations: 6-8GB ram + 10gigE ethernet using iozone over NFS. We're rolling it into the PCBSD rolling update as well. I'm thinking it makes sense to roll this into the 9.2 release to give us more scalability. -Alfred On 7/7/13 1:34 AM, Andre Oppermann wrote: On 07.07.2013 08:32, Alfred Perlstein wrote: Andre, Are you going to have time to MFC things from -current for auto-tuning -stable before 9.2? I simply ran out of time on Friday and MFCing such a big change requires more testing. I fear (maybe unnecessarily?) that we are about to ship yet another release that can't do basic 10gigE when sufficient memory exists. There was some debate with myself whether such a behavior changing MFC would be appropriate for a mid-stream stable release. I guess yes, though a number of people who currently set the parameters manually would have to remove their tuning settings. If you don't have time, then let me know and I'll see what I can do. Can you help me with with testing? -- Alfred Perlstein VP Software Engineering, iXsystems ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: status of autotuning freebsd for 9.2
On 7/15/13 5:44 AM, Andre Oppermann wrote: On 15.07.2013 08:38, Andre Oppermann wrote: On 13.07.2013 09:47, Alfred Perlstein wrote: Andre, we have a number of people running this patch in the following configurations: 6-8GB ram + 10gigE ethernet using iozone over NFS. As you haven't seen any problems yet I've asked RE to green light the MFC. RE has rejected the MFC out of fears for unexpected regressions. That is unfortunate. I guess re@ doesn't understand that FreeBSD 9.2 will be unusable out of the box for doing 10gigE for more than a few microseconds. Can we not just do my original patch that has the check for 64bit pointers before unscaling maxusers? That would be dirt simple and just work with minimal risk. -- Alfred Perlstein VP Software Engineering, iXsystems ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: status of autotuning freebsd for 9.2
On 7/15/13 7:13 AM, Glen Barber wrote: On Mon, Jul 15, 2013 at 05:48:40AM -0700, Alfred Perlstein wrote: On 7/15/13 5:44 AM, Andre Oppermann wrote: On 15.07.2013 08:38, Andre Oppermann wrote: On 13.07.2013 09:47, Alfred Perlstein wrote: Andre, we have a number of people running this patch in the following configurations: 6-8GB ram + 10gigE ethernet using iozone over NFS. As you haven't seen any problems yet I've asked RE to green light the MFC. RE has rejected the MFC out of fears for unexpected regressions. That is unfortunate. I guess re@ doesn't understand that FreeBSD 9.2 will be unusable out of the box for doing 10gigE for more than a few microseconds. Can we not just do my original patch that has the check for 64bit pointers before unscaling maxusers? That would be dirt simple and just work with minimal risk. IMHO, this is considered a new feature, and not a critical bug fix. re@ asked from the start of the code slush to avoid new features, and at this point, it is too late. It is not worth introducing possible regressions, which will only delay the 9.2-RELEASE. Glen OK, then we need a release notes telling people a sane value for nmbclusters and friends so that they know how to make 10gigE work. I'll poll my team for a value if someone else has one, that would be even better. -- Alfred Perlstein VP Software Engineering, iXsystems ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: status of autotuning freebsd for 9.2
Andre, I'm kind of bummed out this didn't make it into 9.2, I'm wondering can I commit this to 9-stable now? (or is it already in?) Would you do the honors? -Alfred On 7/8/13 7:37 AM, Andre Oppermann wrote: On 07.07.2013 20:24, Alfred Perlstein wrote: On 7/7/13 1:34 AM, Andre Oppermann wrote: Can you help me with with testing? Yes. Please give me your proposed changes and I'll stand up a machine and give feedback. http://people.freebsd.org/~andre/mfc-autotuning-20130708.diff This is functional bundle MFC of these original commits: MFC r242029 (alfred): Allow autotune maxusers > 384 on 64 bit machines. MFC r242847 (alfred): Allow maxusers to scale on machines with large address space. MFC r243631 (andre): Base the mbuf related limits on the available physical memory or kernel memory, whichever is lower. The overall mbuf related memory limit must be set so that mbufs (and clusters of various sizes) can't exhaust physical RAM or KVM. At the same time divorce maxfiles from maxusers and set maxfiles to physpages / 8 with a floor based on maxusers. This way busy servers can make use of the significantly increased mbuf limits with a much larger number of open sockets. MFC r243639 (andre): Complete r243631 by applying the remainder of kern_mbuf.c that got lost while merging into the commit tree. MFC r243668 (andre): Using a long is the wrong type to represent the realmem and maxmbufmem variable as they may overflow on i386/PAE and i386 with > 2GB RAM. MFC r243995, r243996, r243997 (pjd): Style cleanups, Make use of the fact that uma_zone_set_max(9) already returns actual limit set. MFC r244080 (andre): Prevent long type overflow of realmem calculation on ILP32 by forcing calculation to be in quad_t space. Fix style issue with second parameter to qmin(). MFC r245469 (alfred): Do not autotune ncallout to be greater than 18508. MFC r245575 (andre): Move the mbuf memory limit calculations from init_param2() to tunable_mbinit() where it is next to where it is used later. MFC r246207 (andre): Remove unused VM_MAX_AUTOTUNE_NMBCLUSTERS define. MFC r249843 (andre): Base the calculation of maxmbufmem in part on kmem_map size instead of kernel_map size to prevent kernel memory exhaustion by mbufs and a subsequent panic on physical page allocation failure. -- Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: status of autotuning freebsd for 9.2
On Aug 19, 2013, at 2:52 AM, Andre Oppermann wrote: > On 16.08.2013 10:29, Andre Oppermann wrote: >> On 16.08.2013 08:32, Alfred Perlstein wrote: >>> Andre, I'm kind of bummed out this didn't make it into 9.2, I'm wondering >>> can I commit this to >>> 9-stable now? (or is it already in?) >> >> It didn't make it because there was only sparse feedback after the >> call for testers. There were a couple of replies that it is being >> tested but no statements either way if it was good or not. Hence >> I erred on the side of caution and refrained from committing it. > > Revisiting the history of this after vacation absence actually shows > that we straddled the release code freeze deadline and you had provided > good testing feedback. However the MFC got rejected by RE on the fear > of introducing unknown regressions into the release process. > >>> Would you do the honors? >> >> Yes, will do later today. > > Committed to stable/9 as r254515. > > Let me know if there are any issues. Thanks Andre. Maybe we can do a point release/patch release with this in a few weeks for 9.2.1 or 9.2p1 because 9.2 out of the box performance is abysmal not only in networking but also disk as maxvnodes is clipped way too small even with plenty of ram. > > -- > Andre > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: status of autotuning freebsd for 9.2
Performance is bad for large memory requirements period. Vnodes and mbufs on a machine with 24gb ram is limited to the same amount as a machine with less than 4GB ram. This was fixed in head but not merged back in time. This results in poor out of the box performance on 10gige and servers with high vnode requirements. Sent from my iPhone On Aug 19, 2013, at 7:30 AM, Outback Dingo wrote: > > > > On Mon, Aug 19, 2013 at 10:26 AM, Alfred Perlstein > wrote: >> >> >> On Aug 19, 2013, at 2:52 AM, Andre Oppermann wrote: >> >> > On 16.08.2013 10:29, Andre Oppermann wrote: >> >> On 16.08.2013 08:32, Alfred Perlstein wrote: >> >>> Andre, I'm kind of bummed out this didn't make it into 9.2, I'm >> >>> wondering can I commit this to >> >>> 9-stable now? (or is it already in?) >> >> >> >> It didn't make it because there was only sparse feedback after the >> >> call for testers. There were a couple of replies that it is being >> >> tested but no statements either way if it was good or not. Hence >> >> I erred on the side of caution and refrained from committing it. >> > >> > Revisiting the history of this after vacation absence actually shows >> > that we straddled the release code freeze deadline and you had provided >> > good testing feedback. However the MFC got rejected by RE on the fear >> > of introducing unknown regressions into the release process. >> > >> >>> Would you do the honors? >> >> >> >> Yes, will do later today. >> > >> > Committed to stable/9 as r254515. >> > >> > Let me know if there are any issues. >> >> Thanks Andre. >> >> Maybe we can do a point release/patch release with this in a few weeks for >> 9.2.1 or 9.2p1 because 9.2 out of the box performance is abysmal not only in >> networking but also disk as maxvnodes is clipped way too small even with >> plenty of ram. > > So your saying, 9.2-RELEASE performance suffers degradation against say 9.1 > ?? are you referring to with this patch enabled? or just in general > 9.2-RELEASE > >> > >> > -- >> > Andre >> > >> ___ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: status of autotuning freebsd for 9.2
On 8/19/13 9:19 AM, Outback Dingo wrote: On Mon, Aug 19, 2013 at 12:17 PM, Andre Oppermann <mailto:an...@freebsd.org>> wrote: On 19.08.2013 18:09, Outback Dingo wrote: On Mon, Aug 19, 2013 at 12:05 PM, Alfred Perlstein mailto:alf...@ixsystems.com> <mailto:alf...@ixsystems.com <mailto:alf...@ixsystems.com>>> wrote: Performance is bad for large memory requirements period. Vnodes and mbufs on a machine with 24gb ram is limited to the same amount as a machine with less than 4GB ram. This was fixed in head but not merged back in time. is there a patch set i can backport on my own, do we know what revision(s) are required? Ive got boxes with 128GB and 10Gbe Intel... so im willing to do some work.. I have committed it to 9-stable this morning with r254515. No backporting necessary. Okay so wait, your saying the autotune commit this morning resolves Alfreds claims of abysmal performance in general, Yes. or is there other additional fixes in head aside from the autotune hes mentioning Well of course head has cool code, but this was a big problem. -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Looking for driver help
On 9/8/13 3:01 AM, Ryan McIntosh wrote: I sent an email out to freebsd-net without a response, soo this is my last attempt at getting any assistance here. I have a QLE3142-CU-CK (rebranded NetXen NX3-20GCU w/ NX3031 chipset) with no driver support in *BSD from anything I saw. I came across solaris's ntxn driver which seems to work appropriately but I have no use for solaris as a host o/s. Naturally I'll attempt at trying to get the driver to work myself, however I'm far from knowledgeable on the method to port a driver, but I won't say no to making it work after the response Qlogic gave me. Any insight/assistance/pointers would be helpful, including which mailing list might be best for this. Ryan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" What version of FreeBSD are you using? FreeBSD 10 has drivers for several qlogic 10gb cards. It would help to see output of "pciconf -l" on this machine as well knowing what version you are using. -- Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Looking for driver help
Hey Ryan, I really don't see much that I can help you with, giving FreeBSD current a shot might help, but after quite a bit of grep(1) I didn't seem to find support for this driver in -current so you may be SOL. -Alfred On 9/9/13 11:11 PM, Ryan McIntosh wrote: Presently 9.1-RELEASE but I believe I searched HEAD for the driver which came up with nothing. I'm all ears though if you find something. root@dev01:/root # pciconf -l hostb0@pci0:0:0:0: class=0x06 card=0xbc8015d9 chip=0x40038086 rev=0x20 hdr=0x00 pcib1@pci0:0:1:0: class=0x060400 card=0xbc8015d9 chip=0x40218086 rev=0x20 hdr=0x01 pcib2@pci0:0:5:0: class=0x060400 card=0xbc8015d9 chip=0x40258086 rev=0x20 hdr=0x01 pcib7@pci0:0:7:0: class=0x060400 card=0xbc8015d9 chip=0x40278086 rev=0x20 hdr=0x01 none0@pci0:0:15:0: class=0x088000 card=0xbc8015d9 chip=0x402f8086 rev=0x20 hdr=0x00 hostb1@pci0:0:16:0: class=0x06 card=0xbc8015d9 chip=0x40308086 rev=0x20 hdr=0x00 hostb2@pci0:0:16:1: class=0x06 card=0xbc8015d9 chip=0x40308086 rev=0x20 hdr=0x00 hostb3@pci0:0:16:2: class=0x06 card=0xbc8015d9 chip=0x40308086 rev=0x20 hdr=0x00 hostb4@pci0:0:16:3: class=0x06 card=0xbc8015d9 chip=0x40308086 rev=0x20 hdr=0x00 hostb5@pci0:0:16:4: class=0x06 card=0xbc8015d9 chip=0x40308086 rev=0x20 hdr=0x00 hostb6@pci0:0:17:0: class=0x06 card=0xbc8015d9 chip=0x40318086 rev=0x20 hdr=0x00 hostb7@pci0:0:21:0: class=0x06 card=0xbc8015d9 chip=0x40358086 rev=0x20 hdr=0x00 hostb8@pci0:0:21:1: class=0x06 card=0xbc8015d9 chip=0x40358086 rev=0x20 hdr=0x00 hostb9@pci0:0:22:0: class=0x06 card=0xbc8015d9 chip=0x40368086 rev=0x20 hdr=0x00 hostb10@pci0:0:22:1:class=0x06 card=0xbc8015d9 chip=0x40368086 rev=0x20 hdr=0x00 uhci0@pci0:0:29:0: class=0x0c0300 card=0xbc8015d9 chip=0x26888086 rev=0x09 hdr=0x00 uhci1@pci0:0:29:1: class=0x0c0300 card=0xbc8015d9 chip=0x26898086 rev=0x09 hdr=0x00 uhci2@pci0:0:29:2: class=0x0c0300 card=0xbc8015d9 chip=0x268a8086 rev=0x09 hdr=0x00 ehci0@pci0:0:29:7: class=0x0c0320 card=0xbc8015d9 chip=0x268c8086 rev=0x09 hdr=0x00 pcib8@pci0:0:30:0: class=0x060401 card=0xbc8015d9 chip=0x244e8086 rev=0xd9 hdr=0x01 isab0@pci0:0:31:0: class=0x060100 card=0xbc8015d9 chip=0x26708086 rev=0x09 hdr=0x00 ahci0@pci0:0:31:2: class=0x010601 card=0xbc8015d9 chip=0x26818086 rev=0x09 hdr=0x00 none1@pci0:0:31:3: class=0x0c0500 card=0xbc8015d9 chip=0x269b8086 rev=0x09 hdr=0x00 none2@pci0:1:0:0: class=0x02 card=0x01264040 chip=0x01004040 rev=0x42 hdr=0x00 none3@pci0:1:0:1: class=0x02 card=0x01264040 chip=0x01004040 rev=0x42 hdr=0x00 pcib3@pci0:3:0:0: class=0x060400 card=0xbc8015d9 chip=0x35008086 rev=0x01 hdr=0x01 pcib6@pci0:3:0:3: class=0x060400 card=0xbc8015d9 chip=0x350c8086 rev=0x01 hdr=0x01 pcib4@pci0:4:0:0: class=0x060400 card=0xbc8015d9 chip=0x35108086 rev=0x01 hdr=0x01 pcib5@pci0:4:2:0: class=0x060400 card=0xbc8015d9 chip=0x35188086 rev=0x01 hdr=0x01 em0@pci0:6:0:0: class=0x02 card=0x109615d9 chip=0x10968086 rev=0x01 hdr=0x00 em1@pci0:6:0:1: class=0x02 card=0x109615d9 chip=0x10968086 rev=0x01 hdr=0x00 none4@pci0:8:0:0: class=0x0c0600 card=0x627415b3 chip=0x627415b3 rev=0x20 hdr=0x00 vgapci0@pci0:9:1:0: class=0x03 card=0xbc8015d9 chip=0x515e1002 rev=0x02 hdr=0x00 - snip from pciconf -lv for the card in question (its a dual port) - none2@pci0:1:0:0: class=0x02 card=0x01264040 chip=0x01004040 rev=0x42 hdr=0x00 vendor = 'NetXen Incorporated' device = 'NX3031 Multifunction 1/10-Gigabit Server Adapter' class = network subclass = ethernet none3@pci0:1:0:1: class=0x02 card=0x01264040 chip=0x01004040 rev=0x42 hdr=0x00 vendor = 'NetXen Incorporated' device = 'NX3031 Multifunction 1/10-Gigabit Server Adapter' class = network subclass = ethernet - end snip - root@dev01:/root # uname -a FreeBSD dev01 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 root@dev01:/root # I'll upgrade to whatever if there's a chance of a driver already existing but so far I've found nothing. Thanks and sorry for the delay. Ryan On Sun, Sep 8, 2013 at 11:37 AM, Alfred Perlstein wrote: On 9/8/13 3:01 AM, Ryan McIntosh wrote: I sent an email out to freebsd-net without a response, soo this is my last attempt at getting any assistance here. I have a QLE3142-CU-CK (rebranded NetXen NX3-20GCU w/ NX3031 chipset) with no driver support in *BSD from anything I saw. I came across solaris's ntxn driver which seems to work appropriately but I have no use for solaris as a host o/s. Naturally I'll attempt at trying to get the driver to work myself, however I'm far from knowledgeable on the method to port a driver, but I won't say no
Re: 9.2-PRE: switch off that stupid "Nakatomi Socrates"
On 9/27/13 7:14 PM, Freddie Cash wrote: On Sep 27, 2013 5:05 PM, "grenville armitage" wrote: On 09/28/2013 08:06, David Demelier wrote: [..] Also in the future you can just forgot that crappy ideas as you can see, nobody liked it. I beg to differ. I know it's not a poll, but myself and the 5 people in my office all thought it was awesome, and will be leaving it enabled for as long as 9.2 is installed on our servers. That definitely puts it above "nobody liked it". Lighten up. Go outside, take a deep breath of fresh air. Move on. Life is too short for this. :) Agreed. When it stop being fun, then it will see a decline in participation. -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: DDoS in FreeBSD 6.2-STABLE And Problen With The Clock
* Mike Tancsa <[EMAIL PROTECTED]> [070611 13:58] wrote: > At 04:54 PM 6/11/2007, Chuck Swiger wrote: > this unfortunate event by reordering instructions if needed, but if > >you wrote your own assembly, you could in fact do a hardware DDoS if > >you weren't careful. :-) > > Hi, > I thought DDoS = _Distributed_ Denial of Service where > multiple attacking devices gang up to attack a host. Is your example > not just a plain old Denial of Service (DoS) ? Well it takes 3 execution pipelines... -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unix domain socket leak in 6-STABLE
* Alexandre Biancalana <[EMAIL PROTECTED]> [070613 12:40] wrote: > On 6/13/07, Ulrich Spoerlein <[EMAIL PROTECTED]> wrote: > > > >Hi, > > > >as you are aware, there is a unix domain socket leak in 6-STABLE, > >which AFAIK is not yet fully fixed. > > > >I wanted to ask about the status or some possible fixes, as I know a > >way to reproduce the problem in a matter of minutes. > > > >We are running Cyrus and Postfix with the user DB in OpenLDAP. When > >using ldapi://%2fvar%2frun%2fopenldap%2fldapi/ as a connection URL for > >both Postfix' user lookup and cyrus' user lookup (via nss_ldap). slapd > >quickly runs out of filedescriptors as it is not closing any unix > >sockets (judging by ever increasing lsof output). > > > >Using TCP sockets is just fine. If there are patches I could try, > >don't hesitate to send them to me. > > > > Ohhh !! I had exactly the same problem last night. > > After change the line of /usr/local/etc/nss_ldap.conf from > > uri ldap://127.0.0.1/ > > to > > uri ldapi://%2fvar%2frun%2fopenldap%2fldapi/ > > The open sockets off this machine started to increase until reach maxfiles > limit and show messages like this: > > kernel: kern.maxfiles limit exceeded by uid 65534, please see tuning(7). > > and slapd stopped to accept new connections. > > During the day (production hours) the number off connections (using TCP > sockets) to OpenLDAP range from 16 to 45. Last night after change the type > connection to Unix Domain Socket the number of connections raised rapidly to > about 4000. I get this numbers using sockstat -c command. > > This machine is our Samba PDC, running 6.2-STABLE compile in Apr 5 13:33:50 > using samba-3.0.24,1, nss_ldap-1.255, openldap-server-2.3.34_1 > > I can provide more information if need. > > Any Advises/Patches ? I would advise running "truss" or ktrace against the process to see if it's actually attempting to close the descriptor. this would explain if the leak is in the application, or maybe libc/kernel. -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about 'top' values on memory usage
* William LeFebvre <[EMAIL PROTECTED]> [071015 06:49] wrote: > > Unfortunately, freebsd does not appear to track the amount of shared > virtual memory for each process. It could be obtained by walking > through all the pages in a process's vm map, but that would really slow > top down. I don't know of any freebsd utility that would give that > information for an individual process. But hey, if it's out there > somewhere where it is easy to grab, I would be very happy to add it to top. Or this could be properly accounted for when the map is updated? > Personally, based on my experience, I would be more concerned with the > amount of available cpu cycles than memory. In my experience, once you > run out of idle time on a web server you have exceeded its capacity to > serve pages. In that situation it doesn't matter how many httpd > processes there are, the system is still not able to keep up with > demand. And that will probably happen before the system starts > thrashing from limited memory. Bill, I would have to differ with you based on personal experience, I've almost never run out of cpu on a webserver, typically it's the RAM that gets blown out. Once the server starts to page, you typically wind up with a cascade failure and the box just goes ... belly up. I would worry about ram. Typically the best way to scale a box is to load it and keep running more httpds until "something happens" or you reach enough httpd to service your load, at that point if "something happens" (ie the box tanks) you add more ram. -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
LOCK_PROFILING in -stable
Hey guys, I have LOCK_PROFILING done for a product based on FreeBSD-6, this means I can relatively easily backport LOCK_PROFILING from FreeBSD-7 to FreeBSD-6. Do we want this? I'd like to do it if people want it. -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/104406: [ufs] Processes get stuck in "ufs" state under persistent CPU load
* Oleg Derevenetz <[EMAIL PROTECTED]> [071019 08:17] wrote: > Hi all, > > Can anyone take a look on PR kern/104406 ? I got repeatable hang situation, > but I can't obtain a kernel dump to get result of all show commands from > here: > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html > > After my break to debugger using Ctrl+Alt+Esc sequence and entering a > "panic" command kernel does not wrote a kernel dump but seems to hang. Can > anyone describe how to obtain a kernel dump in this situation, or at least > say - which output of show commands need in first place to debug this ? > Output of all suggested commands is huge and I afraid of making mistake > when carrying this output from screen to list of paper and back :-) Oleg, one thing you can do to make this less painful is to run your machine's console over serial port. First get a crossover serial cable, make sure it works from one box to another, it should be easy to run "tip com1" on both boxes to ensure that it works. Then you just need to add console=comconsole to /boot/loader.conf and your box's console should come over serial. Then on the machine watching the console, you can just do this: % script Script started, output file is typescript % tip com1 ...do ddb stuff now... ...stop tip % exit now you should have everything logged into a file called "typescript" should save you a big headache. As far as getting a dump from ddb, try this: ddb> call doadump I'm completely at a loss why this isn't a base ddb command "dump" but whatever... :) -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/104406: [ufs] Processes get stuck in "ufs" state underpersistent CPU load
* Oleg Derevenetz <[EMAIL PROTECTED]> [071020 09:58] wrote: > > > Can anyone take a look on PR kern/104406 ? I got repeatable hang > situation, > > > but I can't obtain a kernel dump to get result of all show commands from > > > here: > > > > > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html > > > > > > After my break to debugger using Ctrl+Alt+Esc sequence and entering a > > > "panic" command kernel does not wrote a kernel dump but seems to hang. > Can > > > anyone describe how to obtain a kernel dump in this situation, or at > least > > > say - which output of show commands need in first place to debug this ? > > > Output of all suggested commands is huge and I afraid of making mistake > > > when carrying this output from screen to list of paper and back :-) > > > > Oleg, one thing you can do to make this less painful is to > > run your machine's console over serial port. > > > > First get a crossover serial cable, make sure it works from one > > box to another, it should be easy to run "tip com1" on both > > boxes to ensure that it works. > > > > Then you just need to add console=comconsole to /boot/loader.conf > > and your box's console should come over serial. > > > > Then on the machine watching the console, you can just do this: > > > > % script > > Script started, output file is typescript > > % tip com1 > > ...do ddb stuff now... > > ...stop tip > > % exit > > > > now you should have everything logged into a file called "typescript" > > should save you a big headache. > > Thanks, I'll try it in the monday morning. > > > As far as getting a dump from ddb, try this: > > > > ddb> call doadump > > > > I'm completely at a loss why this isn't a base ddb command "dump" > > but whatever... :) > > Unfortunately, this doesn't work too. I called duty personnel in this > datacenter and asked them to do this, and person on duty tells me that after > he enters this command something like that arrives on monitor: > > db> call doadump > Dumping 3072 MB > > Dump aborted error I/O > Dump failed. (Error 5) Hmnmm, that seems like you might be having a hardware problem, what disk device do you have? Have you also enabled kernel dumps via /etc/rc.conf:dumpdev= ? -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: LOCK_PROFILING in -stable
* Robert Watson <[EMAIL PROTECTED]> [071020 10:21] wrote: > > On Sat, 20 Oct 2007, Kris Kennaway wrote: > > >Alfred Perlstein wrote: > >>Hey guys, I have LOCK_PROFILING done for a product based on FreeBSD-6, > >>this means I can relatively easily backport LOCK_PROFILING from FreeBSD-7 > >>to FreeBSD-6. > >> > >>Do we want this? > >> > >>I'd like to do it if people want it. > > > >I think it should be done, performance is a lot better than the old 6.x > >version and it also adds another very useful performance metric (time > >spent waiting for the lock). The only concern is that it doesn't break > >ABI support when not compiled in, but I'm pretty sure you've already told > >me this is OK. Thanks for looking at this. > > This is my feeling also -- I would consider ABI breakage a show stopper for > 6.x, but feel otherwise that the new code is much more mature and capable > and would be quite beneficial to people building appliances and related > products on 6.x. You might check with Attilio about whether there are any > remaining outstanding issues that need to be resolved first, and make sure > to send a heads up out on stable@ and put a note in UPDATING that the > option and details have changed. I still get confused as to the meaning of this... It only breaks ABI when it's enabled. I think that is OK, right? -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: LOCK_PROFILING in -stable
* Kris Kennaway <[EMAIL PROTECTED]> [071021 01:56] wrote: > Alfred Perlstein wrote: > >* Robert Watson <[EMAIL PROTECTED]> [071020 10:21] wrote: > >>On Sat, 20 Oct 2007, Kris Kennaway wrote: > >> > >>>Alfred Perlstein wrote: > >>>>Hey guys, I have LOCK_PROFILING done for a product based on FreeBSD-6, > >>>>this means I can relatively easily backport LOCK_PROFILING from > >>>>FreeBSD-7 to FreeBSD-6. > >>>> > >>>>Do we want this? > >>>> > >>>>I'd like to do it if people want it. > >>>I think it should be done, performance is a lot better than the old 6.x > >>>version and it also adds another very useful performance metric (time > >>>spent waiting for the lock). The only concern is that it doesn't break > >>>ABI support when not compiled in, but I'm pretty sure you've already > >>>told me this is OK. Thanks for looking at this. > >>This is my feeling also -- I would consider ABI breakage a show stopper > >>for 6.x, but feel otherwise that the new code is much more mature and > >>capable and would be quite beneficial to people building appliances and > >>related products on 6.x. You might check with Attilio about whether there > >>are any remaining outstanding issues that need to be resolved first, and > >>make sure to send a heads up out on stable@ and put a note in UPDATING > >>that the option and details have changed. > > > >I still get confused as to the meaning of this... > > > >It only breaks ABI when it's enabled. > > > >I think that is OK, right? > > > > Yes, that is fine. Other existing debugging options also break ABI when > enabled, so it's OK. OK, I should have something over the next couple of weeks. -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: LOCK_PROFILING in -stable
* Skip Ford <[EMAIL PROTECTED]> [071024 10:47] wrote:
> Robert Watson wrote:
> > On Sat, 20 Oct 2007, Alfred Perlstein wrote:
> >
> > >>This is my feeling also -- I would consider ABI breakage a show stopper
> > >>for 6.x, but feel otherwise that the new code is much more mature and
> > >>capable and would be quite beneficial to people building appliances and
> > >>related products on 6.x. You might check with Attilio about whether there
> > >>are any remaining outstanding issues that need to be resolved first, and
> > >>make sure to send a heads up out on stable@ and put a note in UPDATING
> > >>that the option and details have changed.
> > >
> > >I still get confused as to the meaning of this...
> > >
> > >It only breaks ABI when it's enabled.
> > >
> > >I think that is OK, right?
> >
> > As we're eliminating MUTEX_PROFILING and replacing it with LOCK_PROFILING,
> > I think it is OK that the ABI for one differs from the other as long as the
> > base kernel ABI remains static. I.e., this seems OK to me also.
>
> If -stable will have LOCK_PROFILING, it'd be really nice to have
> it compatible with a standard world in some way, even if just with
> a makefile hack that builds netstat_lp(1) in addition to
> netstat(1) (and other utilities.)
>
> One can easily boot a diskless email, web, or name server into
> kernels with other debug-type options without maintaining
> multiple worlds. One might want to run a LOCK_PROFILING stable
> kernel on a diskless email server for a period of time, but
> that will require either a matching world, or putting up with
> breakage for that period of time, neither of which is a fair
> expectation in a stable environment, IMO.
>
> I can maintain local makefile hacks for production if somebody
> with some makefile foo gets me started.
This is really beyond the scope of what I have time for however
I can say that probably all that is needed is a Makefile that
uses something like a makefile in a directory next to netstat
called netstat_lp and either duplicate the makefile and add:
SRCDIR= ${.CURDIR}/netstat
CFLAGS+=-DLOCKPROFILING
or like make the netstat directory have a "Makefile.netstat.inc" in it
with the common parts and have both Makefiles for netstat and netstat_lp
include it. in fact you could hack netstat to exec netstat_lp if the
sysctls indicating lockprofiling is enabled... e. :)
good luck!
--
- Alfred Perlstein
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rrdtool performance tuning (fwd)
* Dmitry Morozovsky <[EMAIL PROTECTED]> [071029 12:44] wrote: > > [hmm, after thinking a bit I decided it would be more appropriate here, in > [EMAIL PROTECTED] > > Dear colleagues, > > any hints to tune rrdtool with ~30k rrd files (approx 2k target devices)? > > machine is mostly IO-bound, showing 100% disk load with 8 or sometimes even 3 > mB/s, 300-400 tps (it's 2 SATA300 disks in gmirror) More ram? Turn off atime? Hash the data files into multiple directories to avoid having 2k files in one dir. Not sure how rrd tool works internally, but it might make sense to see if you can use some layering library to force it to cache some open files per process or something. giving a better synopsis on how rrd records data could help us help you. -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rrdtool performance tuning (fwd)
* Dmitry Morozovsky <[EMAIL PROTECTED]> [071030 02:30] wrote: > On Mon, 29 Oct 2007, Alfred Perlstein wrote: > > AP> * Dmitry Morozovsky <[EMAIL PROTECTED]> [071029 12:44] wrote: > AP> > > AP> > [hmm, after thinking a bit I decided it would be more appropriate here, > in > AP> > [EMAIL PROTECTED] > AP> > > AP> > Dear colleagues, > AP> > > AP> > any hints to tune rrdtool with ~30k rrd files (approx 2k target > devices)? > AP> > > AP> > machine is mostly IO-bound, showing 100% disk load with 8 or sometimes > even 3 > AP> > mB/s, 300-400 tps (it's 2 SATA300 disks in gmirror) > AP> > AP> More ram? > > Already 2G, mostly inactive/free. > > AP> > AP> Turn off atime? > > For sure, and even tried to move rrd data to smaller UFS2 - same result. > > AP> Hash the data files into multiple directories to avoid having 2k files > AP> in one dir. > > Hmm, I thought 2k is not so much, especially where UFSDIRHASH is in place... > > AP> Not sure how rrd tool works internally, but it might make sense > AP> to see if you can use some layering library to force it to cache > AP> some open files per process or something. > > It seems it using a lot of mmap... My try hacking the code and adding MAP_NOSYNC to the call to mmap(2). Try hacking the code to keep the file mapped instead of open/closing it on each access. -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD based bandwidth manager, traffic shaper
* Steffen Schumacher <[EMAIL PROTECTED]> [071107 07:33] wrote: > On 07.11.2007 23:18:40 +0800, Balgansuren Batsukh wrote: > > Which product of Juniper doing such job? > > > > Most juniper products (JUNOS) is based on FreeBSD, however they > are typically high-end boxes that costs lots of $.. Its hardware > based forwarding, with a FreeBSD based control-plane. Whoa whoa... it's true that Juniper has some of the best top end networking kit, but now there is a bunch of Juniper products that are for the mid range and even "SoHo" (sp?). You can have a look at all the products here: http://www.juniper.net/products_and_services/index.html?from=HomePage-Header-to-ProductsServices -Alfred > > /[EMAIL PROTECTED] > > > Balgaa > > > > - Original Message - From: "Oleg Derevenetz" <[EMAIL PROTECTED]> > > To: "Balgansuren Batsukh" <[EMAIL PROTECTED]>; > > Cc: <[EMAIL PROTECTED]> > > Sent: Wednesday, November 07, 2007 11:05 PM > > Subject: Re: FreeBSD based bandwidth manager, traffic shaper > > > > > >>> I am looking high performance bandwidth manager, traffic shaper for IP > >>> core network to configure leased line, xDSL, Ethernet, GPON/EPON, > >>> wireless subscribers. > >>> > >>> Is there any FreeBSD based solution? > >> > >> Juniper :-) > >> > >> -- > >> Oleg Derevenetz <[EMAIL PROTECTED]> OOD3-RIPE > >> Phone: +7 4732 539880 > >> Fax: +7 4732 531415 http://www.vsi.ru > >> CenterTelecom Voronezh ISPhttp://isp.vsi.ru > >> > >> ___ > >> freebsd-stable@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >> To unsubscribe, send any mail to "[EMAIL PROTECTED]" > >> > >> > >> > >> > >> -- > >> No virus found in this incoming message. > >> Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: > >> 269.15.23/1114 - Release Date: 11/6/2007 8:05 PM > >> > > > > ___ > > [EMAIL PROTECTED] mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-isp > > 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]" -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: impressive buildworld time
* Kris Kennaway <[EMAIL PROTECTED]> [071114 12:07] wrote: > Jeremy Chadwick wrote: > >On Wed, Nov 14, 2007 at 05:56:16PM +0100, Claus Guttesen wrote: > >>Hi. > >> > >>Just installed a new DL360 with 8 cores at 2.33 Ghz and 8 GB ram and > >>15K rpm sas-disks. When I installed the beta2 from cd 'make -j 9 > >>buildworld' took approx. 20 min. After a recompile of userland and > >>kernel and switch to ULE it went down to: > >> > >>>>>World build completed on Wed Nov 14 17:44:08 CET 2007 > >>-- > >>3552.428u 1298.485s 16:15.89 497.0% 6156+1325k 25257+8117io 3368pf+0w > >> > >>Not very scientific and only one run but none the less my fastest > >>buildworld time ever on FreeBSD. :-) > > > >Congrats! :-) 16 minutes is really impressive... > > > >Our 2.13GHz C2D 6420 boxes w/ 2GB RAM can do this in about 19 minutes > >flat (using ULE scheduler). Disks are 7200rpm SATA300. make -j2 used; > >and this was RELENG_6. > > > >The reason I like the buildworld "benchmark" is because it's a fairly > >real-world test and not something specific to just one piece of how > >a machine behaves (e.g. memory benchmark, disk benchmark, CPU benchmark, > >etc.). > > It's not a good SMP benchmark though, because large parts are entirely > single-threaded, and other large parts do not parallelize beyond more > than a couple of CPUs. Also it is entirely incomparable between > different versions of the source tree. I think an interesting SoC project would be to write something that would be able to sort of glue together all the makefiles under directories and teach make how to build a dep graph such that for example all of usr.bin could be built in parallel. We'd need some syntactic sugar to explicitly state which recurive makes could be run in parallel and hopefully figure out a way to avoid actually forking make(1) but instead do something like maintain multiple copies of the state. -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Some processes stay active after killing its PID
* Roland Smith <[EMAIL PROTECTED]> [071127 11:59] wrote: > On Tue, Nov 27, 2007 at 01:24:56PM -0600, Stephen Montgomery-Smith wrote: > > > > > > On Tue, 27 Nov 2007, Honza Holakovsky wrote: > > > >> Well, didn't know that, "/bin/kill -9 wdfs_PID" works, great > >> > >> Thanks a lot, after your advice I read an article about csh built-in > >> commands, never heard of it from any fbsd handbook... > > > > I am completely baffled why this worked. Why would /bin/kill -9 work when > > the built in csh kill -9 wouldn't? > > According to the manual page for the built-in kill command, it > recognizes 'kill -s 9', but not 'kill -9'. Is it too late to remove csh from the base system? :D -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: msdosfs performance unbearable
* Dominic Fandrey <[EMAIL PROTECTED]> [071127 00:47] wrote: > ufs: > $ time -h tar -xf php_manual_en.tar.gz > 3.31s real 0.43s user 0.51s sys > > > msdosfs: > I stopped that after 45 minutes. > > Also the system becomes barely responsive. The mouse moves extremely sloppy > and a key-press often causes 2 characters to be printed. Mouse-clicks are > either lost or take more than 10 seconds to be recognized. Which version of FreeBSD? can you get more information about the FAT system? -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB memory stick as dump device
* V??clav Haisman <[EMAIL PROTECTED]> [071128 01:11] wrote: > Hi, > is it possible to use USB memory stick as dump device for panic dumps? I have > a 6.2 box with gmirrors and no non-gmirror disks. I have never managed to get > dumps work onto the swap partition on the mirror. So...is it possible to use > USB stick as a dump device or should I not even try that? > > -- > VH > I don't think that will work currently. -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: msdosfs performance unbearable
* Dominic Fandrey <[EMAIL PROTECTED]> [071128 01:04] wrote:
> Alfred Perlstein wrote:
> > * Dominic Fandrey <[EMAIL PROTECTED]> [071127 00:47] wrote:
> >> ufs:
> >> $ time -h tar -xf php_manual_en.tar.gz
> >>3.31s real 0.43s user 0.51s sys
> >>
> >>
> >> msdosfs:
> >> I stopped that after 45 minutes.
> >>
> >> Also the system becomes barely responsive. The mouse moves extremely sloppy
> >> and a key-press often causes 2 characters to be printed. Mouse-clicks are
> >> either lost or take more than 10 seconds to be recognized.
> >
> > Which version of FreeBSD? can you get more information about the
> > FAT system?
>
> Csupped and build yesterday:
> $ uname -a
> FreeBSD mobileKamikaze.norad 7.0-BETA3 FreeBSD 7.0-BETA3 #0: Tue Nov 27
> 20:53:17 CET 2007
> [EMAIL PROTECTED]:/usr/obj/TPR40-7/i386/usr/src/sys/TPR40-7 i386
>
> Partition information:
> /dev/ad0s3 on /mnt/msdos/software (msdosfs, local)
> /dev/ad0s4 on /mnt/msdos/vault (msdosfs, local)
>
> Actually I don't know any way of aquiring (<= how is this spelled?) useful
> data about Fat32 partitions in FreeBSD.
Ok that's fine, I was wondering is the MSDOS filesystem over USB
or something? Is the UFS and MSDOSFS on the same media?
-Alfred
>
> Anyway:
> mobileKamikaze$ strace -o ~/msdos.trace tar -xf php_manual_en.tar.gz
> ^C
>
> And here is the beginning of the trace:
> execve(0xbfbfe608, [0xbfbfeaf4], [/* 0 vars */]) = 0
> __sysctl([...], 0xbfbfe86c, 0xbfbfe870, NULL, 0) = 0
> syscall_477(0, 0x110, 0x3, 0x1000, 0x, 0, 0) = 0x2808
> munmap(0x2808, 272) = 0
> __sysctl([...], 0x2807c87c, 0xbfbfe8d0, NULL, 0) = 0
> syscall_477(0, 0x8000, 0x3, 0x1002, 0x, 0, 0) = 0x2808
> issetugid(0x2807598c) = 0
> open("/etc/libmap.conf", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFDIR|0543, st_size=18446253021508551011, ...}) = 0
> read(3, "", 4096) = 0
> close(3)= 0
> open("/var/run/ld-elf.so.hints", O_RDONLY) = 3
> read(3, "f/rtld.c:3297\n\0\0%s: Unexpected "..., 128) = 128
> syscall_478(0x3, 0x80, 0, 0)= 0x80
> read(3, "/lib:/usr/lib:/usr/lib/compat:/u"..., 274) = 274
> close(3)= 0
> access("/lib/libarchive.so.4", F_OK)= -1 ENOENT (No such file or
> directory)
> access("/usr/lib/libarchive.so.4", F_OK) = 0
> open("/usr/lib/libarchive.so.4", O_RDONLY) = 3
> fstat(3, {st_mode=0, st_size=0, ...}) = 0
> read(3, "\177ELF\1\1\1\t\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0pP\0\000"..., 4096) =
> 4096
> syscall_477(0, 0x25000, 0x5, 0x20002, 0x3, 0, 0) = 0x28088000
> mprotect(0x280aa000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
> mprotect(0x280aa000, 4096, PROT_READ|PROT_EXEC) = 0
> syscall_477(0x280ab000, 0x1000, 0x3, 0x12, 0x3, 0x22000, 0) = 0x280ab000
> syscall_477(0x280ac000, 0x1000, 0x3, 0x1012, 0x, 0, 0) = 0x280ac000
> close(3)= 0
> access("/lib/libbz2.so.3", F_OK)= -1 ENOENT (No such file or
> directory)
> access("/usr/lib/libbz2.so.3", F_OK)= 0
> open("/usr/lib/libbz2.so.3", O_RDONLY) = 3
> fstat(3, {st_mode=0, st_size=0, ...}) = 0
> read(3, "\177ELF\1\1\1\t\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\21\0\000"..., 4096)
> = 4096
> syscall_477(0, 0x11000, 0x5, 0x20002, 0x3, 0, 0) = 0x280ad000
> mprotect(0x280bc000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
> mprotect(0x280bc000, 4096, PROT_READ|PROT_EXEC) = 0
> syscall_477(0x280bd000, 0x1000, 0x3, 0x12, 0x3, 0xf000, 0) = 0x280bd000
> close(3)= 0
> access("/lib/libz.so.4", F_OK) = 0
> open("/lib/libz.so.4", O_RDONLY)= 3
> fstat(3, {st_mode=0, st_size=0, ...}) = 0
> read(3, "\177ELF\1\1\1\t\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\27"..., 4096) =
> 4096
> syscall_477(0, 0x12000, 0x5, 0x20002, 0x3, 0, 0) = 0x280be000
> mprotect(0x280ce000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
> mprotect(0x280ce000, 4096, PROT_READ|PROT_EXEC) = 0
> syscall_477(0x280cf000, 0x1000, 0x3, 0x12, 0x3, 0x11000, 0) = 0x280cf000
> close(3)= 0
> access("/lib/libc.so.7", F_OK) = 0
> open("/lib/libc.so.7", O_RDONLY)= 3
> fstat(3, {st_mode=0, st_size=0, ...}) = 0
> read(3, "\177ELF\1\1\1\t\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\327\1"..., 4096) =
> 4096
> syscall_477(0, 0xfd000, 0x5, 0x20002, 0x3, 0, 0) = 0x280d
> mprotect(0x281b2000, 4096,
Re: Packet loss every 30.999 seconds
* David G Lawrence <[EMAIL PROTECTED]> [071219 09:12] wrote: > > >Try it with "find / -type f >/dev/null" to duplicate the problem > > >almost > > >instantly. > > > > I was able to verify last night that (cd /; tar -cpf -) > all.tar would > > trigger the problem. I'm working getting a test running with > > David's ffs_sync() workaround now, adding a few counters there should > > get this narrowed down a little more. > >Unfortunately, the version of the patch that I sent out isn't going to > help your problem. It needs to yield at the top of the loop, but vp isn't > necessarily valid after the wakeup from the msleep. That's a problem that > I'm having trouble figuring out a solution to - the solutions that come > to mind will all significantly increase the overhead of the loop. >As a very inadequate work-around, you might consider lowering > kern.maxvnodes to something like 2 - that might be low enough to > not trigger the problem, but also be high enough to not significantly > affect system I/O performance. I apologize for not reading the code as I am swamped, but a technique that Matt Dillon used for bufs might work here. Can you use a placeholder vnode as a place to restart the scan? you might have to mark it special so that other threads/things (getnewvnode()?) don't molest it, but it can provide for a convenient restart point. -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Packet loss every 30.999 seconds
* David G Lawrence <[EMAIL PROTECTED]> [071221 15:42] wrote: > > >Unfortunately, the version of the patch that I sent out isn't going to > > > help your problem. It needs to yield at the top of the loop, but vp isn't > > > necessarily valid after the wakeup from the msleep. That's a problem that > > > I'm having trouble figuring out a solution to - the solutions that come > > > to mind will all significantly increase the overhead of the loop. > > > > I apologize for not reading the code as I am swamped, but a technique > > that Matt Dillon used for bufs might work here. > > > > Can you use a placeholder vnode as a place to restart the scan? > > you might have to mark it special so that other threads/things > > (getnewvnode()?) don't molest it, but it can provide for a convenient > > restart point. > >That was one of the solutions that I considered and rejected since it > would significantly increase the overhead of the loop. >The solution provided by Kostik Belousov that uses uio_yield looks like > a find solution. I intend to try it out on some servers RSN. Out of curiosity's sake, why would it make the loop slower? one would only add the placeholder when yielding, not for every iteration. -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Packet loss every 30.999 seconds
* David G Lawrence <[EMAIL PROTECTED]> [071221 23:31] wrote: > > > > Can you use a placeholder vnode as a place to restart the scan? > > > > you might have to mark it special so that other threads/things > > > > (getnewvnode()?) don't molest it, but it can provide for a convenient > > > > restart point. > > > > > >That was one of the solutions that I considered and rejected since it > > > would significantly increase the overhead of the loop. > > >The solution provided by Kostik Belousov that uses uio_yield looks like > > > a find solution. I intend to try it out on some servers RSN. > > > > Out of curiosity's sake, why would it make the loop slower? one > > would only add the placeholder when yielding, not for every iteration. > >Actually, I misread your suggestion and was thinking marker flag, > rather than placeholder vnode. Sorry about that. The current code > actually already uses a marker vnode. It is hidden and obfuscated in > the MNT_VNODE_FOREACH macro, further hidden in the __mnt_vnode_first/next > functions, so it should be safe from vnode reclaimation/free problems. That level of obscuring is a bit worrysome. Yes, I did mean placeholder vnode. Even so, is it of utility or not? Or is it already being used and I'm missing something and should just "utsl" at this point? -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A very big Thank You for the inclusion of ZFS
I'm in no way responsible for ZFS, but I wanted to let you know that emails like this are very very awesome to get. Thank you for the kind words, it does make FreeBSD development worthwhile when someone takes the time to send in kind words. -Alfred * Freddie Cash [090526 12:35] wrote: > I just wanted to send out a very big THANK YOU to all those who have > had a hand in bringing ZFS to FreeBSD. You've done a wonderful job. > > With the release of FreeBSD 7.2, things have improved to the point > where I can't crash our storage servers anymore (and I've tried all > the things that would crash 7.0 and 7.1). Bravo! > > What impressed me even more, though, was just how performant a > multiple raidz2 pool could be. During a normal backup run (rsync of > 105 servers each night), we graph sustained reads of 80 MBytes/sec and > writes of 50 MBytes/sec (via snmpd). Nothing too spectacular, but > still quite nice. Didn't realise just how much of a bottleneck the > remote network connections are, though. > > Doing a local iozone benchmark, using a command-line someone posted > online as known to crash ZFS on FreeBSD 7.0, I was able to get just > under 350 MBytes/sec sustained write throughput (as shown by snmpd) > with over 15 MBytes/sec per drive (as shown by gstat). Fiddling with > the iozone options, I was able to push that to over 400 MBytes/sec > sustained write with just shy of 20 MBytes/sec per drive. And CPU > utilisation never went above 40% per core. System never crashed, > hung, locked up, of even seemed slow while connected via SSH. > > While those numbers may not seem all that high to some people, for us, > those are amazing!! :) (We've never used SCSI, or RAID0, or RAID10, > or FibreChannel, or any of the other fancy storage stuff that gives > uber-high stats.) This gives us hope for just how many remote sites > we'll be able to backup to these storage servers (ie still lots of > headroom on the storage side, just need to boost the network side of > things). > > For the curious, the hardware is: > Tyan h2000M motherboard > 2x dual-core AMD Opteron 2220 CPUs at 2.8 GHz > 8 GB ECC DDR2-667 SDRAM > 3Ware 9650SE-12ML PCIe RAID controller > 3Ware 9550SXU-12ML PCI-X RAID controller (64-bit/133 MHz slot) > 24x 500 GB WD SATA2 harddrives (12 per controller, configured as > Single Drives) > 4-port Intel Pro/1000MT PCIe NIC > > The software is: > 64-bit FreeBSD 7.2-RELEASE > no kmem tuning > ZFS ARC limited to 1 GB via /boot/loader.conf > test filesystem has no compression and no atime set > > Pool configuration: > 3 raidz2 vdevs of 8 drives each (1 vdev uses 4-drives from each RAID > controller, the other 2 vdevs use 8 drives from 1 controller) > > iozone commands: > iozone -M -e -+u -T -t 128 -S 4096 -L 64 -r 4k -s 40g -i 0 -i 1 -i 2 > -i 8 -+p 70 -C (350 MBytes/sec writes) > iozone -M -e -+u -T -t 128 -r 128k -s 4g -i 0 -i 1 -i 2 -i 8 -+p 70 > -C (400 MBytes/sec write) > > -- > Freddie Cash > fjwc...@gmail.com > _______ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Sanity check: FreeBSD 9.3 binaries on FreeBSD 9.1?
On 2/2/16 2:09 PM, Alan Amesbury wrote: First off Yes, I know 9.1-RELEASE is deprecated. I want to run something newer, but circumstances require I can't for now. Traditionally in FreeBSD -STABLE (as in 9-STABLE) referred to the APIs as being stable, i.e., stuff compiled within the same major release would generally run on versions within that release... or so I recall. I have an instance where I have a need to run 9.1-RELEASE, but my package building infrastructure is all centered around 9.3-RELEASE or later. Based on my (possibly incorrect) understanding of How Things Are[tm], I think packages built for 9.3-RELEASE will generally run on 9.1-RELEASE. Does this sound generally correct, or am I totally off base here? Any major pitfalls I should know of? It's possible they may work, but that is not guaranteed. Packages built on 9.1 should work on 9.3. Packages built on 9.3 may work on 9.1, but that would only be by chance. -Alfred ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Required audit group is missing...
... stable... :D /usr/src # make installworld ERROR: Required audit group is missing, see /usr/src/UPDATING. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. /usr/src # grep audit /usr/src/UPDATING /usr/src # ??? -- - Alfred Perlstein - CTO Okcupid.com / FreeBSD Hacker / All that jazz - ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
audit note for UPDATING.
Index: UPDATING === RCS file: /home/ncvs/src/UPDATING,v retrieving revision 1.416.2.20 diff -u -r1.416.2.20 UPDATING --- UPDATING9 Mar 2006 21:51:00 - 1.416.2.20 +++ UPDATING10 Mar 2006 15:39:05 - @@ -8,6 +8,10 @@ /usr/ports/UPDATING. Please read that file before running portupgrade. +20060310: + The group 'audit' must be added to your machine to upgrade: + audit:*:77: + 20060309: The support for Linux applications the 3dfx kernel module used to provide is in a separate module named 3dfx_linux now. The -- - Alfred Perlstein - CTO Okcupid.com / FreeBSD Hacker / All that jazz - ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
libstdc++ version bump.
I just got bitten by an upgrade from 5.2.1 to 5.4 where my apps linked with c++ stopped working. The solution I had to do was to copy an old 5.2.1 libstdc++ over my 5.4 one. My question is, why wasn't the library version bumped for this incompatible change? Can we bump it? How can we bump it? Even if it doesn't solve 100% of people's problems, it appears to solve some of mine. So can we do it? thank you, -- - Alfred Perlstein - email: [EMAIL PROTECTED] cell: 408-480-4684 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
