Roland Dreier | 1 Dec 01:06 2009

Re: [PATCH] Fix interrupt handling in ral(4) for RT2661 under load

 > Does it do anything for 2860? I have that as an AP now and every once in
 > a while it stops working, I need to restart the interface.

No, the driver code is a completely different C file.  It's possible
there are analogous bugs for 2860 though, since the hardware and
driver are both closely related to 2661.

 - R.

Holger Mikolon | 1 Dec 23:57 2009

crunchgen diff

Below is a crunchgen diff, which enables a new keyword "proglibs".
This basically allows to specify per-program libraries for the linker.

With that change it is possible to make for example a crunched binary
with ssh, sshd and ssh-keygen ... something I couldn't manage to do
with the default crunchgen tool in base.

Here is an example:

# cat ./ssh.cbin.conf
libs -lgssapi -lkrb5 -lkafs -lcrypto -lutil -lz -ldes
progs ssh sshd ssh-keygen
special ssh srcdir /usr/src/usr.bin/ssh/ssh
special ssh proglibs /usr/src/usr.bin/ssh/lib/obj/libssh.a
special sshd srcdir /usr/src/usr.bin/ssh/sshd
special sshd proglibs /usr/src/usr.bin/ssh/lib/obj/libssh.a /usr/lib/libwrap.a
special ssh-keygen srcdir /usr/src/usr.bin/ssh/ssh-keygen
special ssh-keygen proglibs /usr/src/usr.bin/ssh/lib/obj/libssh.a

Here is the diff:

Index: usr.sbin/crunchgen/crunchgen.8
===================================================================
RCS file: /cvs/src/usr.sbin/crunchgen/crunchgen.8,v
retrieving revision 1.4
diff -u usr.sbin/crunchgen/crunchgen.8
--- usr.sbin/crunchgen/crunchgen.8	24 Nov 2008 18:03:22 -0000	1.4
+++ usr.sbin/crunchgen/crunchgen.8	1 Dec 2009 22:52:54 -0000
 <at>  <at>  -237,6 +237,10  <at>  <at> 
  .Ar progname .
(Continue reading)

Brad | 2 Dec 01:10 2009

bge(4) diff to correct input error counter handling

Do not count input errors twice. We always read input errors from
the MAC in bge_tick(). Previously this would result in bge(4) claiming
a greater number of input errors than what has actually occured.

From FreeBSD

Index: if_bge.c
===================================================================
RCS file: /cvs/src/sys/dev/pci/if_bge.c,v
retrieving revision 1.286
diff -u -p -r1.286 if_bge.c
--- if_bge.c	11 Oct 2009 16:53:13 -0000	1.286
+++ if_bge.c	11 Nov 2009 22:38:13 -0000
 <at>  <at>  -2521,7 +2527,6  <at>  <at>  bge_rxeof(struct bge_softc *sc)

 			if (cur_rx->bge_flags & BGE_RXBDFLAG_ERROR) {
 				m_freem(m);
-				ifp->if_ierrors++;
 				continue;
 			}
 		} else {
 <at>  <at>  -2538,7 +2543,6  <at>  <at>  bge_rxeof(struct bge_softc *sc)

 			if (cur_rx->bge_flags & BGE_RXBDFLAG_ERROR) {
 				m_freem(m);
-				ifp->if_ierrors++;
 				continue;
 			}
 		}

(Continue reading)

Otto Moerbeek | 2 Dec 10:38 2009
Picon

save some entropy

Hi,

apart from the random page addresses obtained form mmap(2) malloc(3)
itself also randomizes cache en chunk operations. It uses a nibble of
randomness per call, so optimize that to not waste half the random
bits. 

Please test, should be a bit faster.

	-Otto
	
Index: malloc.c
===================================================================
RCS file: /cvs/src/lib/libc/stdlib/malloc.c,v
retrieving revision 1.121
diff -u -p -r1.121 malloc.c
--- malloc.c	27 Nov 2009 20:11:01 -0000	1.121
+++ malloc.c	30 Nov 2009 19:40:47 -0000
 <at>  <at>  -64,7 +64,7  <at>  <at> 

 #define MALLOC_MAXCHUNK		(1 << (MALLOC_PAGESHIFT-1))
 #define MALLOC_MAXCACHE		256
-#define MALLOC_DELAYED_CHUNKS	16	/* should be power of 2 */
+#define MALLOC_DELAYED_CHUNKS	15	/* max of getrnibble() */
 /*
  * When the P option is active, we move allocations between half a page
  * and a whole page towards the end, subject to alignment constraints.
 <at>  <at>  -110,7 +110,7  <at>  <at>  struct dir_info {
 					/* free pages cache */
 	struct region_info free_regions[MALLOC_MAXCACHE];
