Re: out of memory errors seen on several AnonCVS servers
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
Re: vga diff for testing
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: SCSI3 0/direct fixed t10.ATA_ST3250310AS_5RY0ZTKS sd0: 238475MB, 512 bytes/sector, 488397168 sectors sd1 at scsibus0 targ 1 lun 0: SCSI3 0/direct fixed naa.5000c500142c3ef3 sd1: 476940MB, 512 bytes/sector, 976773168 sectors sd2 at scsibus0 targ 2 lun 0: 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 at pci0 dev 20 function 3 "AMD Hudson-2 LPC"
typo in dhcrelay comment
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
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
>
Re: yyerror and ospfd reload
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
#include
#include
+#include
#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
#include
#include
+#include
#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
#include
#include
+#include
#include
@@ -1760,13 +1761,1
Re: out of memory errors seen on several AnonCVS servers
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: out of memory errors seen on several AnonCVS servers
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.
vga diff for testing
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: yyerror and ospfd reload
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
> #include
> #include
> +#include
>
> #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);
> }
>
yyerror and ospfd reload
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
#include
#include
+#include
#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: pdksh wrong strips quotes in shell substs
The fix for this is (finally) committed for post-5.3. Sorry about the delay. Philip Guenther
Re: out of memory errors seen on several AnonCVS servers
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 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 , 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 , 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 , 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 , filesdoneproc=0x1ce596f6a956 , direntproc=0x1ce596f6aa89 , dirleaveproc=0x1ce596f6ae1a , 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 , 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", command=0x1ce596f15c24 ) at /usr/src/gnu/usr.bin/cvs/src/server.c:2900 #18 0x1ce596f6180f in serve_co (arg=0x1ce79a67df02 ""
Re: HG2F09 "mystery" USB-to-ethernet adapter fix
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: HG2F09 "mystery" USB-to-ethernet adapter fix
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.
>
jumbos for bnx(4) (again)
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);
HG2F09 "mystery" USB-to-ethernet adapter fix
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.
