Re: Server motherboard recommendation wanted
Quoting Pete French <[EMAIL PROTECTED]>: We have great success using the Tyan Thunder K8SD-Pro (S2882-D) motherboard. It is a dual socket 940 motherboard that supports AMD Opteron 200-series CPU (including dual-core), 16 GB ECC DDR400 RAM, with 2 64-bit/133 MHz PCI-X slots, 2 64-bit/100 MHz PCI-X slots, and 1 32-bit/33 MHz PCI slot. Comes with onboard SATA and (optional) SCSI controllers. I can second this - I bought one after a recopmmendation on this list for a dual core Opteron board to replace a rather flaky MSI. It has performed magnificently, and is comletel stable, plus being well supported by FreBSD 9amd64 in my case). I run Adaptec SCSI controllers, and the onboard NIC's are good quality as well. definitely recommended. -pcf. I would also have to concur with this, and the previous post. We're running 3 Intel based Tyan dual CPU boards and they run/perform very well. Have dual onboard NIC's, 1 64bit PCI slot and 1 PCI-X slot, onboard video, 2 U-160 SCSI ports, 2 133 UATA IDE ports. The only possible "gotcha" with Tyan boards is they are very picky about RAM. So best bet is to use what Tyan approves of. or you may run into trouble. Other than that, I would have a real hard time finding anything but good to say about their boards. In short; FreeBSD (the OS) loves these boards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Right way to use geli + gjournal ?
Hi everyone,
In my laptop, I am running 7.0 Beta-4 (today's kernel + world). my /usr (ad0s1f
) is using gjournal, with its journal on ad0s1h .
I have it mounted with what I believe are the recommended settings:
$ mount
[...]
/dev/ad0s1f.journal on /usr (ufs, asynchronous, local, noatime, gjournal)
[...]
I also have some file-backed geli disks which reside in /usr/home/betom. They
are still using soft-updates (from before I had gjournal on /usr):
/dev/md11.eli on /usr/home/betom/_11 (ufs, local, noatime, soft-updates)
/dev/md13.eli on /usr/home/betom/_13 (ufs, local, noatime, soft-updates)
/dev/md12.eli on /usr/home/betom/_12 (ufs, local, noatime, soft-updates)
Does it make sense to set these GELI disks to async / no-soft-updates as well?
thanks!
Beto
_
{Beto|Norberto|Numard} Meijome
There are no stupid questions, but there are a LOT of inquisitive idiots.
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Is it safe to use CPUTYPE?=native on 7.0 ?
fairly simple question really - on machines where I never use the compiled binaries anywhere else, is it O.K. to set the CPU type to 'native' in make.conf ? According to gcc this should detect the processor type and set the various flas as approrpiate, which is nice, as we have a mix of P3, P4 and AMD processors around the place, and having one make.conf which will do the right thing on all of them would be nice. I've been trying it out on a couple of machines, and it seems to work fine, but I have a feeling that various bits of the kerenel complie are sensetive to the cpu type, so am just asking to check if it's O.K. cheers, -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
-net or kernel: where does this belong?
Posted on -questions but got no response, trying -current and -stable as
well. Sorry for the cross-post but I'm getting kind of desperate...
Hi all,
Since quite a while I have had problems with {CURRENT|RELENG_7} SMP
machines that lock up when accessed from a remote location over a vpn
(ipsec) link and sees a ICMP_REDIRECT.
A message, "kernel: rtfree: has 1 refs, will be present in
logs.
Stefan Lambrev opened a PR
http://www.freebsd.org/cgi/query-pr.cgi?pr=117913
that I thought dealt with this but not sure if this maybe just touches
the messages, not lockups.
Later, I opened another PR
http://www.freebsd.org/cgi/query-pr.cgi?pr=118044
and so far there is absolute silence. See below for the (what I believe)
interesting part.
Question 1: Am I the only one on the planet that sees this problem?
Question 2: Could someone with some knowledge please tell if this is
a real bug or just something I cooked up myself?
Thanks a lot!
--per
Tracing command irq21: bge0 pid 33 tid 100025 td 0xc5119880
cpustop_handler(1,e3ccf958,c0a05b10,1,0,...) at cpustop_handler+0x32
ipi_nmi_handler(1,0,0,0,13,...) at ipi_nmi_handler+0x2f
trap(e3ccf964) at trap+0x30
calltrap() at calltrap+0x6
--- trap 0x13, eip = 0xc074e586, esp = 0xe3ccf9a4, ebp = 0xe3ccf9c8 ---
panic(c0a9b762,c5117660,c0aa0a06,c5117660,186ae,...) at panic+0x26
_mtx_lock_spin_failed(1,19,c0aa0a32,cb,19,...) at _mtx_lock_spin_failed+0x51
_thread_lock_flags(c57c6440,10,c0aa0a32,cb,1,...) at _thread_lock_flags+0xc7
propagate_priority(c0bbceec,0,c0aa0a32,2e2,c50f2a00,...) at
propagate_priority+0xe0
turnstile_wait(c50f2a00,c57c6440,0,17a,c5874678,...) at turnstile_wait+0x48c
_mtx_lock_sleep(c5874678,c5119880,0,c0aaa355,41c,...) at
_mtx_lock_sleep+0x15a
_mtx_lock_flags(c5874678,0,c0aaa355,41c,e3ccfaf4,...) at
_mtx_lock_flags+0xef
rt_setgate(c5874618,cb4ee2c0,e3ccfbac,c5119880,e3ccfb18,...) at
rt_setgate+0x196
rtredirect(e3ccfbbc,e3ccfbac,0,26,e3ccfb9c,...) at rtredirect+0x18e
icmp_input(c6fb6500,14,246,c0b9c7c0,e3ccfc0c,...) at icmp_input+0x50f
ip_input(c6fb6500,14e,800,c526a400,800,...) at ip_input+0x650
netisr_dispatch(2,c6fb6500,10,3,0,...) at netisr_dispatch+0x73
ether_demux(c526a400,c6fb6500,3,0,3,...) at ether_demux+0x1f1
ether_input(c526a400,c6fb6500,c0a6af05,bc4,c526a400,...) at
ether_input+0x37f
bge_intr(c526d000,0,c0a99497,471,c515e564,...) at bge_intr+0x7da
ithread_loop(c5271160,e3ccfd38,c0a9920b,2ea,c52512a8,...) at
ithread_loop+0x1b5
fork_exit(c0732ea0,c5271160,e3ccfd38) at fork_exit+0xb8
fork_trampoline() at fork_trampoline+0x8
--- trap 0, eip = 0, esp = 0xe3ccfd70, ebp = 0 ---
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is it safe to use CPUTYPE?=native on 7.0 ?
On 12/16/07, Pete French <[EMAIL PROTECTED]> wrote:
> fairly simple question really - on machines where I never use the compiled
> binaries anywhere else, is it O.K. to set the CPU type to 'native' in
> make.conf ? According to gcc this should detect the processor type and
> set the various flas as approrpiate, which is nice, as we have a mix of P3,
> P4 and AMD processors around the place, and having one make.conf which will
> do the right thing on all of them would be nice.
>
> I've been trying it out on a couple of machines, and it seems to work fine,
> but I have a feeling that various bits of the kerenel complie are
> sensetive to the cpu type, so am just asking to check if it's O.K.
>
While setting CPUTYPE=native in /etc/make.conf may work, it fails to
set MACHINE_CPU to the correct values for your processor type.
The problem is that bsd.cpu.mk doesn't know how to handle CPU type 'native'.
There is a simple fix for this problem by applying the attached patch
which uses:
gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 | grep mtune
| sed -e 's/.*mtune=//'
to reset CPUTYPE to the processor type of your system when CPUTYPE=native.
Scot
Index: bsd.cpu.mk
===
RCS file: /home/ncvs/src/share/mk/bsd.cpu.mk,v
retrieving revision 1.63
diff -u -r1.63 bsd.cpu.mk
--- bsd.cpu.mk 16 Oct 2007 18:32:37 - 1.63
+++ bsd.cpu.mk 17 Oct 2007 22:28:32 -
@@ -18,6 +18,14 @@
. endif
.else
+# Handle 'native' by converting it to the appropriate CPUTYPE
+
+.if ${MACHINE_ARCH} == "i386" || ${MACHINE_ARCH} == "amd64"
+. if ${CPUTYPE} == "native"
+CPUTYPE != gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 | grep mtune | sed -e 's/.*mtune=//'
+. endif
+.endif
+
# Handle aliases (not documented in make.conf to avoid user confusion
# between e.g. i586 and pentium)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is it safe to use CPUTYPE?=native on 7.0 ?
> While setting CPUTYPE=native in /etc/make.conf may work, it fails to > set MACHINE_CPU to the correct values for your processor type. > > The problem is that bsd.cpu.mk doesn't know how to handle CPU type 'native'. Ah, O.K. - thats the kind of thing I was worried about... > There is a simple fix for this problem by applying the attached patch > which uses: Great, thanks. Out of curiosity, how come this patch isn't in 7.0 ? -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is it safe to use CPUTYPE?=native on 7.0 ?
On 12/16/07, Pete French <[EMAIL PROTECTED]> wrote: > > While setting CPUTYPE=native in /etc/make.conf may work, it fails to > > set MACHINE_CPU to the correct values for your processor type. > > > > The problem is that bsd.cpu.mk doesn't know how to handle CPU type 'native'. > > Ah, O.K. - thats the kind of thing I was worried about... > > > There is a simple fix for this problem by applying the attached patch > > which uses: > > Great, thanks. Out of curiosity, how come this patch isn't in 7.0 ? > PR 112997 was submitted to resolve this problem: http://www.freebsd.org/cgi/query-pr.cgi?pr=112997 it just didn't have enough attention to get someone interested in committing it. Scot ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: OS bug in taskq
On Sat, Dec 15, 2007 at 03:58:10PM -0800, Jeremy Chadwick wrote: > On Sat, Dec 15, 2007 at 01:03:14PM -0700, Elliot Finley wrote: > > I have: > > dumpdev="AUTO" > > in /etc/rc.conf and: > > ... > > in the kernel and I'm still unable to obtain a crash dump. Hopefully > > there is enough info in this email for a hacker to point me in the > > right direction to debug this. > > I can't help with the panic itself, but the reason for the inability to > obtain a crash dump is mentioned in a thread I started in November: > > http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/038069.html > > The explanation of the problem was documented best by Doug Barton in > this thread (over at freebsd-rc@): > > http://lists.freebsd.org/pipermail/freebsd-rc/2007-November/001263.html > > Open PR: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=118255 Why does it work *sometimes* then? Or was this particular problem introduced more recently than the 6.2 branch? I have two apparently similarly configured systems running 6.2p8, with identical hardware, identical apps, and identical load, and I have at least attempted to configure them the same way. Both have /var/crash set up and "dumpon" enabled in rc.conf. Both crashed in the last week. I got a dump on one, which I now need to analyze, but have twice failed to get a dump on the other. (Once this past week, once the previous month.) -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] / [EMAIL PROTECTED] President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD 7.0beta4 panic on ftp transfer
SO I have 7.0beta4 on my server. My HDD have such configuration: ad4: 476940MB at ata2-master SATA300 ad6: 476940MB at ata3-master SATA300 ad10: 152627MB at ata5-master SATA150 ad12: 152627MB at ata6-master SATA150 ar0: 476928MB status: READY ar0: disk0 READY (master) using ad4 at ata2-master ar0: disk1 READY (mirror) using ad6 at ata3-master ar1: 152627MB status: READY ar1: disk0 READY (master) using ad10 at ata5-master ar1: disk1 READY (mirror) using ad12 at ata6-master SMP: AP CPU #1 Launched! During ftp transfer (among 10GB to server) I have kernel panic and reboon wiht such log messages: Dec 17 01:27:24 SERVER ftpd[11594]: ANONYMOUS FTP LOGIN REFUSED FROM MISHA.w Dec 17 01:34:25 SERVER kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad6: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad6: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad6: WARNING - SET_MULTI taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad6: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=211491351 Dec 17 01:35:41 SERVER kernel: ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad4: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad4: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad4: WARNING - SET_MULTI taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad4: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=211491479 Dec 17 01:35:41 SERVER kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad6: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad6: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad6: WARNING - SET_MULTI taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad6: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=211491479 Dec 17 01:35:41 SERVER kernel: ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad4: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad4: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad4: WARNING - SET_MULTI taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad4: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=211491607 Dec 17 01:49:17 SERVER syslogd: kernel boot file is /boot/kernel/kernel Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad4: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad4: WARNING - SET_MULTI taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad4: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=211491607 Dec 17 01:49:17 SERVER syslogd: kernel boot file is /boot/kernel/kernel Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SET_MULTI taskqueue timeout - comp
Packet loss every 30.999 seconds
While trying to diagnose a packet loss problem in a RELENG_6 snapshot dated November 8, 2007 it looks like I've stumbled across a broken driver or kernel routine which stops interrupt processing long enough to severly degrade network performance every 30.99 seconds. Packets appear to make it as far as ether_input() then get lost. Test setup: A - ethernet_switch - B A sends UDP packets to B through an ethernet switch. The interface input packet count and output packet count on the switch match what A is sending and B should be receiving. A UDP receiver running on B sees windows of packet loss with a period of 30.99 seconds. The lost packets are counted based on an incrementing sequence number. On an isolated network the Ipkts counter on B matches what A is sending, but the packets never show up in any of the IP/UDP counters or the program trying to receive them. This behavior can be seen with both em and fxp interfaces. Problem is it only occurs after the receiving host has been up about a day. Reboot, problem clears. GENERIC kernel, nothing more than default daemons running. Behavior seen on three different motherboards so far. It also appears this is not just lost network interrupts. Whatever is spinning in the kernel also impacts syscall latency. An easy way to replicate what I'm seeing is to run gettimeofday() in a tight loop and note when the real time syscall delay exceeds some value (which is dependent on processor speed). As an example on an 3.20GHz CPU a small program will output when the syscall latency is > 5000 usecs. Note the periodic behavior at 30.99 seconds. These big jumps in latency correspond to when packets are being dropped. usecs (epoch)latency diff 1197861705805078 478199 0 1197861721012298 25926 15207220 1197861726332036 11729 5319738 1197861757331549 11691 30999513 1197861788331266 11878 30999717 1197861819330647 11708 30999381 1197861850330192 11698 30999545 1197861881329733 11667 30999541 1197861900018297 6516 18688564 1197861912329282 11684 12310985 1197861943328849 11699 30999567 1197861974328413 11692 30999564 1197862005328228 11916 30999815 1197862036327598 11684 30999370 1197862067327229 11680 30999631 1197862098326860 11667 30999631 1197862129326559 11704 30999699 1197862160326377 11844 30999818 1197862191325890 11674 30999513 (output from packet loss tester) window_start/window_end is packet counter time_start/time_end is absolute time in usecs. window_diff is # of packets missing The test is run at about 15.5Kpps / 132Mbits/second, certainly a lot less than this hardware is capable of running BSD4.X. :missing window_start=311510, time_start=1197861726332008,window_end=311638, time_end=1197861726332011, window_diff=128, time_diff=3 :missing window_start=794482, time_start=1197861757331505,window_end=794609, time_end=1197861757331509, window_diff=127, time_diff=4 :missing window_start=1277313, time_start=1197861788331245,window_end=1277444, time_end=1197861788331249, window_diff=131, time_diff=4 :missing window_start=1760104, time_start=1197861819330625,window_end=1760232, time_end=1197861819330629, window_diff=128, time_diff=4 :missing window_start=2242789, time_start=1197861850330170,window_end=2242916, time_end=1197861850330174, window_diff=127, time_diff=4 :missing window_start=2725818, time_start=1197861881329712,window_end=2725946, time_end=1197861881329715, window_diff=128, time_diff=3 :missing window_start=3208594, time_start=1197861912329261,window_end=3208722, time_end=1197861912329264, window_diff=128, time_diff=3 :missing window_start=3691395, time_start=1197861943328802,window_end=3691522, time_end=1197861943328805, window_diff=127, time_diff=3 :missing window_start=4173793, time_start=1197861974328369,window_end=4173921, time_end=1197861974328373, window_diff=128, time_diff=4 :missing window_start=4656236, time_start=1197862005328176,window_end=4656367, time_end=1197862005328179, window_diff=131, time_diff=3 :missing window_start=5139197, time_start=1197862036327576,window_end=5139325, time_end=1197862036327580, window_diff=128, time_diff=4 :missing window_start=5621958, time_start=1197862067327208,window_end=5622085, time_end=1197862067327211, window_diff=127, time_diff=3 :missing window_start=6104597, time_start=1197862098326839,window_end=6104725, time_end=1197862098326843, window_diff=128, time_diff=4 :missing window_start=6587241, time_start=1197862129326514,window_end=6587369, time_end=1197862129326534, window_diff=128, time_diff=20 :missing window_start=7070051, time_start=1197862160326368,window_end=7070183, time_end=1197862160326371, window_diff=132, time_diff=3 :missing window_start=7552828, time_start=1197862191325873,window_end=7552954, time_end=1197862191325876, window_diff=126, time_diff=3 :missing window_start=8035434, time_start=119786325572,window_end=8035560, time_end=119786325576,
Packet loss every 30.999 seconds
While trying to diagnose a packet loss problem in a RELENG_6 snapshot dated November 8, 2007 it looks like I've stumbled across a broken driver or kernel routine which stops interrupt processing long enough to severly degrade network performance every 30.99 seconds. Packets appear to make it as far as ether_input() then get lost. Test setup: A - ethernet_switch - B A sends UDP packets to B through an ethernet switch. The interface input packet count and output packet count on the switch match what A is sending and B should be receiving. A UDP receiver running on B sees windows of packet loss with a period of 30.99 seconds. The lost packets are counted based on an incrementing sequence number. On an isolated network the Ipkts counter on B matches what A is sending, but the packets never show up in any of the IP/UDP counters or the program trying to receive them. This behavior can be seen with both em and fxp interfaces. Problem is it only occurs after the receiving host has been up about a day. Reboot, problem clears. GENERIC kernel, nothing more than default daemons running. Behavior seen on three different motherboards so far. It also appears this is not just lost network interrupts. Whatever is spinning in the kernel also impacts syscall latency. An easy way to replicate what I'm seeing is to run gettimeofday() in a tight loop and note when the real time syscall delay exceeds some value (which is dependent on processor speed). As an example on an 3.20GHz CPU a small program will output when the syscall latency is > 5000 usecs. Note the periodic behavior at 30.99 seconds. These big jumps in latency correspond to when packets are being dropped. usecs (epoch)latency diff 1197861705805078 478199 0 1197861721012298 25926 15207220 1197861726332036 11729 5319738 1197861757331549 11691 30999513 1197861788331266 11878 30999717 1197861819330647 11708 30999381 1197861850330192 11698 30999545 1197861881329733 11667 30999541 1197861900018297 6516 18688564 1197861912329282 11684 12310985 1197861943328849 11699 30999567 1197861974328413 11692 30999564 1197862005328228 11916 30999815 1197862036327598 11684 30999370 1197862067327229 11680 30999631 1197862098326860 11667 30999631 1197862129326559 11704 30999699 1197862160326377 11844 30999818 1197862191325890 11674 30999513 (output from packet loss tester) window_start/window_end is packet counter time_start/time_end is absolute time in usecs. window_diff is # of packets missing The test is run at about 15.5Kpps / 132Mbits/second, certainly a lot less than this hardware is capable of running BSD4.X. :missing window_start=311510, time_start=1197861726332008,window_end=311638, time_end=1197861726332011, window_diff=128, time_diff=3 :missing window_start=794482, time_start=1197861757331505,window_end=794609, time_end=1197861757331509, window_diff=127, time_diff=4 :missing window_start=1277313, time_start=1197861788331245,window_end=1277444, time_end=1197861788331249, window_diff=131, time_diff=4 :missing window_start=1760104, time_start=1197861819330625,window_end=1760232, time_end=1197861819330629, window_diff=128, time_diff=4 :missing window_start=2242789, time_start=1197861850330170,window_end=2242916, time_end=1197861850330174, window_diff=127, time_diff=4 :missing window_start=2725818, time_start=1197861881329712,window_end=2725946, time_end=1197861881329715, window_diff=128, time_diff=3 :missing window_start=3208594, time_start=1197861912329261,window_end=3208722, time_end=1197861912329264, window_diff=128, time_diff=3 :missing window_start=3691395, time_start=1197861943328802,window_end=3691522, time_end=1197861943328805, window_diff=127, time_diff=3 :missing window_start=4173793, time_start=1197861974328369,window_end=4173921, time_end=1197861974328373, window_diff=128, time_diff=4 :missing window_start=4656236, time_start=1197862005328176,window_end=4656367, time_end=1197862005328179, window_diff=131, time_diff=3 :missing window_start=5139197, time_start=1197862036327576,window_end=5139325, time_end=1197862036327580, window_diff=128, time_diff=4 :missing window_start=5621958, time_start=1197862067327208,window_end=5622085, time_end=1197862067327211, window_diff=127, time_diff=3 :missing window_start=6104597, time_start=1197862098326839,window_end=6104725, time_end=1197862098326843, window_diff=128, time_diff=4 :missing window_start=6587241, time_start=1197862129326514,window_end=6587369, time_end=1197862129326534, window_diff=128, time_diff=20 :missing window_start=7070051, time_start=1197862160326368,window_end=7070183, time_end=1197862160326371, window_diff=132, time_diff=3 :missing window_start=7552828, time_start=1197862191325873,window_end=7552954, time_end=1197862191325876, window_diff=126, time_diff=3 :missing window_start=8035434, time_start=119786325572,window_end=8035560, time_end=119786325576,
Re: Packet loss every 30.999 seconds
On Mon, Dec 17, 2007 at 12:21:43AM -0500, Mark Fullmer wrote: > While trying to diagnose a packet loss problem in a RELENG_6 snapshot dated > November 8, 2007 it looks like I've stumbled across a broken driver or > kernel routine which stops interrupt processing long enough to severly > degrade network performance every 30.99 seconds. > > Packets appear to make it as far as ether_input() then get lost. Are you sure this isn't being caused by something the switch is doing, such as MAC/ARP cache clearing or LACP? I'm just speculating, but it would be worthwhile to remove the switch from the picture (crossover cable to the rescue). I know that at least in the case of fxp(4) and em(4), Jack Vogel does some through testing of throughput using a professional/high-end packet generator (some piece of hardware, I forget the name...) -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Packet loss every 30.999 seconds
While trying to diagnose a packet loss problem in a RELENG_6 snapshot dated November 8, 2007 it looks like I've stumbled across a broken driver or kernel routine which stops interrupt processing long enough to severly degrade network performance every 30.99 seconds. Packets appear to make it as far as ether_input() then get lost. Test setup: A - ethernet_switch - B A sends UDP packets to B through an ethernet switch. The interface input packet count and output packet count on the switch match what A is sending and B should be receiving. A UDP receiver running on B sees windows of packet loss with a period of 30.99 seconds. The lost packets are counted based on an incrementing sequence number. On an isolated network the Ipkts counter on B matches what A is sending, but the packets never show up in any of the IP/UDP counters or the program trying to receive them. This behavior can be seen with both em and fxp interfaces. Problem is it only occurs after the receiving host has been up about a day. Reboot, problem clears. GENERIC kernel, nothing more than default daemons running. Behavior seen on three different motherboards so far. It also appears this is not just lost network interrupts. Whatever is spinning in the kernel also impacts syscall latency. An easy way to replicate what I'm seeing is to run gettimeofday() in a tight loop and note when the real time syscall delay exceeds some value (which is dependent on processor speed). As an example on an 3.20GHz CPU a small program will output when the syscall latency is > 5000 usecs. Note the periodic behavior at 30.99 seconds. These big jumps in latency correspond to when packets are being dropped. usecs (epoch)latency diff 1197861705805078 478199 0 1197861721012298 25926 15207220 1197861726332036 11729 5319738 1197861757331549 11691 30999513 1197861788331266 11878 30999717 1197861819330647 11708 30999381 1197861850330192 11698 30999545 1197861881329733 11667 30999541 1197861900018297 6516 18688564 1197861912329282 11684 12310985 1197861943328849 11699 30999567 1197861974328413 11692 30999564 1197862005328228 11916 30999815 1197862036327598 11684 30999370 1197862067327229 11680 30999631 1197862098326860 11667 30999631 1197862129326559 11704 30999699 1197862160326377 11844 30999818 1197862191325890 11674 30999513 (output from packet loss tester) window_start/window_end is packet counter time_start/time_end is absolute time in usecs. window_diff is # of packets missing The test is run at about 15.5Kpps / 132Mbits/second, certainly a lot less than this hardware is capable of running BSD4.X. :missing window_start=311510, time_start=1197861726332008,window_end=311638, time_end=1197861726332011, window_diff=128, time_diff=3 :missing window_start=794482, time_start=1197861757331505,window_end=794609, time_end=1197861757331509, window_diff=127, time_diff=4 :missing window_start=1277313, time_start=1197861788331245,window_end=1277444, time_end=1197861788331249, window_diff=131, time_diff=4 :missing window_start=1760104, time_start=1197861819330625,window_end=1760232, time_end=1197861819330629, window_diff=128, time_diff=4 :missing window_start=2242789, time_start=1197861850330170,window_end=2242916, time_end=1197861850330174, window_diff=127, time_diff=4 :missing window_start=2725818, time_start=1197861881329712,window_end=2725946, time_end=1197861881329715, window_diff=128, time_diff=3 :missing window_start=3208594, time_start=1197861912329261,window_end=3208722, time_end=1197861912329264, window_diff=128, time_diff=3 :missing window_start=3691395, time_start=1197861943328802,window_end=3691522, time_end=1197861943328805, window_diff=127, time_diff=3 :missing window_start=4173793, time_start=1197861974328369,window_end=4173921, time_end=1197861974328373, window_diff=128, time_diff=4 :missing window_start=4656236, time_start=1197862005328176,window_end=4656367, time_end=1197862005328179, window_diff=131, time_diff=3 :missing window_start=5139197, time_start=1197862036327576,window_end=5139325, time_end=1197862036327580, window_diff=128, time_diff=4 :missing window_start=5621958, time_start=1197862067327208,window_end=5622085, time_end=1197862067327211, window_diff=127, time_diff=3 :missing window_start=6104597, time_start=1197862098326839,window_end=6104725, time_end=1197862098326843, window_diff=128, time_diff=4 :missing window_start=6587241, time_start=1197862129326514,window_end=6587369, time_end=1197862129326534, window_diff=128, time_diff=20 :missing window_start=7070051, time_start=1197862160326368,window_end=7070183, time_end=1197862160326371, window_diff=132, time_diff=3 :missing window_start=7552828, time_start=1197862191325873,window_end=7552954, time_end=1197862191325876, window_diff=126, time_diff=3 :missing window_start=8035434, time_start=119786325572,window_end=8035560, time_end=119786325576,
Re: Packet loss every 30.999 seconds
I'm about 99% sure right now. I'll set this up in a lab tomorrow without an ethernet switch. It takes about a day of uptime before the problem shows up. Sorry for the duplicate messages, I misread a bounce notification. -- mark On Dec 17, 2007, at 12:43 AM, Jeremy Chadwick wrote: On Mon, Dec 17, 2007 at 12:21:43AM -0500, Mark Fullmer wrote: While trying to diagnose a packet loss problem in a RELENG_6 snapshot dated November 8, 2007 it looks like I've stumbled across a broken driver or kernel routine which stops interrupt processing long enough to severly degrade network performance every 30.99 seconds. Packets appear to make it as far as ether_input() then get lost. Are you sure this isn't being caused by something the switch is doing, such as MAC/ARP cache clearing or LACP? I'm just speculating, but it would be worthwhile to remove the switch from the picture (crossover cable to the rescue). I know that at least in the case of fxp(4) and em(4), Jack Vogel does some through testing of throughput using a professional/high-end packet generator (some piece of hardware, I forget the name...) -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http:// www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable- [EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Generation Y - Gerer sans deprimer
= FORMATION GEN= ERATION Y : RECRUTEMENT ET GESTION RECONCILIER LES GENERATIONS POUR PL= US D'EFFICACITE MÉTHODE P&= Eacute;DAGOGIQUE: Apports méthodologiques, exercices pra= tiques et mises en situation, complétées et enrichies d= e partage d'expériences vécues et de témoign= age d'expert. Travail et discussions à partir des cas pr&e acute;sentés par les participants. <= p align="center">POUR INFORMATIONS COMMUNIQUER AU 450-22= 6-2238 OU 1-800-861-6618 PUBLIC VISÉ: Les Dirigeants d'entreprises, et, par d& eacute;légation, toute personne en charge du recrutement, eT l'= intégration et du management de travailleurs issus de la g&eac= ute;nération Y. INTRODUCTION: Les 'Y' e= n entreprise sont caractérisés comme des 'ind&eacut= e;pendants', des 'multi-tâches' voire des 'impatients',= . Ils ont pour eux l'aisance dans les nouvelles technologies, la volo= nté et la capacité d'apprendre sans cesse, la mobilit= é...et ils ont le choix de s'engager ou non, selon que l= es conditions matérielles et l'ambiance observée renc= ontrent ou non leur idée du travail. Le contexte de ple= in emploi n'incite pas à rapprocher les nouvelles gén= érations des anciennes : des compromis succèdent aux d&= eacute;ceptions, pour seulement quelques rares succès d'int&= eacute;gration. Il en résulte un sentiment d'impuissa= nce de la part d'une majorité d'employeurs, voire de ras-le-= bol. Cette formation vise à faire sortir les cadres et dirigea nts de leurs ornières en leur procurant une méthode pou= r recruter et gérer l'intégration de la gén&= eacute;ration Y dans les autres générations. P= OUR INFORMATIONS supplémentaires contactez-nous au 1.877.726= .2238 OBJECTIFS: * Comprendre ce et ceux qui se cachent d= errière 'la génération Y' * Prendre con= science des véritables défis posés par cette g= énération * Intégrer les besoins de cette g énération dans l'environnement et le cadre de travail= au quotidien * Savoir rédiger une offre d'emploi dans le l= angage de la génération Y * Savoir communiquer, en p= articulier dans les étapes de recrutement et d'accueil - conna= ître le langage à bannir * Apprendre les bonnes prati= ques dans les phases-clés d'acquisition d'autonomie des trav= ailleurs de cette génération * Repérer les = vraies sources de motivation sur le long terme et concevoir les strat&e= acute;gies pour y faire face * Conduire le changement auprès = des autres populations et savoir rapprocher les générat= ions * Poser les bases d'une préparation efficace de la rel ève, à tous les échelons et niveaux des entrep= rises * Devenir un 'employeur de choix' pour la gén&eac ute;ration Y PLAN DE COURS 1 - CASSER LES MYTHES : LA G= ENERATION Y EST UN PHENOMENE MONDIAL ET UNE TENDANCE LOURDE 2 - CE QUE= NOUS POUVONS ATTENDRE DE LA GENERATION Y 3 - L'ENGAGEMENT POUR LA G= ENERATION Y : IDEAUX ET VALEURS 4 - LA SEDUCTION RECIPROQUE ET LA CONF= IANCE RECIPROQUE 5 - COMMENT ATTIRER LES JEUNES SANS FAIRE FUIR LES AN= CIENS : TROIS NIVEAUX DE PROBLEMES 6 - LES NOUVELLES DIMENSIONS ET IND= ICATEURS DE LA QUALITE DE VIE AU TRAVAIL 7 - L'EMBAUCHE ET LE PROCES= SUS D'INTEGRATION 8 - LE DEVELOPPEMENT DES COMPETENCES ET LE ROLE D= ES MENTORS 9 - LE DEVELOPPEMENT DE LA RELEVE ET LE ROLE DU MANAGER = 10 - LA GESTION DES SITUATIONS DIFFICILES ET LE ROLE DES SUPERVISEURS = [1]Visitez notre s= ite internet DATES ET LIEUX DE LA FORMATION: DURÉE de la FORMATION: 2 jours N.B. Nombre de place= s limités ( 15 Personnes ) Région de = Montréal: Les 7 et 8 OU les 28 et 29 f&= eacute;vrier 2008 Hôtel Sheraton, 2440, Autoroute des Laurenti= des, Laval Région de Québec: Les 26 et 27 février 2008 Hôtel Des Gouverneu= rs, 3030 boulevard Laurier, Ste-Foy Pour inscription, veuillez= contacter Mme Maryse Morin au 1.877.726.2238 CF Formation 707, = rue du Village, suite 202, Morin-Heights, QC J0R 1H0 [?78.OdbRG=] 1- Si vous so= uhaitez recevoir nos offres de formation, [2]cliquez ici 2- Si vous souhaitez vous retirer d&= eacute;finitivement de notre base de données, [3]cliquez ici References 1. 3D"http://content=/ 2. 3D"http://content.d=/ 3. 3D"http:___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
