Re: CARP forcing failover

> On 1 Mar 2017, at 01:58, Aristedes Maniatis wrote: > > I have a pair network gateway boxes running FreeBSD 11 and pf. Upstream runs > VRRP to provide redundant links, one to each gateway. Internally I'm using > CARP for failover. > > All works well, but I find that

Re: thread taskq / unp_gc() using 100% cpu and stalling unix socket IPC

On 14.11.2012, at 11:50, Markus Gebert markus.geb...@hostpoint.ch wrote: On 14.11.2012, at 08:21, Konstantin Belousov kostik...@gmail.com wrote: On Wed, Nov 14, 2012 at 01:41:04AM +0100, Markus Gebert wrote: On 13.11.2012, at 19:30, Markus Gebert markus.geb...@hostpoint.ch wrote: To me

Re: thread taskq / unp_gc() using 100% cpu and stalling unix socket IPC

On 14.11.2012, at 02:12, Adrian Chadd adr...@freebsd.org wrote: Oh lordie, just hack the kernel to make IP_BINDANY usable by any uid, not just root. I was hoping that capabilitiies would actually be useful these days, but apparently not. :( Then you can stop this FD exchange nonsense

Re: thread taskq / unp_gc() using 100% cpu and stalling unix socket IPC

On 14.11.2012, at 04:30, Alfred Perlstein bri...@mu.org wrote: A couple of ideas: Thanks. 1) convert the taskqueue to a callout, but only allow one to be queued at a time. set the granularity. I think Konstantin's patch is going in this direction. 2) I think you only need to actually

Re: thread taskq / unp_gc() using 100% cpu and stalling unix socket IPC

On 14.11.2012, at 08:21, Konstantin Belousov kostik...@gmail.com wrote: On Wed, Nov 14, 2012 at 01:41:04AM +0100, Markus Gebert wrote: On 13.11.2012, at 19:30, Markus Gebert markus.geb...@hostpoint.ch wrote: To me it looks like the unix socket GC is triggered way too often

thread taskq / unp_gc() using 100% cpu and stalling unix socket IPC

Hi there We have a pair of servers running FreeBSD 9.1-RC3 that act as transparent layer 7 loadbalancer (relayd) and pop/imap proxy (dovecot). Only one of them is active at a given time, it's a failover setup. From time to time the active one gets in a state in which the 'thread taskq' thread

Re: thread taskq / unp_gc() using 100% cpu and stalling unix socket IPC

On 13.11.2012, at 19:30, Markus Gebert markus.geb...@hostpoint.ch wrote: To me it looks like the unix socket GC is triggered way too often and/or running too long, which uses cpu and worse, causes a lot of contention around the unp_list_lock which in turn causes delays for all processes

Re: about thumper aka sun fire x4500

Hi Peter On 18.01.2012, at 20:25, peter h wrote: On Wednesday 18 January 2012 18.15, Adam McDougall wrote: On 01/17/12 17:09, Jeremy Chadwick wrote: On Tue, Jan 17, 2012 at 06:59:08PM +0100, peter h wrote: I have been beating on of these a few days, i have udes freebsd 9.0 and 8.2 Both

Re: chflags on zfs (sappnd)

On 17.11.2010, at 11:49, George Mamalakis wrote: Hi everbody, from http://wiki.freebsd.org/ZFS I understand that chflags are supported by zfs. But if I have a file with sappnd on a zfs filesystem, I am unable to execute a command like this: # touch lili # chflags sappnd lili # ls

Re: chflags on zfs (sappnd)

On 17.11.2010, at 20:00, Andriy Gapon wrote: on 17/11/2010 18:38 Markus Gebert said the following: On 17.11.2010, at 11:49, George Mamalakis wrote: Hi everbody, from http://wiki.freebsd.org/ZFS I understand that chflags are supported by zfs. But if I have a file with sappnd on a zfs

Re: 8.1-RC2 MCE caused by some LAPIC/clock changes?

On 21.07.2010, at 10:33, Andriy Gapon wrote: on 21/07/2010 03:57 Markus Gebert said the following: Another thing though: Today I compared verbose boot output from 8-stable and the current box. I saw that the ioapic sets up IRQ routing differently on these two systems although the hardware

Re: 8.1-RC2 MCE caused by some LAPIC/clock changes?

On 21.07.2010, at 14:36, Andriy Gapon wrote: on 21/07/2010 15:25 Markus Gebert said the following: On 21.07.2010, at 10:33, Andriy Gapon wrote: on 21/07/2010 03:57 Markus Gebert said the following: Another thing though: Today I compared verbose boot output from 8-stable and the current

