Re: mfi timeouts
Hi, I have just tested mfi on a machine that has just arrived. I'm seeing the command timeout problem on boot with 9.0-RC1. The message is mfi0: COMMAND addr TIMEOUT AFTER 59 seconds, and then repeats every 30 seconds (with the time changed, obviously). I have tested the 9.0-RC1 ISO, a 9-stable kernel patched with the patch from the PR I referenced below (also in FreeBSD cvs in revision 1.62 of src/sys/dev/mfi/mfi.c), and 9-stable kernel with the patch at www.freebsd.org/~jhb/patches/mfi.patch with the 'pci_alloc_msix' call changed to 'pci_alloc_msi'. I'm setting up a test with the pci_alloc_msix call unchanged at the moment, but I don't have anything in /boot/loader.conf, so that I'm not expecting that to make a difference. This is on a Supermicro X8DTi-F, 48GB memory and an LSI MegaRAID 9261-8i. 8.2-RELEASE boots fine, dmesg and some output from mfiutil below. Any suggestions gratefully received! Thanks, Jan Mikkelsen On 09/11/2011, at 10:39 AM, Vincent Hoffman wrote: On 08/11/2011 22:24, Vincent Hoffman wrote: On 08/11/2011 19:50, John Baldwin wrote: On Wednesday, November 02, 2011 5:47:38 pm Vincent Hoffman wrote: On 28/10/2011 04:14, Jan Mikkelsen wrote: Hi, There is a patch linked to from this PR, which seems very similar: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/140416 http://lists.freebsd.org/pipermail/freebsd-scsi/2011-March/004839.html The problem is also consistent with running mfiutil clearing the problem. I'm about to deploy mfi controllers in a similar configuration, so I'd be very curious about whether the patch fixes the problem for you. The patch you linked to seems to have removed the stalls, although I have only had it running for a day. I'll post if it stalls again though. I did manage to scrounge the use of a Dell r410 with a LSI Logic / Symbios Logic MegaRAID SAS 2108 [Liberator] (rev 05) Badged as Dell PERC H700 Adapter to test out the patch I originally found but had the same issue as this post http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063821.html I couldnt get the dell to stall in the first place either though so it could be a specific firmware version that the issue. Anyway thanks for the pointers. Hmm, did you try the patch I had posted from that earlier thread? It had two changes in it, one was similar to the patch in the PR, the second added MSI-X support. I've since tweaked it to make the MSI-X support off by default but possible to enable via loader.conf. Would you be willing to try the updated patch at www.freebsd.org/~jhb/patches/mfi.patch? Hi, yes I tried the patch you posted originally, unfortunately the dell never finished booting either. The Supermicro is now in production but I'll take the dell up to 9-STABLE and try your updated patch. The patch didnt apply quite cleanly for 9-STABLE, 1 reject as it had already been applied. I have rebooted the dell and it seems happy with the new patch (msi disabled.) Booting with hw.mfi.msix=1 in /boot/loader.conf causes the timeouts again and stops the boot from completing. I can give root access to the machine if this would be helpful, I cant give KVM access though unfortunately. (but can look in from time to time if needed.) Vince Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.2-RELEASE #0: Thu May 26 14:33:45 EST 2011 r...@valhalla.transactionware.com:/home/janm/p4/freebsd-image-std-2008.2/work/base-freebsd/home/janm/p4/freebsd-image-std-2008.2/FreeBSD/src/sys/GENERIC amd64 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU E5645 @ 2.40GHz (2409.70-MHz K8-class CPU) Origin = GenuineIntel Id = 0x206c2 Family = 6 Model = 2c Stepping = 2 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x9ee3fdSSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT AMD Features=0x2c100800SYSCALL,NX,Page1GB,RDTSCP,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 51543801856 (49156 MB) avail memory = 49664753664 (47364 MB) ACPI APIC Table: SUPERM APIC1519 FreeBSD/SMP: Multiprocessor System Detected: 24 CPUs FreeBSD/SMP: 2 package(s) x 6 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 16 cpu7 (AP): APIC ID: 17 cpu8 (AP): APIC ID: 18 cpu9 (AP): APIC ID: 19 cpu10 (AP): APIC ID: 20 cpu11 (AP): APIC ID: 21 cpu12 (AP): APIC ID: 32 cpu13 (AP): APIC ID: 33 cpu14 (AP): APIC ID: 34 cpu15 (AP): APIC ID: 35 cpu16 (AP): APIC ID: 36 cpu17 (AP): APIC ID: 37 cpu18 (AP):
Re: mfi timeouts
Following up ... Booting the 9-stable kernel with the patch from http://www.freebsd.org/~jhb/patches/mfi.patch, modified to use pci_alloc_msi with hw.mfi.msix=1 boots OK. Haven't put any load on it yet. Will try the plain patch without the pci_alloc_msi change. On 14/11/2011, at 7:03 PM, Jan Mikkelsen wrote: Hi, I have just tested mfi on a machine that has just arrived. I'm seeing the command timeout problem on boot with 9.0-RC1. The message is mfi0: COMMAND addr TIMEOUT AFTER 59 seconds, and then repeats every 30 seconds (with the time changed, obviously). I have tested the 9.0-RC1 ISO, a 9-stable kernel patched with the patch from the PR I referenced below (also in FreeBSD cvs in revision 1.62 of src/sys/dev/mfi/mfi.c), and 9-stable kernel with the patch at www.freebsd.org/~jhb/patches/mfi.patch with the 'pci_alloc_msix' call changed to 'pci_alloc_msi'. I'm setting up a test with the pci_alloc_msix call unchanged at the moment, but I don't have anything in /boot/loader.conf, so that I'm not expecting that to make a difference. This is on a Supermicro X8DTi-F, 48GB memory and an LSI MegaRAID 9261-8i. 8.2-RELEASE boots fine, dmesg and some output from mfiutil below. Any suggestions gratefully received! Thanks, Jan Mikkelsen On 09/11/2011, at 10:39 AM, Vincent Hoffman wrote: On 08/11/2011 22:24, Vincent Hoffman wrote: On 08/11/2011 19:50, John Baldwin wrote: On Wednesday, November 02, 2011 5:47:38 pm Vincent Hoffman wrote: On 28/10/2011 04:14, Jan Mikkelsen wrote: Hi, There is a patch linked to from this PR, which seems very similar: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/140416 http://lists.freebsd.org/pipermail/freebsd-scsi/2011-March/004839.html The problem is also consistent with running mfiutil clearing the problem. I'm about to deploy mfi controllers in a similar configuration, so I'd be very curious about whether the patch fixes the problem for you. The patch you linked to seems to have removed the stalls, although I have only had it running for a day. I'll post if it stalls again though. I did manage to scrounge the use of a Dell r410 with a LSI Logic / Symbios Logic MegaRAID SAS 2108 [Liberator] (rev 05) Badged as Dell PERC H700 Adapter to test out the patch I originally found but had the same issue as this post http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063821.html I couldnt get the dell to stall in the first place either though so it could be a specific firmware version that the issue. Anyway thanks for the pointers. Hmm, did you try the patch I had posted from that earlier thread? It had two changes in it, one was similar to the patch in the PR, the second added MSI-X support. I've since tweaked it to make the MSI-X support off by default but possible to enable via loader.conf. Would you be willing to try the updated patch at www.freebsd.org/~jhb/patches/mfi.patch? Hi, yes I tried the patch you posted originally, unfortunately the dell never finished booting either. The Supermicro is now in production but I'll take the dell up to 9-STABLE and try your updated patch. The patch didnt apply quite cleanly for 9-STABLE, 1 reject as it had already been applied. I have rebooted the dell and it seems happy with the new patch (msi disabled.) Booting with hw.mfi.msix=1 in /boot/loader.conf causes the timeouts again and stops the boot from completing. I can give root access to the machine if this would be helpful, I cant give KVM access though unfortunately. (but can look in from time to time if needed.) Vince Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.2-RELEASE #0: Thu May 26 14:33:45 EST 2011 r...@valhalla.transactionware.com:/home/janm/p4/freebsd-image-std-2008.2/work/base-freebsd/home/janm/p4/freebsd-image-std-2008.2/FreeBSD/src/sys/GENERIC amd64 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU E5645 @ 2.40GHz (2409.70-MHz K8-class CPU) Origin = GenuineIntel Id = 0x206c2 Family = 6 Model = 2c Stepping = 2 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x9ee3fdSSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT AMD Features=0x2c100800SYSCALL,NX,Page1GB,RDTSCP,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 51543801856 (49156 MB) avail memory = 49664753664 (47364 MB) ACPI APIC Table: SUPERM APIC1519 FreeBSD/SMP: Multiprocessor System Detected: 24 CPUs FreeBSD/SMP: 2 package(s) x 6 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP):
stable fails to build for me
I'm running into this: === gnu/lib/libsupc++ (install) clang -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/usr.bin/lex/lib/libyywrap.c install -C -C -o root -g wheel -m 444 libsupc++.a /usr/obj/usr/src/tmp/usr/lib /usr/src/lib/libgpib/ibfoo.c:37:10: fatal error: 'dev/ieee488/ugpib.h' file not found #include dev/ieee488/ugpib.h ^ 1 error generated. mkdep: compile failed /etc/src.conf: WITHOUT_ACCT='yes' WITHOUT_ATM='yes' WITHOUT_AUTHPF='yes' WITHOUT_CTM='yes' WITHOUT_FREEBSD_UPDATE='yes' WITHOUT_HTML='yes' WITHOUT_I4B='yes' WITHOUT_IPFILTER='yes' WITHOUT_IPFW='yes' WITHOUT_IPX='yes' WITHOUT_NDIS='yes' WITHOUT_PMC='yes' WITHOUT_PORTSNAP='yes' WITHOUT_PROFILE='yes' WITHOUT_QUOTAS='yes' WITHOUT_RCMDS='yes' WITHOUT_RCS='yes' WITHOUT_ROUTED='yes' WITHOUT_SENDMAIL='yes' WITHOUT_SLIP='yes' WITHOUT_SYSINSTALL='yes' WITHOUT_WIRELESS='yes' -- Sphinx of black quartz judge my vow. ___ 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: stable fails to build for me [bad setup]
14.11.2011 10:06, Volodymyr Kostyrko wrote: I'm running into this: === gnu/lib/libsupc++ (install) clang -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/usr.bin/lex/lib/libyywrap.c install -C -C -o root -g wheel -m 444 libsupc++.a /usr/obj/usr/src/tmp/usr/lib /usr/src/lib/libgpib/ibfoo.c:37:10: fatal error: 'dev/ieee488/ugpib.h' file not found #include dev/ieee488/ugpib.h ^ 1 error generated. mkdep: compile failed /etc/src.conf: WITHOUT_ACCT='yes' WITHOUT_ATM='yes' WITHOUT_AUTHPF='yes' WITHOUT_CTM='yes' WITHOUT_FREEBSD_UPDATE='yes' WITHOUT_HTML='yes' WITHOUT_I4B='yes' WITHOUT_IPFILTER='yes' WITHOUT_IPFW='yes' WITHOUT_IPX='yes' WITHOUT_NDIS='yes' WITHOUT_PMC='yes' WITHOUT_PORTSNAP='yes' WITHOUT_PROFILE='yes' WITHOUT_QUOTAS='yes' WITHOUT_RCMDS='yes' WITHOUT_RCS='yes' WITHOUT_ROUTED='yes' WITHOUT_SENDMAIL='yes' WITHOUT_SLIP='yes' WITHOUT_SYSINSTALL='yes' WITHOUT_WIRELESS='yes' I'm sorry, for some unknown reason the host lacks /usr/include/dev directory... -- Sphinx of black quartz judge my vow. ___ 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: mfi timeouts
On Thursday, November 10, 2011 5:59:28 am Vincent Hoffman wrote: On 09/11/2011 14:39, John Baldwin wrote: On Tuesday, November 08, 2011 6:39:07 pm Vincent Hoffman wrote: On 08/11/2011 22:24, Vincent Hoffman wrote: On 08/11/2011 19:50, John Baldwin wrote: Hmm, did you try the patch I had posted from that earlier thread? It had two changes in it, one was similar to the patch in the PR, the second added MSI-X support. I've since tweaked it to make the MSI-X support off by default but possible to enable via loader.conf. Would you be willing to try the updated patch at www.freebsd.org/~jhb/patches/mfi.patch? Hi, yes I tried the patch you posted originally, unfortunately the dell never finished booting either. The Supermicro is now in production but I'll take the dell up to 9-STABLE and try your updated patch. The patch didnt apply quite cleanly for 9-STABLE, 1 reject as it had already been applied. Odd, it's against stock head, so I don't know why it would have failed to apply. I have rebooted the dell and it seems happy with the new patch (msi disabled.) Okay, good. I'll commit the non-MSI bits at least and get them merged into 9.0 if possible. Booting with hw.mfi.msix=1 in /boot/loader.conf causes the timeouts again and stops the boot from completing. Ok. Can you try changing it to use MSI instead of MSI-X? Just edit the mfi_pci.c call and replace 'pci_alloc_msix' with 'pci_alloc_msi'. Well the dell has been up for about 19 hours now using MSI, I ran bonnie++ a few times on it and have now stuck it in a permanent loop (will look in from time to time.) Are there any tests you'd like run/info you'd like? No, this looks good. I'll probably commit something to mfi to just enable MSI only (but with a tunable that defaults to off) so people can do broader testing. -- John Baldwin ___ 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: mfi timeouts
On Monday, November 14, 2011 3:03:42 am Jan Mikkelsen wrote: Hi, I have just tested mfi on a machine that has just arrived. I'm seeing the command timeout problem on boot with 9.0-RC1. The message is mfi0: COMMAND addr TIMEOUT AFTER 59 seconds, and then repeats every 30 seconds (with the time changed, obviously). I have tested the 9.0-RC1 ISO, a 9-stable kernel patched with the patch from the PR I referenced below (also in FreeBSD cvs in revision 1.62 of src/sys/dev/mfi/mfi.c), and 9-stable kernel with the patch at www.freebsd.org/~jhb/patches/mfi.patch with the 'pci_alloc_msix' call changed to 'pci_alloc_msi'. You forgot to mention what happened from those tests, did any of them work? -- John Baldwin ___ 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
9.0-RC2: regression in power management on VIA Samuel 2
Hi, I have a few machines (mostly routers) with VIA Samuel 2. FreeBSD 9.0-RC2 breaks power management on them. 8.2-RELEASE detects: CPU: VIA Samuel 2 (532.64-MHz 686-class CPU) Origin = CentaurHauls Id = 0x673 Family = 6 Model = 7 Stepping = 3 Features=0x803035FPU,DE,TSC,MSR,MTRR,PGE,MMX and sysctl dev.cpu.0 says: dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 532 dev.cpu.0.freq_levels: 532/-1 266/-1 dev.cpu.0.cx_supported: C1/0 C2/90 C3/900 dev.cpu.0.cx_lowest: C2 dev.cpu.0.cx_usage: 0.45% 99.54% 0.00% last 783us In 8.2 I can use dev.cpu.0.cx_lowest=C2 in /etc/sysctl.conf and powerd runs fine switching between 532 and 266 MHz. FreeBSD 9.0-RC2 detects: CPU: VIA Samuel 2 (532.65-MHz 686-class CPU) Origin = CentaurHauls Id = 0x673 Family = 6 Model = 7 Stepping = 3 Features=0x803035FPU,DE,TSC,MSR,MTRR,PGE,MMX AMD Features=0x80003DNow! ^^^ the only difference and sysctl dev.cpu.0 is: dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.cx_supported: C1/0 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% last 208us Of course, dev.cpu.0.cx_lowest=C2 is not available and powerd cannot start - powerd -v fails: powerd: lookup freq: No such file or directory I haven't studied sources yet but it seems to me AMD is detected (wrong) and for that reason a wrong power management code path takes place. Is anybody willing to help me with debugging? I have no experience in such low level programming but at least one spare machine and some time to waste. TIA, Oli ___ 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: mfi timeouts
On Thursday, November 10, 2011 5:59:28 am Vincent Hoffman wrote: On 09/11/2011 14:39, John Baldwin wrote: On Tuesday, November 08, 2011 6:39:07 pm Vincent Hoffman wrote: On 08/11/2011 22:24, Vincent Hoffman wrote: On 08/11/2011 19:50, John Baldwin wrote: Hmm, did you try the patch I had posted from that earlier thread? It had two changes in it, one was similar to the patch in the PR, the second added MSI-X support. I've since tweaked it to make the MSI-X support off by default but possible to enable via loader.conf. Would you be willing to try the updated patch at www.freebsd.org/~jhb/patches/mfi.patch? Hi, yes I tried the patch you posted originally, unfortunately the dell never finished booting either. The Supermicro is now in production but I'll take the dell up to 9-STABLE and try your updated patch. The patch didnt apply quite cleanly for 9-STABLE, 1 reject as it had already been applied. Odd, it's against stock head, so I don't know why it would have failed to apply. I have rebooted the dell and it seems happy with the new patch (msi disabled.) Okay, good. I'll commit the non-MSI bits at least and get them merged into 9.0 if possible. Booting with hw.mfi.msix=1 in /boot/loader.conf causes the timeouts again and stops the boot from completing. Ok. Can you try changing it to use MSI instead of MSI-X? Just edit the mfi_pci.c call and replace 'pci_alloc_msix' with 'pci_alloc_msi'. Well the dell has been up for about 19 hours now using MSI, I ran bonnie++ a few times on it and have now stuck it in a permanent loop (will look in from time to time.) Are there any tests you'd like run/info you'd like? Actually, can you please test www.freebsd.org/~jhb/patches/mfi_msi.patch? You will have to set the hw.mfi.msi=1 tunable to enable MSI support. This is a commit candidate if it works. Thanks. -- John Baldwin ___ 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
8.2 + apache == a LOT of sigprocmask
Trying to track down a load problem we're seeing on 8.2-RELEASE-p4 i386 in a busy web hosting environment I came across the following post: http://lists.freebsd.org/pipermail/freebsd-questions/2011-October/234520.html That basically describes what we're seeing as well, including the doesn't happen on Linux part. Does anyone have any ideas about this? With incredibly similar stuff running on 7.x we didn't see this problem, so it seems to be something new in 8. -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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
Re: pkg_add -r does not find packages FreeBSD 9.0 rc1
On Sat, Nov 12, 2011 at 06:13:59PM +0200, Luchesar V. ILIEV wrote: On 12/11/2011 16:36, Kenneth Hatteland wrote: I have installed RC1 and after getting confused with the new install routines, I have my system up. But when I try to install packages like nano and cvsup-without-gui to build my machine up from base the system reports no packages found. This have only rarely happened on my other systems and never on a fresh install.any clues ??? Could it be related to this PR? http://www.freebsd.org/cgi/query-pr.cgi?pr=162490 This is an unfortunate sideeffect of our current release process for major version releases where it's hard to synchronize the change needed to pkg_add and the package sets on the mirrors. There are some workarounds that may make this a bit less painfull, but in general this is one of the reasons why we really should aim for maing the src and ports releases independent from eachother. For now, the best option for BETA and RSs is to override PACKAGESITE as Bane Ivosev suggested. Erwin -- Erwin Lansing http://droso.org Prediction is very difficult especially about the futureer...@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: 8.2 + apache == a LOT of sigprocmask
On 11/14/2011 12:31, Doug Barton wrote: Trying to track down a load problem we're seeing on 8.2-RELEASE-p4 i386 in a busy web hosting environment I came across the following post: http://lists.freebsd.org/pipermail/freebsd-questions/2011-October/234520.html That basically describes what we're seeing as well, including the doesn't happen on Linux part. Does anyone have any ideas about this? With incredibly similar stuff running on 7.x we didn't see this problem, so it seems to be something new in 8. Just took a closer look at our ktrace, and actually our pattern is slightly different than the one in that post. In ours the second option is null, but the third is set: 74195 httpd0.17 RET sigprocmask 0 74195 httpd0.13 CALL sigprocmask(SIG_BLOCK,0,0xbfbf89d4) 74195 httpd0.09 RET sigprocmask 0 74195 httpd0.13 CALL sigprocmask(SIG_BLOCK,0,0xbfbf89d4) 74195 httpd0.09 RET sigprocmask 0 74195 httpd0.12 CALL sigprocmask(SIG_BLOCK,0,0xbfbf89d4) But repeated hundreds of times in a row. -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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
Re: 8.2 + apache == a LOT of sigprocmask
On Monday, November 14, 2011 3:31:43 pm Doug Barton wrote: Trying to track down a load problem we're seeing on 8.2-RELEASE-p4 i386 in a busy web hosting environment I came across the following post: http://lists.freebsd.org/pipermail/freebsd-questions/2011- October/234520.html That basically describes what we're seeing as well, including the doesn't happen on Linux part. Does anyone have any ideas about this? With incredibly similar stuff running on 7.x we didn't see this problem, so it seems to be something new in 8. I suspect it has to do with some of the changes to rtld such that it now always blocks signals while resolving symbols (or something along those lines IIRC). It makes throwing exceptions slow as well. -- John Baldwin ___ 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: 8.2 + apache == a LOT of sigprocmask
On 11/14/2011 12:56, John Baldwin wrote: On Monday, November 14, 2011 3:31:43 pm Doug Barton wrote: Trying to track down a load problem we're seeing on 8.2-RELEASE-p4 i386 in a busy web hosting environment I came across the following post: http://lists.freebsd.org/pipermail/freebsd-questions/2011- October/234520.html That basically describes what we're seeing as well, including the doesn't happen on Linux part. Does anyone have any ideas about this? With incredibly similar stuff running on 7.x we didn't see this problem, so it seems to be something new in 8. I suspect it has to do with some of the changes to rtld such that it now always blocks signals while resolving symbols (or something along those lines IIRC). It makes throwing exceptions slow as well. The calls to sigprocmask() in rtld seem to be doing what you suggest here, but they involve setting and restoring the mask. In my followup post I pasted what we're seeing, which is different, and much more voluminous. For example, 13,500 calls in 30 seconds from a single apache worker process. Although this does seem to explain why our test cases have more calls when compiled with C++ than they do when compiled with C. :) Thanks for the response in any case. Doug -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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
Re: pkg_add -r does not find packages FreeBSD 9.0 rc1
On Mon, 14 Nov 2011 at 15:49 -, Erwin Lansing wrote: This is an unfortunate sideeffect of our current release process for major version releases where it's hard to synchronize the change needed to pkg_add and the package sets on the mirrors. This might be another sign of too frequent major releases. Like some others I would prefer to see fewer major version number changes. A longer lived stable series is preferable (like 3.X and 4.X). Since FreeBSD in not the OS I use most often (unfortunately, since I do prefer BSD), I tend to lag on my personal installations. I'm still at 8.1 and would probably go to 8.3 sometime soon if it became available. I'm not ready for the breakage 9.X might entail for me. Yes, these are just numbers and might not have actual significance. I will probably also be happy to go with 9.0 when released. Common use (and declared FreeBSD use) is that changes with breakage imply the major version number changes and changes without major breakage change the minor version number. I have been the frustrated programmer who is eager to get my code out running on more systems. I have also been the frustrated user waiting for some needed new functionality only in a development/test environment. Trading off the various needs will never satisfy anyone. Note: I'm far more frustrated seeing Firefox hit 8.0 and am glad that Firefox 3.6 is still in ports (even if not the default version). Stuart -- I've never been lost; I was once bewildered for three days, but never lost! -- Daniel Boone ___ 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
Something broken with libdnet? Or FreeBSD 9.0-RC1?
Hello list, I was updating one of my Perl module (Net::Libdnet), and came accross a bug under FreeBSD 9.0-RC1 and libdnet. My setup is one interface configured with multiple aliases. See details at the end of the message. One host works ok (FreeBSD 8.2-RELEASE), and another fails to find correct IP information (FreeBSD 9.0-RC1). The main bug is that under 9.0-RC1, libdnet fails to find the correct inet address for the interface. It gets the first alias instead. I don't know if the bug comes from libdnet or 9.0-RC1, so I let knowledgeable people here to look at it (or not). For those who want to test, you can install libdnet from /usr/ports/net/libdnet. Host FreeBSD 8.2-RELEASE (ok): % ifconfig re0 re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=389bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC ether MAC_ADDR inet PUBLIC_IP4 netmask 0xff00 broadcast PUBLIC_IP4.255 inet6 LOCAL_IP6%re0 prefixlen 64 scopeid 0x1 inet 192.168.0.10 netmask 0x broadcast 192.168.0.10 [...many aliases...] inet6 PUBLIC_IP6::2 prefixlen 128 inet6 PUBLIC_IP6::3 prefixlen 128 inet6 PUBLIC_IP6::4 prefixlen 128 inet6 PUBLIC_IP6::5 prefixlen 128 inet6 PUBLIC_IP6::1 prefixlen 56 % dnet intf get re0 re0: flags=0x31UP,BROADCAST,MULTICAST mtu 1500 inet PUBLIC_IP4/24 link MAC_ADDR alias fe80:1::21c:c0ff:feca:1178/64 alias 192.168.0.10 [...many aliases...] alias PUBLIC_IP6::2/0 alias PUBLIC_IP6::3/0 alias PUBLIC_IP6::4/0 alias PUBLIC_IP6::5/0 alias PUBLIC_IP6::1/0 Host FreeBSD 9.0-RC1 (not ok): % ifconfig re0 re0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=389bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC ether MAC_ADDR inet 192.168.2.10 netmask 0x broadcast 192.168.2.10 [...many aliases...] inet 192.168.1.148 netmask 0xff00 broadcast 192.168.1.255 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseT full-duplex) status: active % dnet intf get re0 re0: flags=0x31UP,BROADCAST,MULTICAST mtu 1500 inet 192.168.2.10 link MAC_ADDR alias 192.168.2.11 alias 192.168.2.12 alias 192.168.2.13 alias 192.168.2.14 alias 192.168.1.148 # Correct inet address -- ^ ___ ___ http://www.GomoR.org/ -+ | / __ |__/Senior Security Engineer | | \__/ | \ ---[ zsh$ alias psed='perl -pe ' ]---| +-- Net::Frame = http://search.cpan.org/~gomor/ ---+ ___ 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
Something broken with libdnet? Or FreeBSD 9.0-RC1?
Hello list, I was updating one of my Perl module (Net::Libdnet), and came accross a bug under FreeBSD 9.0-RC1 and libdnet. My setup is one interface configured with multiple aliases. See details at the end of the message. One host works ok (FreeBSD 8.2-RELEASE), and another fails to find correct IP information (FreeBSD 9.0-RC1). The main bug is that under 9.0-RC1, libdnet fails to find the correct inet address for the interface. It gets the first alias instead. I don't know if the bug comes from libdnet or 9.0-RC1, so I let knowledgeable people here to look at it (or not). For those who want to test, you can install libdnet from /usr/ports/net/libdnet. Host FreeBSD 8.2-RELEASE (ok): % ifconfig re0 re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=389bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC ether MAC_ADDR inet PUBLIC_IP4 netmask 0xff00 broadcast PUBLIC_IP4.255 inet6 LOCAL_IP6%re0 prefixlen 64 scopeid 0x1 inet 192.168.0.10 netmask 0x broadcast 192.168.0.10 [...many aliases...] inet6 PUBLIC_IP6::2 prefixlen 128 inet6 PUBLIC_IP6::3 prefixlen 128 inet6 PUBLIC_IP6::4 prefixlen 128 inet6 PUBLIC_IP6::5 prefixlen 128 inet6 PUBLIC_IP6::1 prefixlen 56 % dnet intf get re0 re0: flags=0x31UP,BROADCAST,MULTICAST mtu 1500 inet PUBLIC_IP4/24 link MAC_ADDR alias fe80:1::21c:c0ff:feca:1178/64 alias 192.168.0.10 [...many aliases...] alias PUBLIC_IP6::2/0 alias PUBLIC_IP6::3/0 alias PUBLIC_IP6::4/0 alias PUBLIC_IP6::5/0 alias PUBLIC_IP6::1/0 Host FreeBSD 9.0-RC1 (not ok): % ifconfig re0 re0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=389bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC ether MAC_ADDR inet 192.168.2.10 netmask 0x broadcast 192.168.2.10 [...many aliases...] inet 192.168.1.148 netmask 0xff00 broadcast 192.168.1.255 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseT full-duplex) status: active % dnet intf get re0 re0: flags=0x31UP,BROADCAST,MULTICAST mtu 1500 inet 192.168.2.10 link MAC_ADDR alias 192.168.2.11 alias 192.168.2.12 alias 192.168.2.13 alias 192.168.2.14 alias 192.168.1.148 # Correct inet address -- ^ ___ ___ http://www.GomoR.org/ -+ | / __ |__/Senior Security Engineer | | \__/ | \ ---[ zsh$ alias psed='perl -pe ' ]---| +-- Net::Frame = http://search.cpan.org/~gomor/ ---+ ___ 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
question on netstat statistics.
I've been trying to work out why my nfs mounts seem to be a little speed limited (thats another email though) and though I'd go through the stats netstat makes available. From the manpage netstat -i | -I interface -s [-f protocol_family | -p protocol] [-M core] [-N system] Display per-interface statistics for each network protocol, for a particular protocol_family, or for a single protocol. I was expecting to be able to see at least some tcp/ip stats per interface, but [root@banshee ~]# ifconfig -l igb0 igb1 lo0 lagg0 lagg0.53 lagg0.52 pflog0 lagg0.66 [root@banshee ~]# for int in $(ifconfig -l) ; do netstat -I $int -s -f inet; done [root@banshee ~]# I can get system wide using netstat -s -f inet and if use netstat -I $int -s I get a bunch of ipv6 stats. and of course i can get the stats from netstat -I $int too. Is this expected behaviour? if so maybe the manpage could be made a little clearer. Thanks, Vince ps tested on [root@ostracod ~]# uname -a FreeBSD ostracod.unsane.co.uk 9.0-RC1 FreeBSD 9.0-RC1 #15 r226879: Fri Oct 28 22:25:26 BST 2011 t...@ostracod.unsane.co.uk:/usr/obj/usr/src/sys/OSTRACOD amd64 [root@ostracod ~]# FreeBSD banshee.namesco.net 8.2-STABLE FreeBSD 8.2-STABLE #5: Wed Nov 2 14:53:03 GMT 2011 t...@banshee.lon.domain.com:/usr/obj/usr/src/sys/BANSHEE amd64 FreeBSD zfstest 9.0-RC2 FreeBSD 9.0-RC2 #0 r227497M: Mon Nov 14 16:14:54 GMT 2011 toor@zfstest:/usr/obj/usr/src/sys/ZFSTEST 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
Re: mfi timeouts
Hi, Sorry about being unclear. They all failed in the same way. So, these combinations have continuous timeout errors and fail to completely boot: Plain 9.0-RC1 9-stable with 1.62 of mfi.c 9-stable with www.freebsd.org/~jhb/patches/mfi.patch, pci_alloc_msi instead of pci_alloc_msix and hw.mfi.msix=0 This boots, but gets mfi0: Cannot allocate interrupt and there are no /dev/mfi* devices: 9-stable with www.freebsd.org/~jhb/patches/mfi.patch and hw.mfi.msix=1 This seems to work, but I have not put any load on it yet: 9-stable with www.freebsd.org/~jhb/patches/mfi.patch, pci_alloc_msi instead of pci_alloc_msix and hw.mfi.msix=1 I see you have a new patch, www.freebsd.org/~jhb/patches/mfi_msi.patch. This patch doesn't seem to include the dummy read from your earlier patch, or the one in 1.62 of mfi.c. I assume I need to apply the 1.62 mfi.c diff to by 9-stable sources as well. Is that correct? Will test out the new patch. Thanks, Jan Mikkelsen On 15/11/2011, at 3:36 AM, John Baldwin wrote: On Monday, November 14, 2011 3:03:42 am Jan Mikkelsen wrote: Hi, I have just tested mfi on a machine that has just arrived. I'm seeing the command timeout problem on boot with 9.0-RC1. The message is mfi0: COMMAND addr TIMEOUT AFTER 59 seconds, and then repeats every 30 seconds (with the time changed, obviously). I have tested the 9.0-RC1 ISO, a 9-stable kernel patched with the patch from the PR I referenced below (also in FreeBSD cvs in revision 1.62 of src/sys/dev/mfi/mfi.c), and 9-stable kernel with the patch at www.freebsd.org/~jhb/patches/mfi.patch with the 'pci_alloc_msix' call changed to 'pci_alloc_msi'. You forgot to mention what happened from those tests, did any of them work? -- John Baldwin ___ 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: question on netstat statistics.
On Mon, Nov 14, 2011 at 11:56:30PM +, Vincent Hoffman wrote:
I've been trying to work out why my nfs mounts seem to be a little speed
limited (thats another email though) and though I'd go through the stats
netstat makes available.
From the manpage
netstat -i | -I interface -s [-f protocol_family | -p protocol] [-M
core]
[-N system]
Display per-interface statistics for each network protocol,
for a
particular protocol_family, or for a single protocol.
I was expecting to be able to see at least some tcp/ip stats per
interface, but
[root@banshee ~]# ifconfig -l
igb0 igb1 lo0 lagg0 lagg0.53 lagg0.52 pflog0 lagg0.66
[root@banshee ~]# for int in $(ifconfig -l) ; do netstat -I $int -s -f
inet; done
[root@banshee ~]#
I can get system wide using netstat -s -f inet and if use netstat -I
$int -s I get a bunch of ipv6 stats.
and of course i can get the stats from netstat -I $int too.
Is this expected behaviour? if so maybe the manpage could be made a
little clearer.
Thanks,
Vince
ps tested on
[root@ostracod ~]# uname -a
FreeBSD ostracod.unsane.co.uk 9.0-RC1 FreeBSD 9.0-RC1 #15 r226879: Fri
Oct 28 22:25:26 BST 2011
t...@ostracod.unsane.co.uk:/usr/obj/usr/src/sys/OSTRACOD amd64
[root@ostracod ~]#
FreeBSD banshee.namesco.net 8.2-STABLE FreeBSD 8.2-STABLE #5: Wed Nov 2
14:53:03 GMT 2011
t...@banshee.lon.domain.com:/usr/obj/usr/src/sys/BANSHEE amd64
FreeBSD zfstest 9.0-RC2 FreeBSD 9.0-RC2 #0 r227497M: Mon Nov 14 16:14:54
GMT 2011 toor@zfstest:/usr/obj/usr/src/sys/ZFSTEST amd64
On my system:
netstat -s = returns system-wide statistics for all IP-related bits
netstat -I {iface} = returns network I/O statistics and related bits
associated with that interface
netstat -I {iface} -s = returns nothing (no output)
netstat -I {iface} -f inet = same as netstat -I {iface} but only
with IPv4 specific data
netstat -I {iface} -s -f inet = returns nothing (no output)
I think what you're actually looking for is, BTW:
netstat -I em0 -inbd
And if you want real-time I/O rates:
netstat -I em0 -bd 1
Where 1 is the number of seconds between polling iterations.
I don't particularly care what the man page says, I just know what
works. :-)
If you're wanting netstat -s output but on a per-interface basis,
those statistics are not tracked per-interface. Maybe netgraph can do
that for you, I do not know.
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, US |
| 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 freebsd-stable-unsubscr...@freebsd.org
Re: question on netstat statistics.
Hi, Jeremy Chadwick wrote: [...] I don't particularly care what the man page says, I just know what works. :-) If there is something in the man page that is not precise, I personally am interested in any inconsistencies with reality so they can be fixed. Even given your detailed explanation, I'm still not 100% clear on what, if anything, is incorrect in the manual. Regards, Glen -- Glen Barber | g...@freebsd.org FreeBSD Documentation Project pgpmEoto4GCuk.pgp Description: PGP signature
Re: question on netstat statistics.
On Mon, Nov 14, 2011 at 07:56:07PM -0500, Glen Barber wrote: Jeremy Chadwick wrote: [...] I don't particularly care what the man page says, I just know what works. :-) If there is something in the man page that is not precise, I personally am interested in any inconsistencies with reality so they can be fixed. Even given your detailed explanation, I'm still not 100% clear on what, if anything, is incorrect in the manual. FWIW, neither am I. The OP seems to be basing his argument syntaxes based on what's in the man page, so if something is vague, confusing, or inaccurate, he will need to state clearly what it is that's an anomaly. My comment was more along the lines of: if it's wrong in the man page, I'm really not that concerned (e.g. file a PR and be done with it). I'm still trying to work out exactly what it is the OP wants statistics-wise on a per-interface basis. I'm left thinking he wants netstat -s output per-interface, but that's not going to happen. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | 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 freebsd-stable-unsubscr...@freebsd.org
Re: question on netstat statistics.
On Mon, Nov 14, 2011 at 05:46:02PM -0800, Jeremy Chadwick wrote: On Mon, Nov 14, 2011 at 07:56:07PM -0500, Glen Barber wrote: Jeremy Chadwick wrote: [...] I don't particularly care what the man page says, I just know what works. :-) If there is something in the man page that is not precise, I personally am interested in any inconsistencies with reality so they can be fixed. Even given your detailed explanation, I'm still not 100% clear on what, if anything, is incorrect in the manual. FWIW, neither am I. The OP seems to be basing his argument syntaxes based on what's in the man page, so if something is vague, confusing, or inaccurate, he will need to state clearly what it is that's an anomaly. My comment was more along the lines of: if it's wrong in the man page, I'm really not that concerned (e.g. file a PR and be done with it). I'm still trying to work out exactly what it is the OP wants statistics-wise on a per-interface basis. I'm left thinking he wants netstat -s output per-interface, but that's not going to happen. Got it, thanks for clarifying. I (mis)read your statement as the manual is wrong, but here's the correct explanation. Thanks. Glen -- Glen Barber | g...@freebsd.org FreeBSD Documentation Project pgpqMh4djnPmN.pgp Description: PGP signature
