sppp goes on a diet
The last diff only had +'s, so restore the balance. Since the sad
demise of art, san, and lmc, there is some crisco that can be flensed.
The diff has ^L's in so there's a risk it may get mangled with
quoted-unreadable encoding, so I've put a copy at
http://junkpile.org/sppp-decisco.diff
Index: if_sppp.h
===
RCS file: /cvs/src/sys/net/if_sppp.h,v
retrieving revision 1.20
diff -u -p -r1.20 if_sppp.h
--- if_sppp.h 20 Nov 2013 08:21:33 - 1.20
+++ if_sppp.h 29 Sep 2015 23:31:45 -
@@ -2,7 +2,7 @@
/* $NetBSD: if_sppp.h,v 1.2.2.1 1999/04/04 06:57:39 explorer Exp $ */
/*
- * Defines for synchronous PPP/Cisco link level subroutines.
+ * Defines for synchronous PPP link level subroutines.
*
* Copyright (C) 1994 Cronyx Ltd.
* Author: Serge Vakulenko,
@@ -156,7 +156,7 @@ struct sppp {
struct ifnet pp_if;/* network interface data */
struct ifqueue pp_cpq; /* PPP control protocol queue */
struct sppp *pp_next; /* next interface in keepalive list */
- u_int pp_flags; /* use Cisco protocol instead of PPP */
+ u_int pp_flags;
u_int pp_framebytes; /* number of bytes added by hardware framing */
u_short pp_alivecnt;/* keepalive packets counter */
u_short pp_loopcnt; /* loopback detection counter */
@@ -208,7 +208,7 @@ struct sppp {
};
#define PP_KEEPALIVE0x01/* use keepalive protocol */
-#define PP_CISCO0x02/* use Cisco protocol instead of PPP */
+ /* 0x02 was PP_CISCO */
/* 0x04 was PP_TIMO */
#define PP_CALLIN 0x08/* we are being called */
#define PP_NEEDAUTH0x10/* remote requested authentication */
Index: if_spppsubr.c
===
RCS file: /cvs/src/sys/net/if_spppsubr.c,v
retrieving revision 1.137
diff -u -p -r1.137 if_spppsubr.c
--- if_spppsubr.c 24 Aug 2015 15:58:35 - 1.137
+++ if_spppsubr.c 29 Sep 2015 23:31:45 -
@@ -1,7 +1,6 @@
/* $OpenBSD: if_spppsubr.c,v 1.137 2015/08/24 15:58:35 mpi Exp $ */
/*
- * Synchronous PPP/Cisco link level subroutines.
- * Keepalive protocol implemented in both Cisco and PPP modes.
+ * Synchronous PPP link level subroutines.
*
* Copyright (C) 1994-1996 Cronyx Engineering Ltd.
* Author: Serge Vakulenko,
@@ -93,7 +92,7 @@
* :
*
* with being something like "bppp0", and
- * being one of "lcp", "ipcp", "cisco", "chap", "pap", etc.
+ * being one of "lcp", "ipcp", "chap", "pap", etc.
*/
#define IFF_PASSIVEIFF_LINK0 /* wait passively for connection */
@@ -151,13 +150,6 @@
#define CHAP_MD5 5 /* hash algorithm - MD5 */
-#define CISCO_MULTICAST0x8f/* Cisco multicast address */
-#define CISCO_UNICAST 0x0f/* Cisco unicast address */
-#define CISCO_KEEPALIVE0x8035 /* Cisco keepalive protocol */
-#define CISCO_ADDR_REQ 0 /* Cisco address request */
-#define CISCO_ADDR_REPLY 1 /* Cisco address reply */
-#define CISCO_KEEPALIVE_REQ2 /* Cisco keepalive request */
-
/* states are named and numbered according to RFC 1661 */
#define STATE_INITIAL 0
#define STATE_STARTING 1
@@ -184,16 +176,6 @@ struct lcp_header {
};
#define LCP_HEADER_LEN sizeof (struct lcp_header)
-struct cisco_packet {
- u_int32_t type;
- u_int32_t par1;
- u_int32_t par2;
- u_short rel;
- u_short time0;
- u_short time1;
-};
-#define CISCO_PACKET_LEN 18
-
/*
* We follow the spelling and capitalization of RFC 1661 here, to make
* it easier comparing with the standard. Please refer to this RFC in
@@ -240,9 +222,6 @@ static struct timeout keepalive_ch;
int sppp_output(struct ifnet *ifp, struct mbuf *m,
struct sockaddr *dst, struct rtentry *rt);
-void sppp_cisco_send(struct sppp *sp, u_int32_t type, u_int32_t par1,
u_int32_t par2);
-void sppp_cisco_input(struct sppp *sp, struct mbuf *m);
-
void sppp_cp_input(const struct cp *cp, struct sppp *sp,
struct mbuf *m);
void sppp_cp_send(struct sppp *sp, u_short proto, u_char type,
@@ -495,15 +474,6 @@ sppp_input(struct ifnet *ifp, struct mbu
case PPP_ALLSTATIONS:
if (ht.control != PPP_UI)
goto invalid;
- if (sp->pp_flags & PP_CISCO) {
- if (debug)
- log(LOG_DEBUG,
- SPP_FMT "PPP packet in Cisco mode "
- "\n",
- SPP_ARGS(ifp),
- ht.address, ht.control, ntohs(ht.protocol));
- goto drop;
- }
switch (ntohs (ht.protocol)) {
default:
if (sp->state[
sppp/pppoe and vlan prio
This diff teachs sppp/pppoe(4) to set ifq priority on control frames
(LCP, PAP/CHAP, the various pppoe PADx). These cannot be set the normal
way because these non-IP frames aren't fed through PF.
It's done using a #define which is currently set to a high priority as
that's what is normally wanted to avoid control packets being dropped on
a busy link (too many missed LCP echoes and the link is likely to be
torn down). AFAICT this is also what cisco are now doing by default;
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/bbdsl/configuration/xe-3s/asr1000/bba-xe-3s-asr1000-book/bba-cos-ppp-pppoe-xe.html#GUID-1B5EEC89-1EDF-459A-A097-22C867B12969
This is connected with the VLAN priority problem mentioned in
https://marc.info/?l=openbsd-misc&m=139889217231865&w=2 and
https://marc.info/?l=openbsd-misc&m=142920873204434&w=2 but isn't
a direct fix (though people who are recompiling to avoid that problem
could use this with a different value than 7, plus a PF rule - that
would allow ifq to work normally on interfaces not involved with pppoe).
Any comments?
Index: if_sppp.h
===
RCS file: /cvs/src/sys/net/if_sppp.h,v
retrieving revision 1.20
diff -u -p -r1.20 if_sppp.h
--- if_sppp.h 20 Nov 2013 08:21:33 - 1.20
+++ if_sppp.h 29 Sep 2015 22:42:49 -
@@ -56,6 +56,7 @@ enum ppp_phase {
#define AUTHMAXLEN 256 /* including terminating '\0' */
#define AUTHCHALEN 16 /* length of the challenge we send */
+#define SPPPCTL_IFQ_PRIO 7 /* priority for control frames */
/*
* Definitions to pass struct sppp data down into the kernel using the
Index: if_spppsubr.c
===
RCS file: /cvs/src/sys/net/if_spppsubr.c,v
retrieving revision 1.137
diff -u -p -r1.137 if_spppsubr.c
--- if_spppsubr.c 24 Aug 2015 15:58:35 - 1.137
+++ if_spppsubr.c 29 Sep 2015 22:42:49 -
@@ -1156,6 +1156,7 @@ sppp_cisco_send(struct sppp *sp, u_int32
return;
m->m_pkthdr.len = m->m_len = PPP_HEADER_LEN + CISCO_PACKET_LEN;
m->m_pkthdr.ph_ifidx = 0;
+ m->m_pkthdr.pf.prio = SPPPCTL_IFQ_PRIO;
h = mtod (m, struct ppp_header*);
h->address = CISCO_MULTICAST;
@@ -1215,6 +1216,7 @@ sppp_cp_send(struct sppp *sp, u_short pr
return;
m->m_pkthdr.len = m->m_len = pkthdrlen + LCP_HEADER_LEN + len;
m->m_pkthdr.ph_ifidx = 0;
+ m->m_pkthdr.pf.prio = SPPPCTL_IFQ_PRIO;
if (sp->pp_flags & PP_NOFRAMING) {
*mtod(m, u_int16_t *) = htons(proto);
@@ -4318,6 +4320,7 @@ sppp_auth_send(const struct cp *cp, stru
if (! m)
return;
m->m_pkthdr.ph_ifidx = 0;
+ m->m_pkthdr.pf.prio = SPPPCTL_IFQ_PRIO;
if (sp->pp_flags & PP_NOFRAMING) {
*mtod(m, u_int16_t *) = htons(cp->proto);
Index: if_pppoe.c
===
RCS file: /cvs/src/sys/net/if_pppoe.c,v
retrieving revision 1.48
diff -u -p -r1.48 if_pppoe.c
--- if_pppoe.c 13 Sep 2015 17:53:44 - 1.48
+++ if_pppoe.c 29 Sep 2015 22:42:49 -
@@ -1077,6 +1077,8 @@ pppoe_send_padi(struct pppoe_softc *sc)
if (m0 == NULL)
return (ENOBUFS);
+ m0->m_pkthdr.pf.prio = SPPPCTL_IFQ_PRIO;
+
/* fill in pkt */
p = mtod(m0, u_int8_t *);
PPPOE_ADD_HEADER(p, PPPOE_CODE_PADI, 0, len);
@@ -1314,6 +1316,8 @@ pppoe_send_padr(struct pppoe_softc *sc)
if (m0 == NULL)
return (ENOBUFS);
+ m0->m_pkthdr.pf.prio = SPPPCTL_IFQ_PRIO;
+
p = mtod(m0, u_int8_t *);
PPPOE_ADD_HEADER(p, PPPOE_CODE_PADR, 0, len);
PPPOE_ADD_16(p, PPPOE_TAG_SNAME);
@@ -1370,6 +1374,8 @@ pppoe_send_padt(struct ifnet *outgoing_i
if (m0 == NULL)
return (ENOBUFS);
+ m0->m_pkthdr.pf.prio = SPPPCTL_IFQ_PRIO;
+
p = mtod(m0, u_int8_t *);
PPPOE_ADD_HEADER(p, PPPOE_CODE_PADT, session, 0);
@@ -1409,6 +1415,8 @@ pppoe_send_pado(struct pppoe_softc *sc)
if (m0 == NULL)
return (ENOBUFS);
+ m0->m_pkthdr.pf.prio = SPPPCTL_IFQ_PRIO;
+
p = mtod(m0, u_int8_t *);
PPPOE_ADD_HEADER(p, PPPOE_CODE_PADO, 0, len);
PPPOE_ADD_16(p, PPPOE_TAG_ACCOOKIE);
@@ -1447,6 +1455,8 @@ pppoe_send_pads(struct pppoe_softc *sc)
m0 = pppoe_get_mbuf(len + PPPOE_HEADERLEN);
if (m0 == NULL)
return (ENOBUFS);
+
+ m0->m_pkthdr.pf.prio = SPPPCTL_IFQ_PRIO;
p = mtod(m0, u_int8_t *);
PPPOE_ADD_HEADER(p, PPPOE_CODE_PADS, sc->sc_session, len);
Re: Unable to install bootblocks
Apologies for not including dmesg in original email. OpenBSD 5.8-current (RAMDISK_CD) #1271: Tue Sep 29 10:30:11 MDT 2015 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 117374976 (111MB) avail mem = 112254976 (107MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (364 entries) bios0: vendor Phoenix Technologies LTD version "6.00" date 06/22/2012 bios0: VMware, Inc. VMware Virtual Platform acpi0 at bios0: rev 2 acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz, 2000.02 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,SSE3,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,HV,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: apic clock running at 65MHz ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x01 ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x01 pci1 at ppb0 bus 1 "Intel 82371AB PIIX4 ISA" rev 0x08 at pci0 dev 7 function 0 not configured pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility pciide0: channel 0 disabled (no drives) atapiscsi0 at pciide0 channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: ATAPI 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 "Intel 82371AB Power" rev 0x08 at pci0 dev 7 function 3 not configured "VMware VMCI" rev 0x10 at pci0 dev 7 function 7 not configured vga1 at pci0 dev 15 function 0 "VMware SVGA II" rev 0x00 vga1: aperture needed wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation) ppb1 at pci0 dev 17 function 0 "VMware PCI" rev 0x02 pci2 at ppb1 bus 2 ppb2 at pci0 dev 21 function 0 "VMware PCIE" rev 0x01 pci3 at ppb2 bus 3 vmwpvs0 at pci3 dev 0 function 0 "VMware PVSCSI" rev 0x02: apic 1 int 18 scsibus1 at vmwpvs0: 16 targets sd0 at scsibus1 targ 0 lun 0: SCSI2 0/direct fixed sd0: 1024MB, 512 bytes/sector, 2097152 sectors sd1 at scsibus1 targ 1 lun 0: SCSI2 0/direct fixed sd1: 1024MB, 512 bytes/sector, 2097152 sectors sd2 at scsibus1 targ 2 lun 0: SCSI2 0/direct fixed sd2: 20MB, 512 bytes/sector, 40960 sectors ppb3 at pci0 dev 21 function 1 "VMware PCIE" rev 0x01 pci4 at ppb3 bus 4 ppb4 at pci0 dev 21 function 2 "VMware PCIE" rev 0x01 pci5 at ppb4 bus 5 ppb5 at pci0 dev 21 function 3 "VMware PCIE" rev 0x01 pci6 at ppb5 bus 6 ppb6 at pci0 dev 21 function 4 "VMware PCIE" rev 0x01 pci7 at ppb6 bus 7 ppb7 at pci0 dev 21 function 5 "VMware PCIE" rev 0x01 pci8 at ppb7 bus 8 ppb8 at pci0 dev 21 function 6 "VMware PCIE" rev 0x01 pci9 at ppb8 bus 9 ppb9 at pci0 dev 21 function 7 "VMware PCIE" rev 0x01 pci10 at ppb9 bus 10 ppb10 at pci0 dev 22 function 0 "VMware PCIE" rev 0x01 pci11 at ppb10 bus 11 vmx0 at pci11 dev 0 function 0 "VMware VMXNET3" rev 0x01: apic 1 int 19, address 00:50:56:81:63:e3 ppb11 at pci0 dev 22 function 1 "VMware PCIE" rev 0x01 pci12 at ppb11 bus 12 ppb12 at pci0 dev 22 function 2 "VMware PCIE" rev 0x01 pci13 at ppb12 bus 13 ppb13 at pci0 dev 22 function 3 "VMware PCIE" rev 0x01 pci14 at ppb13 bus 14 ppb14 at pci0 dev 22 function 4 "VMware PCIE" rev 0x01 pci15 at ppb14 bus 15 ppb15 at pci0 dev 22 function 5 "VMware PCIE" rev 0x01 pci16 at ppb15 bus 16 ppb16 at pci0 dev 22 function 6 "VMware PCIE" rev 0x01 pci17 at ppb16 bus 17 ppb17 at pci0 dev 22 function 7 "VMware PCIE" rev 0x01 pci18 at ppb17 bus 18 ppb18 at pci0 dev 23 function 0 "VMware PCIE" rev 0x01 pci19 at ppb18 bus 19 ppb19 at pci0 dev 23 function 1 "VMware PCIE" rev 0x01 pci20 at ppb19 bus 20 ppb20 at pci0 dev 23 function 2 "VMware PCIE" rev 0x01 pci21 at ppb20 bus 21 ppb21 at pci0 dev 23 function 3 "VMware PCIE" rev 0x01 pci22 at ppb21 bus 22 ppb22 at pci0 dev 23 function 4 "VMware PCIE" rev 0x01 pci23 at ppb22 bus 23 ppb23 at pci0 dev 23 function 5 "VMware PCIE" rev 0x01 pci24 at ppb23 bus 24 ppb24 at pci0 dev 23 function 6 "VMware PCIE" rev 0x01 pci25 at ppb24 bus 25 ppb25 at pci0 dev 23 function 7 "VMware PCIE" rev 0x01 pci26 at ppb25 bus 26 ppb26 at pci0 dev 24 function 0 "VMware PCIE" rev 0x01 pci27 at ppb26 bus 27 ppb27 at pci0 dev 24 function 1 "VMware PCIE" rev 0x01 pci28 at ppb27 bus 28 ppb28 at pci0 dev 24 function 2 "VMware PCIE" rev 0x01 pci29 at ppb28 bus 29 ppb29 at pci0 dev 24 function 3 "VMware PCIE" rev 0x01 pci30 at ppb29 bus 30 ppb30 at pci0 dev 24 function 4 "VMware PCIE" rev 0x01 pci31 at ppb30 bus 31 ppb31 at pci0 dev 24 function 5 "VMware PCIE" rev 0x01 pci32 at ppb31 bus 32 ppb32 at pci0 dev 24 function 6 "VMware PCIE" rev 0x01 pci33 at ppb32 bus 33 ppb33 at pci0 dev 24 function 7 "VMware PCIE" rev 0x01 pci34 at ppb33 bus 34 isa0 at mainbus0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com1 at isa0 port 0x2f8/8
Unable to install bootblocks
Hi, While installing openbsd on vmware using today's snapshot 29-sep-2015, I get the following message on the final part of the install process, leaving the system in an unusable state (not booting normally after installing from bsd.rd). The hypervisor is running esx 5.1.0 Guest settings: 128mb ram 1gb hdd SCSI controller is set to paravirtual NIC is set to vmx3 installboot: invalid boot record signature (0x) @ sector 0 Failed to install bootblocks. You will not be able to boot OpenBSD from sd0 Best regards, Pedro Caetano
Re: Unlocking em(4) a bit further
On 29.9.2015. 1:00, Hrvoje Popovski wrote: > On 28.9.2015. 23:53, Mark Kettenis wrote: >> This diff makes the tx completion path run without the kernel lock >> held. With this change, the interrupt handler will not grab the >> kernel lock under normal circumstances. The diff follows the same >> approach as dlg@ took with vmx(4). >> >> The diff removes the code that tries to reclaim tx descriptors in >> if_start() if we have only EM_TX_CLEANUP_THRESHOLD available >> descriptors left. Running tx_eof() in both the normal transmit path >> and from the interrupt handler becomes a locking nightmare. >> >> Seems to survive some serious stress-testing with tcpbench and ping -f >> on my x220: >> >> em0 at pci0 dev 25 function 0 "Intel 82579LM" rev 0x04: msi, address >> f0:de:f1:70:87:8a >> >> Could use some further testing of course. > > > > Hi, > i'm getting 720kpps with 128 byte packets through bridge with two i350. > Everything seems stable and openbsd box is responsive. Will leave it > over night with routed setup i'm getting stable 1Mpps (64b packets) and box is happy and responsive ... both tests are with pf disabled ... sysctl kern.pool_debug=0 net.inet.ip.forwarding=1 net.inet.ip.ifq.maxlen=8192 ddb.console=1
Re: minor release of libxcb (1.11.1)
On Tue, Sep 29, 2015 at 01:34:03PM +0100, Stuart Henderson wrote: > On 2015/09/29 14:27, Peter Hessler wrote: > > On 2015 Sep 28 (Mon) at 22:23:49 +0200 (+0200), Matthieu Herrb wrote: > > :On Wed, Sep 16, 2015 at 02:37:38AM -0600, David Coppa wrote: > > :> > > :> Hi! > > :> > > :> Here's an update to libxcb-1.11.1 > > :> > > :> Changes: > > :> > > :> - Expose 64-bit sequence numbers for XLib > > :> - Call _xcb_wake_up_next_reader from xcb_wait_for_special_event > > :> - Fix a thread hang with xcb_wait_for_special_event() > > :> > > :> Tested in a full xenocara rebuild on amd64. > > :> I think a minor crank is required. > > : > > :The diff looks ok, but we currently don't have anything in xenocara > > :using the new functions. Do you know any application in ports that > > :would use it if available ? > > : > > > > Is it that painful to bump a library minor? I think we should always be > > safe and bump even when we don't know if it would be used. > > Oh I was assuming this related to testing rather than bumps. Yes a bump > is necessary, it's not about what current ports do, but about what future > updates might start using. Yes I was referring to testing. Of course a minor bump is needed. In the mean time I read the code a bit more. I was wrong, the new code is used indeed by the old API too. So it is tested if you run normal X applications. so ok matthieu@. -- Matthieu Herrb pgpIrLqDJg5eT.pgp Description: PGP signature
Re: [patch] cleaner checksum modification for pf
* Alexandr Nedvedicky [2015-09-29 12:17]: > I have not looked at current checksum handling at PF on OpenBSD, so can't tell > exactly what's going on there. I feel PF does not bother too much with > updating > the checksum, when it changes the packet. It seems to me the > in_proto_cksum_out() gets called as soon as outbound packet gets inspected by > pf_test() to calculate/fix checksums. It looks like in_proto_cksum_out() has > to > recalculate checksum in SW for entire packet, when underlying HW does not > offer > checksum offload. Is that right? Or am I missing some piece? Basically. Packets that are modified by pf or are locally originated get "needs checksumming" flags (there are a few actually). in_proto_cksum_out basically emulates the hw cksum engine if we don't have one. I consider having one the norm these days. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual & Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: D-Link DSR octeon-based models
On 09/29/15 14:38, Paul Irofti wrote: On Mon, Sep 14, 2015 at 04:52:07PM +0200, Alexis de BRUYN wrote: Hi Paul, I have tried the last -current/octeon (and 5.7/octeon) on a D-Link DSR-500N (HW A1), but the bootoctlinux command failed. Regards, Wow, a reply to a one and a half year-old email! :-) Yes thanks for your answer! I think you need to clean the randomdata section from your kernel because we don't have a native bootloader for Octeon. $ objcopy -R .openbsd.randomdata bsd bsd.tmp && mv bsd.tmp bsd Shoudn't I do this on a bsd.rd instead? I have got the following error: $ objcopy -R .openbsd.randomdata bsd bsd.tmp objcopy: Unable to recognise the format of the input file `bsd' I am running objcopy on a -current/amd64 machine with the last octeon bsd.rd snapshot. -- Alexis de BRUYN
Re: D-Link DSR octeon-based models
On Mon, Sep 14, 2015 at 04:52:07PM +0200, Alexis de BRUYN wrote: > Hi Paul, > > I have tried the last -current/octeon (and 5.7/octeon) on a D-Link DSR-500N > (HW A1), but the bootoctlinux command failed. > > Regards, Wow, a reply to a one and a half year-old email! :-) I think you need to clean the randomdata section from your kernel because we don't have a native bootloader for Octeon. $ objcopy -R .openbsd.randomdata bsd bsd.tmp && mv bsd.tmp bsd > > U-Boot 1.1.1 (Development build, svnversion: exported) (Build time: Sep 1 > 2010 - 16:21:09) > > Warning: Board descriptor tuple not found in eeprom, using defaults > CUST_DSR500N board revision major:2, minor:0, serial #: unknown > OCTEON CN5010-SCP pass 1.1, Core clock: 300 MHz, DDR clock: 200 MHz (400 Mhz > data rate) > DRAM: 128 MB > Flash: 32 MB > Clearing DRAM.. done > BIST check passed. > Starting PCI > PCI Status: PCI 32-bit > PCI BAR 0: 0x, PCI BAR 1: Memory 0x PCI 0xf800 > Net: octeth0, octeth1, octeth2 > > Hit any key to stop autoboot: 0 > D-Link DSR-500N bootloader# dhcp > Interface 0 has 3 ports (RGMII) > BOOTP broadcast 1 > octeth0: Up 1000 Mbps Full duplex (port 0) > *** Unhandled DHCP Option in OFFER/ACK: 28 > *** Unhandled DHCP Option in OFFER/ACK: 42 > *** Unhandled DHCP Option in OFFER/ACK: 28 > *** Unhandled DHCP Option in OFFER/ACK: 42 > DHCP client bound to address 192.168.0.39 > D-Link DSR-500N bootloader# tftpboot 0 bsd.rd > Using octeth0 device > TFTP from server 192.168.0.236; our IP address is 192.168.0.39 > Filename 'bsd.rd'. > Load address: 0x550 > Loading: # > done > Bytes transferred = 7548970 (73302a hex), 3311 Kbytes/sec > D-Link DSR-500N bootloader# bootoctlinux > ELF file is 64 bit > Attempting to allocate memory for ELF segment: addr: 0x8100 > (adjusted to: 0x0100), size 0x764600 > Allocated memory for ELF segment: addr: 0x8100, size 0x764600 > Attempting to allocate memory for ELF segment: addr: 0x816ec790 > (adjusted to: 0x016ec790), size 0x2400 > Error allocating memory for elf image! > ## ERROR loading File! > > > On 02/13/14 11:52, Paul Irofti wrote: > >Hi there, > > > >I just updated the hardware section for the octeon port and added the > >DSR-500 model to the supported list. > > > >I was wondering if similar models might also work with what's in-tree. > > > >Could people NFS-boot or at least try the ramdisk kernel on similar > >models (e.g. DSR-500N, DSR-1000, DSR-1000N) and report back so we can > >expand the supported list? > > > >Thank you, > >Paul > > > > -- > Alexis de BRUYN
Re: minor release of libxcb (1.11.1)
On 2015/09/29 14:27, Peter Hessler wrote: > On 2015 Sep 28 (Mon) at 22:23:49 +0200 (+0200), Matthieu Herrb wrote: > :On Wed, Sep 16, 2015 at 02:37:38AM -0600, David Coppa wrote: > :> > :> Hi! > :> > :> Here's an update to libxcb-1.11.1 > :> > :> Changes: > :> > :> - Expose 64-bit sequence numbers for XLib > :> - Call _xcb_wake_up_next_reader from xcb_wait_for_special_event > :> - Fix a thread hang with xcb_wait_for_special_event() > :> > :> Tested in a full xenocara rebuild on amd64. > :> I think a minor crank is required. > : > :The diff looks ok, but we currently don't have anything in xenocara > :using the new functions. Do you know any application in ports that > :would use it if available ? > : > > Is it that painful to bump a library minor? I think we should always be > safe and bump even when we don't know if it would be used. Oh I was assuming this related to testing rather than bumps. Yes a bump is necessary, it's not about what current ports do, but about what future updates might start using.
Re: minor release of libxcb (1.11.1)
On 2015 Sep 28 (Mon) at 22:23:49 +0200 (+0200), Matthieu Herrb wrote: :On Wed, Sep 16, 2015 at 02:37:38AM -0600, David Coppa wrote: :> :> Hi! :> :> Here's an update to libxcb-1.11.1 :> :> Changes: :> :> - Expose 64-bit sequence numbers for XLib :> - Call _xcb_wake_up_next_reader from xcb_wait_for_special_event :> - Fix a thread hang with xcb_wait_for_special_event() :> :> Tested in a full xenocara rebuild on amd64. :> I think a minor crank is required. : :The diff looks ok, but we currently don't have anything in xenocara :using the new functions. Do you know any application in ports that :would use it if available ? : Is it that painful to bump a library minor? I think we should always be safe and bump even when we don't know if it would be used. -- We gave you an atomic bomb, what do you want, mermaids? -- I. I. Rabi to the Atomic Energy Commission
Re: minor release of libxcb (1.11.1)
On 2015/09/29 13:53, David Coppa wrote: > > The diff looks ok, but we currently don't have anything in xenocara > > using the new functions. Do you know any application in ports that > > would use it if available ? > > I don't know, I've just followed the "rule" new functions->minor bump. > > Maybe Stuart can grep the ports tree with ag... > > The new functions are: > > uint64_t xcb_send_request64(xcb_connection_t *c, int flags, struct > iovec *vector, const xcb_protocol_request_t *request); > > void *xcb_wait_for_reply64(xcb_connection_t *c, uint64_t request, > xcb_generic_error_t **e); > > int xcb_poll_for_reply64(xcb_connection_t *c, uint64_t request, void > **reply, xcb_generic_error_t **error); I don't see anything.
Re: minor release of libxcb (1.11.1)
On Mon, Sep 28, 2015 at 10:23 PM, Matthieu Herrb wrote: > On Wed, Sep 16, 2015 at 02:37:38AM -0600, David Coppa wrote: >> >> Hi! >> >> Here's an update to libxcb-1.11.1 >> >> Changes: >> >> - Expose 64-bit sequence numbers for XLib >> - Call _xcb_wake_up_next_reader from xcb_wait_for_special_event >> - Fix a thread hang with xcb_wait_for_special_event() >> >> Tested in a full xenocara rebuild on amd64. >> I think a minor crank is required. > > The diff looks ok, but we currently don't have anything in xenocara > using the new functions. Do you know any application in ports that > would use it if available ? I don't know, I've just followed the "rule" new functions->minor bump. Maybe Stuart can grep the ports tree with ag... The new functions are: uint64_t xcb_send_request64(xcb_connection_t *c, int flags, struct iovec *vector, const xcb_protocol_request_t *request); void *xcb_wait_for_reply64(xcb_connection_t *c, uint64_t request, xcb_generic_error_t **e); int xcb_poll_for_reply64(xcb_connection_t *c, uint64_t request, void **reply, xcb_generic_error_t **error); Ciao! David
Re: [patch] cleaner checksum modification for pf
Hello, I've tried Richard's patch on sparc. I took a brief look at its source code. It's essentially what PF is doing on Solaris. The checksum handling in PF on systems with HW assisted checksums is getting tricky for local (out)bound packets. The approach we take on Solaris is as follows: - for inbound packets PF always trusts HW, if HW says chksum is correct, then checksum is correct. if HW is not able to verify checksum (HW checksum verification is off), PF falls back to SW verification (1) - PF does not check (verify) checksum for outbound packets, outbound packet is either - forwarded, so checksum has been verified in inbound side (2a) - local outbound, then checksum is either valid or to be calculated by HW (2b) The things are getting pretty wild in 2b, when PF is doing PBR (policy based routing) on outbound packets. Consider situation when IP stack routes packet via NIC, which is able to calculate chksum in HW. IP stack sets flags and fields and passes packet to PF. PF changes interface, where packet is bound to, to NIC, which is not able to calculate checksum, so the HW-cksum flags set by IP stack are no longer valid. In this case we always revert to calculation in SW. I have not looked at current checksum handling at PF on OpenBSD, so can't tell exactly what's going on there. I feel PF does not bother too much with updating the checksum, when it changes the packet. It seems to me the in_proto_cksum_out() gets called as soon as outbound packet gets inspected by pf_test() to calculate/fix checksums. It looks like in_proto_cksum_out() has to recalculate checksum in SW for entire packet, when underlying HW does not offer checksum offload. Is that right? Or am I missing some piece? On the other hand Richard's patch adjusts checksums by delta caused by update. The adjustment is of few operations (add/and/not) on very small chunk of memory. The price should be same we pay for extra logic to decide if HW will compute chksum for us or we have to do it on our own. However we will save plenty of cycles, when we would have to revert to SW. I currently have small suggestion to improve Richard's patch. The macro in PF_ALGNMNT() in pfvar.h uses modulo: #define PF_HI (true) #define PF_LO (!PF_HI) #define PF_ALGNMNT(off) (((off) % 2) == 0 ? PF_HI : PF_LO) I think we can get away with simple and operation (& 1), which will be faster than % on many platforms. #define PF_ALGNMNT(off) (((off) & 1) == 0 ? PF_HI : PF_LO) regards sasha
relayd maintainance diff for OpenBSD 5.7
OpenBSD 5.7 errata: http://www.openbsd.org/errata57.html#015_relayd 015: RELIABILITY FIX: September 28, 2015 All architectures Various problems were identified in relayd and merged back from current to 5.7 in this maintanance update. This patch is for 5.7 only, it fixes reliability problems that where identified during the OpenBSD 5.8 release cycle.
