HG2F09 mystery USB-to-ethernet adapter fix

2013-03-03 Thread Chuck Guzis
Lately, a bunch of cheap Chinese USB-to-Ethernet dongles have been 
making their appearance in various parts of the world by a Chinese 
vendor.  Often these can be gotten for around USD$2 or less. They're 
frequently referred to as HG2f09 adapters.


The VID/PID is 066b/20f9, which would lead one to think that the maker 
is Linksys--except the PID doesn't appear in any Linksys registry.   So 
we've got a counterfeit.  (Why pay good money to IF-USB when you can 
just borrow a VID?  I've seen the same thing in cheap USB flash drives. )


A bit of probing shows the operative device is the Asix AX88772B (and 
has been verified by others).


The pragmatic approach would be to reprogram the serial configuration 
EEPROM in this thing to match something better known, say, the Linksys 
USB200, but Asix Taiwan is not forthcoming with their programming 
utility, citing confidential, restricted to verified customers.I'm 
not inclined to tear my hair out trying to write a utility for a $2 part 
(there are some pretty good hints in the Asix datasheet).


Mine arrived with a mini-CD containing Windows drivers (uncertified, of 
course) and Linux source (no good for OpenBSD).


At any rate, a stopgap solution for me was to simply add the following 
line to the 5.2 USB if_axe.c axe_devs[] structure:


{ { USB_VENDOR_LINKSYS, 0x20f9}, AX772 | AX772B},  // Fake Linksys 
HG20f9


It's an ugly hack, but it seems to work just fine.  I have a bit of a 
dilemma tagging the code as if this really were a Linksys-badged 
device.  I'll leave the symbolic definitions to those official 
custodians of OpenBSD source for a cleaner version, should the need for 
this arise.


You can see the extent of the problem, just by searching the web for 
HG2f09.


Perhaps there should be some sort of USB VID/PID aliasing capability 
to avoid having to rebuild the kernel for this sort of thing.


Submitted for whatever it's worth...

Cheers,
Chuck Guzis
Sydex, Inc.




jumbos for bnx(4) (again)

2013-03-03 Thread Andreas Bartelt

Hello,

last year, a patch regarding bnx(4) jumbos was provided and refined by 
dlg@, kettenis@ and brad@.


I've tested the diff for if_bnx.c against current and setting MTUs  
1500 works in principle.


However, with this diff enabled on current, there's quickly 
deteriorating packet loss regardless of packet size (i.e. when pinging a 
directly connected host) and the interface quickly becomes unusable.


Are these problems probably related to BCM5709 (I think Brad tested with 
BCM5708) or are there general problems with this patch?


# dmesg|grep -i bcm
bnx0 at pci7 dev 0 function 0 Broadcom BCM5709 rev 0x20: apic 0 int 6
bnx1 at pci7 dev 0 function 1 Broadcom BCM5709 rev 0x20: apic 0 int 13
bnx2 at pci8 dev 0 function 0 Broadcom BCM5709 rev 0x20: apic 0 int 7
bnx3 at pci8 dev 0 function 1 Broadcom BCM5709 rev 0x20: apic 0 int 15
brgphy0 at bnx0 phy 1: BCM5709 10/100/1000baseT PHY, rev. 8
brgphy1 at bnx1 phy 1: BCM5709 10/100/1000baseT PHY, rev. 8
brgphy2 at bnx2 phy 1: BCM5709 10/100/1000baseT PHY, rev. 8
brgphy3 at bnx3 phy 1: BCM5709 10/100/1000baseT PHY, rev. 8

Best Regards
Andreas
Index: sys/dev/pci/if_bnx.c
===
RCS file: /cvs/src/sys/dev/pci/if_bnx.c,v
retrieving revision 1.100
diff -u -r1.100 if_bnx.c
--- sys/dev/pci/if_bnx.c13 Jan 2013 05:45:10 -  1.100
+++ sys/dev/pci/if_bnx.c2 Mar 2013 10:06:46 -
@@ -848,6 +848,8 @@
sc-bnx_rx_ticks   = 18;
 #endif
 
+   sc-mbuf_alloc_size = BNX_MAX_JUMBO_MRU;
+
/* Update statistics once every second. */
sc-bnx_stats_ticks = 100  0x00;
 
@@ -878,9 +880,10 @@
ifp-if_ioctl = bnx_ioctl;
ifp-if_start = bnx_start;
ifp-if_watchdog = bnx_watchdog;
+   ifp-if_hardmtu = BNX_MAX_JUMBO_MTU;
IFQ_SET_MAXLEN(ifp-if_snd, USABLE_TX_BD - 1);
IFQ_SET_READY(ifp-if_snd);
-   m_clsetwms(ifp, MCLBYTES, 2, USABLE_RX_BD);
+   m_clsetwms(ifp, sc-mbuf_alloc_size, 2, USABLE_RX_BD);
bcopy(sc-eaddr, sc-arpcom.ac_enaddr, ETHER_ADDR_LEN);
bcopy(sc-bnx_dev.dv_xname, ifp-if_xname, IFNAMSIZ);
 
@@ -894,8 +897,6 @@
ifp-if_capabilities |= IFCAP_VLAN_HWTAGGING;
 #endif
 
