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 an...@freebsd.org 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
Re: Upgrading FreeBSD to use the NEW pf syntax.
On Wed, Nov 21, 2012 at 8:56 AM, Gleb Smirnoff gleb...@freebsd.org 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: 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 3:52 PM, Gleb Smirnoff gleb...@freebsd.org 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: 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: 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 mjguzik gmail.com
___
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
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: -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
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
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 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
