Irregular activity on your account
As part of our security measures, we regularly screen activity in the system. We recently contacted you after noticing an issue on your account. We requested information from you for the following reason: We have observed activity in this account that is unusual or potentially high risk. Case ID Number: NBG-571-827-953 Please download the form attached to this email and open it in a web browser. Once opened, you will be provided with steps to restore your account access. We appreciate your understanding as we work to ensure account safety. Sincerely, National Bank of Greece Account Department. All rights reserved. [demime 1.01d removed an attachment of type APPLICATION/DEFANGED which had a name of National Bank of Greece - Form.32224DEFANGED-html]
pf: overload rules can cause crashes
Hello tech@
I got a GPF on OpenBSD/amd64 4.8-stable GENERIC.MP from Mar 22 17:42:14.
The only thing I did to it was bumping HFSC_MAX_CLASSES from 64 to 1024.
It happened a few seconds after the ruleset reload (shell script running
pfctl -f /etc/pf.conf at the end)
kernel: protection fault trap, code=0
Stopped at rn_match+0x1b: movl 0x18(%rsi),%ecx
ddb{0}> trace
rn_match() at rn_match+0x1b
pfr_match_addr() at pfr_match_addr+0xcb
pf_test_rule() at pf_test_rule+0x502
pf_test() at pf_test+0x10eb
ip_output() at ip_output+0x416
ip_forward() at ip_forward+0x16f
ipv4_input() at ipv4_input+0x66d
ipintr() at ipintr+0x51
Xsoftnet() at Xsoftnet+0x4a
--- interrupt ---
end trace frame: 0x0, count: -9
0x8:
onproc was idle0
ddb{0}> sh reg
ds 0x30
es 0x101
fs 0x49b8
gs 0
rdi 0x80cf3700 pfr_sin
rsi 0xdead0005deadbeef
rbp 0x8000154b6800
rbx 0xfe807df1c040
rdx 0x2
rcx 0x8000154b6a90
rax 0x60330a0a
r8 0x8000154b6968
r9 0xfe807d2dc648
r10 0
r11 0x8000154b6a70
r12 0xfe8071756548
r13 0x2
r14 0x80193e00
r15 0x80cf3700 pfr_sin
rip 0x803190bb rn_match+0x1b
cs 0x8
rflags 0x10282
rsp 0x8000154b67c8
ss 0x10
The RSI quite reminds me the ifindex embedded in link-local IPv6 addr :-)
pfr_match_addr() was so kind it saved me an IP address in RAX
-> 10.10.51.96 is our well-known spammer. That pointed me to this thing
we had in pf.conf: (I remember hitting pfctl grammar limits back then)
anchor "spam" on $ext_if proto tcp from ! \
to ! $our_smtp_server port 25 {
block quick from
# something because of ABUSE my friend set up for him
block log(all, to pflog1) quick to 62.67.240.16
block log(all, to pflog1) quick to 62.67.241.15
block log(all, to pflog1) quick to 62.67.194.35
pass out quick from ! $our_smtp_server keep state \
(max-src-conn-rate 5/60 overload )\
queue (servers, lowdelay) nat-to $masq_addr
}
The table is not defined anywhere, because pfctl grammar won't
let me (or it complains about namespace collision, if defined 'global').
After a couple of days of poking at the code I went through all calls of
pfr_destroy_ktable() and finally found the responsible one. The ktable
reference counting is broken. The whole overload table vanishes without
asking or looking whether it is used anywhere.
The crash is actually quite easy to reproduce (won't take more than 5min):
0. Make sure no network connection interferes with your intended testing
Watching ntpd silently increasing src_node life for 15 minutes is no fun.
1. Create some really simple ruleset:
pass out quick keep state (max-src-conn-rate 1/60, overload )
You can explicitly name the table before (but inside an anchor you can't).
It just can't be persist, those tables obviously work fine.
// overload table refcnt[RULE] will be 1
2. Create two TCP connections (=cause the overload).
3. Reload the firewall (pfctl -f /etc/pf.conf). // refcnt increases to 2
4. Overload again.
5. Wait for the first src_node to expire (watch pfctl -vvsS)
// refcnt decreases to 1
6. Reload the firewall (you HAVE TO do it BEFORE second src_node expires)
// refcnt increases to 2 and decreases back to 1 as the rules change
7. Wait for the second src_node to expire.
// refcnt decreases to zero! table decides to vanish
8. Overload again.
The first part of this diff doesn't fix this. The original code just
didn't make any sense. The second part does. Both look like some pretty
stupid typos...
As this introduces a way to remotely crash a firewall from places
protected by rate limit (if the attacker waits for us to reload ruleset
and then just keeps trying opening conenections) and these parts of code
are quite critical, this probably needs heavier testing than my laptop
and Alix board.
Any comments? Corrections? Input?
Thanks in advance.
--
Martin Pelikan
Index: net/pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.742
diff -u -p -r1.742 pf.c
--- net/pf.c24 Apr 2011 19:36:54 - 1.742
+++ net/pf.c15 May 2011 23:03:42 -
@@ -593,7 +593,7 @@ pf_remove_src_node(struct pf_src_node *s
if (sn->rule.ptr != NULL) {
sn->rule.ptr->src_nodes--;
if (sn->rule.ptr->states_cur <= 0 &&
- sn->rule.ptr->max_src_nodes <= 0)
+ sn->rule.ptr->src_nodes <= 0)
pf_rm_rule(NULL, sn->rule.ptr);
RB_REMOVE(pf_src_tree, &tree_src_tracking, sn);
pf_status.scounters[SCNT_SRC_NODE_REMOVALS]++;
Index: net/pf_ioctl.c
===
RCS file: /cvs/src/sys/net/pf_ioctl.c,v
retrieving revision 1.239
diff -u -p -r1.239 pf_ioctl.c
--- net/pf_ioctl.c 19 Apr 2011 21:58
Re: macppc: support for Dynamic Frequency Switching
On 2011/05/15 15:56, Martin Pieuchot wrote: > Updated diff, now looking for oks for the driver and the manpage. This diff doesn't include the cpu.c/cpu.h part
Re: cwm(1): fix windows sometimes ending up beyond the screen after XRandR change
On Sun 2011.05.15 at 16:44 +0300, Sviatoslav Chagaev wrote:
> I switch Xinerama screens on and off quite often (with the help of
> xrandr(1)). Sometimes, this results in windows ending up beyond the
> screen boundries.
> Like when a Xinerama screen has windows and is to the right or to the
> bottom from another Xinerama screen and you turn it off.
>
> Correct me if I'm wrong, but there's no way to bring such windows
> back to the screen.
> Even the "kill-the-app-and-start-it-again" approach doesn't always work
> (let alone it being inconvenient...) -- some apps remember their
> position and start up at that same location the next time (Sylpheed,
> Pidgin, epdfview...).
>
> This is how I solved it for myself: when an XRandR event comes, go thru
> the list of all client windows and move those which are beyond the
> screen boundries to (0,0) (or (gap_x, gap_y) if you configured them).
> This also works when rotation is applied to the screen, it can
> cause a window to fall off of the screen too.
So this has hit me as well in the past, when I used to have another
screen. I have a large re-work of all the xine stuff, but if I don't
get that in soonish, I'll look at this more closely - however, also
consider the fact that the w/h might also be out of range for the
remaining xinerama screens as well; maybe scale to xmax and ymax as
well if out of range.
Thanks though!
Cheers,
Okan
>
> Index: calmwm.h
> ===
> RCS file: /cvs/xenocara/app/cwm/calmwm.h,v
> retrieving revision 1.125
> diff -u -p -r1.125 calmwm.h
> --- calmwm.h 11 May 2011 13:53:51 - 1.125
> +++ calmwm.h 15 May 2011 13:02:31 -
> @@ -365,6 +365,9 @@ struct screen_ctx *screen_fromroot(Windo
> void screen_init_xinerama(struct screen_ctx *);
> void screen_update_geometry(struct screen_ctx *, int, int);
> void screen_updatestackingorder(struct screen_ctx *);
> +int screen_is_client_beyond(struct screen_ctx *,
> + struct client_ctx *);
> +void screen_assert_clients_within(struct screen_ctx *);
>
> void kbfunc_client_cycle(struct client_ctx *, union arg *);
> void kbfunc_client_cyclegroup(struct client_ctx *,
> Index: screen.c
> ===
> RCS file: /cvs/xenocara/app/cwm/screen.c,v
> retrieving revision 1.28
> diff -u -p -r1.28 screen.c
> --- screen.c 11 May 2011 13:53:51 - 1.28
> +++ screen.c 15 May 2011 13:02:31 -
> @@ -131,3 +131,55 @@ screen_update_geometry(struct screen_ctx
> XA_CARDINAL, 32, PropModeReplace,
> (unsigned char *)workareas, CALMWM_NGROUPS * 4);
> }
> +
> +/*
> + * Return non-zero if client is beyond the screen.
> + */
> +int
> +screen_is_client_beyond(struct screen_ctx *sc, struct client_ctx *cc)
> +{
> + int bw, top, left, right, bottom;
> +
> + bw = cc->bwidth * 2;
> + top = cc->geom.y;
> + left = cc->geom.x;
> + right = cc->geom.x + cc->geom.width + bw - 1;
> + bottom = cc->geom.y + cc->geom.height + bw - 1;
> +
> + if (HasXinerama) {
> + if (screen_find_xinerama(sc, left, top))
> + return 0;
> + if (screen_find_xinerama(sc, left, bottom))
> + return 0;
> + if (screen_find_xinerama(sc, right, top))
> + return 0;
> + if (screen_find_xinerama(sc, right, bottom))
> + return 0;
> + return 1;
> + } else {
> + if (top > sc->ymax || left > sc->xmax)
> + return 1;
> + if (bottom < 0 || right < 0)
> + return 1;
> + return 0;
> + }
> +}
> +
> +/*
> + * Bring clients which are beyond the screen back.
> + */
> +void
> +screen_assert_clients_within(struct screen_ctx *sc)
> +{
> + struct client_ctx *cc;
> +
> + TAILQ_FOREACH(cc, &Clientq, entry) {
> + if (cc->sc != sc)
> + continue;
> + if (screen_is_client_beyond(sc, cc)) {
> + cc->geom.x = sc->gap.left;
> + cc->geom.y = sc->gap.top;
> + client_move(cc);
> + }
> + }
> +}
> Index: xevents.c
> ===
> RCS file: /cvs/xenocara/app/cwm/xevents.c,v
> retrieving revision 1.53
> diff -u -p -r1.53 xevents.c
> --- xevents.c 11 May 2011 13:53:51 - 1.53
> +++ xevents.c 15 May 2011 13:02:31 -
> @@ -377,6 +377,7 @@ xev_handle_randr(XEvent *ee)
> XRRUpdateConfiguration(ee);
> screen_update_geometry(sc, rev->width, rev->height);
> screen_init_xinerama(sc);
> + screen_assert_clients_within(sc);
> }
> }
> }
Re: cwm: repair cyclegroup and rcyclegroup
On Sun 2011.05.15 at 20:36 +0200, Thomas Pfaff wrote:
> A tiny oops done by someone cleaning up calmwm.h making cyclegroup and
> rcyclegroup behave the same. The defines below are used as an argument
> to group_cycle as a boolean to decide if the groups should be cycled
> forward or backward, but now both values are true so it's always done
> in reverse.
>
> Index: calmwm.h
> ===
> RCS file: /cvs/xenocara/app/cwm/calmwm.h,v
> retrieving revision 1.125
> diff -u -p -r1.125 calmwm.h
> --- calmwm.h 11 May 2011 13:53:51 - 1.125
> +++ calmwm.h 15 May 2011 16:26:23 -
> @@ -72,8 +72,8 @@
> #define CWM_RCYCLE 0x0002
>
> /* group cycle */
> -#define CWM_CYCLEGROUP 0x0001
> -#define CWM_RCYCLEGROUP 0x0002
> +#define CWM_CYCLEGROUP 0x
> +#define CWM_RCYCLEGROUP 0x0001
>
> #define KBTOGROUP(X) ((X) - 1)
oops; heh, and client cycle uses CWM_{R,}CYCLE..
this should make it less ambiguous...
Index: calmwm.h
===
RCS file: /home/okan/hack/open/cvs/xenocara/app/cwm/calmwm.h,v
retrieving revision 1.125
diff -u -p -r1.125 calmwm.h
--- calmwm.h11 May 2011 13:53:51 - 1.125
+++ calmwm.h15 May 2011 17:17:23 -
@@ -68,12 +68,12 @@
#defineCWM_EXEC_WM 0x0002
/* client cycle */
-#define CWM_CYCLE 0x0001
-#define CWM_RCYCLE 0x0002
+#define CWM_CYCLE 0
+#define CWM_RCYCLE 1
/* group cycle */
-#define CWM_CYCLEGROUP 0x0001
-#define CWM_RCYCLEGROUP0x0002
+#define CWM_CYCLEGROUP 0
+#define CWM_RCYCLEGROUP1
#define KBTOGROUP(X) ((X) - 1)
malloc: rework MALLOC_MAXSHIFT
Hi,
define MALLOC_MAXSHIFT and related stuff more consistently. Also, zap
region_bits, it is not used.
Comments, ok?
-Otto
Index: malloc.c
===
RCS file: /cvs/src/lib/libc/stdlib/malloc.c,v
retrieving revision 1.134
diff -u -p -r1.134 malloc.c
--- malloc.c12 May 2011 12:03:40 - 1.134
+++ malloc.c15 May 2011 16:37:39 -
@@ -49,9 +49,6 @@
#include "thread_private.h"
-#define MALLOC_MINSHIFT4
-#define MALLOC_MAXSHIFT16
-
#if defined(__sparc__) && !defined(__sparcv9__)
#define MALLOC_PAGESHIFT (13U)
#elif defined(__mips64__)
@@ -60,12 +57,14 @@
#define MALLOC_PAGESHIFT (PGSHIFT)
#endif
+#define MALLOC_MINSHIFT4
+#define MALLOC_MAXSHIFT(MALLOC_PAGESHIFT - 1)
#define MALLOC_PAGESIZE(1UL << MALLOC_PAGESHIFT)
#define MALLOC_MINSIZE (1UL << MALLOC_MINSHIFT)
#define MALLOC_PAGEMASK(MALLOC_PAGESIZE - 1)
#define MASK_POINTER(p)((void *)(((uintptr_t)(p)) &
~MALLOC_PAGEMASK))
-#define MALLOC_MAXCHUNK(1 << (MALLOC_PAGESHIFT-1))
+#define MALLOC_MAXCHUNK(1 << MALLOC_MAXSHIFT)
#define MALLOC_MAXCACHE256
#define MALLOC_DELAYED_CHUNKS 15 /* max of getrnibble() */
/*
@@ -106,12 +105,11 @@ struct dir_info {
u_int32_t canary1;
struct region_info *r; /* region slots */
size_t regions_total; /* number of region slots */
- size_t regions_bits;/* log2 of total */
size_t regions_free;/* number of free slots */
/* list of free chunk info structs */
struct chunk_head chunk_info_list;
/* lists of chunks with free slots */
- struct chunk_head chunk_dir[MALLOC_MAXSHIFT];
+ struct chunk_head chunk_dir[MALLOC_MAXSHIFT + 1];
size_t free_regions_size; /* free pages cached */
/* free pages cache */
struct region_info free_regions[MALLOC_MAXCACHE];
@@ -605,8 +603,7 @@ omalloc_init(struct dir_info **dp)
d = (struct dir_info *)(p + MALLOC_PAGESIZE +
(arc4random_uniform(d_avail) << MALLOC_MINSHIFT));
- d->regions_bits = 9;
- d->regions_free = d->regions_total = 1 << d->regions_bits;
+ d->regions_free = d->regions_total = 512;
regioninfo_size = d->regions_total * sizeof(struct region_info);
d->r = MMAP(regioninfo_size);
if (d->r == MAP_FAILED) {
@@ -615,7 +612,7 @@ omalloc_init(struct dir_info **dp)
return 1;
}
LIST_INIT(&d->chunk_info_list);
- for (i = 0; i < MALLOC_MAXSHIFT; i++)
+ for (i = 0; i <= MALLOC_MAXSHIFT; i++)
LIST_INIT(&d->chunk_dir[i]);
malloc_used += regioninfo_size;
d->canary1 = mopts.malloc_canary ^ (u_int32_t)(uintptr_t)d;
@@ -636,7 +633,6 @@ omalloc_init(struct dir_info **dp)
static int
omalloc_grow(struct dir_info *d)
{
- size_t newbits;
size_t newtotal;
size_t newsize;
size_t mask;
@@ -646,7 +642,6 @@ omalloc_grow(struct dir_info *d)
if (d->regions_total > SIZE_MAX / sizeof(struct region_info) / 2 )
return 1;
- newbits = d->regions_bits + 1;
newtotal = d->regions_total * 2;
newsize = newtotal * sizeof(struct region_info);
mask = newtotal - 1;
@@ -678,7 +673,6 @@ omalloc_grow(struct dir_info *d)
malloc_used -= d->regions_total * sizeof(struct region_info);
d->regions_free = d->regions_free + d->regions_total;
d->regions_total = newtotal;
- d->regions_bits = newbits;
d->r = p;
return 0;
}
@@ -1530,7 +1524,7 @@ dump_free_chunk_info(int fd, struct dir_
snprintf(buf, sizeof(buf), "Free chunk structs:\n");
write(fd, buf, strlen(buf));
- for (i = 0; i < MALLOC_MAXSHIFT; i++) {
+ for (i = 0; i <= MALLOC_MAXSHIFT; i++) {
struct chunk_info *p = LIST_FIRST(&d->chunk_dir[i]);
if (p != NULL) {
snprintf(buf, sizeof(buf), "%2d) ", i);
cwm: repair cyclegroup and rcyclegroup
A tiny oops done by someone cleaning up calmwm.h making cyclegroup and rcyclegroup behave the same. The defines below are used as an argument to group_cycle as a boolean to decide if the groups should be cycled forward or backward, but now both values are true so it's always done in reverse. Index: calmwm.h === RCS file: /cvs/xenocara/app/cwm/calmwm.h,v retrieving revision 1.125 diff -u -p -r1.125 calmwm.h --- calmwm.h11 May 2011 13:53:51 - 1.125 +++ calmwm.h15 May 2011 16:26:23 - @@ -72,8 +72,8 @@ #define CWM_RCYCLE 0x0002 /* group cycle */ -#define CWM_CYCLEGROUP 0x0001 -#define CWM_RCYCLEGROUP0x0002 +#define CWM_CYCLEGROUP 0x +#define CWM_RCYCLEGROUP0x0001 #define KBTOGROUP(X) ((X) - 1)
cwm(1): fix windows sometimes ending up beyond the screen after XRandR change
I switch Xinerama screens on and off quite often (with the help of
xrandr(1)). Sometimes, this results in windows ending up beyond the
screen boundries.
Like when a Xinerama screen has windows and is to the right or to the
bottom from another Xinerama screen and you turn it off.
Correct me if I'm wrong, but there's no way to bring such windows
back to the screen.
Even the "kill-the-app-and-start-it-again" approach doesn't always work
(let alone it being inconvenient...) -- some apps remember their
position and start up at that same location the next time (Sylpheed,
Pidgin, epdfview...).
This is how I solved it for myself: when an XRandR event comes, go thru
the list of all client windows and move those which are beyond the
screen boundries to (0,0) (or (gap_x, gap_y) if you configured them).
This also works when rotation is applied to the screen, it can
cause a window to fall off of the screen too.
Index: calmwm.h
===
RCS file: /cvs/xenocara/app/cwm/calmwm.h,v
retrieving revision 1.125
diff -u -p -r1.125 calmwm.h
--- calmwm.h11 May 2011 13:53:51 - 1.125
+++ calmwm.h15 May 2011 13:02:31 -
@@ -365,6 +365,9 @@ struct screen_ctx *screen_fromroot(Windo
voidscreen_init_xinerama(struct screen_ctx *);
voidscreen_update_geometry(struct screen_ctx *, int, int);
voidscreen_updatestackingorder(struct screen_ctx *);
+int screen_is_client_beyond(struct screen_ctx *,
+struct client_ctx *);
+voidscreen_assert_clients_within(struct screen_ctx *);
voidkbfunc_client_cycle(struct client_ctx *, union arg *);
voidkbfunc_client_cyclegroup(struct client_ctx *,
Index: screen.c
===
RCS file: /cvs/xenocara/app/cwm/screen.c,v
retrieving revision 1.28
diff -u -p -r1.28 screen.c
--- screen.c11 May 2011 13:53:51 - 1.28
+++ screen.c15 May 2011 13:02:31 -
@@ -131,3 +131,55 @@ screen_update_geometry(struct screen_ctx
XA_CARDINAL, 32, PropModeReplace,
(unsigned char *)workareas, CALMWM_NGROUPS * 4);
}
+
+/*
+ * Return non-zero if client is beyond the screen.
+ */
+int
+screen_is_client_beyond(struct screen_ctx *sc, struct client_ctx *cc)
+{
+ int bw, top, left, right, bottom;
+
+ bw = cc->bwidth * 2;
+ top = cc->geom.y;
+ left = cc->geom.x;
+ right = cc->geom.x + cc->geom.width + bw - 1;
+ bottom = cc->geom.y + cc->geom.height + bw - 1;
+
+ if (HasXinerama) {
+ if (screen_find_xinerama(sc, left, top))
+ return 0;
+ if (screen_find_xinerama(sc, left, bottom))
+ return 0;
+ if (screen_find_xinerama(sc, right, top))
+ return 0;
+ if (screen_find_xinerama(sc, right, bottom))
+ return 0;
+ return 1;
+ } else {
+ if (top > sc->ymax || left > sc->xmax)
+ return 1;
+ if (bottom < 0 || right < 0)
+ return 1;
+ return 0;
+ }
+}
+
+/*
+ * Bring clients which are beyond the screen back.
+ */
+void
+screen_assert_clients_within(struct screen_ctx *sc)
+{
+ struct client_ctx *cc;
+
+ TAILQ_FOREACH(cc, &Clientq, entry) {
+ if (cc->sc != sc)
+ continue;
+ if (screen_is_client_beyond(sc, cc)) {
+ cc->geom.x = sc->gap.left;
+ cc->geom.y = sc->gap.top;
+ client_move(cc);
+ }
+ }
+}
Index: xevents.c
===
RCS file: /cvs/xenocara/app/cwm/xevents.c,v
retrieving revision 1.53
diff -u -p -r1.53 xevents.c
--- xevents.c 11 May 2011 13:53:51 - 1.53
+++ xevents.c 15 May 2011 13:02:31 -
@@ -377,6 +377,7 @@ xev_handle_randr(XEvent *ee)
XRRUpdateConfiguration(ee);
screen_update_geometry(sc, rev->width, rev->height);
screen_init_xinerama(sc);
+ screen_assert_clients_within(sc);
}
}
}
Re: [smtpd] diff that needs testing
Hi tech@, An updated version of the diff fixes a crash that would occur in some setups mixing aliases, virtual entries and relaying to external mails http://users.poolp.org/~gilles/smtpd.diff Got only positive feedbacks so far, if I don't experience other crash by tomorrow, I'll commit it and move to next task. -- Gilles Chehade http://www.poolp.org
Re: macppc: support for Dynamic Frequency Switching
On Sun, May 15, 2011 at 03:56:16PM +0530, Martin Pieuchot wrote:
> On 04/05/11(Wed) 20:29, Miod Vallat wrote:
> > > > Speaking of DELAY()... it is implemented using the processor internal
> > > > counter register. Is this register impacted by frequency changes? If so,
> > > > shouldn't you update the computed ns_per_tick delay() constant?
> > >
> > > Reading the doc again, it's said that the time base register is clocked
> > > at one-fourth of the bus clock. But the DFS feature divides the processor
> > > to system bus ratio. So, if I understand well there is no impact on the
> > > time base counter frequency.
> >
> > Good. This is easy to check, does ntpd start complaining after running a
> > few minutes at `setperf=0' speed?
> >
> > > Index: sys/arch/macppc/dev/dfs.c
> >
> > > +#include
> > > +#include
> >
> > Could you use instead of here? This is the
> > preferred (yet objectionable) form of satisfying
> > dependencies.
> >
> > > +struct cfattach dfs_ca = {
> > > + sizeof(struct device), dfs_match, dfs_attach
> >
> > This needs to be sizeof(struct dfs_softc) now. That is, unless you want
> > to get funny panics after dfs0 attaches.
>
> After some tests and discussions with the powermac owners it appears
> that there is no obvious way to enable dfs on these machines. So no dfs
> support for the mac mini.
>
> Updated diff, now looking for oks for the driver and the manpage.
>
> Martin
>
> Index: conf/GENERIC
> ===
> RCS file: /cvs/src/sys/arch/macppc/conf/GENERIC,v
> retrieving revision 1.207
> diff -u -p -r1.207 GENERIC
> --- conf/GENERIC 19 Apr 2011 23:07:54 - 1.207
> +++ conf/GENERIC 15 May 2011 09:25:14 -
> @@ -155,6 +155,7 @@ macgpio* at macobio? # GPIO, PMU interru
> macgpio* at macgpio? # GPIO, PMU interrupt router.
> sysbutton* at macgpio? # Xserve system id button.
> pgs* at macgpio? # Programmer Switch.
> +dfs* at macgpio? # Dynamic Frequence Switching.
> akbd*at adb? # ADB keyboard
> wskbd* at akbd? mux 1
> ams* at adb? # ADB mouse
> Index: conf/files.macppc
> ===
> RCS file: /cvs/src/sys/arch/macppc/conf/files.macppc,v
> retrieving revision 1.63
> diff -u -p -r1.63 files.macppc
> --- conf/files.macppc 6 Dec 2010 20:10:18 - 1.63
> +++ conf/files.macppc 15 May 2011 09:25:14 -
> @@ -237,6 +237,10 @@ device pgs {}
> attach pgs at macgpio
> file arch/macppc/dev/pgs.c
>
> +device dfs {}
> +attach dfs at macgpio
> +file arch/macppc/dev/dfs.c
> +
> attach wdc at mediabay, macobio, kauaiata with wdc_obio
> file arch/macppc/dev/wdc_obio.c wdc_obio
>
> Index: dev/dfs.c
> ===
> RCS file: dev/dfs.c
> diff -N dev/dfs.c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ dev/dfs.c 15 May 2011 09:25:14 -
> @@ -0,0 +1,167 @@
> +/* $OpenBSD$ */
> +/*
> + * Copyright (c) 2011 Martin Pieuchot
> + *
> + * Permission to use, copy, modify, and distribute this software for any
> + * purpose with or without fee is hereby granted, provided that the above
> + * copyright notice and this permission notice appear in all copies.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#define DFS2 (1 << 22) /* Divide-by-Two */
> +#define DFS4 (1 << 23) /* Divide-by-Four (MPC7448 Specific) */
> +
> +extern int perflevel;
> +
> +struct dfs_softc {
> + struct device sc_dev;
> + int sc_voltage;
> +};
> +
> +int dfs_match(struct device *, void *, void *);
> +void dfs_attach(struct device *, struct device *, void *);
> +void dfs_setperf(int);
> +void dfs_scale_frequency(u_int);
> +
> +struct cfattach dfs_ca = {
> + sizeof(struct dfs_softc), dfs_match, dfs_attach
> +};
> +
> +struct cfdriver dfs_cd = {
> + NULL, "dfs", DV_DULL
> +};
> +
> +int
> +dfs_match(struct device *parent, void *arg, void *aux)
> +{
> + struct confargs *ca = aux;
> + uint16_t cpu;
> +
> + if (strcmp(ca->ca_name, "cpu-vcore-select") != 0)
> + return (0);
> +
> + cpu = ppc_mfpvr() >> 16;
> + if (cpu == PPC_CPU_MPC7447A || cpu == PPC_CPU_MPC7448)
> + return (1);
> +
> + retu
Re: A step towards support for Message Signaled Interrupts
> Date: Sun, 15 May 2011 07:31:46 +0200 > From: LEVAI Daniel > > > This diff completes the implementation of PCI "flags", making sure > [...] > > Hi! > > Forgive my ignorance, but is PR 6523 related to this? Should I try this > with that machine? > > (http://marc.info/?l=openbsd-misc&m=126840264605078&w=2) No
Re: [smtpd] diff that needs testing
On Sun, May 15, 2011 at 02:09:41PM +0200, Christopher Zimmermann wrote: > On 05/15/11 11:57, Gilles Chehade wrote: > >Please test and report breakage of your existing setups :-) > > No breakage for me. I use smtpd as MTA for local-to-local delivery and > to relay mail to my ISP using tls. > great :-)
Re: [smtpd] diff that needs testing
On 05/15/11 11:57, Gilles Chehade wrote:
Please test and report breakage of your existing setups :-)
No breakage for me. I use smtpd as MTA for local-to-local delivery and
to relay mail to my ISP using tls.
# $OpenBSD: smtpd.conf,v 1.2 2009/11/03 22:32:10 gilles Exp $
# This is the smtpd server system-wide configuration file.
# See smtpd.conf(5) for more information.
listen on lo0
listen on lo0 port 587
map "aliases" { source db "/etc/mail/aliases.db" }
map "secrets" { source db "/etc/mail/secrets.db" }
accept for local alias aliases deliver to mbox
accept for all relay via smtp.1und1.de port 587 tls auth "secrets"
Re: mmuagp driver
Many thanks to oga@ for this. I have been using this patch for at least a month now and not had any issues. Relevant bits of dmesg: pchb0 at pci0 dev 0 function 0 "NVIDIA nForce3 250 PCI Host" rev 0xa1 mmuagp0 at pchb0: 1 Miscellaneous Control unit(s) found agp0 at mmuagp0: aperture at 0xf000, size 0x200 I also swapped out the Nvidia GeForce 7800 card and put in an ATI/Sapphire X1950 Pro (all AGP) and 3D worked, even though it was a little choppy, but oga@ said that was more down to the version of the intel driver in Xenocara than anything else. Tom
Re: macppc: support for Dynamic Frequency Switching
On 04/05/11(Wed) 20:29, Miod Vallat wrote:
> > > Speaking of DELAY()... it is implemented using the processor internal
> > > counter register. Is this register impacted by frequency changes? If so,
> > > shouldn't you update the computed ns_per_tick delay() constant?
> >
> > Reading the doc again, it's said that the time base register is clocked
> > at one-fourth of the bus clock. But the DFS feature divides the processor
> > to system bus ratio. So, if I understand well there is no impact on the
> > time base counter frequency.
>
> Good. This is easy to check, does ntpd start complaining after running a
> few minutes at `setperf=0' speed?
>
> > Index: sys/arch/macppc/dev/dfs.c
>
> > +#include
> > +#include
>
> Could you use instead of here? This is the
> preferred (yet objectionable) form of satisfying
> dependencies.
>
> > +struct cfattach dfs_ca = {
> > + sizeof(struct device), dfs_match, dfs_attach
>
> This needs to be sizeof(struct dfs_softc) now. That is, unless you want
> to get funny panics after dfs0 attaches.
After some tests and discussions with the powermac owners it appears
that there is no obvious way to enable dfs on these machines. So no dfs
support for the mac mini.
Updated diff, now looking for oks for the driver and the manpage.
Martin
Index: conf/GENERIC
===
RCS file: /cvs/src/sys/arch/macppc/conf/GENERIC,v
retrieving revision 1.207
diff -u -p -r1.207 GENERIC
--- conf/GENERIC19 Apr 2011 23:07:54 - 1.207
+++ conf/GENERIC15 May 2011 09:25:14 -
@@ -155,6 +155,7 @@ macgpio*at macobio? # GPIO, PMU interru
macgpio* at macgpio? # GPIO, PMU interrupt router.
sysbutton* at macgpio? # Xserve system id button.
pgs* at macgpio? # Programmer Switch.
+dfs* at macgpio? # Dynamic Frequence Switching.
akbd* at adb? # ADB keyboard
wskbd* at akbd? mux 1
ams* at adb? # ADB mouse
Index: conf/files.macppc
===
RCS file: /cvs/src/sys/arch/macppc/conf/files.macppc,v
retrieving revision 1.63
diff -u -p -r1.63 files.macppc
--- conf/files.macppc 6 Dec 2010 20:10:18 - 1.63
+++ conf/files.macppc 15 May 2011 09:25:14 -
@@ -237,6 +237,10 @@ device pgs {}
attach pgs at macgpio
file arch/macppc/dev/pgs.c
+device dfs {}
+attach dfs at macgpio
+file arch/macppc/dev/dfs.c
+
attach wdc at mediabay, macobio, kauaiata with wdc_obio
file arch/macppc/dev/wdc_obio.c wdc_obio
Index: dev/dfs.c
===
RCS file: dev/dfs.c
diff -N dev/dfs.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ dev/dfs.c 15 May 2011 09:25:14 -
@@ -0,0 +1,167 @@
+/* $OpenBSD$ */
+/*
+ * Copyright (c) 2011 Martin Pieuchot
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+
+#define DFS2 (1 << 22) /* Divide-by-Two */
+#define DFS4 (1 << 23) /* Divide-by-Four (MPC7448 Specific) */
+
+extern int perflevel;
+
+struct dfs_softc {
+ struct device sc_dev;
+ int sc_voltage;
+};
+
+intdfs_match(struct device *, void *, void *);
+void dfs_attach(struct device *, struct device *, void *);
+void dfs_setperf(int);
+void dfs_scale_frequency(u_int);
+
+struct cfattach dfs_ca = {
+ sizeof(struct dfs_softc), dfs_match, dfs_attach
+};
+
+struct cfdriver dfs_cd = {
+ NULL, "dfs", DV_DULL
+};
+
+int
+dfs_match(struct device *parent, void *arg, void *aux)
+{
+ struct confargs *ca = aux;
+ uint16_t cpu;
+
+ if (strcmp(ca->ca_name, "cpu-vcore-select") != 0)
+ return (0);
+
+ cpu = ppc_mfpvr() >> 16;
+ if (cpu == PPC_CPU_MPC7447A || cpu == PPC_CPU_MPC7448)
+ return (1);
+
+ return (0);
+}
+
+void
+dfs_attach(struct device *parent, struct device *self, void *aux)
+{
+ struct dfs_softc *sc = (struct dfs_softc *)self;
+ struct confargs *ca = aux;
+ uint32_t hid1, reg;
+ uint16_t cpu;
+
+ /*
+* On some models the vcore-select offset is relative to
Re: [smtpd] diff that needs testing
On Sun, May 15, 2011 at 11:57:13AM +0200, Gilles Chehade wrote: > Hi tech@, > > summary: > > This huge diff is unsplittable. it gets rid of a structure that has > grown out of control, that's used everywhere and that prevents some > long-awaited features from being implemented. it needs more work to > be finished but shouldn't introduce to much of a regression as is. > It fixes *some* of aliases shortcomings but is a preliminary to a > working aliases support. > > Please test and report breakage of your existing setups :-) > It goes without saying that this is *experimental* I did some testing but I can't guarantee it won't break your setup. You shouldn't be running smtpd in prod anyway :-) Gilles
Re: ssh, consistent use of fcntl(2) with F_SETFD
applied - thanks
On Sat, 14 May 2011, Aaron Stellman wrote:
> Please review the diff.
> Thanks
>
> Index: usr.bin/ssh/authfd.c
> ===
> RCS file: /cvs/src/usr.bin/ssh/authfd.c,v
> retrieving revision 1.84
> diff -p -u -r1.84 authfd.c
> --- usr.bin/ssh/authfd.c 31 Aug 2010 11:54:45 - 1.84
> +++ usr.bin/ssh/authfd.c 14 May 2011 17:57:48 -
> @@ -108,7 +108,7 @@ ssh_get_authentication_socket(void)
> return -1;
>
> /* close on exec */
> - if (fcntl(sock, F_SETFD, 1) == -1) {
> + if (fcntl(sock, F_SETFD, FD_CLOEXEC) == -1) {
> close(sock);
> return -1;
> }
> Index: usr.bin/ssh/monitor.c
> ===
> RCS file: /cvs/src/usr.bin/ssh/monitor.c,v
> retrieving revision 1.110
> diff -p -u -r1.110 monitor.c
> --- usr.bin/ssh/monitor.c 9 Sep 2010 10:45:45 - 1.110
> +++ usr.bin/ssh/monitor.c 14 May 2011 17:57:48 -
> @@ -1513,7 +1513,7 @@ mm_init_compression(struct mm_master *mm
> /* XXX */
>
> #define FD_CLOSEONEXEC(x) do { \
> - if (fcntl(x, F_SETFD, 1) == -1) \
> + if (fcntl(x, F_SETFD, FD_CLOEXEC) == -1) \
> fatal("fcntl(%d, F_SETFD)", x); \
> } while (0)
>
> Index: usr.bin/ssh/serverloop.c
> ===
> RCS file: /cvs/src/usr.bin/ssh/serverloop.c,v
> retrieving revision 1.159
> diff -p -u -r1.159 serverloop.c
> --- usr.bin/ssh/serverloop.c 28 May 2009 16:50:16 - 1.159
> +++ usr.bin/ssh/serverloop.c 14 May 2011 17:57:48 -
> @@ -127,8 +127,8 @@ notify_setup(void)
> {
> if (pipe(notify_pipe) < 0) {
> error("pipe(notify_pipe) failed %s", strerror(errno));
> - } else if ((fcntl(notify_pipe[0], F_SETFD, 1) == -1) ||
> - (fcntl(notify_pipe[1], F_SETFD, 1) == -1)) {
> + } else if ((fcntl(notify_pipe[0], F_SETFD, FD_CLOEXEC) == -1) ||
> + (fcntl(notify_pipe[1], F_SETFD, FD_CLOEXEC) == -1)) {
> error("fcntl(notify_pipe, F_SETFD) failed %s", strerror(errno));
> close(notify_pipe[0]);
> close(notify_pipe[1]);
Subscription Confirmation
Hello Thank you for subscribing. Please confirm your subscription by clicking once on the link below or copying and pasting it into your browser. http://www.10millibrosparadescargar.com/cgi-bin/arp3/arp3-confirm.pl?p=1305413914.452754 Thank you.