-   sc-mbuf_alloc_size = BNX_MAX_MRU;
-
printf(%s: address %s\n, sc-bnx_dev.dv_xname,
ether_sprintf(sc-arpcom.ac_enaddr));
 
@@ -2664,8 +2665,8 @@
 * Create DMA maps for the Rx buffer mbufs.
 */
for (i = 0; i  TOTAL_RX_BD; i++) {
-   if (bus_dmamap_create(sc-bnx_dmatag, BNX_MAX_MRU,
-   BNX_MAX_SEGMENTS, BNX_MAX_MRU, 0, BUS_DMA_NOWAIT,
+   if (bus_dmamap_create(sc-bnx_dmatag, sc-mbuf_alloc_size,
+   1, sc-mbuf_alloc_size, 0, BUS_DMA_NOWAIT,
sc-rx_mbuf_map[i])) {
printf(: Could not create Rx mbuf %d DMA map!\n, i);
rc = ENOMEM;
@@ -3680,10 +3681,10 @@
*prod_bseq);
 
/* This is a new mbuf allocation. */
-   m = MCLGETI(NULL, M_DONTWAIT, sc-arpcom.ac_if, MCLBYTES);
+   m = MCLGETI(NULL, M_DONTWAIT, sc-arpcom.ac_if, sc-mbuf_alloc_size);
if (!m)
return (ENOBUFS);
-   m-m_len = m-m_pkthdr.len = MCLBYTES;
+   m-m_len = m-m_pkthdr.len = sc-mbuf_alloc_size;
/* the chip aligns the ip header for us, no need to m_adj */
 
/* Map the mbuf cluster into device memory. */
@@ -4013,6 +4014,16 @@
REG_WR(sc, BNX_MQ_MAP_L2_5, val | BNX_MQ_MAP_L2_5_ARM);
}
 
+   CTX_WR(sc, GET_CID_ADDR(RX_CID), BNX_L2CTX_RX_PG_BUF_SIZE, 0);
+
+   /* Configure the rx_bd and page chain mbuf cluster size. */
+   val = (sc-mbuf_alloc_size  16);
+   CTX_WR(sc, GET_CID_ADDR(RX_CID), BNX_L2CTX_RX_PG_BUF_SIZE, val);
+
+   /* Configure the context reserved for jumbo support. */
+   CTX_WR(sc, GET_CID_ADDR(RX_CID), BNX_L2CTX_RX_RBDC_KEY,
+   BNX_L2CTX_RX_RBDC_JUMBO_KEY);
+
/* Point the hardware to the first page in the chain. */
val = (u_int32_t)((u_int64_t)sc-rx_bd_chain_paddr[0]  32);
CTX_WR(sc, GET_CID_ADDR(RX_CID), BNX_L2CTX_NX_BDHADDR_HI, val);
@@ -4787,7 +4798,7 @@
bnx_set_mac_addr(sc);
 
/* Calculate and program the Ethernet MRU size. */
-   ether_mtu = BNX_MAX_STD_ETHER_MTU_VLAN;
+   ether_mtu = BNX_MAX_JUMBO_ETHER_MTU_VLAN;
 
DBPRINT(sc, BNX_INFO, %s(): setting MRU = %d\n,
__FUNCTION__, ether_mtu);


Re: HG2F09 mystery USB-to-ethernet adapter fix

2013-03-03 Thread Jonathan Gray
As it seems this doesn't clash with any other device
we should just be able to add it.

On Sun, Mar 03, 2013 at 12:25:11AM -0800, Chuck Guzis wrote:
 Lately, a bunch of cheap Chinese USB-to-Ethernet dongles have been
 making their appearance in various parts of the world by a Chinese
 vendor.  Often these can be gotten for around USD$2 or less. They're
 frequently referred to as HG2f09 adapters.
 
 The VID/PID is 066b/20f9, which would lead one to think that the
 maker is Linksys--except the PID doesn't appear in any Linksys
 registry.   So we've got a counterfeit.  (Why pay good money to
 IF-USB when you can just borrow a VID?  I've seen the same thing
 in cheap USB flash drives. )
 
 A bit of probing shows the operative device is the Asix AX88772B
 (and has been verified by others).
 
 The pragmatic approach would be to reprogram the serial
 configuration EEPROM in this thing to match something better known,
 say, the Linksys USB200, but Asix Taiwan is not forthcoming with
 their programming utility, citing confidential, restricted to
 verified customers.I'm not inclined to tear my hair out trying
 to write a utility for a $2 part (there are some pretty good hints
 in the Asix datasheet).
 
 Mine arrived with a mini-CD containing Windows drivers (uncertified,
 of course) and Linux source (no good for OpenBSD).
 
 At any rate, a stopgap solution for me was to simply add the
 following line to the 5.2 USB if_axe.c axe_devs[] structure:
 
 { { USB_VENDOR_LINKSYS, 0x20f9}, AX772 | AX772B},  // Fake
 Linksys HG20f9
 
 It's an ugly hack, but it seems to work just fine.  I have a bit of
 a dilemma tagging the code as if this really were a Linksys-badged
 device.  I'll leave the symbolic definitions to those official
 custodians of OpenBSD source for a cleaner version, should the need
 for this arise.
 
 You can see the extent of the problem, just by searching the web for
 HG2f09.
 
 Perhaps there should be some sort of USB VID/PID aliasing
 capability to avoid having to rebuild the kernel for this sort of
 thing.
 
 Submitted for whatever it's worth...
 
 Cheers,
 Chuck Guzis
 Sydex, Inc.
 



Re: HG2F09 mystery USB-to-ethernet adapter fix

2013-03-03 Thread Stuart Henderson
On 2013/03/03 00:25, Chuck Guzis wrote:
 The VID/PID is 066b/20f9, which would lead one to think that the
 maker is Linksys--except the PID doesn't appear in any Linksys
 registry.   So we've got a counterfeit.  (Why pay good money to
 IF-USB when you can just borrow a VID?  I've seen the same thing in
 cheap USB flash drives. )