Re: 8.1-RC2 MCE caused by some LAPIC/clock changes? (was: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2?)

On 20.07.2010, at 10:15, jhell wrote: Any ideas how to proceed? Adding to this I remembered some specific commits that caught my attention when they happened. Specifically they were to mca.c (locate mca) on my machine provided the file paths and svn log provided the commit log. When

Re: 8.1-RC2 MCE caused by some LAPIC/clock changes? (was: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2?)

On 20.07.2010, at 21:59, John Baldwin wrote: I started narrowing the revisions down until I found out, that while on r202386 I'm still able to trigger the MCE, r202387 seems to solve the problem on CURRENT: http://svn.freebsd.org/viewvc/base?view=revisionrevision=202387 Although this

Re: 8.1-RC2 MCE caused by some LAPIC/clock changes? (was: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2?)

On 13.07.2010, at 16:02, Markus Gebert wrote: Unfortunately, I have not been able to get anything useful out the svn commit logs, which could explain this. Maybe someone else has an idea what could have changed between 7 and 8 to break it, and again between 8 and CURRENT to magically fix

Re: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2?

On 12.07.2010, at 14:41, Markus Gebert wrote: In the meantime, I'll try harder to reproduce the MCE on current... Well, I can't. It's been running the test load for almost 24 hours without any sign of problems. The kernel config is the same as under 8.1, GENERIC+ipfw (USB not excluded

Re: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2?

On 10.07.2010, at 19:37, Alan Cox wrote: On Fri, Jul 9, 2010 at 6:53 PM, Markus Gebert markus.geb...@hostpoint.ch wrote: [snip] Yes, this hardware comes from Sun directly, but getting Sun (/Oracle) support for this issue is gonna be tough. FreeBSD is unsupported, and in a short test

Re: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2?

On 10.07.2010, at 01:53, Markus Gebert wrote: I'm curious if disabling USB legacy support in the BIOS causes it to still die even with ehci not loaded. If so, then the SMI# for the ehci controller must somehow prevent the issue, perhaps by triggering frequently enough to slow

Re: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2?

On 12.07.2010, at 14:51, John Baldwin wrote: Well, the situation has changed. Machine died over the weekend running our test load with above kernel configuration. It seems that not having ehci in the kernel at boot just makes the MCE much more unlikely to occur, but it occurs. With ehci,

Re: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2?

On 12.07.2010, at 14:48, John Baldwin wrote: Hmm with mca disabled in the loader you should not be getting any MCE's at all as we don't enable the MCE interrupt in the CPU in that case. Are you disabling it in the BIOS rather than loader.conf? I disabled it in loader.conf, just tested

Re: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2?

On 12.07.2010, at 17:06, John Baldwin wrote: Are you using Cx states other than C1 for the CPUs at all? Not sure how to find out, but I did not change anything in the BIOS settings (if even possible) or through sysctl regarding cpu idle modes. Anyway, here's what I found: # sysctl

Re: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2?

On 12.07.2010, at 17:40, Jeremy Chadwick wrote: cx_supported indicates your CPU only supports C1 and not lower power-saving states (C2/C3/C4, etc.). Non-C1 states can sometimes do interesting things when it comes to interrupt handling. I believe your system may support the C1E state (given

Re: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2?

On 12.07.2010, at 17:43, Adam McDougall wrote: I also get MCE on x4100m2 when causing significant disk activity in mpt while also downloading through em0 or em1. Could you reproduce this on 6.x or 7.x? Because whatever we try here, we simply couldn't so far. A short test with Ubuntu also

Re: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2?

Am 09.07.2010 um 17:56 schrieb Jeremy Chadwick: Can you re-run this with -lvc instead? Thanks. Also vmstat -i would be useful. That's all I can think of off the top of my head. Sure. # pciconf -lvc no...@pci0:0:0:0: class=0x058000 card=0x chip=0x005e10de rev=0xa3 hdr=0x00

Re: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2?

Hi John Am 09.07.2010 um 22:03 schrieb John Baldwin: On Friday, July 09, 2010 11:26:00 am Markus Gebert wrote: -- MCA: Bank 4, Status 0xb4430c2b MCA: Global Cap 0x0105, Status 0x0007 MCA: Vendor AuthenticAMD, ID 0x40f13, APIC ID 2 MCA: CPU 2 UNCOR BUSLG