| From | Subject | Date |
|---|---|---|
| Sebastian Benoit | relayd: exec program on gateway change
Hi,
i am using relayd in "router" mode for a cable-modem link that sometimes
does not work.
I need to run a programm to load/unload pf-rules and to restart a
proxy with a different config whenever this happens.
Here is a patch that adds an "exec" option to the router section like this:
router "uplinks" {
route 0.0.0.0/0
forward to <gateways> check icmp
exec "/usr/local/sbin/relayd_test" timeout 10
}
The code that does the exec is taken from ...
| Dec 27, 3:24 pm 2010 |
| Top Shop | Nove patike za super figuru!
Top Shop
Pro
| Dec 27, 2:37 am 2010 |
| Loganaden Velvindron | Re: MicroLinear 6692 PHY for tl(4) -- Olicom 2326
Here's the src with appropriate copyright.
/* $OpenBSD: ukphy.c,v 1.20 2010/07/23 07:47:13 jsg Exp $ */
/* $NetBSD: ukphy.c,v 1.9 2000/02/02 23:34:57 thorpej Exp $ */
/*-
* Copyright (c) 1997, 1998, 1999
* Bill Paul <wpaul@ctr.columbia.edu>. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* ...
| Dec 27, 12:02 am 2010 |
| Mark Kettenis | Re: MicroLinear 6692 PHY for tl(4) -- Olicom 2326
To be consistent with other PHY drivers, this should probably be
something like:
Ehm, what does this actually do? This will always result in "other"
being set to NULL isn't it?
It looks like this driver is written to deal with a 10baseT companion
PHY. Does your tl(4) have such a companion PHY? Did you test 10baseT
| Dec 27, 1:58 am 2010 |
| Loganaden Velvindron | Re: MicroLinear 6692 PHY for tl(4) -- Olicom 2326
Yep. I started from ukphy.c and ported bits from the freebsd mlphy driver. I'll amend it shortly, once I get to work.
//Logan
| Dec 26, 10:00 pm 2010 |
| Ted Unangst | Re: MicroLinear 6692 PHY for tl(4) -- Olicom 2326
On Sun, Dec 26, 2010 at 3:40 PM, Loganaden Velvindron
Not entirely relevant, but this is crediting NetBSD. If the code came
from the FreeBSD tl driver, it should be credited as such. It looks
like you probably started with the ukphy driver, but I'm not sure how
| Dec 26, 8:57 pm 2010 |
| Philip Guenther | Re: correct mxcsr+mxcsr_mask handling (revised)
On Sun, Dec 26, 2010 at 7:24 AM, Mark Kettenis <mark.kettenis@xs4all.nl>
Well, on i386, npxinit() is called for the primary cpu when the npx is
attached, which is way after the secondary cpus are attached. Can we
assume it to be safe to call npxinit() before the npx device is
attached? It wouldn't surprise me to hear that it only works when npx
errors are reported using exceptions and not ISA interrupts...which
would explain why the early calls are fine on multi-CPU systems,
'cause they all ...
| Dec 26, 10:57 pm 2010 |
| Philip Guenther | Re: correct mxcsr+mxcsr_mask handling (revised)
On Mon, 27 Dec 2010, Mark Kettenis wrote:
Ah, I missed the CPUF_GO bit. Gotta love the simplicity of the MP boot
Okay, check out the revised diff below. I've tested the updated amd64
part; I would appreciate a confirmation from an i386 w/X11 user for that
part.
Philip
Index: amd64/amd64/fpu.c
===================================================================
RCS file: /cvs/src/sys/arch/amd64/amd64/fpu.c,v
retrieving revision 1.21
diff -u -p -r1.21 fpu.c
--- ...
| Dec 27, 1:07 pm 2010 |
| Mark Kettenis | Re: correct mxcsr+mxcsr_mask handling (revised)
Looks like you're fooled by another not-so-subtle difference between
i386 and amd64. On amd64 the CPUs are spun up when they attach. On
i386 that doesn't happen until we call cpu_boot_secondary_processors()
in main(), which is long after npx(4) attaches and npxinit() gets
Right.
| Dec 27, 9:20 am 2010 |
| Josh Elsasser | Re: correct mxcsr+mxcsr_mask handling (revised)
Works for me, X runs and test program no longer drops us into ddb:
OpenBSD 4.8-current (GENERIC) #43: Mon Dec 27 13:08:01 PST 2010
joshe@flint.joshe.fake:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Celeron(R) M processor 1.40GHz ("GenuineIntel" 686-class) 1.40 GHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,SBF
It couldn't hurt to also test this on a machine where the fxsave
instruction writes an empty mask. This should ...
| Dec 27, 3:05 pm 2010 |
| Philip Guenther | Re: amd64 atomic macro naming cleanup
That's simple enough, it just means deleting three '+' lines from the
atomic.h part of the diff, deleting the _l and _ul macros and leaving
just the x86_atomic_testset_i() macro (which is only used in lock.h).
I'm fine with that.
oks?
Philip Guenther
| Dec 26, 9:26 pm 2010 |
| Mark Kettenis | Re: amd64 atomic macro naming cleanup
Actually we have quite a bit of "long" usage in the kernel; addresses,
sizes, etc. etc. Basically everything that needs to be 32 bits on a
32-bit system and 64 bits on a 64-bit system is defined as a typedef
of "long".
What are these x86_atomic_*() macros used for? Well, we inherited
them from NetBSD, and there they are used to make sharing code between
i386 and amd64 easier. Now in OpenBSD we don't really share code like
that, but I still think it should still be our goal to reduce ...
| Dec 27, 9:07 am 2010 |
| Kjell Wooding | Re: Add back-to-indentation (M-m) for mg
Looks good. Here is a slight cleanup. Essentially, fix alphabetical
ordering, change function name :
Index: def.h
===================================================================
RCS file: /cvs/src/usr.bin/mg/def.h,v
retrieving revision 1.113
diff -u -u -r1.113 def.h
--- def.h 30 Jun 2010 19:12:54 -0000 1.113
+++ def.h 27 Dec 2010 21:58:28 -0000
@@ -511,6 +511,7 @@
int forwdel(int, int);
int backdel(int, int);
int space_to_tabstop(int, int);
+int ...
| Dec 27, 3:01 pm 2010 |
| previous day | today | next day |
|---|---|---|
| December 26, 2010 | December 27, 2010 | December 28, 2010 |