There are a whole bunch of USB vendor IDs used in the wild which don't
show up in the IF-USB list. It seems more common to just make up a number
rather than borrow one though.

 At any rate, a stopgap solution for me was to simply add the
 following line to the 5.2 USB if_axe.c axe_devs[] structure:
 
 { { USB_VENDOR_LINKSYS, 0x20f9}, AX772 | AX772B},  // Fake
 Linksys HG20f9

I'd be fine with adding the ID but it should be done properly via usbdevs
and then use the symbolic name in if_axe.c.



Re: out of memory errors seen on several AnonCVS servers

2013-03-03 Thread Stuart Henderson
Summary of off-list mail exchange: anoncvs.usa consistently has a
realloc failure in xenocara/font/misc-misc/18x18ja.bdf, some other
servers have a failure the first time checking this file out when
it's part of the whole directory, but resuming or checking out
individually does work.

$ cvs -d anon...@anoncvs.spacehopper.org:/cvs get xenocara/font/misc-misc
U xenocara/font/misc-misc/10x20.bdf
U xenocara/font/misc-misc/12x13ja.bdf
cvs [server aborted]: out of memory; can not reallocate 3833880 bytes

$ cvs -d anon...@anoncvs.spacehopper.org:/cvs get xenocara/font/misc-misc
U xenocara/font/misc-misc/18x18ja.bdf
U xenocara/font/misc-misc/18x18ko.bdf.xaa
U xenocara/font/misc-misc/18x18ko.bdf.xab
snip

But against anoncvs.usa it always fails:

$ cvs -d anon...@anoncvs.usa.openbsd.org:/cvs get 
xenocara/font/misc-misc/18x18ja.bdf
cvs [server aborted]: out of memory; can not reallocate 5242880 bytes

This only happens with the network protocol (either via pserver
or 'cvs server' via ssh) not with local checkouts.

Forcing a coredump when realloc fails results in the backtrace below.

