date:20101227

Re: MicroLinear 6692 PHY for tl(4) -- Olicom 2326

2010-12-27 Thread Mark Kettenis

 Date: Mon, 27 Dec 2010 02:02:03 -0500 (EST)
 From: logana...@devio.us (Loganaden Velvindron)

Looks like your diff has some issues with tabs versus spaces.

 void
 mlphy_attach(struct device *parent, struct device *self, void *aux)
 {
   struct mlphy_softc *msc = (struct mlphy_softc *)self;
   struct mii_softc *sc = (struct mii_softc *)self;
   struct mii_attach_args *ma = aux;
   struct mii_data *mii = ma-mii_data;

   printf(:ML phy \n);

To be consistent with other PHY drivers, this should probably be
something like:

printf(: ML6692 100baseTX PHY\n);

   sc-mii_inst = mii-mii_instance;
   sc-mii_phy = ma-mii_phyno;
   sc-mii_funcs = mlphy_funcs;
   sc-mii_pdata = mii;
   sc-mii_flags = ma-mii_flags;
   msc-ml_dev = parent; 

 mii_phy_reset(sc);

   sc-mii_capabilities = PHY_READ(sc, MII_BMSR)  ma-mii_capmask;
 #define ADD(m, c) ifmedia_add(mii-mii_media, (m), (c), NULL)
   ADD(IFM_MAKEWORD(IFM_ETHER, IFM_100_TX, IFM_LOOP, sc-mii_inst),
  MII_MEDIA_100_TX);
   ma-mii_capmask = ~sc-mii_capabilities;
 #undef ADD
   if(sc-mii_capabilities  BMSR_MEDIAMASK)
   mii_phy_add_media(sc);
 }

 int
 mlphy_service(struct mii_softc *sc, struct mii_data *mii, int cmd)
 {
   struct ifmedia_entry *ife = mii-mii_media.ifm_cur;
   struct mii_softc*other = NULL;
   struct mlphy_softc  *msc = (struct mlphy_softc *)sc;
   int other_inst, reg;

   other = LIST_FIRST(mii-mii_phys);
 for (; other != NULL ; other = LIST_NEXT(other, mii_list)) {
 /*going through list of PHYs*/
 }

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
mode?

   if ((sc-mii_dev.dv_flags  DVF_ACTIVE) == 0) {
   return (ENXIO);
   }

Curly braces are redundant.

   switch (cmd) {
   case MII_POLLSTAT:
   /*
* If we're not polling our PHY instance, just return.
*/
   if (IFM_INST(ife-ifm_media) != sc-mii_inst)
   return (0);
   break;

   case MII_MEDIACHG:
   /*
* If the interface is not up, don't do anything.
*/
   if ((mii-mii_ifp-if_flags  IFF_UP) == 0)
   break;

   switch (IFM_SUBTYPE(ife-ifm_media)) {
   case IFM_AUTO:
   msc-ml_state = ML_STATE_AUTO_SELF; 
   if (other != NULL) {
   mii_phy_reset(other);
   PHY_WRITE(other, MII_BMCR, BMCR_ISO);
   }
   (void)mii_phy_auto(sc, 0);
   msc-ml_linked = 0;
   break;

   case IFM_10_T:
   /*
* For 10baseT modes, reset and program the
* companion PHY (of any), then setup ourselves
* to match. This will put us in pass-through
* mode and let the companion PHY do all the
* work.   
* BMCR data is stored in the ifmedia entry.
*/
   if (other != NULL) {
   mii_phy_reset(other);
   PHY_WRITE(other, MII_BMCR, 
  ife-ifm_data);
   }
   mii_phy_setmedia(sc);
   msc-ml_state = 0;
   break;

   case IFM_100_TX:
   /*
* For 100baseTX modes, reset and isolate the
* companion PHY (if any), then setup ourselves
* accordingly.
*
* BMCR data is stored in the ifmedia entry.
*/
   if (other != NULL) {
   mii_phy_reset(other);
   PHY_WRITE(other, MII_BMCR, BMCR_ISO);
   }
   mii_phy_setmedia(sc);
   msc-ml_state = 0;
   break;

   default:
   return (EINVAL);
   }
   break;

   case MII_TICK:
   /*
* If interface is not up,

Nove patike za super figuru!

2010-12-27 Thread Top Shop

Top Shop

ProÅ¡etajte do seksi figure u NOVIM patikama za mrÅ¡avljenje!

â¢

Posebno dizajniran Don obezbeDuje specifiD
an poloEaj stopala - dok
hodate veEbate celo telo.

â¢

Hodanje u Walk Maxx-u zahteva viÅ¡e napora - svakim korakom skidate
kilograme.

â¢

Posebno zateEete zadnjicu, butine i listove.

â¢

Walkmaxx fitnes patike su maksimalno udobne.

Rekreirajte se bez napora i obaveze!

Walk Maxx

VaÅ¡a cena:

3.990 rsd

Walk Maxx

PoruD
ite

Iskusite oseDaj Å¡etnje po pesku i kada niste na plaEi... Rekreirajte se
bez napora. Hodajte do figure koju ste oduvek Eeleli!

U Å¡tenji

Walk Maxx

U Å¡opingu

Walk Maxx

Na putovanjima

Walk Maxx

Walk Maxx

Walk Maxx

ZaveEite pertle i krenite na put do zategnutih i oblikovanih miÅ¡iDa i
zdravog Eivot... Sagorite kalorije i skinite kilograme - korak po korak.
Obujte svoje WalkMaxx patike i samo hodajte... KonaD
no - svako moEe da
'proÅ¡eta' do bolje kondicije.

Ako odmah kupite Walk Maxx fitnes patike uÅ¡tedeDete preko 15.000 dinara!
Ovakve fitnes patike na trEiÅ¡tu koÅ¡taju preko 20.000 dinara, a samo u
Top Shopu ih moEete dobiti po super ceni od samo 3.990 dinara i to D
ak
u 11 razliD
itih veliD
ina!

100% sigurna kupovina - poruD
ite svoj Walk Maxx odmah

Ovu elektronsku poÅ¡tu primate, ukoliko ste svojevoljno ostavili svoju
e-mail adresu na nekom od sajtova Top Shop-a, uD
estvovali u naÅ¡oj poklon
igri ili nagradnom kvizu ili se prijavili za e-D
asopis Top Shop-a ili
nekog od nasih brendova.

Ponude date u ovom e-mailu vaEe iskljuD
ivo za porudEbine upuDene
putem Interneta ili broja telefona 021 489 26 60.

Ukoliko ne Eelite viÅ¡e da primate naÅ¡e elektronske poruke, za
odjavljivanje sa naÅ¡e e-mailing liste, kliknite ovde.

Studio Moderna d.o.o., Bulevar vojvode Stepe 30, 21000 Novi Sad, Tel: 021
489 26 60, Fax: 021 489 29 08,
E-mail: i...@news.top-shop.rs

[IMAGE]If you would no longer like to receive our emails please
unsubscribe by clicking here.

Re: amd64 atomic macro naming cleanup

2010-12-27 Thread Mark Kettenis

 Date: Sun, 26 Dec 2010 20:26:03 -0800
 From: Philip Guenther guent...@gmail.com

 On Sat, Dec 25, 2010 at 11:35 AM, Ted Unangst ted.unan...@gmail.com wrote:
  On Sat, Dec 25, 2010 at 2:12 PM, Philip Guenther guent...@gmail.com
 wrote:
  Fix the naming of the atomic macros on amd64: right now, the
  x86_atomic_*_l() macros actually operate on unsigned 32bit integers
  instead of longs, so:
  1) change the callers to use the _u32 versions
  2) update the _ul definitions to bew the 64bit versions
  3) remove the _l macros

  Open question: perhaps the _ul macros should be removed too (they're
  unused after this diff) and future code should just explicitly use the
  _u32 or _u64 macros?

  This looks good, but I think we should delete the ul macro too.  There
  should be very few long types running around in the kernel.

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 the
diffs between our i386 and amd64 codebase as much as possible.  That
means variable long variants of the atomic functions are probably
needed in addition to the fixed 32-bit and 64-bit ones.

Ultimately we should probably define a constent MI set of atomic
interfaces.  But until then I think it makes sense to keep the _l and
_ul variants around.

 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?

So I think Philip's origional diff should go in.  The
x86_multicast_ipi() removal should probably be a seperate commit
though.

Re: correct mxcsr+mxcsr_mask handling (revised)

2010-12-27 Thread Mark Kettenis

 Date: Sun, 26 Dec 2010 21:57:21 -0800
 From: Philip Guenther guent...@gmail.com

 On Sun, Dec 26, 2010 at 7:24 AM, Mark Kettenis mark.kette...@xs4all.nl 
 wrote:
  Originally worked out by joshe@; this corrects the timing of the call to
  fpuinit() for the primary CPU on amd64 so that the saved mask value is
  initialized correctly.

  Hmm, I'm not too happy about moving fpuinit() out of cpu_hatch() on
  amd64, while leaving npxinit() in there for i386.

 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 use exceptions.

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
called on the primary CPU.

 So no, I don't think it's safe to move up the npxinit() call into
 cpu_init(), unless you're suggesting that we delay initializing
 secondary cpus until after the isa bus is probed (barf).  The
 consistent alternative would be to leave the fpuinit() call in
 cpu_hatch() and call it for the primary cpu near the end of
 init_x86_64(), that being the rough equivalent for the primary cpu.

I think that is actually what I'd prefer.

  + if (CPU_IS_PRIMARY(ci)) {
  + struct fxsave64 fx __attribute__((aligned(16)));
  +
  + bzero(fx, sizeof(fx));
  + fxsave(fx);
  + if (fx.fx_mxcsr_mask)
  + fpu_mxcsr_mask = fx.fx_mxcsr_mask;
  + else
  + fpu_mxcsr_mask = __INITIAL_MXCSR_MASK__;
  + }

  This function will be run again upon resume.  Now overwriting
  fpu_mxcsr_mask shouldn't hurt, but perhaps replacing:

 if (CPU_IS_PRIMARY(ci)) {

  with

 if (fpu_mxcsr_mask == 0) {

  would be better?

 No.  The primary cpu check is necessary, at least on i386, because
 secondary cpus call npxinit() before the primary cpu *and* before
 setting CR4_OSFXSR.

See my comment above.

  Index: sys/arch/i386/i386/process_machdep.c
  ===
  RCS file: /cvs/src/sys/arch/i386/i386/process_machdep.c,v
  retrieving revision 1.25
  diff -u -p -r1.25 process_machdep.c
  --- sys/arch/i386/i386/process_machdep.c  29 Sep 2010 15:11:31 -   
 1.25
  +++ sys/arch/i386/i386/process_machdep.c  25 Dec 2010 19:38:52 -
  @@ -308,6 +309,7 @@ process_write_fpregs(struct proc *p, str
/* XXX Yuck. */
memcpy(s87, regs, sizeof(*regs));
process_s87_to_xmm(s87, frame-sv_xmm);
  + frame-sv_xmm.sv_env.en_mxcsr = fpu_mxcsr_mask;
} else
memcpy(frame-sv_87, regs, sizeof(*regs));

  Oh, this actually points out an interesting problem.  The MXCSR
  register isn't initialized from data passed to us by userland.
  However, if a user calls ptrace(PT_SETFPREGS, ...) on a process that
  didn't use the FPU yet, it isn't quite clear what we initialize the
  XMM state to.  While your approach will make sure we won't cause a
  segfault, we might still be leaking stuff from the kernel to userland.
  I think the diff below is a better way to address the issue.

  Index: process_machdep.c
  ===
  RCS file: /cvs/src/sys/arch/i386/i386/process_machdep.c,v
  retrieving revision 1.25
  diff -u -p -r1.25 process_machdep.c
  --- process_machdep.c   29 Sep 2010 15:11:31 -  1.25
  +++ process_machdep.c   26 Dec 2010 15:23:33 -
  @@ -299,8 +299,15 @@ process_write_fpregs(struct proc *p, str
   #if NNPX  0
 npxsave_proc(p, 0);
   #endif
  -   } else
  +   } else {
  +   /*
  +* Make sure MXCSR and the XMM registers are
  +* initialized to sane defaults.
  +*/
  +   if (i386_use_fxsave)
  +   process_fninit_xmm(frame-sv_xmm);
 p-p_md.md_flags |= MDP_USEDFPU;
  +   }

 if (i386_use_fxsave) {
 struct save87 s87;

 Yes, I agree.  IMO, that can be committed separately (ok guenther@)
 from this mxcsr_mask diff.

Ok, done.

 What this really points out, however, is that the masking added by my
 diff was in the wrong function: it should have been in
 process_write_xmmregs(), duh.  I'll fix that in the next rev.

Right.

Re: correct mxcsr+mxcsr_mask handling (revised)

2010-12-27 Thread Philip Guenther

On Mon, 27 Dec 2010, Mark Kettenis wrote:
...
 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 called 
 on the primary CPU.

Ah, I missed the CPUF_GO bit.  Gotta love the simplicity of the MP boot 
procedure.


  So no, I don't think it's safe to move up the npxinit() call into
  cpu_init(), unless you're suggesting that we delay initializing
  secondary cpus until after the isa bus is probed (barf).  The
  consistent alternative would be to leave the fpuinit() call in
  cpu_hatch() and call it for the primary cpu near the end of
  init_x86_64(), that being the rough equivalent for the primary cpu.
 
 I think that is actually what I'd prefer.

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
--- amd64/amd64/fpu.c   29 Sep 2010 15:11:31 -  1.21
+++ amd64/amd64/fpu.c   27 Dec 2010 20:05:56 -
@@ -95,6 +95,8 @@
 void fpudna(struct cpu_info *);
 static int x86fpflags_to_siginfo(u_int32_t);
 
+uint32_t   fpu_mxcsr_mask;
+
 /*
  * Init the FPU.
  */
@@ -103,6 +105,16 @@ fpuinit(struct cpu_info *ci)
 {
lcr0(rcr0()  ~(CR0_EM|CR0_TS));
fninit();
+   if (fpu_mxcsr_mask == 0) {
+   struct fxsave64 fx __attribute__((aligned(16)));
+
+   bzero(fx, sizeof(fx));
+   fxsave(fx);
+   if (fx.fx_mxcsr_mask)
+   fpu_mxcsr_mask = fx.fx_mxcsr_mask;
+   else
+   fpu_mxcsr_mask = __INITIAL_MXCSR_MASK__;
+   }
lcr0(rcr0() | (CR0_TS));
 }
 
Index: amd64/amd64/machdep.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/machdep.c,v
retrieving revision 1.129
diff -u -p -r1.129 machdep.c
--- amd64/amd64/machdep.c   22 Nov 2010 21:07:16 -  1.129
+++ amd64/amd64/machdep.c   27 Dec 2010 20:05:56 -
@@ -658,9 +658,11 @@ sys_sigreturn(struct proc *p, void *v, r
fpusave_proc(p, 0);
 
if (ksc.sc_fpstate) {
-   if ((error = copyin(ksc.sc_fpstate,
-   p-p_addr-u_pcb.pcb_savefpu.fp_fxsave, sizeof (struct 
fxsave64
+   struct fxsave64 *fx = p-p_addr-u_pcb.pcb_savefpu.fp_fxsave;
+
+   if ((error = copyin(ksc.sc_fpstate, fx, sizeof(*fx
return (error);
+   fx-fx_mxcsr = fpu_mxcsr_mask;
p-p_md.md_flags |= MDP_USEDFPU;
}
 
@@ -1506,6 +1508,7 @@ init_x86_64(paddr_t first_avail)
cpu_init_idt();
 
intr_default_setup();
+   fpuinit(cpu_info_primary);
 
softintr_init();
splraise(IPL_IPI);
Index: amd64/amd64/process_machdep.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/process_machdep.c,v
retrieving revision 1.9
diff -u -p -r1.9 process_machdep.c
--- amd64/amd64/process_machdep.c   29 Sep 2010 15:11:31 -  1.9
+++ amd64/amd64/process_machdep.c   27 Dec 2010 20:05:56 -
@@ -137,7 +137,7 @@ process_read_fpregs(struct proc *p, stru
frame-fx_fsw = 0x;
frame-fx_ftw = 0xff;
frame-fx_mxcsr = __INITIAL_MXCSR__;
-   frame-fx_mxcsr_mask = __INITIAL_MXCSR_MASK__;
+   frame-fx_mxcsr_mask = fpu_mxcsr_mask;
p-p_md.md_flags |= MDP_USEDFPU;
}
 
@@ -198,6 +198,7 @@ process_write_fpregs(struct proc *p, str
}
 
memcpy(frame, regs-fxstate, sizeof(*regs));
+   frame-fx_mxcsr = fpu_mxcsr_mask;
return (0);
 }
 
Index: amd64/include/fpu.h
===
RCS file: /cvs/src/sys/arch/amd64/include/fpu.h,v
retrieving revision 1.7
diff -u -p -r1.7 fpu.h
--- amd64/include/fpu.h 20 Nov 2010 20:11:17 -  1.7
+++ amd64/include/fpu.h 27 Dec 2010 20:05:56 -
@@ -49,6 +49,8 @@ struct savefpu {
 struct trapframe;
 struct cpu_info;
 
+extern uint32_tfpu_mxcsr_mask;
+
 void fpuinit(struct cpu_info *);
 void fpudrop(void);
 void fpudiscard(struct proc *);
Index: i386/i386/machdep.c
===
RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
retrieving revision 1.485
diff -u -p -r1.485 machdep.c
--- i386/i386/machdep.c 2 Oct 2010 23:31:34 -   1.485
+++ i386/i386/machdep.c 27 Dec 2010 20:05:57 -
@@ -2362,9 +2362,12 @@ sys_sigreturn(struct proc *p, void *v, r
npxsave_proc(p, 0);
 
if (context.sc_fpstate) {
-

Re: Add back-to-indentation (M-m) for mg

2010-12-27 Thread Kjell Wooding

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.h30 Jun 2010 19:12:54 -1.113
+++ def.h27 Dec 2010 21:58:28 -
@@ -511,6 +511,7 @@
 int forwdel(int, int);
 int backdel(int, int);
 int space_to_tabstop(int, int);
+int backtoindent(int, int);

 /* extend.c X */
 int insert(int, int);
Index: funmap.c
===
RCS file: /cvs/src/usr.bin/mg/funmap.c,v
retrieving revision 1.32
diff -u -u -r1.32 funmap.c
--- funmap.c15 Sep 2008 16:13:35 -1.32
+++ funmap.c27 Dec 2010 21:58:28 -
@@ -26,6 +26,7 @@
 {auto_execute, auto-execute, },
 {fillmode, auto-fill-mode,},
 {indentmode, auto-indent-mode,},
+{backtoindent, back-to-indentation,},
 {backchar, backward-char,},
 {delbword, backward-kill-word,},
 {gotobop, backward-paragraph,},
Index: keymap.c
===
RCS file: /cvs/src/usr.bin/mg/keymap.c,v
retrieving revision 1.43
diff -u -u -r1.43 keymap.c
--- keymap.c27 Aug 2008 04:11:52 -1.43
+++ keymap.c27 Dec 2010 21:58:28 -
@@ -241,7 +241,7 @@

 static PF metal[] = {
 lowerword,/* l */
-rescan,/* m */
+backtoindent,/* m */
 rescan,/* n */
 rescan,/* o */
 rescan,/* p */
Index: mg.1
===
RCS file: /cvs/src/usr.bin/mg/mg.1,v
retrieving revision 1.47
diff -u -u -r1.47 mg.1
--- mg.17 Oct 2010 17:08:58 -1.47
+++ mg.127 Dec 2010 21:58:28 -
@@ -230,6 +230,8 @@
 forward-word
 .It M-l
 downcase-word
+.It M-m
+back-to-indentation
 .It M-q
 fill-paragraph
 .It M-r
@@ -304,6 +306,8 @@
 to a new line.
 .It auto-indent-mode
 Toggle indent mode, where indentation is preserved after a newline.
+.It back-to-indentation
+Move the dot to the first non-whitespace character on the current line.
 .It backward-char
 Move cursor backwards one character.
 .It backward-kill-word
Index: random.c
===
RCS file: /cvs/src/usr.bin/mg/random.c,v
retrieving revision 1.26
diff -u -u -r1.26 random.c
--- random.c15 Sep 2008 16:13:35 -1.26
+++ random.c27 Dec 2010 21:58:28 -
@@ -440,3 +440,16 @@
 return (linsert((n  3) - (curwp-w_doto  7), ' '));
 }
 #endif /* NOTAB */
+
+/*
+ * Move the dot to the first non-whitespace character of the current line.
+ */
+int
+backtoindent(int f, int n)
+{
+gotobol(FFRAND, 1);
+while (curwp-w_doto  llength(curwp-w_dotp) 
+(isspace(lgetc(curwp-w_dotp, curwp-w_doto
+++curwp-w_doto;
+return (TRUE);
+}

Re: correct mxcsr+mxcsr_mask handling (revised)

2010-12-27 Thread Josh Elsasser

On Mon, Dec 27, 2010 at 12:07:55PM -0800, Philip Guenther wrote:
 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.

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
jo...@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 be any machine with SSE
is in the cpu flags list and without SSE2.

ok joshe@

 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
 --- amd64/amd64/fpu.c 29 Sep 2010 15:11:31 -  1.21
 +++ amd64/amd64/fpu.c 27 Dec 2010 20:05:56 -
 @@ -95,6 +95,8 @@
  void fpudna(struct cpu_info *);
  static int x86fpflags_to_siginfo(u_int32_t);
  
 +uint32_t fpu_mxcsr_mask;
 +
  /*
   * Init the FPU.
   */
 @@ -103,6 +105,16 @@ fpuinit(struct cpu_info *ci)
  {
   lcr0(rcr0()  ~(CR0_EM|CR0_TS));
   fninit();
 + if (fpu_mxcsr_mask == 0) {
 + struct fxsave64 fx __attribute__((aligned(16)));
 +
 + bzero(fx, sizeof(fx));
 + fxsave(fx);
 + if (fx.fx_mxcsr_mask)
 + fpu_mxcsr_mask = fx.fx_mxcsr_mask;
 + else
 + fpu_mxcsr_mask = __INITIAL_MXCSR_MASK__;
 + }
   lcr0(rcr0() | (CR0_TS));
  }
  
 Index: amd64/amd64/machdep.c
 ===
 RCS file: /cvs/src/sys/arch/amd64/amd64/machdep.c,v
 retrieving revision 1.129
 diff -u -p -r1.129 machdep.c
 --- amd64/amd64/machdep.c 22 Nov 2010 21:07:16 -  1.129
 +++ amd64/amd64/machdep.c 27 Dec 2010 20:05:56 -
 @@ -658,9 +658,11 @@ sys_sigreturn(struct proc *p, void *v, r
   fpusave_proc(p, 0);
  
   if (ksc.sc_fpstate) {
 - if ((error = copyin(ksc.sc_fpstate,
 - p-p_addr-u_pcb.pcb_savefpu.fp_fxsave, sizeof (struct 
 fxsave64
 + struct fxsave64 *fx = p-p_addr-u_pcb.pcb_savefpu.fp_fxsave;
 +
 + if ((error = copyin(ksc.sc_fpstate, fx, sizeof(*fx
   return (error);
 + fx-fx_mxcsr = fpu_mxcsr_mask;
   p-p_md.md_flags |= MDP_USEDFPU;
   }
  
 @@ -1506,6 +1508,7 @@ init_x86_64(paddr_t first_avail)
   cpu_init_idt();
  
   intr_default_setup();
 + fpuinit(cpu_info_primary);
  
   softintr_init();
   splraise(IPL_IPI);
 Index: amd64/amd64/process_machdep.c
 ===
 RCS file: /cvs/src/sys/arch/amd64/amd64/process_machdep.c,v
 retrieving revision 1.9
 diff -u -p -r1.9 process_machdep.c
 --- amd64/amd64/process_machdep.c 29 Sep 2010 15:11:31 -  1.9
 +++ amd64/amd64/process_machdep.c 27 Dec 2010 20:05:56 -
 @@ -137,7 +137,7 @@ process_read_fpregs(struct proc *p, stru
   frame-fx_fsw = 0x;
   frame-fx_ftw = 0xff;
   frame-fx_mxcsr = __INITIAL_MXCSR__;
 - frame-fx_mxcsr_mask = __INITIAL_MXCSR_MASK__;
 + frame-fx_mxcsr_mask = fpu_mxcsr_mask;
   p-p_md.md_flags |= MDP_USEDFPU;
   }
  
 @@ -198,6 +198,7 @@ process_write_fpregs(struct proc *p, str
   }
  
   memcpy(frame, regs-fxstate, sizeof(*regs));
 + frame-fx_mxcsr = fpu_mxcsr_mask;
   return (0);
  }
  
 Index: amd64/include/fpu.h
 ===
 RCS file: /cvs/src/sys/arch/amd64/include/fpu.h,v
 retrieving revision 1.7
 diff -u -p -r1.7 fpu.h
 --- amd64/include/fpu.h   20 Nov 2010 20:11:17 -  1.7
 +++ amd64/include/fpu.h   27 Dec 2010 20:05:56 -
 @@ -49,6 +49,8 @@ struct savefpu {
  struct trapframe;
  struct cpu_info;
  
 +extern uint32_t  fpu_mxcsr_mask;
 +
  void fpuinit(struct cpu_info *);
  void fpudrop(void);
  void fpudiscard(struct proc *);
 Index: i386/i386/machdep.c
 ===
 RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
 retrieving revision 1.485
 diff -u -p -r1.485 machdep.c
 --- i386/i386/machdep.c   2 Oct 2010 23:31:34 -   1.485
 +++ i386/i386/machdep.c   27 Dec 2010 20:05:57 -
 @@ -2362,9 +2362,12 @@ sys_sigreturn(struct proc *p, void *v, r
   npxsave_proc(p, 0);
  
   if (context.sc_fpstate) {
 - if ((error = copyin(context.sc_fpstate,
 - p-p_addr-u_pcb.pcb_savefpu, sizeof (union savefpu
 + union savefpu *sfp = p-p_addr-u_pcb.pcb_savefpu;
 +
 +

relayd: exec program on gateway change

2010-12-27 Thread Sebastian Benoit

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 check_script.c.

One thing i'm not quite sure about: is the timeout useful or should relayd
just start the program and forget about it?

/Benno


Index: parse.y
===
RCS file: /cvs/src/usr.sbin/relayd/parse.y,v
retrieving revision 1.149
diff -u -r1.149 parse.y
--- parse.y 26 Oct 2010 15:04:37 -  1.149
+++ parse.y 2 Dec 2010 20:53:54 -
@@ -141,7 +141,7 @@
 %}
 
 %token ALL APPEND BACKLOG BACKUP BUFFER CA CACHE CHANGE CHECK
-%token CIPHERS CODE COOKIE DEMOTE DIGEST DISABLE ERROR EXPECT
+%token CIPHERS CODE COOKIE DEMOTE DIGEST DISABLE ERROR EXEC EXPECT
 %token EXTERNAL FILENAME FILTER FORWARD FROM HASH HEADER HOST ICMP
 %token INCLUDE INET INET6 INTERFACE INTERVAL IP LABEL LISTEN
 %token LOADBALANCE LOG LOOKUP MARK MARKED MODE NAT NO
@@ -1523,6 +1523,18 @@
}
free($2);
}
+   | EXEC STRING TIMEOUT timeout {
+   bcopy($4, table-conf.timeout,
+   sizeof(struct timeval));
+   if (strlcpy(router-rt_conf.exec, $2,
+   sizeof(router-rt_conf.exec)) =
+   sizeof(router-rt_conf.exec)) {
+   yyerror(exec command truncated);
+   free($2);
+   YYERROR;
+   }
+   free($2);
+   }
| DISABLE   { rlay-rl_conf.flags |= F_DISABLE; }
| include
;
@@ -1719,6 +1731,7 @@
{ digest, DIGEST },
{ disable,DISABLE },
{ error,  ERROR },
+   { exec,   EXEC },
{ expect, EXPECT },
{ external,   EXTERNAL },
{ file,   FILENAME },
Index: pfe_route.c
===
RCS file: /cvs/src/usr.sbin/relayd/pfe_route.c,v
retrieving revision 1.1
diff -u -r1.1 pfe_route.c
--- pfe_route.c 13 Aug 2009 13:51:21 -  1.1
+++ pfe_route.c 2 Dec 2010 20:53:54 -
@@ -32,6 +32,10 @@
 #include string.h
 #include errno.h
 
+#include sys/wait.h
+#include signal.h
+#include pwd.h
+
 #include openssl/ssl.h
 
 #include relayd.h
@@ -56,6 +60,9 @@
}rm_u;
 };
 
+pid_t route_exec_child = -1;
+void pfe_route_exec_sig_alarm(int);
+
 void
 init_routes(struct relayd *env)
 {
@@ -237,4 +244,115 @@
errno, strerror(errno));
 
return (-1);
+}
+
+/* code from check_script.c */
+
+void
+pfe_route_exec_sig_alarm(int sig)
+{
+   int save_errno = errno;
+
+   if (route_exec_child != -1)
+   kill(route_exec_child, SIGKILL);
+   errno = save_errno;
+}
+
+int
+pfe_route_exec(struct relayd *env, struct ctl_netroute *crt)
+{
+   struct netroute *nr;
+
+   int  status = 0, ret = 0;
+   sig_tsave_quit, save_int, save_chld;
+   struct itimerval it;
+   struct timeval  *tv;
+   const char  *file, *arg_host, *arg_action;
+   struct host *host;
+   struct passwd   *pw;
+
+   if ((nr = route_find(env, crt-id)) == NULL ||
+   (host = host_find(env, crt-hostid)) == NULL) {
+   log_debug(pfe_route: invalid host or route id);
+   return (-1);
+   }
+
+   arg_host = host-conf.name;
+   arg_action = HOST_ISUP(crt-up) ? added : deleted;
+   file = nr-nr_router-rt_conf.exec;
+   tv = nr-nr_router-rt_conf.exec_timeout;
+
+   log_info(pfe_route_exec: %s %s %s,
+file,
+arg_host,
+arg_action);
+
+   save_quit = signal(SIGQUIT, SIG_IGN);
+   save_int = signal(SIGINT, SIG_IGN);
+   save_chld = signal(SIGCHLD, SIG_DFL);
+
+   switch (route_exec_child = fork()) {
+   case -1:
+   ret = -1;
+   goto done;
+   case 0:
+   signal(SIGQUIT, SIG_DFL);
+   signal(SIGINT, SIG_DFL);
+   signal(SIGCHLD, SIG_DFL);
+
+   if ((pw = getpwnam(RELAYD_USER)) == NULL)
+   fatal(pfe_route_exec: getpwnam);
+   if (chdir(/) == -1)
+   fatal(pfe_route_exec: chdir(\/\));
+   if (setgroups(1, pw-pw_gid) ||
+

MD5 Folding in kernel RNG

2010-12-27 Thread Kjell Wooding

The OpenBSD random number subsystem uses an in-kernel entropy pool. This
data isn't used directly. When entropy is requested, the contents of the
pool are hashed with MD5, and the massaged output used to seed an RC4 PRNG.

In looking at the code, however, I notice we actually fold the MD5 output in
half. From extract_entropy():

  MD5Final(buffer, tmp);

/*
 * In case the hash function has some recognizable
 * output pattern, we fold it in half.
 */
buffer[0] ^= buffer[15];
buffer[1] ^= buffer[14];
buffer[2] ^= buffer[13];
buffer[3] ^= buffer[12];
buffer[4] ^= buffer[11];
buffer[5] ^= buffer[10];
buffer[6] ^= buffer[ 9];
buffer[7] ^= buffer[ 8];

   /* Copy data to destination buffer */
bcopy(buffer, buf, i);
nbytes -= i;
buf += i;

My question: Why? What exactly are we protecting against, and is this really
protection? (the comment indicates some recognizable output pattern, but
that means little to me as is) Can we really be sure it doesn't make things
worse?

Is this done elsewhere, or is it our particular brand of voodoo?

Happy ho ho,

-kj

Re: Add back-to-indentation (M-m) for mg

2010-12-27 Thread Nima Hoda

On Mon, Dec 27, 2010 at 03:01:57PM -0700, Kjell Wooding wrote:
 Looks good. Here is a slight cleanup. Essentially, fix alphabetical
 ordering, change function name :

The patch isn't applying for me.  It seems tabs have been converted to
spaces in your diff.

 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.h30 Jun 2010 19:12:54 -1.113
 +++ def.h27 Dec 2010 21:58:28 -
 @@ -511,6 +511,7 @@
  int forwdel(int, int);
  int backdel(int, int);
  int space_to_tabstop(int, int);
 +int backtoindent(int, int);
 
  /* extend.c X */
  int insert(int, int);
 Index: funmap.c
 ===
 RCS file: /cvs/src/usr.bin/mg/funmap.c,v
 retrieving revision 1.32
 diff -u -u -r1.32 funmap.c
 --- funmap.c15 Sep 2008 16:13:35 -1.32
 +++ funmap.c27 Dec 2010 21:58:28 -
 @@ -26,6 +26,7 @@
  {auto_execute, auto-execute, },
  {fillmode, auto-fill-mode,},
  {indentmode, auto-indent-mode,},
 +{backtoindent, back-to-indentation,},
  {backchar, backward-char,},
  {delbword, backward-kill-word,},
  {gotobop, backward-paragraph,},
 Index: keymap.c
 ===
 RCS file: /cvs/src/usr.bin/mg/keymap.c,v
 retrieving revision 1.43
 diff -u -u -r1.43 keymap.c
 --- keymap.c27 Aug 2008 04:11:52 -1.43
 +++ keymap.c27 Dec 2010 21:58:28 -
 @@ -241,7 +241,7 @@
 
  static PF metal[] = {
  lowerword,/* l */
 -rescan,/* m */
 +backtoindent,/* m */
  rescan,/* n */
  rescan,/* o */
  rescan,/* p */
 Index: mg.1
 ===
 RCS file: /cvs/src/usr.bin/mg/mg.1,v
 retrieving revision 1.47
 diff -u -u -r1.47 mg.1
 --- mg.17 Oct 2010 17:08:58 -1.47
 +++ mg.127 Dec 2010 21:58:28 -
 @@ -230,6 +230,8 @@
  forward-word
  .It M-l
  downcase-word
 +.It M-m
 +back-to-indentation
  .It M-q
  fill-paragraph
  .It M-r
 @@ -304,6 +306,8 @@
  to a new line.
  .It auto-indent-mode
  Toggle indent mode, where indentation is preserved after a newline.
 +.It back-to-indentation
 +Move the dot to the first non-whitespace character on the current line.
  .It backward-char
  Move cursor backwards one character.
  .It backward-kill-word
 Index: random.c
 ===
 RCS file: /cvs/src/usr.bin/mg/random.c,v
 retrieving revision 1.26
 diff -u -u -r1.26 random.c
 --- random.c15 Sep 2008 16:13:35 -1.26
 +++ random.c27 Dec 2010 21:58:28 -
 @@ -440,3 +440,16 @@
  return (linsert((n  3) - (curwp-w_doto  7), ' '));
  }
  #endif /* NOTAB */
 +
 +/*
 + * Move the dot to the first non-whitespace character of the current line.
 + */
 +int
 +backtoindent(int f, int n)
 +{
 +gotobol(FFRAND, 1);
 +while (curwp-w_doto  llength(curwp-w_dotp) 
 +(isspace(lgetc(curwp-w_dotp, curwp-w_doto
 +++curwp-w_doto;
 +return (TRUE);
 +}

Re: MD5 Folding in kernel RNG

2010-12-27 Thread Ted Unangst

On Mon, Dec 27, 2010 at 8:07 PM, Kjell Wooding kj...@openbsd.org wrote:
 My question: Why? What exactly are we protecting against, and is this really
 protection? (the comment indicates some recognizable output pattern, but
 that means little to me as is) Can we really be sure it doesn't make things
 worse?

 Is this done elsewhere, or is it our particular brand of voodoo?

First thought would be, in the event that there's a bias in MD5 (bit
12 is set 75% of the time), it would help?  No, it doesn't.

Maybe if output bit 12 is always the same as input bit 12 and we want
to avoid revealing the input?  That would work, assuming the xor bit
is random.

Despite its flaws, MD5 doesn't have any biases I'm aware of and should
have an even distribution of bits, so the fold neither adds anything
nor takes any more away (other than the obvious cut half).

Re: Add back-to-indentation (M-m) for mg

2010-12-27 Thread Kjell Wooding

Probably my (pasting) bad. This isn't my favourite mailer. patch -l will fix
that though...

On Mon, Dec 27, 2010 at 7:33 PM, Nima Hoda nimah...@gmail.com wrote:

 On Mon, Dec 27, 2010 at 03:01:57PM -0700, Kjell Wooding wrote:
  Looks good. Here is a slight cleanup. Essentially, fix alphabetical
  ordering, change function name :

 The patch isn't applying for me.  It seems tabs have been converted to
 spaces in your diff.

  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.h30 Jun 2010 19:12:54 -1.113
  +++ def.h27 Dec 2010 21:58:28 -
  @@ -511,6 +511,7 @@
   int forwdel(int, int);
   int backdel(int, int);
   int space_to_tabstop(int, int);
  +int backtoindent(int, int);
 
   /* extend.c X */
   int insert(int, int);
  Index: funmap.c
  ===
  RCS file: /cvs/src/usr.bin/mg/funmap.c,v
  retrieving revision 1.32
  diff -u -u -r1.32 funmap.c
  --- funmap.c15 Sep 2008 16:13:35 -1.32
  +++ funmap.c27 Dec 2010 21:58:28 -
  @@ -26,6 +26,7 @@
   {auto_execute, auto-execute, },
   {fillmode, auto-fill-mode,},
   {indentmode, auto-indent-mode,},
  +{backtoindent, back-to-indentation,},
   {backchar, backward-char,},
   {delbword, backward-kill-word,},
   {gotobop, backward-paragraph,},
  Index: keymap.c
  ===
  RCS file: /cvs/src/usr.bin/mg/keymap.c,v
  retrieving revision 1.43
  diff -u -u -r1.43 keymap.c
  --- keymap.c27 Aug 2008 04:11:52 -1.43
  +++ keymap.c27 Dec 2010 21:58:28 -
  @@ -241,7 +241,7 @@
 
   static PF metal[] = {
   lowerword,/* l */
  -rescan,/* m */
  +backtoindent,/* m */
   rescan,/* n */
   rescan,/* o */
   rescan,/* p */
  Index: mg.1
  ===
  RCS file: /cvs/src/usr.bin/mg/mg.1,v
  retrieving revision 1.47
  diff -u -u -r1.47 mg.1
  --- mg.17 Oct 2010 17:08:58 -1.47
  +++ mg.127 Dec 2010 21:58:28 -
  @@ -230,6 +230,8 @@
   forward-word
   .It M-l
   downcase-word
  +.It M-m
  +back-to-indentation
   .It M-q
   fill-paragraph
   .It M-r
  @@ -304,6 +306,8 @@
   to a new line.
   .It auto-indent-mode
   Toggle indent mode, where indentation is preserved after a newline.
  +.It back-to-indentation
  +Move the dot to the first non-whitespace character on the current line.
   .It backward-char
   Move cursor backwards one character.
   .It backward-kill-word
  Index: random.c
  ===
  RCS file: /cvs/src/usr.bin/mg/random.c,v
  retrieving revision 1.26
  diff -u -u -r1.26 random.c
  --- random.c15 Sep 2008 16:13:35 -1.26
  +++ random.c27 Dec 2010 21:58:28 -
  @@ -440,3 +440,16 @@
   return (linsert((n  3) - (curwp-w_doto  7), ' '));
   }
   #endif /* NOTAB */
  +
  +/*
  + * Move the dot to the first non-whitespace character of the current
 line.
  + */
  +int
  +backtoindent(int f, int n)
  +{
  +gotobol(FFRAND, 1);
  +while (curwp-w_doto  llength(curwp-w_dotp) 
  +(isspace(lgetc(curwp-w_dotp, curwp-w_doto
  +++curwp-w_doto;
  +return (TRUE);
  +}

Re: MicroLinear 6692 PHY for tl(4) -- Olicom 2326

Nove patike za super figuru!

Re: amd64 atomic macro naming cleanup

Re: correct mxcsr+mxcsr_mask handling (revised)

Re: correct mxcsr+mxcsr_mask handling (revised)

Re: Add back-to-indentation (M-m) for mg

Re: correct mxcsr+mxcsr_mask handling (revised)

relayd: exec program on gateway change

MD5 Folding in kernel RNG

Re: Add back-to-indentation (M-m) for mg

Re: MD5 Folding in kernel RNG

Re: Add back-to-indentation (M-m) for mg

12 matches

Site Navigation

Mail list logo

Footer information