(Continue reading)

Michael Shalayeff | 2 Dec 14:09 2009
Picon

Re: save some entropy

On Wed, Dec 02, 2009 at 10:38:10AM +0100, Otto Moerbeek wrote:
> Hi,
re

> apart from the random page addresses obtained form mmap(2) malloc(3)
> itself also randomizes cache en chunk operations. It uses a nibble of
> randomness per call, so optimize that to not waste half the random
> bits. 

arc4 random does not use entropy and is very cheap
almost the speed of memory copy. "caching" arc4 output
like this is the same as running rot13 twice (:

> Please test, should be a bit faster.
> 
> 	-Otto
> 	
> Index: malloc.c
> ===================================================================
> RCS file: /cvs/src/lib/libc/stdlib/malloc.c,v
> retrieving revision 1.121
> diff -u -p -r1.121 malloc.c
> --- malloc.c	27 Nov 2009 20:11:01 -0000	1.121
> +++ malloc.c	30 Nov 2009 19:40:47 -0000
>  <at>  <at>  -64,7 +64,7  <at>  <at> 
>  
>  #define MALLOC_MAXCHUNK		(1 << (MALLOC_PAGESHIFT-1))
>  #define MALLOC_MAXCACHE		256
> -#define MALLOC_DELAYED_CHUNKS	16	/* should be power of 2 */
> +#define MALLOC_DELAYED_CHUNKS	15	/* max of getrnibble() */
(Continue reading)

Otto Moerbeek | 2 Dec 14:25 2009
Picon

Re: save some entropy

On Wed, Dec 02, 2009 at 01:09:02PM +0000, Michael Shalayeff wrote:

> On Wed, Dec 02, 2009 at 10:38:10AM +0100, Otto Moerbeek wrote:
> > Hi,
> re
> 
> > apart from the random page addresses obtained form mmap(2) malloc(3)
> > itself also randomizes cache en chunk operations. It uses a nibble of
> > randomness per call, so optimize that to not waste half the random
> > bits. 
> 
> arc4 random does not use entropy and is very cheap
> almost the speed of memory copy. "caching" arc4 output
> like this is the same as running rot13 twice (:

at least it saves on calls to arc4_stir() and thus on sysctl(2) and
getpid(2) calls.

	-Otto

> 
> > Please test, should be a bit faster.
> > 
> > 	-Otto
> > 	
> > Index: malloc.c
> > ===================================================================
> > RCS file: /cvs/src/lib/libc/stdlib/malloc.c,v
> > retrieving revision 1.121
> > diff -u -p -r1.121 malloc.c
(Continue reading)

Otto Moerbeek | 2 Dec 14:44 2009
Picon

Re: save some entropy

On Wed, Dec 02, 2009 at 02:25:57PM +0100, Otto Moerbeek wrote:

> On Wed, Dec 02, 2009 at 01:09:02PM +0000, Michael Shalayeff wrote:
> 
> > On Wed, Dec 02, 2009 at 10:38:10AM +0100, Otto Moerbeek wrote:
> > > Hi,
> > re
> > 
> > > apart from the random page addresses obtained form mmap(2) malloc(3)
> > > itself also randomizes cache en chunk operations. It uses a nibble of
> > > randomness per call, so optimize that to not waste half the random
> > > bits. 
> > 
> > arc4 random does not use entropy and is very cheap
> > almost the speed of memory copy. "caching" arc4 output
> > like this is the same as running rot13 twice (:
> 
> at least it saves on calls to arc4_stir() and thus on sysctl(2) and
> getpid(2) calls.

I was a bit puzzled by mickeys comment, remenbering that the kernel
arc4 does use entropy, and indeed rc4random_buf() in the kernel which
provides the random data for stirring the userland arc4random(3) calls
arc4maybeinit() which potentially consumes entropy via arc4_stir() and
get_random_bytes(). The the trigger to stir in the kernel is timer
based, not consumption based. 

	-Otto

(Continue reading)

Henning Brauer | 2 Dec 15:21 2009
Picon

[henning <at> openbsd.org: unbreak sticky-address]

this needs testing by people using sticky-address. if we don't get
this in sticky-address will be broken in 4.7.

----- Forwarded message from Henning Brauer <henning <at> openbsd.org> -----

Date: Thu, 26 Nov 2009 00:10:15 +0100
From: Henning Brauer <henning <at> openbsd.org>
Subject: unbreak sticky-address
X-PGP-Key: 3A83DF32
User-Agent: Mutt/1.5.20 (2009-06-14)

so. sticky-adress is broken beyond relief. thsi basically reimplements
it... kinda. we need one source tracking node (src node) per state for
each of:
-limit # of states per src addr (this can be global or per rule)
-nat with sticky-addr (always per rule)
-rdr with sticky-addr (always per rule)

match CONSIDERABLY complicates things here. since we do the address
selection on the fly while traversing the ruleset and the rule is part
of the key in the src nodes RB tree... you get the idea. we dunno the
last matching one yet. good news: we don't really need to.

to not grow the states much (actually, not at all) i chose to hang the
src nodes off the stack in an SLIST. typically one entry, max of 4.

# pfctl -sr
match out on em1 inet all nat-to { 172.16.8.8, 172.16.8.9, 172.16.8.10
} round-robin sticky-address
pass all flags S/SA keep state
(Continue reading)

David Coppa | 2 Dec 16:22 2009
Picon

Sierra Wireless AirCard 881 does not attach correctly

Hi,

I've a problem with a Sierra Wireless AirCard 881 (PCMCIA) on my ThinkPad X41.
It correctly attaches as umsm0, but then only the first port (ucom0) is 
configured and this port is not "AT-capable". The card has instead four serial 
ports and the third (ucom2) is the one that accepts AT commands.

Since this card works ok under both winxp and linux, I think I can exclude 
hardware related problems.

This is an extract from dmesg:

ohci0 at cardbus0 dev 0 function 0 "NEC USB" rev 0x43: irq 11, version 1.0
usb5 at ohci0: USB revision 1.0
uhub5 at usb5 "NEC OHCI root hub" rev 1.00/1.00 addr 1
ohci1 at cardbus0 dev 0 function 1 "NEC USB" rev 0x43: irq 11, version 1.0
usb6 at ohci1: USB revision 1.0
uhub6 at usb6 "NEC OHCI root hub" rev 1.00/1.00 addr 1
umsm0 at uhub5 port 1 configuration 1 interface 0 "Sierra Wireless, Incorporated AirCard" rev 1.10/0.02
addr 2
ucom0 at umsm0

And output from "usbdevs -dv":

Controller /dev/usb0:
addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), Intel(0x8086), rev 1.00
 port 1 powered
 port 2 powered
 port 3 addr 2: high speed, self powered, config 1, External HDD(0x0701), Western Digital(0x1058), rev
2.40, iSerialNumber DEF10C20641E
(Continue reading)

David Coppa | 2 Dec 16:40 2009
Picon

Re: Sierra Wireless AirCard 881 does not attach correctly

I forgot to say that I'm running the latest current (snapshot dated 11/30/2009)

OpenBSD 4.6-current (GENERIC) #442: Sun Nov 29 23:02:05 MST 2009
    deraadt <at> i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Pentium(R) M processor 1.60GHz ("GenuineIntel" 686-class) 1.60 GHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,SBF,EST,TM2
real mem  = 2137485312 (2038MB)
avail mem = 2062401536 (1966MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 12/14/06, BIOS32 rev. 0  <at>  0xfd750, SMBIOS rev. 2.33  <at>  0xe0010 (59 entries)
bios0: vendor IBM version "74ET64WW (2.09 )" date 12/14/2006
bios0: IBM 2525E2G
apm0 at bios0: Power Management spec V1.2
apm0: battery life expectancy 100%
apm0: AC on, battery charge high
acpi at bios0 function 0x0 not configured
pcibios0 at bios0: rev 2.1  <at>  0xfd6e0/0x920
pcibios0: PCI IRQ Routing Table rev 1.0  <at>  0xfdec0/240 (13 entries)
pcibios0: PCI Interrupt Router at 000:31:0 ("Intel 82371FB ISA" rev 0x00)
pcibios0: PCI bus #5 is the last bus
bios0: ROM list: 0xc0000/0xf600! 0xcf800/0x1600 0xd1000/0x1000 0xdc000/0x4000! 0xe0000/0x10000
cpu0 at mainbus0: (uniprocessor)
cpu0: Enhanced SpeedStep 1597 MHz: speeds: 1600, 1500, 1400, 1300, 1200, 1100, 1000, 900, 800, 600 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
mem address conflict 0x7f700000/0x80000
io address conflict 0x5800/0x8
io address conflict 0x5808/0x4
io address conflict 0x5810/0x8
io address conflict 0x580c/0x4
pchb0 at pci0 dev 0 function 0 "Intel 82915GM Host" rev 0x03
(Continue reading)


Gmane