This file *can* be successfully checked out in a newer version of cvs
(I built a vanilla copy from upstream's sources), I made a start at
porting our patches across, but got stuck in a few places (and of
course such a change would require *very* careful checking considering
what we use cvs for).


(gdb) bt
#0  0x1ce596f65c1d in xrealloc (ptr=0x0, bytes=3833880)
at /usr/src/gnu/usr.bin/cvs/src/subr.c:72
#1  0x1ce596f52953 in linevector_copy (to=0x7f7c7f60, 
from=0x7f7c7f50) at /usr/src/gnu/usr.bin/cvs/src/rcs.c:6762
#2  0x1ce596f53524 in RCS_deltas (rcs=0x1ce79d124f00, fp=0x1ce799b1ca00, 
rcsbuf=0x7f7c7f00, version=0x1ce79a67dfc0 1.1.1.1, op=RCS_FETCH, 
text=0x7f7c8228, len=0x7f7c8220, log=0x7f7c8218, 
loglen=0x7f7c8210) at /usr/src/gnu/usr.bin/cvs/src/rcs.c:7172
#3  0x1ce596f4e3e2 in RCS_checkout (rcs=0x1ce79d124f00, workfile=0x0, 
rev=0x1ce79a67dfc0 1.1.1.1, nametag=0x1ce79a67dfd0 1.1.1.1, 
options=0x1ce79a67d590 , sout=0x0, 
pfn=0x1ce596f6bea3 checkout_to_buffer, callerdat=0x1ce79d124400)
at /usr/src/gnu/usr.bin/cvs/src/rcs.c:4114
#4  0x1ce596f6b7ae in checkout_file (finfo=0x7f7c8600, 
vers_ts=0x1ce79d124b00, adding=0, merging=0, update_server=1)
at /usr/src/gnu/usr.bin/cvs/src/update.c:1367
#5  0x1ce596f6a768 in update_fileproc (callerdat=0x0, finfo=0x7f7c8600)
at /usr/src/gnu/usr.bin/cvs/src/update.c:776
#6  0x1ce596f57ccc in do_file_proc (p=0x1ce7a1fad000, 
closure=0x7f7c8630) at /usr/src/gnu/usr.bin/cvs/src/recurse.c:823
#7  0x1ce596f30f61 in walklist (list=0x1ce79bc21000, 
proc=0x1ce596f57b4e do_file_proc, closure=0x7f7c8630)
at /usr/src/gnu/usr.bin/cvs/src/hash.c:370
#8  0x1ce596f57a06 in do_recursion (frame=0x7f7c86b0)
at /usr/src/gnu/usr.bin/cvs/src/recurse.c:727
#9  0x1ce596f582f5 in do_dir_proc (p=0x1ce7a1fad500, 
closure=0x7f7c8840) at /usr/src/gnu/usr.bin/cvs/src/recurse.c:1087
#10 0x1ce596f30f61 in walklist (list=0x1ce7a0e25800, 
proc=0x1ce596f57cfe do_dir_proc, closure=0x7f7c8840)
at /usr/src/gnu/usr.bin/cvs/src/hash.c:370
#11 0x1ce596f57af9 in do_recursion (frame=0x7f7c88e0)
at /usr/src/gnu/usr.bin/cvs/src/recurse.c:754
#12 0x1ce596f573c7 in start_recursion (
fileproc=0x1ce596f6a24a update_fileproc, 
filesdoneproc=0x1ce596f6a956 update_filesdone_proc, 
direntproc=0x1ce596f6aa89 update_dirent_proc, 
dirleaveproc=0x1ce596f6ae1a update_dirleave_proc, callerdat=0x0, argc=0, 
argv=0x1ce79a67d100, local=0, which=3, aflag=0, readlock=1, 
update_preload=0x1ce79bf776e0 xenocara/font/misc-misc, dosrcs=1)
at /usr/src/gnu/usr.bin/cvs/src/recurse.c:351
#13 0x1ce596f6a212 in do_update (argc=0, argv=0x0, xoptions=0x0, xtag=0x0, 
xdate=0x0, xforce=1, local=0, xbuild=1, xaflag=0, xprune=0, xpipeout=0, 
which=3, xjoin_rev1=0x0, xjoin_rev2=0x0, 
preload_update_dir=0x1ce79bf776e0 xenocara/font/misc-misc, xdotemplate=1)
at /usr/src/gnu/usr.bin/cvs/src/update.c:511
#14 0x1ce596f1767f in checkout_proc (argc=1, argv=0x1ce79a67d410, 
where_orig=0x0, mwhere=0x0, mfile=0x0, shorten=0, local_specified=0, 
omodule=0x1ce79bf77d20 xenocara/font/misc-misc, 
msg=0x1ce597093f6f Updating)
at /usr/src/gnu/usr.bin/cvs/src/checkout.c:1014
#15 0x1ce596f425eb in do_module (db=0x1ce79bf77f60, 
mname=0x1ce79bf77d20 xenocara/font/misc-misc, m_type=CHECKOUT, 
msg=0x1ce597093f6f Updating, 
callback_proc=0x1ce596f1687f checkout_proc, where=0x0, shorten=0, 
local_specified=0, run_module_prog=1, build_dirs=1, extra_arg=0x0)
at /usr/src/gnu/usr.bin/cvs/src/modules.c:317
#16 0x1ce596f1656f in checkout (argc=1, argv=0x1ce79bf775f0)
at /usr/src/gnu/usr.bin/cvs/src/checkout.c:376
#17 0x1ce596f5fc52 in do_cvs_command (cmd_name=0x1ce5970a2fdb checkout, 

Re: pdksh wrong strips quotes in shell substs

2013-03-03 Thread Philip Guenther
The fix for this is (finally) committed for post-5.3.  Sorry about the delay.


Philip Guenther



yyerror and ospfd reload

2013-03-03 Thread Stuart Henderson
If ospfd is running and you attempt to reload a configuration file
but it has an error (or the parser thinks it has an error even though
the file is valid..), yyerror just prints to stderr so the message
is lost unless you're running ospfd in the foreground.

I wrote a diff to handle this (included at the bottom of this mail)
but then I noticed that bgpd already does the same, so this just syncs
with bgpd's handling. OK?

Index: parse.y
===
RCS file: /cvs/src/usr.sbin/ospfd/parse.y,v
retrieving revision 1.73
diff -u -p -r1.73 parse.y
--- parse.y 13 Dec 2010 13:43:37 -  1.73
+++ parse.y 3 Mar 2013 21:13:58 -
@@ -36,6 +36,7 @@
 #include stdarg.h
 #include stdio.h
 #include string.h
+#include syslog.h
 
 #include ospf.h
 #include ospfd.h
