openbsd-tech mailing list

FromSubjectsort iconDate
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 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 daytodaynext day
December 26, 2010December 27, 2010December 28, 2010