Re: current sluggish under load in the last few weeks
> Has something changed in the scheduler recently? Yes: r242736, r242852+r243069. Your description of your problem is a bit vague, but you might start by looking at the effect of the above commits. b. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
current sluggish under load in the last few weeks
Hi All, Has something changed in the scheduler recently? I don't have anything concrete, just anecdotal evidence, but my current desktop feels a little less responsive under heavy CPU load than it did a few weeks ago. Usually my high CPU processes (builds) are nice'd, but even with that, thing still get kinda sluggish, for example the mouse pointer will take it's time responding. Didn't do that a few weeks back. Wondering if it's just me? Thanks, Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: -Current built with clang as default + ports
On 11/13/12 18:51, AN wrote: > Can anyone comment on current built with clang as default compiler and > ports? Are there any major problems, programs that don't run? > Specifically, I am interested in how Gnome and Xorg (Gnome and Xorg > built with default system gcc) work on world built with clang. I can't comment on Gnome, but I run current on my desktop and use KDE4. I had to patch a few ports to build. Those patches have been sent in as PRs. Overall, the switch to ports built with clang was amazingly uneventful. So far, I haven't noticed anything that built but didn't work properly. > I believe the work around for ports that don't build with clang is to > put USE_GCC=4.7+ in the port makefile, is this correct? Any comments > would be appreciated, thanks in advance. A good bit of fixing for clang has already been done. I was able to fix pretty much everything I encountered that didn't build with clang, so didn't have to set USE_GCC anywhere, but it's there as a "last resort." Of course, those are just my experiences, YMMV. Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: -Current built with clang as default + ports
This is all good advice. Note, however: On Wed, Nov 14, 2012 at 10:59:49AM +0100, Dimitry Andric wrote: > Of special interest are the results from the build cluster, where you > can get a quick overview of which ports don't build, and how many other > ports depend on them. Unfortunately those web pages are offline right now and will not be back online in the next few days. mcl ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
amdtemp for amd 8120
Having new amd 8120 box with asus m5a97 mobo, I wait to install 9.1 on it. Both RC1 ad RC2 live memsticks images failed to show temperatures. Some posts reported of using amdtemp source from head successfully. What is the lattest amdtemp source on head? I assume I could go to /usr/src/dyd/dev/amdtemp/ and replace amdtemp.c with head code. Then to recompile the kernel as I do usually, including "device amdtemp" in it. Alternatelly, I might use that code and compile it, rena- ming final result to ie tempmeasure.ko and putting it in /boot/modules directory. With "kldload tempmeasure" later. What would be prefered method? When release comes out, I will try to use amdtemp from it before doing further com- pile. If fails, head source might help. Best regards Zoran ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: problem booting to multi-vdev root pool
on 21/11/2012 09:51 Andrei Lavreniyuk said the following: > Problem solved. Raidz pool mount without zpool.cache. > > > # zpool status -v > pool: zsolar > state: ONLINE > scan: resilvered 2,56M in 0h0m with 0 errors on Tue Nov 20 10:26:35 2012 > config: > > NAME STATE READ WRITE CKSUM > zsolar ONLINE 0 0 0 > raidz2-0 ONLINE 0 0 0 > gpt/disk0 ONLINE 0 0 0 > gpt/disk2 ONLINE 0 0 0 > gpt/disk3 ONLINE 0 0 0 > > errors: No known data errors > > # uname -a > FreeBSD opensolaris.technica-03.local 10.0-CURRENT FreeBSD > 10.0-CURRENT #6 r243278M: Wed Nov 21 09:28:51 EET 2012 > root@opensolaris.technica-03.local:/usr/obj/usr/src/sys/SMP64R amd64 > > > Thanks! Thank you for testing! -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pw keeps setting /etc/group to 0600
On Wed, Nov 21, 2012 at 05:45:43PM +0200, Jaakko Heinonen wrote: > On 2012-11-19, Mateusz Guzik wrote: > > First, pw should not fail if other instance is running, it should wait > > instead (think of parallel batch scripts adding some users/groups). > > > > Second, current code has a race: > > lockfd = open(group_file, O_RDONLY, 0); > > if (lockfd < 0 || fcntl(lockfd, F_SETFD, 1) == -1) > > err(1, "%s", group_file); > > if (flock(lockfd, LOCK_EX|LOCK_NB) == -1) { > > [..] > > gr_copy(pfd, tfd, gr, old_gr); /* copy from groupfile to tempfile */ > > [..] > > rename(tempfile,groupfile); > > Hmm, could using the O_EXLOCK flag for open() instead of flock() help here? > Yes, this would fix the race. But the problem of pw exiting due to other process holding the lock remains. And I think that fixing it will require holding a lock over whole time pw is running so that we have stable snapshot of user base at least in regard of local files. One could create one lock, say /etc/.pw.lock, that would be used to synchronize any changes to /etc/master.passwd, /etc/group and whatnot. And then there is this API issue (but maybe this is just me nitpicking). -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pw keeps setting /etc/group to 0600
On 2012-11-19, Mateusz Guzik wrote: > First, pw should not fail if other instance is running, it should wait > instead (think of parallel batch scripts adding some users/groups). > > Second, current code has a race: > lockfd = open(group_file, O_RDONLY, 0); > if (lockfd < 0 || fcntl(lockfd, F_SETFD, 1) == -1) > err(1, "%s", group_file); > if (flock(lockfd, LOCK_EX|LOCK_NB) == -1) { > [..] > gr_copy(pfd, tfd, gr, old_gr); /* copy from groupfile to tempfile */ > [..] > rename(tempfile,groupfile); Hmm, could using the O_EXLOCK flag for open() instead of flock() help here? > Now let's consider threads A and B: > > A: open() > A: lock(); > A: gr_copy > B: open() > > Now B has file descriptor to /etc/group that is about to be removed. > > A: rename() > A: unlock() > B: lock() > > Now B has a lock on unlinked file. > > B: gr_copy() > B: rename() > > ... and stores new content losing modifications done by A -- Jaakko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Upgrading FreeBSD to use the NEW pf syntax.
On Wed, Nov 21, 2012 at 3:52 PM, Gleb Smirnoff wrote: > On Wed, Nov 21, 2012 at 03:44:13PM +0100, Ermal Lu?i wrote: > E> Cherry-picking would be when tehre is reasonable similarities. > E> Also another argument to do this would be simplicity on locking as well > as > E> i told you when you started the changes. > > You were wrong. OpenBSD doesn't move towards SMP model. Locking more > recent pf is not simplier, but the opposite. > > I am sorry but you are asking arguments i already have given you. You didn;t listen once and i do not expect this time as well. > E> Though i am open to work together on this to merge the new syntax > thorugh a > E> whole bulk merge rather than cherry-pick. > > How many bugs have you closed after the previous bulk import? Why should > we expect anything good from new import if the previous one was a PITA? > > Well you have used it for your work so it was not so PITA. Most of the ones you closed had message 'This is to old to be true'; 'I have re-written PF and this should be fixed'. > And still I don't see any answer on the question: what exact features or > perfomance improvements are we going to obtain from "the new pf"? > > See above. > E> You already have 'broken' some functionality as if-bound in FreeBSD > 10.x so > > Is there any PR filed on that? I didn't even receive a mail about that. > > I really do not think you do the right approach or the right communication on this. Sorry for replying to you ;). > -- > Totus tuus, Glebius. > -- Ermal ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Upgrading FreeBSD to use the NEW pf syntax.
On Wed, Nov 21, 2012 at 03:44:13PM +0100, Ermal Lu?i wrote: E> Cherry-picking would be when tehre is reasonable similarities. E> Also another argument to do this would be simplicity on locking as well as E> i told you when you started the changes. You were wrong. OpenBSD doesn't move towards SMP model. Locking more recent pf is not simplier, but the opposite. E> Though i am open to work together on this to merge the new syntax thorugh a E> whole bulk merge rather than cherry-pick. How many bugs have you closed after the previous bulk import? Why should we expect anything good from new import if the previous one was a PITA? And still I don't see any answer on the question: what exact features or perfomance improvements are we going to obtain from "the new pf"? E> You already have 'broken' some functionality as if-bound in FreeBSD 10.x so Is there any PR filed on that? I didn't even receive a mail about that. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Upgrading FreeBSD to use the NEW pf syntax.
On Wed, Nov 21, 2012 at 8:56 AM, Gleb Smirnoff wrote: > Mark, > > On Tue, Nov 20, 2012 at 03:43:17PM +0100, Mark Martinec wrote: > M> For one thing, I'm desperately awaiting NAT64 support (the 'af-to' > M> translation rule in newer pf (5.1?), committed on 2011-10). > > Backport this exact feature to FreeBSD and send patch. > > M> Other: packet normalization (scrub) has been reworked and simplified, > M> and is now a rulset option. Considering that scrub is currently broken > M> (9.1, see list of PF bugs in FreeBSD), along with several other > M> bugs that need fixing, it seems the (scarce) manpower would better > M> be spent in moving on, than keeping the already leaky (buggy) pf > M> afloat. > > Yes, scrub improvements can be cherry picked and added to FreeBSD, too. > > The issues is you cannot without modifying rule config. > But if you think that bulk import of new version would close all current > bugs without opening new problems, then you are mistaking. Last bulk > import introduced much more bugs than it closed. And this statement isn't > a accusation towards the person who did the import. This is just a generic > rule. If you take 100k lines of code that were developed for another > operating system kernel and without thourough reviewing it just make it > compile and link with another kernel, then you are about to miss many > rough edges that will show up later, when the code would be utilized. > > Thus, cherry-picking is preferred over bulk imports. > > Well it depends on the amount of work. Cherry-picking would be when tehre is reasonable similarities. Also another argument to do this would be simplicity on locking as well as i told you when you started the changes. Though i am open to work together on this to merge the new syntax thorugh a whole bulk merge rather than cherry-pick. You already have 'broken' some functionality as if-bound in FreeBSD 10.x so why not break syntax and see to introduce if real value behind a converter as well. > -- > Totus tuus, Glebius. > ___ > freebsd...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org" > -- Ermal ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Looking for bge(4) , bce(4) and igb(4) cards
Andre I'll try to do it today or next monday when I get back from vacation . They are all hp branded nic's . I ordered them with in the last few years to use in place of bce nic's on the main boards of hp servers . --- On Nov 14, 2012, at 5:31 AM, Andre Oppermann wrote: > Hello > > I currently working on a number of drivers for popular network > cards and extend them with automatic hybrid interrupt/polling > ithread processing with life-lock prevention (so that the driver > can't consume all CPU when under heavy load or attack). > > To properly test this I need the proper hardware as PCIe network > cards: > > bge(4) Broadcom BCM57xx/BCM590x > bce(4) Broadcom NetXtreme II (BCM5706/5708/5709/5716) > igb(4) Intel PRO/1000 i82575, i82576, i82580, i210, i350 > > If you have one of these and can spare it I'd be very glad if > you could send it to me. I'm located in Switzerland/Europe. > I can reply to you privately to give you my shipping address. > > > Of course if you have any other PCIe Gigabit Ethernet cards > with a driver in FreeBSD I'm interested in receiving one as > well. Of particular interest are: > > em(4) Intel i82571 to i82573 > lem(4) Intel i82540 to i82546 > age(4) Atheros L1 GigE > ???anything else 1GigE with PCIe > > > The same goes for 10 Gigabit Ethernet but the setup is a bit > more involved and I haven't done that yet, but will do soon > (the issue being expensive SPF+ optics): > > bxe(4) Broadcom BCM5771x 10GigE > cxbge(4) Chelsio T4 10GigE > ixgbe(4) Intel i82598 and i82599 10GigE > mxge(4) Myricom Myri10G > qlxgb(4) QLogic 3200 and 8200 10GigE > sfxge(4) Solarflare > > Many thanks for your support! > > -- > Andre > ___ > freebsd-sta...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"