@@ -692,14 +693,16 @@ struct keywords {
 int
 yyerror(const char *fmt, ...)
 {
-   va_list ap;
+   va_list  ap;
+   char*nfmt;
 
file-errors++;
va_start(ap, fmt);
-   fprintf(stderr, %s:%d: , file-name, yylval.lineno);
-   vfprintf(stderr, fmt, ap);
-   fprintf(stderr, \n);
+   if (asprintf(nfmt, %s:%d: %s, file-name, yylval.lineno, fmt) == -1)
+   fatalx(yyerror asprintf);
+   vlog(LOG_CRIT, nfmt, ap);
va_end(ap);
+   free(nfmt);
return (0);
 }
 


Here's the one I came up with myself FWIW.

Index: parse.y
===
RCS file: /cvs/src/usr.sbin/ospfd/parse.y,v
retrieving revision 1.73
diff -u -p -r1.73 parse.y
--- parse.y 13 Dec 2010 13:43:37 -  1.73
+++ parse.y 3 Mar 2013 21:01:25 -
@@ -693,12 +693,14 @@ int
 yyerror(const char *fmt, ...)
 {
va_list ap;
+   char *buf;
 
file-errors++;
va_start(ap, fmt);
-   fprintf(stderr, %s:%d: , file-name, yylval.lineno);
-   vfprintf(stderr, fmt, ap);
-   fprintf(stderr, \n);
+   if (vasprintf(buf, fmt, ap) = 0) {
+   log_warnx(%s:%d: %s, file-name, yylval.lineno, buf);
+   free(buf);
+   }
va_end(ap);
return (0);
 }



Re: yyerror and ospfd reload

2013-03-03 Thread Theo de Raadt
I like the bgpd behaviour, and all the similar daemons should have the
same behaviour.

 If ospfd is running and you attempt to reload a configuration file
 but it has an error (or the parser thinks it has an error even though
 the file is valid..), yyerror just prints to stderr so the message
 is lost unless you're running ospfd in the foreground.
 
 I wrote a diff to handle this (included at the bottom of this mail)
 but then I noticed that bgpd already does the same, so this just syncs
 with bgpd's handling. OK?
 
 Index: parse.y
 ===
 RCS file: /cvs/src/usr.sbin/ospfd/parse.y,v
 retrieving revision 1.73
 diff -u -p -r1.73 parse.y
 --- parse.y   13 Dec 2010 13:43:37 -  1.73
 +++ parse.y   3 Mar 2013 21:13:58 -
 @@ -36,6 +36,7 @@
  #include stdarg.h
  #include stdio.h
  #include string.h
 +#include syslog.h
  
  #include ospf.h
  #include ospfd.h
 @@ -692,14 +693,16 @@ struct keywords {
  int
  yyerror(const char *fmt, ...)
  {
 - va_list ap;
 + va_list  ap;
 + char*nfmt;
  
   file-errors++;
   va_start(ap, fmt);
 - fprintf(stderr, %s:%d: , file-name, yylval.lineno);
 - vfprintf(stderr, fmt, ap);
 - fprintf(stderr, \n);
 + if (asprintf(nfmt, %s:%d: %s, file-name, yylval.lineno, fmt) == -1)
 + fatalx(yyerror asprintf);
 + vlog(LOG_CRIT, nfmt, ap);
   va_end(ap);
 + free(nfmt);
   return (0);
  }
  
 
 
 Here's the one I came up with myself FWIW.
 
 Index: parse.y
 ===
 RCS file: /cvs/src/usr.sbin/ospfd/parse.y,v
 retrieving revision 1.73
 diff -u -p -r1.73 parse.y
 --- parse.y   13 Dec 2010 13:43:37 -  1.73
 +++ parse.y   3 Mar 2013 21:01:25 -
 @@ -693,12 +693,14 @@ int
  yyerror(const char *fmt, ...)
  {
   va_list ap;
 + char *buf;
  
   file-errors++;
   va_start(ap, fmt);
 - fprintf(stderr, %s:%d: , file-name, yylval.lineno);
 - vfprintf(stderr, fmt, ap);
 - fprintf(stderr, \n);
 + if (vasprintf(buf, fmt, ap) = 0) {
 + log_warnx(%s:%d: %s, file-name, yylval.lineno, buf);
 + free(buf);
 + }
   va_end(ap);
   return (0);
  }
 



vga diff for testing

2013-03-03 Thread Mark Kettenis
In order to be able to support a framebuffer console on i386/amd64 I'd
like to reorder some code such that wsdisaplay(4) attaches to vga(4)
*after* drm(4).  Since I don't have any hardware with radeondrm(4) I'd
appreciate it if people with access to such hardware would test the
diff below.  Just check that your vga text glass console and X still
work.

Thanks,

Mark


Index: vga_pci.c
===
RCS file: /cvs/src/sys/dev/pci/vga_pci.c,v
retrieving revision 1.69
diff -u -p -r1.69 vga_pci.c
--- vga_pci.c   8 Oct 2012 21:47:50 -   1.69
+++ vga_pci.c   3 Mar 2013 21:34:59 -
@@ -249,8 +249,6 @@ vga_pci_attach(struct device *parent, st
}
 #endif
printf(\n);
-   sc-sc_vc = vga_common_attach(self, pa-pa_iot, pa-pa_memt,
-   WSDISPLAY_TYPE_PCIVGA);
 
vga_pci_bar_init(sc, pa);
 
@@ -294,6 +292,9 @@ vga_pci_attach(struct device *parent, st
 #if NDRM  0
config_found_sm(self, aux, NULL, drmsubmatch);
 #endif
+
+   sc-sc_vc = vga_common_attach(self, pa-pa_iot, pa-pa_memt,
+   WSDISPLAY_TYPE_PCIVGA);
 }
 
 int



Re: out of memory errors seen on several AnonCVS servers

2013-03-03 Thread Ted Unangst
On Sun, Mar 03, 2013 at 16:16, Stuart Henderson wrote:
 Summary of off-list mail exchange: anoncvs.usa consistently has a
 realloc failure in xenocara/font/misc-misc/18x18ja.bdf, some other
 servers have a failure the first time checking this file out when
 it's part of the whole directory, but resuming or checking out
 individually does work.

amd64?  Use i386. :)  or opencvs.



Re: out of memory errors seen on several AnonCVS servers

2013-03-03 Thread Stuart Henderson
On 2013/03/03 17:11, Ted Unangst wrote:
 On Sun, Mar 03, 2013 at 16:16, Stuart Henderson wrote:
  Summary of off-list mail exchange: anoncvs.usa consistently has a
  realloc failure in xenocara/font/misc-misc/18x18ja.bdf, some other
  servers have a failure the first time checking this file out when
  it's part of the whole directory, but resuming or checking out
  individually does work.
 
 amd64?  Use i386. :)  or opencvs.
 

