a GOOD idea to harden OpenSSH!
I'm writing here, because the ssh dev list says: Mail Delivery Status Notification (Delay) [Status: Error, Address: openssh-unix-...@mindrot.org, ResponseCode 451, Temporary failure, please try again later.] So: What is you're opinion about the next idea? Please write down ++/-- thoughts: it's against brute-force attacks on sshd: if a user wants to connect to an ssh server then he have to wait a couple of seconds, then he can write his passphare. the couple of seconds is defined in the sshd config, e.g.: 2 seconds the method musn't show that the user have to wait 2 seconds to write his passphare. important: the user could type in his password before the 2 seconds, but the sshd will only process the chars that has been typed after 2 second! effect: in this way, if a brute force robot comes, and tries to log in with a generated password it will likely input that in a matter of miliseconds, ok. BUT: the sshd will only give back that, that the password is bad. - because it only processes the password that has been typed 2 seconds after the type you're password appear on client side. if this idea would spread, then the attackers would adapt, and wait e.g.: 5 seconds before their robot gives the generated password to sshd. - BUT: this will take them too much resources, and the brute-force will be far less effective. so can this be a feature in sshd? :O What do you think? Thank you!
Re: a GOOD idea to harden OpenSSH!
Isn't limiting the number of retries obtaining the same result? I mean, limiting the number of retries to 5 and having to wait for 10 seconds after five failed attempts will have the same outcome without the hassle, IMO. On Tue, 29 Mar 2011 22:58:53 -0700 nagygabor88 nagygabo...@zoho.com wrote: What is you're opinion about the next idea? Please write down ++/-- thoughts: -- Mihai Militaru mihai.milit...@xmpp.ro
Re: a GOOD idea to harden OpenSSH!
IMHO it is absolutelly useless, objections are: 1. You can limit connections using firewall. 2. You already have the feature by name limiting the number of retries 3. If you really want PROTECTION - you should turn off password authentication completelly and use RSA key with passphrase. On Wed, 30 Mar 2011 09:54:06 +0300 Mihai Militaru mihai.milit...@xmpp.ro wrote: Isn't limiting the number of retries obtaining the same result? I mean, limiting the number of retries to 5 and having to wait for 10 seconds after five failed attempts will have the same outcome without the hassle, IMO. On Tue, 29 Mar 2011 22:58:53 -0700 nagygabor88 nagygabo...@zoho.com wrote: What is you're opinion about the next idea? Please write down ++/-- thoughts: -- With best regards, Gregory Edigarov
Re: a GOOD idea to harden OpenSSH!
Don't reinvent wheel http://home.nuug.no/~peter/pf/en/bruteforce.html On Wed, Mar 30, 2011 at 7:58 AM, nagygabor88 nagygabo...@zoho.com wrote: I'm writing here, because the ssh dev list says: Mail Delivery Status Notification (Delay) [Status: Error, Address: openssh-unix-...@mindrot.org, ResponseCode 451, Temporary failure, please try again later.] So: What is you're opinion about the next idea? Please write down ++/-- thoughts: it's against brute-force attacks on sshd: if a user wants to connect to an ssh server then he have to wait a couple of seconds, then he can write his passphare. the couple of seconds is defined in the sshd config, e.g.: 2 seconds the method musn't show that the user have to wait 2 seconds to write his passphare. important: the user could type in his password before the 2 seconds, but the sshd will only process the chars that has been typed after 2 second! effect: in this way, if a brute force robot comes, and tries to log in with a generated password it will likely input that in a matter of miliseconds, ok. BUT: the sshd will only give back that, that the password is bad. - because it only processes the password that has been typed 2 seconds after the type you're password appear on client side. if this idea would spread, then the attackers would adapt, and wait e.g.: 5 seconds before their robot gives the generated password to sshd. - BUT: this will take them too much resources, and the brute-force will be far less effective. so can this be a feature in sshd? :O What do you think? Thank you!
Re: a GOOD idea to harden OpenSSH!
On Wed, Mar 30, 2011 at 10:06:14AM +0300, Gregory Edigarov wrote: IMHO it is absolutelly useless, objections are: 1. You can limit connections using firewall. 2. You already have the feature by name limiting the number of retries 3. If you really want PROTECTION - you should turn off password authentication completelly and use RSA key with passphrase. On Wed, 30 Mar 2011 09:54:06 +0300 Mihai Militaru mihai.milit...@xmpp.ro wrote: It's a great way to keep someone out of their own system.
Re: sil3512 PCMCIA eSATA card not configured
We don't support pciide at cardbus yet. The cardbus code ideally needs to be folded into the pci code, this would solve these kinds of problems but is quite painful to do. On Wed, Mar 30, 2011 at 02:30:10AM +0100, iproudlyeat...@gmail.com wrote: I have a Delock 2xeSATA PCMCIA card that isn't configured/recognized(?) on amd64 4.9-current. Since the sil3512 controller is supported by pciide(4), should it have worked?
Re: a GOOD idea to harden OpenSSH!
On Wed, Mar 30, 2011 at 03:00:18PM +0700, Edho P Arief wrote: On Wed, Mar 30, 2011 at 2:22 PM, Alexander Schrijver alexander.schrij...@gmail.com wrote: It's a great way to keep someone out of their own system. Unless you enable root login... How does that help?
Re: MAXDSIZ
currently not but this machine will be a DB server (Postgresql + Mysql) and it was aksed if we could go beyond the 8G. In any case, for now, if I can address 8G physical memory is fine. Thanks for your feedback Tony On Mon, Mar 28, 2011 at 6:59 PM, Ted Unangst ted.unan...@gmail.com wrote: No, are you having a problem with 8GB? On Mar 28, 2011, at 8:59 AM, Tony Berth tonybe...@googlemail.com wrote: Dear OBSD list members, in the meanwhile, are any changes to the following: ... Make amd64 machines be able to use more than 4G ram, and crank the MAXDSIZ to allow allocations/mmap() up to 8G. ... as this was reported on: ... http://www.openbsd.org/plus44.html ... For example to extend it, let's say, to 16GB? Thanks Tony
Re: a GOOD idea to harden OpenSSH!
On 30 March 2011 20:22, Alexander Schrijver alexander.schrij...@gmail.com wrote: On Wed, Mar 30, 2011 at 10:06:14AM +0300, Gregory Edigarov wrote: IMHO it is absolutelly useless, objections are: 1. You can limit connections using firewall. 2. You already have the feature by name limiting the number of retries 3. If you really want PROTECTION - you should turn off password authentication completelly and use RSA key with passphrase. On Wed, 30 Mar 2011 09:54:06 +0300 Mihai Militaru mihai.milit...@xmpp.ro wrote: It's a great way to keep someone out of their own system. It still amazes me the people are using tunneled plain-text passwords on internet facing systems. Learn how to use ssh-keygen and .ssh/authorized keys - I would hazard that a better security measure would be to turn off tunneled clear text logins by default.
Re: a GOOD idea to harden OpenSSH!
On Wed, Mar 30, 2011 at 3:11 PM, Alexander Schrijver alexander.schrij...@gmail.com wrote: On Wed, Mar 30, 2011 at 03:00:18PM +0700, Edho P Arief wrote: On Wed, Mar 30, 2011 at 2:22 PM, Alexander Schrijver alexander.schrij...@gmail.com wrote: It's a great way to keep someone out of their own system. Unless you enable root login... How does that help? How would someone locked out of their own system when disabling password login? (I guessed home partition didn't get mounted before which is why I mentioned enabling root login)
Re: a GOOD idea to harden OpenSSH!
On Wed, 30 Mar 2011 09:22:44 +0200, Alexander Schrijver alexander.schrij...@gmail.com wrote: On Wed, Mar 30, 2011 at 10:06:14AM +0300, Gregory Edigarov wrote: IMHO it is absolutelly useless, objections are: 1. You can limit connections using firewall. 2. You already have the feature by name limiting the number of retries 3. If you really want PROTECTION - you should turn off password authentication completelly and use RSA key with passphrase. On Wed, 30 Mar 2011 09:54:06 +0300 Mihai Militaru mihai.milit...@xmpp.ro wrote: It's a great way to keep someone out of their own system. Obviously, if you do limit the number of connections using pf(4) (or some other firewall), you should maintain a whitelist of good IP's who are always allowed to connect. I myself protect my servers tcp/22 with pf(4) and I do maintain a whiltelist. It contains the IP of my default gateway and one more IP from a trusted network. That way, I can't lock me out. Besides, if you have remote servers, you should have out of band management (speaks: serial console!). If you don't, well then, Amateur I say! Cheers, Marian
Re: a GOOD idea to harden OpenSSH!
On Wed, Mar 30, 2011 at 2:22 PM, Alexander Schrijver alexander.schrij...@gmail.com wrote: It's a great way to keep someone out of their own system. Unless you enable root login...
Re: [darkice] Re: Build darkice on OpenBSD 4.8
Anybody there was able to compile darkice on OpenBSD 4.8 or -current ? On Tue, Mar 29, 2011 at 4:47 PM, Evgeniy Sudyr eject.in...@gmail.comwrote: I got source from anoncvs and then added include to .cpp files #include /usr/src/usr.sbin/nsd/compat/pselect.c now I'm getting next error: /usr/include/g++/i386-unknown-openbsd4.9/bits/ctype_base.h: At global scope: /usr/include/g++/i386-unknown-openbsd4.9/bits/ctype_base.h:55: warning: overflow in implicit constant conversion mv -f .deps/main.Tpo .deps/main.Po g++ -DHAVE_CONFIG_H -I. -I/usr/local/include-O2 -pedantic -Wall -pthread -g -O2 -MT aflibDebug.o -MD -MP -MF .deps/aflibDebug.Tpo -c -o aflibDebug.o aflibDebug.cc mv -f .deps/aflibDebug.Tpo .deps/aflibDebug.Po g++ -DHAVE_CONFIG_H -I. -I/usr/local/include-O2 -pedantic -Wall -pthread -g -O2 -MT aflibConverter.o -MD -MP -MF .deps/aflibConverter.Tpo -c -o aflibConverter.o aflibConverter.cc aflibConverter.cc: In member function 'int aflibConverter::resampleFast(int, int, short int*, short int*)': aflibConverter.cc:525: warning: deprecated conversion from string constant to 'char*' aflibConverter.cc: In member function 'int aflibConverter::resampleWithFilter(int, int, short int*, short int*, short int*, short int*, short unsigned int, short unsigned int, short unsigned int)': aflibConverter.cc:571: warning: deprecated conversion from string constant to 'char*' aflibConverter.cc:639: warning: deprecated conversion from string constant to 'char*' mv -f .deps/aflibConverter.Tpo .deps/aflibConverter.Po g++ -O2 -pedantic -Wall -pthread -g -O2-o darkice AudioSource.o BufferedSink.o CastSink.o FileSink.o Connector.o MultiThreadedConnector.o DarkIce.o Exception.o IceCast.o IceCast2.o ShoutCast.o FileCast.o LameLibEncoder.o TwoLameLibEncoder.o VorbisLibEncoder.o FaacEncoder.o aacPlusEncoder.o OssDspSource.o SerialUlaw.o SolarisDspSource.o TcpSocket.o Util.o ConfigSection.o DarkIceConfig.o Reporter.o AlsaDspSource.o JackDspSource.o main.o aflibDebug.o aflibConverter.o -L/usr/local/lib -lmp3lame SolarisDspSource.o(.text+0x160): In function `pselect(int, fd_set*, fd_set*, fd_set*, timespec const*, unsigned int const*)': /usr/src/usr.sbin/nsd/compat/pselect.c:23: multiple definition of `pselect(int, fd_set*, fd_set*, fd_set*, timespec const*, unsigned int const*)' FileSink.o(.text+0x240):/usr/src/usr.sbin/nsd/compat/pselect.c:23: first defined here TcpSocket.o(.text+0x190): In function `pselect(int, fd_set*, fd_set*, fd_set*, timespec const*, unsigned int const*)': /usr/src/usr.sbin/nsd/compat/pselect.c:23: multiple definition of `pselect(int, fd_set*, fd_set*, fd_set*, timespec const*, unsigned int const*)' FileSink.o(.text+0x240):/usr/src/usr.sbin/nsd/compat/pselect.c:23: first defined here Util.o(.text+0x260): In function `pselect(int, fd_set*, fd_set*, fd_set*, timespec const*, unsigned int const*)': /usr/src/usr.sbin/nsd/compat/pselect.c:23: multiple definition of `pselect(int, fd_set*, fd_set*, fd_set*, timespec const*, unsigned int const*)' FileSink.o(.text+0x240):/usr/src/usr.sbin/nsd/compat/pselect.c:23: first defined here aflibDebug.o(.text+0x3bf): In function `aflibDebug::debug(char const*, ...)': /usr/src/darkice-1.0/src/aflibDebug.cc:218: warning: vsprintf() is often misused, please use vsnprintf() Util.o(.text+0x1f1): In function `Util::strCpy(char*, char const*)': /usr/src/darkice-1.0/src/Util.cpp:144: warning: strcpy() is almost always misused, please use strlcpy() IceCast.o(.text+0x23f): In function `IceCast::sendLogin()': /usr/src/darkice-1.0/src/Referable.h:144: warning: sprintf() is often misused, please use snprintf() Exception.o(.text+0x1f9): In function `Exception::Exception(char const*, unsigned int, char const*, char const*, char const*, int)': /usr/src/darkice-1.0/src/Exception.cpp:128: warning: strcat() is almost always misused, please use strlcat() collect2: ld returned 1 exit status *** Error code 1 On Tue, Mar 29, 2011 at 12:58 AM, Adrian Pardini adr...@tangopardo.com.ar wrote: On Monday 28 March 2011 17:32:25 Ckos MarC3y wrote: On 28/03/11 22:03, Evgeniy Sudyr wrote: Hi Akos, there is select.h manual from OpenBSD project http://www.openbsd.org/cgi-bin/man.cgi?query=selectapropos=0sektion=0m anpath=OpenBSD+Currentarch=i386format=html thanks for the link. it seems like openbsd doesn't have pselect(), only select() how good are you with coding? :) Hi all, here is an pselect implementation for OpenBSD: ftp://ftp.fr.openbsd.org/pub/OpenBSD/src/usr.sbin/nsd/compat/pselect.c right now I don't have at hand an OpenBSD box to try it but I hope you can work it out. Except for the race condition warning the code looks fine. -- Adrian. http://elesquinazotango.com.ar http://ovejafm.com -- -- With regards, Eugene Sudyr -- -- With regards, Eugene Sudyr
Re: MAXDSIZ
2011/3/30 Tony Berth tonybe...@googlemail.com currently not but this machine will be a DB server (Postgresql + Mysql) and it was aksed if we could go beyond the 8G. In any case, for now, if I can address 8G physical memory is fine. ..which you cant. -- To our sweethearts and wives. May they never meet. -- 19th century toast
WSI presenta: Congreso de Marketing Digital,Tendencias, Realidad Aumentada y más este 11 de abril Cd. de México
[IMAGE] Wsi y Pms Capacitacisn Efectiva de Mixico presentan: Congreso Nacional Internet Marketing Evolution este 11 de abril Ciudad de Mixico. Digital Marketing, Social Media, Search Engine Optimization, Realidad Aumentada y mas Empresa Registrada ante la STPS Reg. COLG640205CP30005 Smguenos en Twitter@pmscapacitacion o bien en Facebook PMS de Mixico Solicite Mayores informes responda este correo electrsnico con los siguientes datos. Empresa: Nombre: Telifono: Email: Nzmero de Interesados: Y en breve le haremos llegar la informacisn completa del evento. O bien comunmquense a nuestros telifonos un ejecutivo con gusto le atendera Tels. (33) 8851-2365, (33)8851-2741. Copyright (C) 2010, PMS Capacitacisn Efectiva de Mixico S.C. Derechos Reservados. PMS de Mixico, El logo de PMS de Mixico son marcas registradas. ADVERTENCIA PMS de Mixico no cuenta con alianzas estratigicas de ningzn tipo dentro de la Republica Mexicana. NO SE DEJE ENGAQAR - DIGA NO A LA PIRATERIA. Todos los logotipos, marcas comerciales e imagenes son propiedad de sus respectivas corporaciones y se utilizan con fines informativos solamente. Este Mensaje ha sido enviado a misc@openbsd.org como usuario de Pms de Mixico o bien un usuario le refiris para recibir este boletmn. Como usuario de Pms de Mixico, en este acto autoriza de manera expresa que Pms de Mixico le puede contactar vma correo electrsnico u otros medios. Si usted ha recibido este mensaje por error, haga caso omiso de el y reporte su cuenta respondiendo este correo con el subject BAJAMKT Unsubscribe to this mailing list, reply a blank message with the subject UNSUBSCRIBE BAJAMKT Tenga en cuenta que la gestisn de nuestras bases de datos es de suma importancia y no es intencisn de la empresa la inconformidad del receptor. [demime 1.01d removed an attachment of type image/jpeg which had a name of promoime.jpg]
Re: Performance degradation after upgrade
Ok, now we have been doing some testing and probably found the problem. All tests were done on the same machine with an Intel S5000VSA MB and a Xeon E5420 2,5 Ghz processor, running OpenBSD 4.8 amd64 GENERIC (SP kernel). We tested the performance with iperf, running two clients connected through a bridge. With the Intel Pro/1000 PCIe (82576) dual port cards with the bridge between two cards (in this case em0 to em2) we got the worst performance, 150 Mbit/s. While testing this and watching with 'systat vmstat', the CPU was 99% busy handling interrupts. The amount of interrupts were about 3000/s on em0 (where the iperf client was connected) and 1500/s on em2 (iperf server). At the same time 'systat ifs' showed about 10 new livelocks per second. Next we tested regular PCI Intel Pro/1000MT (82545GM) cards and now we got the performance we had hoped for in the first place. 910 Mbit/s with 8000 intr/s on both cards at 50% CPU (intr). No livelocks. We thought perhaps the issue was related to the PCIe bus, so we did one final test, this time with quad port Intel Pro/1000 QP (82576) PCIe cards. These performed excellent, with 940 Mbit/s, 8200 intr/s per card and 60% CPU (intr). So, it seems the dual port PCIe cards suck and we have to replace them. //Peter On 2011-03-29 07:40, Peter Hallin wrote: I realized now that this measurement is wrong. vmstat -iz seems to calculate the interrupt rate based a longer period, and this measurement was taken just after we started to push traffic through the machine again. The amount of interrupts per second when checking with systat (which seems to have a shorter measurement period) at the same time was way higher, about 5000 intr/s on em0 and em2. Sorry for the wrong data
Re: MAXDSIZ
I can't??? So the limit of 4G physical memory still exists? And why was this statement made from 4.4 release? Thanks On Wed, Mar 30, 2011 at 12:39 PM, Janne Johansson icepic...@gmail.comwrote: 2011/3/30 Tony Berth tonybe...@googlemail.com currently not but this machine will be a DB server (Postgresql + Mysql) and it was aksed if we could go beyond the 8G. In any case, for now, if I can address 8G physical memory is fine. ..which you cant. -- To our sweethearts and wives. May they never meet. -- 19th century toast
Re: Performance degradation after upgrade
Could you donate a dual port card to the project if you replace them? I would like to figure out why some em(4) perform badly while the same chip on a different card seems to perform as expected. Can you provide the vmstat -zi output of the 4 port card? I wonder how the interrupts are shared on the 2 port and the 4 port card. IIRC on the original vmstat -zi output em0 shared the interrupt with the pci bridge. -- :wq Claudio On Wed, Mar 30, 2011 at 02:05:31PM +0200, Peter Hallin wrote: Ok, now we have been doing some testing and probably found the problem. All tests were done on the same machine with an Intel S5000VSA MB and a Xeon E5420 2,5 Ghz processor, running OpenBSD 4.8 amd64 GENERIC (SP kernel). We tested the performance with iperf, running two clients connected through a bridge. With the Intel Pro/1000 PCIe (82576) dual port cards with the bridge between two cards (in this case em0 to em2) we got the worst performance, 150 Mbit/s. While testing this and watching with 'systat vmstat', the CPU was 99% busy handling interrupts. The amount of interrupts were about 3000/s on em0 (where the iperf client was connected) and 1500/s on em2 (iperf server). At the same time 'systat ifs' showed about 10 new livelocks per second. Next we tested regular PCI Intel Pro/1000MT (82545GM) cards and now we got the performance we had hoped for in the first place. 910 Mbit/s with 8000 intr/s on both cards at 50% CPU (intr). No livelocks. We thought perhaps the issue was related to the PCIe bus, so we did one final test, this time with quad port Intel Pro/1000 QP (82576) PCIe cards. These performed excellent, with 940 Mbit/s, 8200 intr/s per card and 60% CPU (intr). So, it seems the dual port PCIe cards suck and we have to replace them. //Peter On 2011-03-29 07:40, Peter Hallin wrote: I realized now that this measurement is wrong. vmstat -iz seems to calculate the interrupt rate based a longer period, and this measurement was taken just after we started to push traffic through the machine again. The amount of interrupts per second when checking with systat (which seems to have a shorter measurement period) at the same time was way higher, about 5000 intr/s on em0 and em2. Sorry for the wrong data
Re: MAXDSIZ
On Wed, Mar 30, 2011 at 01:22:19PM +0200, Tony Berth wrote: I can't??? So the limit of 4G physical memory still exists? And why was this statement made from 4.4 release? Yes, the limit still exists. Work on that is progressing, but slowly. I don't think 4.4 was shipped with bigmem enabled. CVS tells me it was not: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/amd64/amd64/machdep.c rev 1.82 -Otto Thanks On Wed, Mar 30, 2011 at 12:39 PM, Janne Johansson icepic...@gmail.comwrote: 2011/3/30 Tony Berth tonybe...@googlemail.com currently not but this machine will be a DB server (Postgresql + Mysql) and it was aksed if we could go beyond the 8G. In any case, for now, if I can address 8G physical memory is fine. ..which you cant. -- To our sweethearts and wives. May they never meet. -- 19th century toast
Curso de Nominas 2011
Marzo 2011 Curso de Nominas 2011 VisiC3n Humana (ConsultorC-a en Recursos Humanos) tiene el agrado de invitarlo al Curso de NC3minas 2011 que se llevarC! a cabo en el mes de Abril de 2011. OBJETIVO: Conocer las disposiciones legales y procedimientos para realizar al correcto cC!lculo de una nC3mina. DIRIGIDO A: Encargados de Recursos Humanos, NC3minas, Encargados de Pago de Impuestos de las Empresas, Contadores, Administradores, PsicolC3gos, Ingenieros y en general a toda persona que tiene la responsabilidad del Departamento de Personal. Temario: * Ingresos Gravados para el trabajador * Ingresos exentos para el trabajador * DeterminaciC3n de las retenciones mensuales de ISR segC:n tarifa * DeterminaciC3n del subsidio al empleo * CC!lculo de la previsiC3n social, exenta y gravada * Diferentes cC!lculos de retenciC3n de ISR en forma diaria, semanal, decenal, quincenal y mensual * Retenciones por pagos de prima dominical, vacacional, gratificaciC3n y tiempo extra * Procedimientos opcionales de ISR por ingresos de varios meses obtenidos en un solo mes * CC!lculo de etenciC3n para los trabajadores de pagos extraordinarios, finiquitos, indemnizaciones, compensaciones, etc. * Obligaciones de los patones y trabajadores Fecha y Sede: SC!bado 2 de Abril de 2011 9:00 a 14: 00 horas PROMOCICN CON PRONTO PAGO HASTA EL DC A 31 DE MARZO 2011 $990 MCS IVA Costo Normal pagando el dC-a del evento $1,350 mC!s IVA El curso se imparte en nuestras instalaciones ubicadas en: Dr. BarragC!n NB: 560 Despacho 5 Col. Narvarte, MC)xico D.F. Tels. 5538 0071, 3548 4737 (llamada local en el D.F.) Fax: 8502 2187 (llamada local en el D.F.) CONSULTA NUESTRO CALENDARIO DE CURSOS ( http://www.analisisrh.biz ) Borrar suscripciC3n ( http://www.cursosrh.net/acymailing/index.php?option=com_acymailingctrl=usertask=unsubmailid=15subid=648018key=49fc1a7ea1030b277cddf52f828e8b13 )
Re: MAXDSIZ
On Wed, Mar 30, 2011 at 01:22:19PM +0200, Tony Berth wrote: I can't??? So the limit of 4G physical memory still exists? And why was this statement made from 4.4 release? physical vs virtual memory, as has been explained already it's no longer 1950; we've got this thing called swap Thanks On Wed, Mar 30, 2011 at 12:39 PM, Janne Johansson icepic...@gmail.comwrote: 2011/3/30 Tony Berth tonybe...@googlemail.com currently not but this machine will be a DB server (Postgresql + Mysql) and it was aksed if we could go beyond the 8G. In any case, for now, if I can address 8G physical memory is fine. ..which you cant. -- To our sweethearts and wives. May they never meet. -- 19th century toast
Network card EM not recognized
Hello, I am having problems with some network card on 2 appliances that i just bought. Indeed, two network card (82575EB chipset) are not recognized correctly. I get the following error message : /em0 at pci2 dev 0 function 0 Intel PRO/1000 PT (82575EB) rev 0x02: cannot find i/o space em1 at pci2 dev 0 function 1 Intel PRO/1000 PT (82575EB) rev 0x02: cannot find i/o space/ While the other six (82574L chipset) are working properly : /em2 at pci3 dev 0 function 0 Intel PRO/1000 MT (82574L) rev 0x00: apic 2 int 16 (irq 10), address 00:10:f3:1a:49:6a ppb3 at pci0 dev 28 function 1 Intel 82801I PCIE rev 0x02: apic 2 int 16 (irq 10) pci4 at ppb3 bus 4 em3 at pci4 dev 0 function 0 Intel PRO/1000 MT (82574L) rev 0x00: apic 2 int 17 (irq 5), address 00:10:f3:1a:49:6b ppb4 at pci0 dev 28 function 2 Intel 82801I PCIE rev 0x02: apic 2 int 18 (irq 11) pci5 at ppb4 bus 5 em4 at pci5 dev 0 function 0 Intel PRO/1000 MT (82574L) rev 0x00: apic 2 int 18 (irq 11), address 00:10:f3:1a:49:6c ppb5 at pci0 dev 28 function 3 Intel 82801I PCIE rev 0x02: apic 2 int 19 (irq 15) pci6 at ppb5 bus 6 em5 at pci6 dev 0 function 0 Intel PRO/1000 MT (82574L) rev 0x00: apic 2 int 19 (irq 15), address 00:10:f3:1a:49:6d ppb6 at pci0 dev 28 function 4 Intel 82801I PCIE rev 0x02: apic 2 int 17 (irq 5) pci7 at ppb6 bus 7 em6 at pci7 dev 0 function 0 Intel PRO/1000 MT (82574L) rev 0x00: apic 2 int 16 (irq 10), address 00:10:f3:1a:49:6e ppb7 at pci0 dev 28 function 5 Intel 82801I PCIE rev 0x02: apic 2 int 16 (irq 10) pci8 at ppb7 bus 8 em7 at pci8 dev 0 function 0 Intel PRO/1000 MT (82574L) rev 0x00: apic 2 int 17 (irq 5), address 00:10:f3:1a:49:6f/ Yet the 82575EB chipset is in the list of hardware supported by OpenBSD. http://www.openbsd.org/cgi-bin/man.cgi?query=emarch=amd64sektion=4 I have tested with OpenBSD 4.8-release, OpenBSD 4.8-stable and OpenBSD snapshot 4.9 (2011/03/30), on amd64 GENERIC.MP and i386 GENERIC.MP platforms but the problem is the same every time. I tried to free irq in bios (disabling serial ports..) but nothing changed. Does anyone have any idea ? Thank you in advance. Here is the dmesg : # dmesg @\^H\^D\^A\^A\^B\^H\^H\^BOpenBSD 4.9-current (RAMDISK_CD) #879: Wed Mar 23 12:37:41 MDT 2011 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 3756785664 (3582MB) avail mem = 3645091840 (3476MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xfb460 (27 entries) bios0: vendor American Megatrends Inc. version 080015 date 05/05/2009 acpi0 at bios0: rev 0 acpi0: sleep states S0 acpi0: tables DSDT FACP APIC MCFG OEMB acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz, 2926.40 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3 ,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG cpu0: 3MB 64b/line 8-way L2 cache cpu0: apic clock running at 265MHz cpu at mainbus0: not configured ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 9 (P0P1) acpiprt2 at acpi0: bus 3 (P0P4) acpiprt3 at acpi0: bus 4 (P0P5) acpiprt4 at acpi0: bus 5 (P0P6) acpiprt5 at acpi0: bus 6 (P0P7) acpiprt6 at acpi0: bus 7 (P0P8) acpiprt7 at acpi0: bus 8 (P0P9) pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel 3200/3210 Host rev 0x01 ppb0 at pci0 dev 1 function 0 Intel 3200/3210 PCIE rev 0x01: apic 2 int 16 (irq 10) pci1 at ppb0 bus 1 ppb1 at pci0 dev 6 function 0 Intel 3210 PCIE rev 0x01: apic 2 int 16 (irq 10) pci2 at ppb1 bus 2 em0 at pci2 dev 0 function 0 Intel PRO/1000 PT (82575EB) rev 0x02: cannot find i/o space em1 at pci2 dev 0 function 1 Intel PRO/1000 PT (82575EB) rev 0x02: cannot find i/o space ppb2 at pci0 dev 28 function 0 Intel 82801I PCIE rev 0x02: apic 2 int 17 (irq 5) pci3 at ppb2 bus 3 em2 at pci3 dev 0 function 0 Intel PRO/1000 MT (82574L) rev 0x00: apic 2 int 16 (irq 10), address 00:10:f3:1a:49:6a ppb3 at pci0 dev 28 function 1 Intel 82801I PCIE rev 0x02: apic 2 int 16 (irq 10) pci4 at ppb3 bus 4 em3 at pci4 dev 0 function 0 Intel PRO/1000 MT (82574L) rev 0x00: apic 2 int 17 (irq 5), address 00:10:f3:1a:49:6b ppb4 at pci0 dev 28 function 2 Intel 82801I PCIE rev 0x02: apic 2 int 18 (irq 11) pci5 at ppb4 bus 5 em4 at pci5 dev 0 function 0 Intel PRO/1000 MT (82574L) rev 0x00: apic 2 int 18 (irq 11), address 00:10:f3:1a:49:6c ppb5 at pci0 dev 28 function 3 Intel 82801I PCIE rev 0x02: apic 2 int 19 (irq 15) pci6 at ppb5 bus 6 em5 at pci6 dev 0 function 0 Intel PRO/1000 MT (82574L) rev 0x00: apic 2 int 19 (irq 15), address 00:10:f3:1a:49:6d ppb6 at pci0 dev 28 function 4 Intel 82801I PCIE rev 0x02: apic 2 int 17 (irq 5) pci7 at ppb6 bus 7 em6 at pci7 dev 0 function 0 Intel PRO/1000 MT (82574L) rev 0x00: apic 2 int 16 (irq 10), address 00:10:f3:1a:4@: apic 2 int 16 (irq 10) pci8 at ppb7 bus 8 em7 at pci8 dev 0 function 0 Intel PRO/1000 MT
Re: MAXDSIZ
On 03/30/11 05:21, Tony Berth wrote: I can't??? So the limit of 4G physical memory still exists? And why was this statement made from 4.4 release? Worse, an amd64 kernel looking at 8GB of real, physical ram only makes a wee bit under 3GB available. OpenBSD 4.9-current (GENERIC.MP) #852: Sun Mar 20 13:21:59 MDT 2011 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3220111360 (3070MB) avail mem = 3120357376 (2975MB) Jeff
LAST day to take advantage of our 5 for 4 Offer
Please click here if the e-mail below is not displayed correctly Cast in Style www.castinstyle.co.uk Beautiful Cast Iron Home and Garden Ware IT'S THE LAST DAY TO TAKE ADVANTAGE - ENDS TOMORROW For the whole of March we are giving away FREE products. Buy 5 of anything you like on our web site and we will give you lowest cost item completely FREE. Fantastic for your spring renovation project if you need several items or just if you love our products. Offer ends 31st March 2011 Click here for more details Make us your One Stop Shop for all your home architectural hardware [IMAGE] [IMAGE] Remove me from this newsletter
Dear,misc: 善用Voip網絡加強業務告訴發展!
Having problems viewing this email? Please click here.For enquiry, please send email to powert...@epromotion.com.hk eg!f3i1h.d;%d8 ge'e.9o h+ f f-$.ef d;;d=f %h)h+ i;i5h3 powert...@epromotion.com.hk ef f(d8 f3e f6e0fegd?!d;6o h+ f ih#ie. Important Notice: Base on the Unsolicited Electronic Messages Ordinance, if you DO NOT want to receive any promotional email messages from us in the future, please kindly reply this e-mail for DELETION. If you would like to continue to receive our promotional email massages, you do not need to reply us.
Re: sil3512 PCMCIA eSATA card not configured
On 30 March 2011 09:06, Jonathan Gray j...@goblin.cx wrote: We don't support pciide at cardbus yet. The cardbus code ideally needs to be folded into the pci code, this would solve these kinds of problems but is quite painful to do. Would an expresscard work?
Re: MAXDSIZ
I have loaded the machine with processes and I think it consumed slightly more than 4G physical, running 3 compiles at once. OpenBSD userland (make -j4) + Clang/LLVM (make -j4) + ITK (make -j4). I was checking with top -s3 -1. OpenBSD just returns kernel page memory very very quickly, so it is difficult for it to consume more :). But seriously, after this compile, kernel was holding onto some memory. At idle (after compilation) it was an excess of 300-500M more, instead of 1-1.3G, it was around 1.7G. Opensolaris does aggressive caching trying to maintain and fill out all the available RAM, but OpenBSD gives back the memory very very quickly. Thanks On Wed, Mar 30, 2011 at 5:39 AM, Janne Johansson icepic...@gmail.com wrote: 2011/3/30 Tony Berth tonybe...@googlemail.com currently not but this machine will be a DB server (Postgresql + Mysql) and it was aksed if we could go beyond the 8G. In any case, for now, if I can address 8G physical memory is fine. ..which you cant. -- To our sweethearts and wives. May they never meet. -- 19th century toast
Re: MAXDSIZ
On Wed, 30 Mar 2011 13:15:10 -0500 Amit Kulkarni amitk...@gmail.com wrote: OpenBSD just returns kernel page memory very very quickly, so it is difficult for it to consume more :). But seriously, after this compile, kernel was holding onto some memory. At idle (after compilation) it was an excess of 300-500M more, instead of 1-1.3G, it was around 1.7G. Opensolaris does aggressive caching trying to maintain and fill out all the available RAM, but OpenBSD gives back the memory very very quickly. concerning the file cache, sysctl kern.bufcachepercent=90 runs flawlessly; maybe worth a default setting.
Re: MAXDSIZ
On 2011-03-30 17.48, Jeff Ross wrote: On 03/30/11 05:21, Tony Berth wrote: I can't??? So the limit of 4G physical memory still exists? And why was this statement made from 4.4 release? Worse, an amd64 kernel looking at 8GB of real, physical ram only makes a wee bit under 3GB available. OpenBSD 4.9-current (GENERIC.MP) #852: Sun Mar 20 13:21:59 MDT 2011 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3220111360 (3070MB) avail mem = 3120357376 (2975MB) That depends somewhat on the hardware you're running on, most likely the address space footprint made by the video memory. This is what one of my Supermicro servers looks like: OpenBSD 4.7 (GENERIC.MP) #130: Wed Mar 17 20:48:50 MDT 2010 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3756720128 (3582MB) avail mem = 3650265088 (3481MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xfb980 (77 entries) bios0: vendor American Megatrends Inc. version 080014 date 10/13/2008 bios0: Supermicro H8DMT /B -- internetlabbet.se / work: +46 8 551 124 80 / Words must Benny Lvfgren/ mobile: +46 70 718 11 90 / be weighed, / fax:+46 8 551 124 89/not counted. /email: benny -at- internetlabbet.se
OpenBSD Torrents - Tracker + Seed Hosting Needed
I currently run the OpenBSD torrent tracker at http://openbsd.somedomain.net as well as the primary seeder but due to external circumstances I am no longer able to continue hosting it. I am looking for someone interested and able to take this over. I am more than happy to help with administration of the tracker and seeding, but can no longer host it. The best candidate would be someone who already has a local OpenBSD mirror because this requires just a few things more than having a mirror. Below is described what I am using, but can also help set up a different system. * Running the tracker. It is currently a PHPBTTracker which requires PHP and MySQL, it does use mod_rewrite to do some pretty urls but that is not required. There may be better tracker software out now, but I've used this one since 2005 and it seems to work fine. It isn't currently on the same machine as the seeder and could really be anywhere. I can point openbsd.somedomain.net at a new address or you can use a new url and I can set up a redirect. * Creating the torrents. I have a collection of perl and shell scripts that create the torrents. Just pass a directory containing the files to be seeded and they will generate a torrent, compare it the existing torrent and if it is different, add it to the tracker and update the seeding client. There is another script that monitors the mirror log and when the mirror process switches to another directory regenerates the torrent. * Seeding the torrents. I am currently using Transmission for seeding, I was using the official Python BitTorrent client, but it was too much of a hog. The script above takes care of adding and removing torrents. So far Transmission seems to work well. * Changing version numbers for current and previous releases every 6 months. (This is the only manual step) If you already have a mirror you probably don't need to do this. I don't have a specific time frame when the transition needs to be complete, but I was hoping to have it done already. If I can't find a replacement soon, this service will have to go away, and the list will again be inundated with why aren't there torrents questions every 6 months. Let me know if you are interested and if so we can start working out the details. l8rZ, -- andrew - http://afresh1.com Computer Science: solving today's problems tomorrow.
Re: MAXDSIZ
On Wed, 30 Mar 2011 22:12:56 +0200 Benny Lofgren bl-li...@lofgren.biz wrote: On 2011-03-30 17.48, Jeff Ross wrote: On 03/30/11 05:21, Tony Berth wrote: Worse, an amd64 kernel looking at 8GB of real, physical ram only makes a wee bit under 3GB available. real mem = 3220111360 (3070MB) avail mem = 3120357376 (2975MB) That depends somewhat on the hardware you're running on, most likely the address space footprint made by the video memory. This is what one of my Supermicro servers looks like: real mem = 3756720128 (3582MB) avail mem = 3650265088 (3481MB) Yep, that 4gb limit is not available memory presented to the user, but is the maximum addressable memory space for the whole system. Those 2GB of RAM on the graphicscard, in order to be be accessible, are mapped into that area/amount before the user get's its share.
Re: sil3512 PCMCIA eSATA card not configured
On Wed, Mar 30, 2011 at 06:05:42PM +0100, iproudlyeat...@gmail.com wrote: On 30 March 2011 09:06, Jonathan Gray j...@goblin.cx wrote: We don't support pciide at cardbus yet. The cardbus code ideally needs to be folded into the pci code, this would solve these kinds of problems but is quite painful to do. Would an expresscard work? Yes as they show as pci, and expresscard to cardbus adapters with the cardbus card will work as well as the end result will show as pci there as well :)
Re: MAXDSIZ
OpenBSD just returns kernel page memory very very quickly, so it is difficult for it to consume more :). But seriously, after this compile, kernel was holding onto some memory. At idle (after compilation) it was an excess of 300-500M more, instead of 1-1.3G, it was around 1.7G. Opensolaris does aggressive caching trying to maintain and fill out all the available RAM, but OpenBSD gives back the memory very very quickly. concerning the file cache, sysctl kern.bufcachepercent=90 runs flawlessly; maybe worth a default setting. Might be okay for high physical memory machines but not low. I remember Opensolaris also filled out bufcache for ZFS, which was a bloated pig.
Re: MAXDSIZ
* Amit Kulkarni amitk...@gmail.com [2011-03-30 23:19]: Might be okay for high physical memory machines but not low. I remember Opensolaris also filled out bufcache for ZFS, which was a bloated pig. and ClaimsToBeOpen-Solaris' bufcache allocation strategies have exactly what to do with openbsd's? -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: MAXDSIZ
Nothing directly, just observing a comparison of default choice. OpenBSD opts for one strategy (bufcache = 10%) and Opensolaris opts for another (bufcache close to 100%). * Amit Kulkarni amitk...@gmail.com [2011-03-30 23:19]: Might be okay for high physical memory machines but not low. I remember Opensolaris also filled out bufcache for ZFS, which was a bloated pig. and ClaimsToBeOpen-Solaris' bufcache allocation strategies have exactly what to do with openbsd's?
Re: MAXDSIZ
* Amit Kulkarni amitk...@gmail.com [2011-03-31 00:45]: Nothing directly, just observing a comparison of default choice. OpenBSD opts for one strategy (bufcache = 10%) and Opensolaris opts for another (bufcache close to 100%). you are wrong. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Julio mes de la Secretaria, lV Convención Playa del Carmen 2011
[IMAGE] Pms Capacitacisn Efectiva de Mixico le presenta este programa: Convencisn Nacional Secretarmas Ejecutivas y Asistentes 2011 22-23 de Julio, Playa del Carmen Exclusivas conferencias presentadas por 3 Expertos Expositores Empresa Registrada ante la STPS Reg. COLG640205CP30005 Smguenos en Twitter@pmscapacitacion o bien en Facebook PMS de Mixico Solicite Mayores informes responda este correo electrsnico con los siguientes datos. Empresa: Nombre: Telifono: Email: Nzmero de Interesados: Y en breve le haremos llegar la informacisn completa del evento. O bien comunmquense a nuestros telifonos un ejecutivo con gusto le atendera Tels. (33) 8851-2365, (33)8851-2741. Copyright (C) 2010, PMS Capacitacisn Efectiva de Mixico S.C. Derechos Reservados. PMS de Mixico, El logo de PMS de Mixico son marcas registradas. ADVERTENCIA PMS de Mixico no cuenta con alianzas estratigicas de ningzn tipo dentro de la Republica Mexicana. NO SE DEJE ENGAQAR - DIGA NO A LA PIRATERIA. Todos los logotipos, marcas comerciales e imagenes son propiedad de sus respectivas corporaciones y se utilizan con fines informativos solamente. Este Mensaje ha sido enviado a misc@openbsd.org como usuario de Pms de Mixico o bien un usuario le refiris para recibir este boletmn. Como usuario de Pms de Mixico, en este acto autoriza de manera expresa que Pms de Mixico le puede contactar vma correo electrsnico u otros medios. Si usted ha recibido este mensaje por error, haga caso omiso de el y reporte su cuenta respondiendo este correo con el subject BAJACONVENCION Unsubscribe to this mailing list, reply a blank message with the subject UNSUBSCRIBE BAJACONVENCION Tenga en cuenta que la gestisn de nuestras bases de datos es de suma importancia y no es intencisn de la empresa la inconformidad del receptor. [demime 1.01d removed an attachment of type image/jpeg which had a name of image001.jpg]
Re: MAXDSIZ
* Amit Kulkarni amitk...@gmail.com [2011-03-31 01:09]: On Wed, Mar 30, 2011 at 5:47 PM, Henning Brauer lists-open...@bsws.de wrote: * Amit Kulkarni amitk...@gmail.com [2011-03-31 00:45]: Nothing directly, just observing a comparison of default choice. OpenBSD opts for one strategy (bufcache = 10%) and Opensolaris opts for another (bufcache close to 100%). you are wrong. where? please educate me. your guess on the reasoning for the default is oh so wrong. nuff said. have a beer or 13, relax and wait. (and your 13 gonna be cheaper than one bjor here) -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: MAXDSIZ
On 03/30/11 19:18, Henning Brauer wrote: * Amit Kulkarniamitk...@gmail.com [2011-03-31 01:09]: On Wed, Mar 30, 2011 at 5:47 PM, Henning Brauerlists-open...@bsws.de wrote: * Amit Kulkarniamitk...@gmail.com [2011-03-31 00:45]: Nothing directly, just observing a comparison of default choice. OpenBSD opts for one strategy (bufcache = 10%) and Opensolaris opts for another (bufcache close to 100%). you are wrong. where? please educate me. your guess on the reasoning for the default is oh so wrong. nuff said. have a beer or 13, relax and wait. (and your 13 gonna be cheaper than one bjor here) Gonna chime in that I'm quite curious as well. Anyone else care to explain why? My assumptions for why OpenBSD's bufcache percent being low are probably quite wrong. And what are we readers to wait for, anyway?
Re: MAXDSIZ
* Scott McEachern sc...@blackstaff.ca [2011-03-31 01:26]: And what are we readers to wait for, anyway? the bump. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: MAXDSIZ
On 3/30/11 7:23 PM, Scott McEachern wrote: On 03/30/11 19:18, Henning Brauer wrote: * Amit Kulkarniamitk...@gmail.com [2011-03-31 01:09]: On Wed, Mar 30, 2011 at 5:47 PM, Henning Brauerlists-open...@bsws.de wrote: * Amit Kulkarniamitk...@gmail.com [2011-03-31 00:45]: Nothing directly, just observing a comparison of default choice. OpenBSD opts for one strategy (bufcache = 10%) and Opensolaris opts for another (bufcache close to 100%). you are wrong. where? please educate me. your guess on the reasoning for the default is oh so wrong. nuff said. have a beer or 13, relax and wait. (and your 13 gonna be cheaper than one bjor here) Gonna chime in that I'm quite curious as well. Anyone else care to explain why? My assumptions for why OpenBSD's bufcache percent being low are probably quite wrong. And what are we readers to wait for, anyway? OK, I may be way off track and totally wrong here, but isn't that worked Bob did may be two hacketon ago and the bufcache isn't limited to 10% anymore, but goes all the way to 90%. My memory may be failing me big time, but I clearly remember him acting up a lots on the buffer cache in OpenBSD and there was actually very funny comments at that hacketon including some developers saying the eared like girls high pitch scream or something. (; May be was the wrong work, but I clearly remember that being Bob screaming as well based on the feedback. Way to lazy to find reference to in on undeadly, but I believe that's possibly what Henning is suggesting to you. Again unless I am way off and that's really possible, OpenBSD do not use only 10% buffer cache for some time now and thanks to Bob for that! But again, may be I put my foot in my mouth once more. (; Best, Daniel
Re: MAXDSIZ
where? please educate me. On Wed, Mar 30, 2011 at 5:47 PM, Henning Brauer lists-open...@bsws.de wrote: * Amit Kulkarni amitk...@gmail.com [2011-03-31 00:45]: Nothing directly, just observing a comparison of default choice. OpenBSD opts for one strategy (bufcache = 10%) and Opensolaris opts for another (bufcache close to 100%). you are wrong.
Re: Performance degradation after upgrade
2011/3/30 Peter Hallin peter.hal...@ldc.lu.se Ok, now we have been doing some testing and probably found the problem. All tests were done on the same machine with an Intel S5000VSA MB and a Xeon E5420 2,5 Ghz processor, running OpenBSD 4.8 amd64 GENERIC (SP kernel). We tested the performance with iperf, running two clients connected through a bridge. With the Intel Pro/1000 PCIe (82576) dual port cards with the bridge between two cards (in this case em0 to em2) we got the worst performance, 150 Mbit/s. While testing this and watching with 'systat vmstat', the CPU was 99% busy handling interrupts. The amount of interrupts were about 3000/s on em0 (where the iperf client was connected) and 1500/s on em2 (iperf server). At the same time 'systat ifs' showed about 10 new livelocks per second. Next we tested regular PCI Intel Pro/1000MT (82545GM) cards and now we got the performance we had hoped for in the first place. 910 Mbit/s with 8000 intr/s on both cards at 50% CPU (intr). No livelocks. We thought perhaps the issue was related to the PCIe bus, so we did one final test, this time with quad port Intel Pro/1000 QP (82576) PCIe cards. These performed excellent, with 940 Mbit/s, 8200 intr/s per card and 60% CPU (intr). So, it seems the dual port PCIe cards suck and we have to replace them. //Peter Just as curiosity: Did you used both ports from the Intel Pro/1000 PCIe (82576)? And if is used a single port PCI-Ex Intel Card?
Re: MAXDSIZ
Henning, Hey you guys are going to bump up the default and enable bigmem as default too? :) Is it scheduled for this hackathon? Daniel, Thanks, I will look into that. Undeadly is good. OK, I may be way off track and totally wrong here, but isn't that worked Bob did may be two hacketon ago and the bufcache isn't limited to 10% anymore, but goes all the way to 90%. My memory may be failing me big time, but I clearly remember him acting up a lots on the buffer cache in OpenBSD and there was actually very funny comments at that hacketon including some developers saying the eared like girls high pitch scream or something. (; May be was the wrong work, but I clearly remember that being Bob screaming as well based on the feedback. Way to lazy to find reference to in on undeadly, but I believe that's possibly what Henning is suggesting to you. Again unless I am way off and that's really possible, OpenBSD do not use only 10% buffer cache for some time now and thanks to Bob for that! But again, may be I put my foot in my mouth once more. (; Best, Daniel
Facture N� 18965874
[IMAGE] Chers clients ! --- Pour la Nouvelle security de 2011 , Nous avons recemment examine votre compte et nous avons besoin de plus d'informations sur votre entreprise pour nous permettre de fournir un service ininterrompu. Jusqu a ce que nous pouvons recueillir cette information, l'acces a votre compte de caracteristiques sensibles sera limite. Nous tenons a retablir votre acces le plus rapidement possible. Nous nous excusons pour la gene occasionnee. . Comment puis-je retablir l'acces a mon compte? Accedez a votre compte ici Merci pour votre coopiration Copyright ) 2011 FreeBox (France) Free.fr
Re: MAXDSIZ
If you use real hardware bigmen is default. On Wed, 30 Mar 2011 19:57 -0500, Amit Kulkarni amitk...@gmail.com wrote: Henning, Hey you guys are going to bump up the default and enable bigmem as default too? :) Is it scheduled for this hackathon? Daniel, Thanks, I will look into that. Undeadly is good. OK, I may be way off track and totally wrong here, but isn't that worked Bob did may be two hacketon ago and the bufcache isn't limited to 10% anymore, but goes all the way to 90%. My memory may be failing me big time, but I clearly remember him acting up a lots on the buffer cache in OpenBSD and there was actually very funny comments at that hacketon including some developers saying the eared like girls high pitch scream or something. (; May be was the wrong work, but I clearly remember that being Bob screaming as well based on the feedback. Way to lazy to find reference to in on undeadly, but I believe that's possibly what Henning is suggesting to you. Again unless I am way off and that's really possible, OpenBSD do not use only 10% buffer cache for some time now and thanks to Bob for that! But again, may be I put my foot in my mouth once more. (; Best, Daniel