The problems in opencvs are more insidious.



Re: yyerror and ospfd reload

2013-03-03 Thread Stuart Henderson
On 2013/03/03 14:25, Theo de Raadt wrote:
 I like the bgpd behaviour, and all the similar daemons should have the
 same behaviour.

Here it is for all of the daemons which have parse.y and log.c; it only
really affects the ones which support reload, but I think it makes sense to
use the same code in all for consistency.

ldapd, bgpd, npppd, ntpd already use vlog, hostapd doesn't use log.c.

Index: ospf6d/parse.y
===
RCS file: /cvs/src/usr.sbin/ospf6d/parse.y,v
retrieving revision 1.21
diff -u -p -r1.21 parse.y
--- ospf6d/parse.y  27 Jun 2011 03:07:26 -  1.21
+++ ospf6d/parse.y  3 Mar 2013 22:13:10 -
@@ -38,6 +38,7 @@
 #include stdarg.h
 #include stdio.h
 #include string.h
+#include syslog.h
 
 #include ospf6.h
 #include ospf6d.h
@@ -516,14 +517,16 @@ struct keywords {
 int
 yyerror(const char *fmt, ...)
 {
-   va_list ap;
+   va_list  ap;
+   char*nfmt;
 
file-errors++;
va_start(ap, fmt);
-   fprintf(stderr, %s:%d: , file-name, yylval.lineno);
-   vfprintf(stderr, fmt, ap);
-   fprintf(stderr, \n);
+   if (asprintf(nfmt, %s:%d: %s, file-name, yylval.lineno, fmt) == -1)
+   fatalx(yyerror asprintf);
+   vlog(LOG_CRIT, nfmt, ap);
va_end(ap);
+   free(nfmt);
return (0);
 }
 
Index: ospfd/parse.y
===
RCS file: /cvs/src/usr.sbin/ospfd/parse.y,v
retrieving revision 1.73
diff -u -p -r1.73 parse.y
--- ospfd/parse.y   13 Dec 2010 13:43:37 -  1.73
+++ ospfd/parse.y   3 Mar 2013 22:13:10 -
@@ -36,6 +36,7 @@
 #include stdarg.h
 #include stdio.h
 #include string.h
+#include syslog.h
 
 #include ospf.h
 #include ospfd.h
@@ -692,14 +693,16 @@ struct keywords {
 int
 yyerror(const char *fmt, ...)
 {
-   va_list ap;
+   va_list  ap;
+   char*nfmt;
 
file-errors++;
va_start(ap, fmt);
-   fprintf(stderr, %s:%d: , file-name, yylval.lineno);
-   vfprintf(stderr, fmt, ap);
-   fprintf(stderr, \n);
+   if (asprintf(nfmt, %s:%d: %s, file-name, yylval.lineno, fmt) == -1)
+   fatalx(yyerror asprintf);
+   vlog(LOG_CRIT, nfmt, ap);
va_end(ap);
+   free(nfmt);
return (0);
 }
 
Index: dvmrpd/parse.y
===
RCS file: /cvs/src/usr.sbin/dvmrpd/parse.y,v
retrieving revision 1.22
diff -u -p -r1.22 parse.y
--- dvmrpd/parse.y  31 Dec 2010 21:22:42 -  1.22
+++ dvmrpd/parse.y  3 Mar 2013 22:13:10 -
@@ -358,14 +358,16 @@ struct keywords {
 int
 yyerror(const char *fmt, ...)
 {
-   va_list ap;
+   va_list  ap;
+   char*nfmt;
 
file-errors++;
va_start(ap, fmt);
-   fprintf(stderr, %s:%d: , file-name, yylval.lineno);
-   vfprintf(stderr, fmt, ap);
-   fprintf(stderr, \n);
+   if (asprintf(nfmt, %s:%d: %s, file-name, yylval.lineno, fmt) == -1)
+   fatalx(yyerror asprintf);
+   vlog(LOG_CRIT, nfmt, ap);
va_end(ap);
+   free(nfmt);
return (0);
 }
 
Index: ifstated/ifstated.h
===
RCS file: /cvs/src/usr.sbin/ifstated/ifstated.h,v
retrieving revision 1.6
diff -u -p -r1.6 ifstated.h
--- ifstated/ifstated.h 4 Feb 2010 13:50:14 -   1.6
+++ ifstated/ifstated.h 3 Mar 2013 22:14:38 -
@@ -142,5 +142,6 @@ voidlog_warn(const char *, ...);
 void   log_warnx(const char *, ...);
 void   log_info(const char *, ...);
 void   log_debug(const char *, ...);
+void   vlog(int, const char *, va_list);
 __dead void fatal(const char *);
 __dead void fatalx(const char *);
Index: ifstated/parse.y
===
RCS file: /cvs/src/usr.sbin/ifstated/parse.y,v
retrieving revision 1.30
diff -u -p -r1.30 parse.y
--- ifstated/parse.y3 Aug 2010 18:42:40 -   1.30
+++ ifstated/parse.y3 Mar 2013 22:13:10 -
@@ -355,13 +355,15 @@ int
 yyerror(const char *fmt, ...)
 {
va_list  ap;
+   char*nfmt;
 
file-errors++;
va_start(ap, fmt);
-   fprintf(stderr, %s:%d: , file-name, yylval.lineno);
-   vfprintf(stderr, fmt, ap);
-   fprintf(stderr, \n);
+   if (asprintf(nfmt, %s:%d: %s, file-name, yylval.lineno, fmt) == -1)
+   fatalx(yyerror asprintf);
+   vlog(LOG_CRIT, nfmt, ap);
va_end(ap);
+   free(nfmt);
return (0);
 }
 
Index: relayd/parse.y
===
RCS file: /cvs/src/usr.sbin/relayd/parse.y,v
retrieving revision 1.168
diff -u -p -r1.168 parse.y
--- relayd/parse.y  19 Oct 2012 16:49:50 -  1.168
+++ relayd/parse.y  3 Mar 2013 22:13:10 -
@@ -51,6 +51,7 @@
 #include netdb.h
 #include string.h
 #include ifaddrs.h
+#include 

Re: vga diff for testing

2013-03-03 Thread Ryan Freeman
On Sun, Mar 03, 2013 at 10:39:46PM +0100, Mark Kettenis wrote:
 In order to be able to support a framebuffer console on i386/amd64 I'd
 like to reorder some code such that wsdisaplay(4) attaches to vga(4)
 *after* drm(4).  Since I don't have any hardware with radeondrm(4) I'd
 appreciate it if people with access to such hardware would test the
 diff below.  Just check that your vga text glass console and X still
 work.
 

Hey Mark,

Seems all good here on an i386 with radeondrm(4):

vga1 at pci1 dev 0 function 0 ATI Radeon Mobility X1400 rev 0x00
radeondrm0 at vga1: apic 1 int 16
drm0 at radeondrm0
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)

Both text console and X seem as fine as ever, killed X a couple
times and restarted, plus switched back and forth between X and
console a few times to make sure everything seemed ok.

Cheers,

-ryan

 Thanks,
 
 Mark
 
 
 Index: vga_pci.c
 ===
 RCS file: /cvs/src/sys/dev/pci/vga_pci.c,v
 retrieving revision 1.69
 diff -u -p -r1.69 vga_pci.c
 --- vga_pci.c 8 Oct 2012 21:47:50 -   1.69
 +++ vga_pci.c 3 Mar 2013 21:34:59 -
 @@ -249,8 +249,6 @@ vga_pci_attach(struct device *parent, st
   }
  #endif
   printf(\n);
 - sc-sc_vc = vga_common_attach(self, pa-pa_iot, pa-pa_memt,
 - WSDISPLAY_TYPE_PCIVGA);
  
   vga_pci_bar_init(sc, pa);
  
 @@ -294,6 +292,9 @@ vga_pci_attach(struct device *parent, st
  #if NDRM  0
   config_found_sm(self, aux, NULL, drmsubmatch);
  #endif
 +
 + sc-sc_vc = vga_common_attach(self, pa-pa_iot, pa-pa_memt,
 + WSDISPLAY_TYPE_PCIVGA);
  }
  
  int
 



typo in dhcrelay comment

2013-03-03 Thread Sebastian Benoit
subject says it all.
ok?

diff --git dhcrelay.c dhcrelay.c
index a2f39d0..4782f65 100644
--- dhcrelay.c
+++ dhcrelay.c
@@ -380,7 +380,7 @@ got_response(struct protocol *l)
if ((result = recv(l-fd, u.packbuf, sizeof(u), 0)) == -1 
errno != ECONNREFUSED) {
/*
-* Ignore ECONNREFUSED as to many dhcp server send a bogus
+* Ignore ECONNREFUSED as too many dhcp servers send a bogus
 * icmp unreach for every request.
 */
warning(recv failed for %s: %m,



Re: vga diff for testing

2013-03-03 Thread Juan Francisco Cantero Hurtado
On Sun, Mar 03, 2013 at 10:39:46PM +0100, Mark Kettenis wrote:
 
 In order to be able to support a framebuffer console on i386/amd64 I'd
 like to reorder some code such that wsdisaplay(4) attaches to vga(4)
 *after* drm(4).  Since I don't have any hardware with radeondrm(4) I'd
 appreciate it if people with access to such hardware would test the
 diff below.  Just check that your vga text glass console and X still
 work.

All works OK. AMD64 and ATI Radeon HD 4350 PCI.


OpenBSD 5.3 (GENERIC.MP) #21: Wed Feb 27 22:58:43 CET 2013
r...@sobremesa.juanfra.info:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8566591488 (8169MB)
avail mem = 8316051456 (7930MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xeb0d0 (65 entries)
bios0: vendor American Megatrends Inc. version 0901 date 09/30/2012
bios0: ASUSTeK COMPUTER INC. F1A55
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG HPET SSDT SSDT
acpi0: wakeup devices SBAZ(S4) PS2K(S4) PS2M(S4) UAR1(S4) UHC1(S4) UHC2(S4) 
USB3(S4) UHC4(S4) USB5(S4) UHC6(S4) UHC7(S4) PE20(S4) PE21(S4) RLAN(S4) 
PE22(S4) PE23(S4) PCE2(S4) PCE4(S4) P0PC(S4)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD A4-3400 APU with Radeon(tm) HD Graphics, 2700.24 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu0: AMD erratum 721 detected and fixed
cpu0: smt 0, core 0, package 0
cpu0: apic clock running at 199MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD A4-3400 APU with Radeon(tm) HD Graphics, 2699.93 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC
cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache
cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu1: AMD erratum 721 detected and fixed
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 3 pa 0xfec0, version 21, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318180 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 3 (PE20)
acpiprt2 at acpi0: bus 4 (PE21)
acpiprt3 at acpi0: bus -1 (PE22)
acpiprt4 at acpi0: bus 5 (PE23)
acpiprt5 at acpi0: bus -1 (BR13)
acpiprt6 at acpi0: bus -1 (PCE2)
acpiprt7 at acpi0: bus -1 (PCE4)
acpiprt8 at acpi0: bus 1 (P0PC)
acpicpu0 at acpi0: C2, PSS
acpicpu1 at acpi0: C2, PSS
acpibtn0 at acpi0: PWRB
cpu0: 2700 MHz: speeds: 2700 2400 2200 2000 1800 1400 1100 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 AMD AMD64 12h Host rev 0x00
ahci0 at pci0 dev 17 function 0 AMD Hudson-2 SATA rev 0x40: msi, AHCI 1.3
scsibus0 at ahci0: 32 targets
sd0 at scsibus0 targ 0 lun 0: ATA, ST3250310AS, 3.AA SCSI3 0/direct fixed 
t10.ATA_ST3250310AS_5RY0ZTKS
sd0: 238475MB, 512 bytes/sector, 488397168 sectors
sd1 at scsibus0 targ 1 lun 0: ATA, ST3500418AS, CC34 SCSI3 0/direct fixed 
naa.5000c500142c3ef3
sd1: 476940MB, 512 bytes/sector, 976773168 sectors
sd2 at scsibus0 targ 2 lun 0: ATA, ST1000DM003-1CH1, CC44 SCSI3 0/direct 
fixed naa.5000c5004fab5f8b
sd2: 953869MB, 512 bytes/sector, 1953525168 sectors
ohci0 at pci0 dev 18 function 0 AMD Hudson-2 USB rev 0x11: apic 3 int 18, 
version 1.0, legacy support
ehci0 at pci0 dev 18 function 2 AMD Hudson-2 USB2 rev 0x11: apic 3 int 17
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 AMD EHCI root hub rev 2.00/1.00 addr 1
ohci1 at pci0 dev 19 function 0 AMD Hudson-2 USB rev 0x11: apic 3 int 18, 
version 1.0, legacy support
ehci1 at pci0 dev 19 function 2 AMD Hudson-2 USB2 rev 0x11: apic 3 int 17
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 AMD EHCI root hub rev 2.00/1.00 addr 1
piixpm0 at pci0 dev 20 function 0 AMD Hudson-2 SMBus rev 0x13: polling
iic0 at piixpm0
iic0: addr 0x20 01=0d 02=17 03=26 04=8c 05=8c 06=8c 07=8c 08=00 09=00 0a=10 
0b=10 0c=10 0d=10 0e=07 0f=8b 10=00 11=00 12=00 13=00 14=00 15=0f 16=17 17=20 
18=e0 19=fb 1a=a8 1b=a3 1c=ac 1d=80 1e=04 1f=03 20=09 21=09 22=09 23=09 24=37 
3e=a3 words 00=ff0d 01=0d17 02=1726 03=268c 04=8c8c 05=8c8c 06=8c8c 07=8c00
spdmem0 at iic0 addr 0x50: 4GB DDR3 SDRAM PC3-10600
spdmem1 at iic0 addr 0x51: 4GB DDR3 SDRAM PC3-10600
azalia0 at pci0 dev 20 function 2 AMD Hudson-2 HD Audio rev 0x01: apic 3 int 
16
azalia0: codecs: Realtek/0x0887
audio0 at azalia0
pcib0 

Re: out of memory errors seen on several AnonCVS servers

2013-03-03 Thread John Long
On Sun, Mar 03, 2013 at 04:16:30PM +, Stuart Henderson wrote:
 Summary of off-list mail exchange: anoncvs.usa consistently has a
 realloc failure in xenocara/font/misc-misc/18x18ja.bdf, some other
 servers have a failure the first time checking this file out when
 it's part of the whole directory, but resuming or checking out
 individually does work.
 
 $ cvs -d anon...@anoncvs.spacehopper.org:/cvs get xenocara/font/misc-misc
 U xenocara/font/misc-misc/10x20.bdf
 U xenocara/font/misc-misc/12x13ja.bdf
 cvs [server aborted]: out of memory; can not reallocate 3833880 bytes

I got this error consistently with anoncvs.openbsd.org as well, on both
amd64 and mips64el. My use case is cvs -d$CVSROOT up -Pd for each of src,
xenocara and ports (normal tracking of -stable). I believe I got the error
on various other CVS servers until I started using spacehopper. I haven't
seen the problem again. Thanks Stuart.

/jl

-- 
ASCII ribbon campaign ( ) Powered by Lemote Fuloong
 against HTML e-mail   X  Loongson MIPS and OpenBSD
   and proprietary/ \http://www.mutt.org
 attachments /   \  Code Blue or Go Home!
 Encrypted email preferred  PGP Key 2048R/DA65BC04