Re: rpki-client: validate.c, roa.c, main.c docs
On Sun, Nov 17, 2019 at 10:25:02PM +0100, Kristaps Dzonsons wrote:
> This causes validate.c's valid_cert() doc not to lie, makes the language
> consistent with other functions, and cleans a typo.
>
> In main.c, this documents tal_load_default() (which it marks static),
> moves a #define to the top of the page, and documents it too.
>
> In roa.c, this adds documentation.
> Index: validate.c
> ===
> RCS file: /cvs/src/usr.sbin/rpki-client/validate.c,v
> retrieving revision 1.5
> diff -u -p -u -r1.5 validate.c
> --- validate.c8 Oct 2019 10:04:36 - 1.5
> +++ validate.c17 Nov 2019 21:11:02 -
> @@ -106,7 +106,7 @@ valid_ip(size_t idx, enum afi afi,
> /*
> * Authenticate a trust anchor by making sure its resources are not
> * inheriting and that the SKI is unique.
> - * Returns *authsz -1 on failure.
> + * Returns *authsz or -1 on failure.
> */
> ssize_t
> valid_ta(const char *fn, const struct auth *auths,
> @@ -167,7 +167,7 @@ valid_ski_aki(const char *fn, const stru
> /*
> * Validate a non-TA certificate: make sure its IP and AS resources are
> * fully covered by those in the authority key (which must exist).
> - * Returns the parent certificate or -1 on failure.
> + * Returns the parent index or -1 on failure.
> */
> ssize_t
> valid_cert(const char *fn, const struct auth *auths,
> @@ -232,7 +232,7 @@ valid_cert(const char *fn, const struct
> /*
> * Validate our ROA: check that the SKI is unique, the AKI exists, and
> * the IP prefix is also contained.
> - * Returns zero if not valid, non-zero if valid.
> + * Returns the parent index or -1 on failure.
> */
> ssize_t
> valid_roa(const char *fn, const struct auth *auths,
> Index: main.c
> ===
> RCS file: /cvs/src/usr.sbin/rpki-client/main.c,v
> retrieving revision 1.22
> diff -u -p -u -r1.22 main.c
> --- main.c4 Nov 2019 09:35:43 - 1.22
> +++ main.c17 Nov 2019 21:19:18 -
> @@ -42,6 +42,11 @@
> #include "extern.h"
>
> /*
> + * Maximum number of TAL files we'll load.
> + */
> +#define TALSZ_MAX 8
> +
> +/*
> * Base directory for where we'll look for all media.
> */
> #define BASE_DIR "/var/cache/rpki-client"
> @@ -1276,9 +1281,13 @@ entity_process(int proc, int rsync, stru
> }
> }
>
> -#define TALSZ_MAX 8
> -
> -size_t
> +/*
> + * Assign filenames ending in ".tal" in "/etc/rpki" into "tals",
> + * returning the number of files found and filled-in.
> + * This may be zero.
> + * Don't exceded "max" filenames.
> + */
> +static size_t
> tal_load_default(const char *tals[], size_t max)
> {
> static const char *basedir = "/etc/rpki";
> Index: roa.c
> ===
> RCS file: /cvs/src/usr.sbin/rpki-client/roa.c,v
> retrieving revision 1.6
> diff -u -p -r1.6 roa.c
> --- roa.c 16 Oct 2019 17:37:46 - 1.6
> +++ roa.c 17 Nov 2019 21:22:40 -
> @@ -450,6 +450,11 @@ roa_read(int fd)
> return p;
> }
>
> +/*
> + * Add each IP address in the ROA into the VRP tree.
> + * Updates "vrps" to be the number of VRPs and "uniqs" to be the unique
> + * number of addresses.
> + */
> void
> roa_insert_vrps(struct vrp_tree *tree, struct roa *roa, size_t *vrps,
> size_t *uniqs)
Those are also OK.
--
:wq Claudio
Re: rpki-client: remove unused variables
On Sun, Nov 17, 2019 at 10:12:15PM +0100, Kristaps Dzonsons wrote:
> This removes some unused variables from the output files.
Indeed, OK claudio@
> ? remove-unused-variables.patch
> Index: output-bird.c
> ===
> RCS file: /cvs/src/usr.sbin/rpki-client/output-bird.c,v
> retrieving revision 1.1
> diff -u -p -u -r1.1 output-bird.c
> --- output-bird.c 16 Oct 2019 17:43:29 - 1.1
> +++ output-bird.c 17 Nov 2019 20:58:47 -
> @@ -25,7 +25,6 @@ output_bird(FILE *out, struct vrp_tree *
> {
> char buf[64];
> struct vrp *v;
> - int first = 1;
>
> fprintf(out, "roa table %s {\n", tablename);
>
> Index: output-csv.c
> ===
> RCS file: /cvs/src/usr.sbin/rpki-client/output-csv.c,v
> retrieving revision 1.1
> diff -u -p -u -r1.1 output-csv.c
> --- output-csv.c 16 Oct 2019 17:43:29 - 1.1
> +++ output-csv.c 17 Nov 2019 20:58:47 -
> @@ -25,7 +25,6 @@ output_csv(FILE *out, struct vrp_tree *v
> {
> char buf[64];
> struct vrp *v;
> - int first = 1;
>
> fprintf(out, "ASN,IP Prefix,Max Length,Trust Anchor\n");
>
--
:wq Claudio
Re: rpki-client: check empty TAL file
On Sun, Nov 17, 2019 at 10:05:11PM +0100, Kristaps Dzonsons wrote:
> If tal_read_file() returns a NULL buffer, which can happen with an empty
> file or one containing only comments, the NULL value eventually
> propogates to tal_parse_buffer() where it crashes on strchr().
>
> This patch also adds/fixes documentation to the some functions,
> specifies a NUL terminator instead of zero, and removes an unused variable.
Looks good, OK claudio@
> Index: tal.c
> ===
> RCS file: /cvs/src/usr.sbin/rpki-client/tal.c,v
> retrieving revision 1.13
> diff -u -p -u -r1.13 tal.c
> --- tal.c 6 Nov 2019 08:29:03 - 1.13
> +++ tal.c 17 Nov 2019 21:02:07 -
> @@ -40,7 +40,6 @@ tal_parse_buffer(const char *fn, char *b
> char*nl, *line;
> unsigned char *b64 = NULL;
> size_t sz;
> - ssize_t linelen;
> int rc = 0, b64sz;
> struct tal *tal = NULL;
> enum rtype rp;
> @@ -134,10 +133,9 @@ out:
> }
>
> /*
> - * Parse a TAL from a file conformant to RFC 7730.
> - * Returns the encoded data or NULL on failure.
> - * Failure can be any number of things: failure to open file, allocate
> - * memory, bad syntax, etc.
> + * Parse a TAL from "buf" conformant to RFC 7730 originally from a file
> + * named "fn".
> + * Returns the encoded data or NULL on syntax failure.
> */
> struct tal *
> tal_parse(const char *fn, char *buf)
> @@ -160,11 +158,19 @@ tal_parse(const char *fn, char *buf)
> if ((p->descr = malloc(dlen + 1)) == NULL)
> err(EXIT_FAILURE, NULL);
> memcpy(p->descr, d, dlen);
> - p->descr[dlen] = 0;
> + p->descr[dlen] = '\0';
>
> return p;
> }
>
> +/*
> + * Read the file named "file" into a returned, NUL-terminated buffer.
> + * This replaces CRLF terminators with plain LF, if found, and also
> + * elides document-leading comment lines starting with "#".
> + * Files may not exceeds 4096 bytes.
> + * This function exits on failure, so it always returns a buffer with
> + * TAL data.
> + */
> char *
> tal_read_file(const char *file)
> {
> @@ -222,7 +228,8 @@ tal_read_file(const char *file)
> if (ferror(in))
> err(EXIT_FAILURE, "getline: %s", file);
> fclose(in);
> -
> + if (buf == NULL)
> + errx(EXIT_FAILURE, "%s: no data", file);
> return buf;
> }
>
--
:wq Claudio
Re: ospfd: type p2p
On Sun, Nov 17, 2019 at 12:44:44PM +0100, Remi Locherer wrote:
> On Sat, Nov 16, 2019 at 06:58:35AM +0100, Claudio Jeker wrote:
> > On Fri, Nov 15, 2019 at 06:06:42PM +0100, Remi Locherer wrote:
> > > On Mon, Nov 04, 2019 at 02:01:57PM +0200, Kapetanakis Giannis wrote:
> > > > On 25/10/2019 13:57, Remi Locherer wrote:
> > > > > Hi tech@,
> > > > >
> > > > > earlier this year I sent a diff that allowed to change an interface
> > > > > from broadcast to point-to-point.
> > > > >
> > > > > https://marc.info/?l=openbsd-tech=156132923203704=2
> > > > >
> > > > > It turned out that this was not sufficient. It made the adjacency
> > > > > come up in p2p mode (no selection of DR or BDR) but didn't set a valid
> > > > > next hop for routes learned over this p2p link. Actually the next hop
> > > > > was
> > > > > 0.0.0.0 which was never installed into the routing table.
> > > > >
> > > > > This is because for P2P interfaces the neighbor address is not taken
> > > > > from
> > > > > the received hello but from the "destination" parameter configured on
> > > > > the
> > > > > interface. Since this is not set on a broadcast interface the address
> > > > > is
> > > > > 0.0.0.0.
> > > > >
> > > > > My new diff changes this. Now also for P2P links the IP address of the
> > > > > neighbor is taken from the hello packets (src address). This on it's
> > > > > own
> > > > > would make it simpler to interfere with the routing from remote. One
> > > > > could
> > > > > send unicast ospf hello messages and potentially disrupt the routing
> > > > > setup.
> > > > > I believe I mitigated this with an additional check I committed in
> > > > > August:
> > > > > only hello messages sent to the multicast address are now processed.
> > > > >
> > > > > The config looks like this:
> > > > >
> > > > > area 0.0.0.0 {
> > > > > interface em0 {
> > > > > type p2p
> > > > > }
> > > > > }
> > > > >
> > > > > It would be nice to get test reports for this new feature (check the
> > > > > fib
> > > > > and routing table!) and also test reports with real p2p2 interfaces
> > > > > (gif
> > > > > or gre).
> > > > >
> > > > > Of course OKs are also welcome. ;-)
> > > > >
> > > > > Remi
> > > >
> > > >
> > > > Hi,
> > > >
> > > > From first test seems to work :)
> > > >
> > > > looking forward test it for IPv6 as well
> > > >
> > > > thanks
> > > >
> > > > Giannis
> > >
> > >
> > > Anyone willing to OK this?
> >
> > See inline.
> >
>
> [...]
>
> >
> > Another option is to just add this ospfe_imsg_compose_rde() to the two
> > places where the addr is updated.
>
> Right, that is actually simpler.
>
> >
> > > +
> > > + return (0);
> > > }
> > >
> > > struct nbr *
> > > Index: ospfd.c
> > > ===
> > > RCS file: /cvs/src/usr.sbin/ospfd/ospfd.c,v
> > > retrieving revision 1.108
> > > diff -u -p -r1.108 ospfd.c
> > > --- ospfd.c 16 May 2019 05:49:22 - 1.108
> > > +++ ospfd.c 23 Jun 2019 21:06:44 -
> > > @@ -911,6 +911,22 @@ merge_interfaces(struct area *a, struct
> > > if_fsm(i, IF_EVT_UP);
> > > }
> > >
> > > + if (i->p2p != xi->p2p) {
> > > + /* re-add interface to enable or disable DR election */
> > > + if (ospfd_process == PROC_OSPF_ENGINE)
> > > + if_fsm(i, IF_EVT_DOWN);
> > > + else if (ospfd_process == PROC_RDE_ENGINE)
> > > + rde_nbr_iface_del(i);
> > > + LIST_REMOVE(i, entry);
> > > + if_del(i);
> > > + LIST_REMOVE(xi, entry);
> > > + LIST_INSERT_HEAD(>iface_list, xi, entry);
> > > + xi->area = a;
> > > + if (ospfd_process == PROC_OSPF_ENGINE)
> > > + xi->state = IF_STA_NEW;
> > > + continue;
> > > + }
> >
> > This is one big hammer. Would be nice to be a bit softer, also should this
> > code be before
> > log_debug("merge_interfaces: proc %d area %s merging "
> > "interface %s", ospfd_process, inet_ntoa(a->id), i->name);
> >
> > Since it re-adds an interface. If so it should also have its own
> > log_debug(). At least I think it makes little sense to merge most of the
> > interface to just remove it and re-add it.
>
> I somehow added this with my first attempt and didn't re-evaluate. It turns
> out that a restart is actually sufficient.
>
> >
> > > +
> > > strlcpy(i->dependon, xi->dependon,
> > > sizeof(i->dependon));
> > > i->depend_ok = xi->depend_ok;
> >
> > Unrelated but I feel this code should be moved up before
> > if (i->passive != xi->passive) {
> > ...
> > }
>
> Yes, I'll send a separate diff for that later.
>
> OK for the new diff?
>
>
>
> Index: hello.c
>
re(4): set isr to the correct value
Hi, This diff sets isr to the correct value (sc->rl_intrs). While here don't assign ifp twice in the same function. Tested with: re0 at pci2 dev 0 function 0 "Realtek 8168" rev 0x15: RTL8168H/8111H (0x5400), msi, address d8:cb:8a:xx:xx:xx re0 at pci3 dev 0 function 0 "Realtek 8168" rev 0x0c: RTL8168G/8111G (0x4c00), msi, address 30:9c:23:xx:x:xx ok? Index: sys/dev/ic/re.c === RCS file: /cvs/src/sys/dev/ic/re.c,v retrieving revision 1.202 diff -u -p -u -p -r1.202 re.c --- sys/dev/ic/re.c 19 Jun 2017 09:36:27 - 1.202 +++ sys/dev/ic/re.c 18 Nov 2019 06:59:26 - @@ -1416,8 +1416,6 @@ re_txeof(struct rl_softc *sc) unsigned intidx; int free = 0; - ifp = >sc_arpcom.ac_if; - prod = sc->rl_ldata.rl_txq_prodidx; cons = sc->rl_ldata.rl_txq_considx; @@ -1955,7 +1953,7 @@ re_init(struct ifnet *ifp) * Enable interrupts. */ re_setup_intr(sc, 1, sc->rl_imtype); - CSR_WRITE_2(sc, RL_ISR, sc->rl_imtype); + CSR_WRITE_2(sc, RL_ISR, sc->rl_intrs); /* Start RX/TX process. */ CSR_WRITE_4(sc, RL_MISSEDPKT, 0);
[PATCH] src/libexec/ftpd: fix nlist with -option does not work
Hello,
At least OpenBSD-6.5 and 6.6's ftpd does not work NLIST command with any
-option like this.
ftp> nlist
150 Opening ASCII mode data connection for 'file list'.
uaa
_sysupgrade
226 Transfer complete.
ftp> nlist -LF
550 -LF: No such file or directory.
ftp>
Here is the remedy, ok?
Index: extern.h
===
RCS file: /cvs/src/libexec/ftpd/extern.h,v
retrieving revision 1.20
diff -u -p -r1.20 extern.h
--- extern.h8 May 2019 23:56:48 - 1.20
+++ extern.h18 Nov 2019 05:48:53 -
@@ -89,7 +89,7 @@ void renamecmd(char *, char *);
char *renamefrom(char *);
void reply(int, const char *, ...);
void reply_r(int, const char *, ...);
-enum ret_cmd { RET_FILE, RET_LIST };
+enum ret_cmd { RET_FILE, RET_LIST, RET_NLIST };
void retrieve(enum ret_cmd, char *);
void send_file_list(char *);
void setproctitle(const char *, ...);
Index: ftpd.c
===
RCS file: /cvs/src/libexec/ftpd/ftpd.c,v
retrieving revision 1.228
diff -u -p -r1.228 ftpd.c
--- ftpd.c 3 Jul 2019 03:24:04 - 1.228
+++ ftpd.c 18 Nov 2019 05:48:53 -
@@ -1124,7 +1124,10 @@ retrieve(enum ret_cmd cmd, char *name)
fin = fopen(name, "r");
st.st_size = 0;
} else {
- fin = ftpd_ls("-lgA", name, );
+ if (cmd == RET_NLIST)
+ fin = ftpd_ls(name, ".", );
+ else
+ fin = ftpd_ls("-lgA", name, );
st.st_size = -1;
st.st_blksize = BUFSIZ;
}
@@ -1166,7 +1169,8 @@ retrieve(enum ret_cmd cmd, char *name)
goto done;
}
}
- dout = dataconn(name, st.st_size, "w");
+ dout = dataconn((cmd == RET_NLIST) ? "file list" : name,
+ st.st_size, "w");
if (dout == NULL)
goto done;
time();
@@ -2626,7 +2630,7 @@ send_file_list(char *whichf)
*/
if (dirname[0] == '-' && *dirlist == NULL &&
transflag == 0) {
- retrieve(RET_FILE, dirname);
+ retrieve(RET_NLIST, dirname);
goto out;
}
perror_reply(550, whichf);
--
SASANO Takayoshi (JG1UAA)
Re: Support for Realtek RTL8125 2.5Gb Ethernet controller
On Mon, Nov 18, 2019 at 07:08:33AM +1000, Jonathan Matthew wrote: > > On Fri, Nov 15, 2019 at 03:44:24PM +0800, Kevin Lo wrote: > > Hi, > > > > The following diff adds support for Realtek RTL8125 chip. > > Tested with Syba SD-PEX24065. > > > > Test reports and OKs are welcome. > > I don't have hardware to test with, but I've read through this and it looks > good to me. One thing I'd suggest is using if_rxring to manage the number of > filled slots on the rx ring rather than always keeping it full. dwge(4) is a > good example of how to use it. Thanks for the review and suggestions. I'll switch to use the interface receive ring API. Regards, Kevin
Re: iwm: support 9260 devices
> Date: Sat, 16 Nov 2019 19:08:05 +0100 > From: Stefan Sperling > > On Sat, Nov 16, 2019 at 11:44:03AM -0600, joshua stein wrote: > > Awesome, thanks guys. It's working great on the 9560 on my ThinkPad > > X1C7. A speed test showed 44/18 Mbps and it continues to work fine > > after an S3 cycle. > > Great :-) > > > The firmware version string looks odd: > > > > iwm0 at pci0 dev 20 function 3 "Intel Dual Band Wireless AC 9560" rev 0x11, > > msi > > iwm0: hw rev 0x310, fw ver 34.-1169155311.0, address 90:78:41:39:57:8d > > I don't know yet what's up with that. Also happens on -17 firmware. > The number we show for -34 firmware on 8260 looks OK though. It's printed using %d; probably should use %u instead.
Re: iwm: support 9260 devices
On Sat, Nov 16, 2019 at 10:01:44PM -0800, Philip Guenther wrote: > > On Sat, Nov 16, 2019 at 8:19 AM Stefan Sperling wrote: > > > On Sat, Nov 16, 2019 at 04:51:44PM +0100, Stefan Sperling wrote: > > > This diff adds support for iwm(4) 9260 devices and hopefully 9560 > > > devices as well but I have not yet had time to test those. > > > > > > Joint work with patrick@. Some parts were lifted from FreeBSD. > > > > > > If you have the followng device in pcidump it should at least get > > > an IP address from DHCP and be able to ping: > > > 4:0:0: Intel Dual Band Wireless-AC 9260 > > > 0x: Vendor ID: 8086, Product ID: 2526 > > > > > > The firmware is not in fw_update yet. > > > In the meantime firmware can be fetched from here: > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ > > > > > > Copy these files to /etc/firmware as indicated: > > > for 9260: iwlwifi-9260-th-b0-jf-b0-34.ucode -> /etc/firmware/iwm-9260-34 > > > for 9560: iwlwifi-9000-pu-b0-jf-b0-34.ucode -> /etc/firmware/iwm-9000-34 > > > > > > Checks for regressions on already supported devices are also welcome, > > > in which case the firmware isn't needed. > > > > Better diff which fixes an Rx throughput issue which was present in > > the previous diff. > > > Looking good so far on my X1 extreme once I > added PCI_PRODUCT_INTEL_WL_9560_2 next to the _1 lines in if_iwm.c. > Awesome! Also applied jcs and guenther diffs on my X1 Extreme: iwm0 at pci0 dev 20 function 3 "Intel Dual Band Wireless AC 9560" rev 0x10, msi iwm0: hw rev 0x310, fw ver 34.3125811985.0, address 48:f1:7f:xx:xx:xx iwm(4) works perfectly. Thanks, Kevin
Re: ix(4) need support for X553
On 14.11.2019. 1:06, Stuart Henderson wrote:
> Apart from the obvious style(9) problems, can anyone give me guidance on
> how to approach this diff? I'm quite uneasy at the amount of changes but these
> nics are quite important, they're all over the place on Atom C3xxx boards
> which are pretty much the main "next step up" from APUs.
>
> I have an A2SDi-2C-HLN4F that I need to put in service soon (not so
> bothered about the ix on this box, I'm using 4xSFP+ ixl, but giving it
> a spin) - applying my merged diff (https://junkpile.org/ixgbe.diff2)
with this diff box panic while booting at starting network
ix0 at pci1 dev 0 function 0 "Intel 82599" rev 0x01: msi, address
ix1 at pci1 dev 0 function 1 "Intel 82599" rev 0x01: msi, address
em0 at pci7 dev 0 function 0 "Intel I350" rev 0x01: msi, address
em1 at pci7 dev 0 function 1 "Intel I350" rev 0x01: msi, address
net.inet.ip.forwarding: 0 -> 1
starting network
panic: attempt to execute user address 0x0 in supervisor mode
Stopped at db_enter+0x10: popq%rbp
TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
*489100 47566 0 0x3 00K ifconfig
db_enter() at db_enter+0x10
panic(81cbe37d) at panic+0x128
pageflttrap(8000224ebeb0,0) at pageflttrap+0x2db
kerntrap(8000224ebeb0) at kerntrap+0x91
alltraps_kern_meltdown() at alltraps_kern_meltdown+0x7b
0(80078000,80078000,aa0519036f37d371,80078000,8
0159300,7) at 0
ixgbe_init(80078000) at ixgbe_init+0x36
ixgbe_ioctl(80078048,8020690c,80159300) at ixgbe_ioctl+0x15a
in_ifinit(80078048,80159300,8000224ec2d0,1) at
in_ifinit+0xf3
in_ioctl_change_ifaddr(8040691a,8000224ec2c0,80078048,1) at
in_ioctl_change_ifaddr+0x350
in_ioctl(8040691a,8000224ec2c0,80078048,1) at in_ioctl+0x12e
ifioctl(fd83b36cad80,8040691a,8000224ec2c0,80004ee0) at
ifioctl+0x99e
sys_ioctl(80004ee0,8000224ec3d0,8000224ec430) at
sys_ioctl+0x3c2
syscall(8000224ec4a0) at syscall+0x389
end trace frame: 0x8000224ec520, count: 0
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports. Insufficient info makes it difficult to find and fix bugs.
ddb{0}>
ddb{0}> show registers
rdi 0x81ef0a18kprintf_mutex
rsi 0x5
rbp 0x8000224ebd40
rbx 0x8000224ebdf0
rdx 0xc800121a
rcx0x286
rax 0x1
r80x8000224ebd00
r90x8015937c
r10 0x42179c57eeeb011c
r11 0xe24334526c571546
r12 0x38
r13 0x8000224ebd50
r140x100
r15 0x81cbe37dcy_pio_rec+0x3a81
rip 0x81b1a660db_enter+0x10
cs 0x8
rflags 0x282
rsp 0x8000224ebd40
ss 0x10
db_enter+0x10: popq%rbp
ddb{0}>
dmesg
OpenBSD 6.6-current (GENERIC.MP) #5: Mon Nov 18 00:13:49 CET 2019
hrv...@r620-1.srce.hr:/sys/arch/amd64/compile/GENERIC.MP
real mem = 17115840512 (16322MB)
avail mem = 16584732672 (15816MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xcf42c000 (99 entries)
bios0: vendor Dell Inc. version "2.8.0" date 06/26/2019
bios0: Dell Inc. PowerEdge R620
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC SPCR HPET DMAR MCFG WDAT SLIC ERST HEST
BERT EINJ T
CPA PC__ SRAT SSDT
acpi0: wakeup devices PCI0(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 4 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E5-2643 v2 @ 3.50GHz, 3600.46 MHz, 06-3e-04
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,C
FLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,V
MX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLI
NE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SM
EP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 2, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 6 (application processor)
cpu1: Intel(R) Xeon(R) CPU E5-2643 v2 @ 3.50GHz, 3600.00 MHz, 06-3e-04
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,C
FLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,V
MX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLI
NE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SM
rpki-client: validate.c, roa.c, main.c docs
This causes validate.c's valid_cert() doc not to lie, makes the language
consistent with other functions, and cleans a typo.
In main.c, this documents tal_load_default() (which it marks static),
moves a #define to the top of the page, and documents it too.
In roa.c, this adds documentation.
Index: validate.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/validate.c,v
retrieving revision 1.5
diff -u -p -u -r1.5 validate.c
--- validate.c 8 Oct 2019 10:04:36 - 1.5
+++ validate.c 17 Nov 2019 21:11:02 -
@@ -106,7 +106,7 @@ valid_ip(size_t idx, enum afi afi,
/*
* Authenticate a trust anchor by making sure its resources are not
* inheriting and that the SKI is unique.
- * Returns *authsz -1 on failure.
+ * Returns *authsz or -1 on failure.
*/
ssize_t
valid_ta(const char *fn, const struct auth *auths,
@@ -167,7 +167,7 @@ valid_ski_aki(const char *fn, const stru
/*
* Validate a non-TA certificate: make sure its IP and AS resources are
* fully covered by those in the authority key (which must exist).
- * Returns the parent certificate or -1 on failure.
+ * Returns the parent index or -1 on failure.
*/
ssize_t
valid_cert(const char *fn, const struct auth *auths,
@@ -232,7 +232,7 @@ valid_cert(const char *fn, const struct
/*
* Validate our ROA: check that the SKI is unique, the AKI exists, and
* the IP prefix is also contained.
- * Returns zero if not valid, non-zero if valid.
+ * Returns the parent index or -1 on failure.
*/
ssize_t
valid_roa(const char *fn, const struct auth *auths,
Index: main.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/main.c,v
retrieving revision 1.22
diff -u -p -u -r1.22 main.c
--- main.c 4 Nov 2019 09:35:43 - 1.22
+++ main.c 17 Nov 2019 21:19:18 -
@@ -42,6 +42,11 @@
#include "extern.h"
/*
+ * Maximum number of TAL files we'll load.
+ */
+#define TALSZ_MAX 8
+
+/*
* Base directory for where we'll look for all media.
*/
#define BASE_DIR "/var/cache/rpki-client"
@@ -1276,9 +1281,13 @@ entity_process(int proc, int rsync, stru
}
}
-#define TALSZ_MAX 8
-
-size_t
+/*
+ * Assign filenames ending in ".tal" in "/etc/rpki" into "tals",
+ * returning the number of files found and filled-in.
+ * This may be zero.
+ * Don't exceded "max" filenames.
+ */
+static size_t
tal_load_default(const char *tals[], size_t max)
{
static const char *basedir = "/etc/rpki";
Index: roa.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/roa.c,v
retrieving revision 1.6
diff -u -p -r1.6 roa.c
--- roa.c 16 Oct 2019 17:37:46 - 1.6
+++ roa.c 17 Nov 2019 21:22:40 -
@@ -450,6 +450,11 @@ roa_read(int fd)
return p;
}
+/*
+ * Add each IP address in the ROA into the VRP tree.
+ * Updates "vrps" to be the number of VRPs and "uniqs" to be the unique
+ * number of addresses.
+ */
void
roa_insert_vrps(struct vrp_tree *tree, struct roa *roa, size_t *vrps,
size_t *uniqs)
rpki-client: remove unused variables
This removes some unused variables from the output files.
? remove-unused-variables.patch
Index: output-bird.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/output-bird.c,v
retrieving revision 1.1
diff -u -p -u -r1.1 output-bird.c
--- output-bird.c 16 Oct 2019 17:43:29 - 1.1
+++ output-bird.c 17 Nov 2019 20:58:47 -
@@ -25,7 +25,6 @@ output_bird(FILE *out, struct vrp_tree *
{
char buf[64];
struct vrp *v;
- int first = 1;
fprintf(out, "roa table %s {\n", tablename);
Index: output-csv.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/output-csv.c,v
retrieving revision 1.1
diff -u -p -u -r1.1 output-csv.c
--- output-csv.c 16 Oct 2019 17:43:29 - 1.1
+++ output-csv.c 17 Nov 2019 20:58:47 -
@@ -25,7 +25,6 @@ output_csv(FILE *out, struct vrp_tree *v
{
char buf[64];
struct vrp *v;
- int first = 1;
fprintf(out, "ASN,IP Prefix,Max Length,Trust Anchor\n");
Re: Support for Realtek RTL8125 2.5Gb Ethernet controller
On Fri, Nov 15, 2019 at 03:44:24PM +0800, Kevin Lo wrote: > Hi, > > The following diff adds support for Realtek RTL8125 chip. > Tested with Syba SD-PEX24065. > > Test reports and OKs are welcome. I don't have hardware to test with, but I've read through this and it looks good to me. One thing I'd suggest is using if_rxring to manage the number of filled slots on the rx ring rather than always keeping it full. dwge(4) is a good example of how to use it. > > Index: share/man/man4/Makefile > === > RCS file: /cvs/src/share/man/man4/Makefile,v > retrieving revision 1.740 > diff -u -p -u -p -r1.740 Makefile > --- share/man/man4/Makefile 4 Nov 2019 23:53:37 - 1.740 > +++ share/man/man4/Makefile 15 Nov 2019 07:24:51 - > @@ -62,7 +62,7 @@ MAN=aac.4 abcrtc.4 ac97.4 acphy.4 acrtc > pvclock.4 pwdog.4 pwmbl.4 pwmreg.4 \ > qla.4 qle.4 qlw.4 qsphy.4 \ > radio.4 ral.4 random.4 rdomain.4 rd.4 rdac.4 re.4 rdcphy.4 rgephy.4 \ > - ricohrtc.4 rkclock.4 rkdwusb.4 rkgpio.4 rkgrf.4 rkiic.4 \ > + rge.4 ricohrtc.4 rkclock.4 rkdwusb.4 rkgpio.4 rkgrf.4 rkiic.4 \ > rkpcie.4 rkpinctrl.4 rkpmic.4 rktemp.4 \ > rl.4 rlphy.4 route.4 rsu.4 rtsx.4 rum.4 run.4 \ > rtfps.4 rtw.4 rtwn.4 safe.4 safte.4 sbus.4 schsio.4 \ > Index: share/man/man4/pci.4 > === > RCS file: /cvs/src/share/man/man4/pci.4,v > retrieving revision 1.374 > diff -u -p -u -p -r1.374 pci.4 > --- share/man/man4/pci.4 26 Sep 2019 13:09:55 - 1.374 > +++ share/man/man4/pci.4 15 Nov 2019 07:24:51 - > @@ -253,6 +253,8 @@ Emulex OneConnect 10Gb Ethernet device > AMD PCnet-PCI 10/100 Ethernet device > .It Xr re 4 > Realtek 8139C+/8169/816xS/811xS/8168/810xE 10/100/Gigabit Ethernet device > +.It Xr rge 4 > +Realtek 8125 2.5Gb Ethernet device > .It Xr rl 4 > Realtek 8129/8139 10/100 Ethernet device > .It Xr se 4 > Index: share/man/man4/rge.4 > === > RCS file: share/man/man4/rge.4 > diff -N share/man/man4/rge.4 > --- /dev/null 1 Jan 1970 00:00:00 - > +++ share/man/man4/rge.4 15 Nov 2019 07:24:51 - > @@ -0,0 +1,55 @@ > +.\" $OpenBSD$ > +.\" > +.\" Copyright (c) 2019 Kevin Lo > +.\" > +.\" Permission to use, copy, modify, and distribute this software for any > +.\" purpose with or without fee is hereby granted, provided that the above > +.\" copyright notice and this permission notice appear in all copies. > +.\" > +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES > +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF > +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR > +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN > +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF > +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > +.\" > +.Dd $Mdocdate$ > +.Dt RGE 4 > +.Os > +.Sh NAME > +.Nm rge > +.Nd Realtek 8125 PCI Express 2.5Gb Ethernet device > +.Sh SYNOPSIS > +.Cd "rge* at pci?" > +.Sh DESCRIPTION > +The > +.Nm > +driver provides support for PCI Express 2.5Gb Ethernet adapters based > +on the Realtek RTL8125 Ethernet controller, including the following: > +.Pp > +.Bl -bullet -offset indent -compact > +.It > +Realtek RTL8125 2.5GbE Adapter (2500baseT) > +.It > +Rivet Networks Killer E3000 Adapter (2500baseT) > +.El > +.Sh SEE ALSO > +.Xr arp 4 , > +.Xr ifmedia 4 , > +.Xr intro 4 , > +.Xr netintro 4 , > +.Xr pci 4 , > +.Xr hostname.if 5 , > +.Xr ifconfig 8 > +.Sh HISTORY > +The > +.Nm > +driver first appeared in > +.Ox 6.7 . > +.Sh AUTHORS > +.An -nosplit > +The > +.Nm > +driver was written by > +.An Kevin Lo Aq Mt ke...@openbsd.org . > Index: sys/arch/amd64/conf/GENERIC > === > RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v > retrieving revision 1.480 > diff -u -p -u -p -r1.480 GENERIC > --- sys/arch/amd64/conf/GENERIC 26 Sep 2019 12:59:01 - 1.480 > +++ sys/arch/amd64/conf/GENERIC 15 Nov 2019 07:24:52 - > @@ -513,6 +513,7 @@ bge* at pci? # Broadcom > BCM57xx (aka > bnx* at pci? # Broadcom BCM5706/5708 GigE > re* at pci? # Realtek 8169/8169S/8110S > re* at cardbus? # Realtek 8169/8169S/8110S > +rge* at pci? # Realtek 8125 > stge*at pci? # Sundance TC9021 GigE > #lge*at pci? # Level1 LXT1001 GigE > hme* at pci? # Sun Happy Meal > Index: sys/arch/i386/conf/GENERIC > === > RCS file:
rpki-client: check empty TAL file
If tal_read_file() returns a NULL buffer, which can happen with an empty
file or one containing only comments, the NULL value eventually
propogates to tal_parse_buffer() where it crashes on strchr().
This patch also adds/fixes documentation to the some functions,
specifies a NUL terminator instead of zero, and removes an unused variable.
Index: tal.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/tal.c,v
retrieving revision 1.13
diff -u -p -u -r1.13 tal.c
--- tal.c 6 Nov 2019 08:29:03 - 1.13
+++ tal.c 17 Nov 2019 21:02:07 -
@@ -40,7 +40,6 @@ tal_parse_buffer(const char *fn, char *b
char *nl, *line;
unsigned char *b64 = NULL;
size_t sz;
- ssize_t linelen;
int rc = 0, b64sz;
struct tal *tal = NULL;
enum rtype rp;
@@ -134,10 +133,9 @@ out:
}
/*
- * Parse a TAL from a file conformant to RFC 7730.
- * Returns the encoded data or NULL on failure.
- * Failure can be any number of things: failure to open file, allocate
- * memory, bad syntax, etc.
+ * Parse a TAL from "buf" conformant to RFC 7730 originally from a file
+ * named "fn".
+ * Returns the encoded data or NULL on syntax failure.
*/
struct tal *
tal_parse(const char *fn, char *buf)
@@ -160,11 +158,19 @@ tal_parse(const char *fn, char *buf)
if ((p->descr = malloc(dlen + 1)) == NULL)
err(EXIT_FAILURE, NULL);
memcpy(p->descr, d, dlen);
- p->descr[dlen] = 0;
+ p->descr[dlen] = '\0';
return p;
}
+/*
+ * Read the file named "file" into a returned, NUL-terminated buffer.
+ * This replaces CRLF terminators with plain LF, if found, and also
+ * elides document-leading comment lines starting with "#".
+ * Files may not exceeds 4096 bytes.
+ * This function exits on failure, so it always returns a buffer with
+ * TAL data.
+ */
char *
tal_read_file(const char *file)
{
@@ -222,7 +228,8 @@ tal_read_file(const char *file)
if (ferror(in))
err(EXIT_FAILURE, "getline: %s", file);
fclose(in);
-
+ if (buf == NULL)
+ errx(EXIT_FAILURE, "%s: no data", file);
return buf;
}
Re: ospfd: type p2p
On Sat, Nov 16, 2019 at 06:58:35AM +0100, Claudio Jeker wrote:
> On Fri, Nov 15, 2019 at 06:06:42PM +0100, Remi Locherer wrote:
> > On Mon, Nov 04, 2019 at 02:01:57PM +0200, Kapetanakis Giannis wrote:
> > > On 25/10/2019 13:57, Remi Locherer wrote:
> > > > Hi tech@,
> > > >
> > > > earlier this year I sent a diff that allowed to change an interface
> > > > from broadcast to point-to-point.
> > > >
> > > > https://marc.info/?l=openbsd-tech=156132923203704=2
> > > >
> > > > It turned out that this was not sufficient. It made the adjacency
> > > > come up in p2p mode (no selection of DR or BDR) but didn't set a valid
> > > > next hop for routes learned over this p2p link. Actually the next hop
> > > > was
> > > > 0.0.0.0 which was never installed into the routing table.
> > > >
> > > > This is because for P2P interfaces the neighbor address is not taken
> > > > from
> > > > the received hello but from the "destination" parameter configured on
> > > > the
> > > > interface. Since this is not set on a broadcast interface the address is
> > > > 0.0.0.0.
> > > >
> > > > My new diff changes this. Now also for P2P links the IP address of the
> > > > neighbor is taken from the hello packets (src address). This on it's own
> > > > would make it simpler to interfere with the routing from remote. One
> > > > could
> > > > send unicast ospf hello messages and potentially disrupt the routing
> > > > setup.
> > > > I believe I mitigated this with an additional check I committed in
> > > > August:
> > > > only hello messages sent to the multicast address are now processed.
> > > >
> > > > The config looks like this:
> > > >
> > > > area 0.0.0.0 {
> > > > interface em0 {
> > > > type p2p
> > > > }
> > > > }
> > > >
> > > > It would be nice to get test reports for this new feature (check the fib
> > > > and routing table!) and also test reports with real p2p2 interfaces (gif
> > > > or gre).
> > > >
> > > > Of course OKs are also welcome. ;-)
> > > >
> > > > Remi
> > >
> > >
> > > Hi,
> > >
> > > From first test seems to work :)
> > >
> > > looking forward test it for IPv6 as well
> > >
> > > thanks
> > >
> > > Giannis
> >
> >
> > Anyone willing to OK this?
>
> See inline.
>
[...]
>
> Another option is to just add this ospfe_imsg_compose_rde() to the two
> places where the addr is updated.
Right, that is actually simpler.
>
> > +
> > + return (0);
> > }
> >
> > struct nbr *
> > Index: ospfd.c
> > ===
> > RCS file: /cvs/src/usr.sbin/ospfd/ospfd.c,v
> > retrieving revision 1.108
> > diff -u -p -r1.108 ospfd.c
> > --- ospfd.c 16 May 2019 05:49:22 - 1.108
> > +++ ospfd.c 23 Jun 2019 21:06:44 -
> > @@ -911,6 +911,22 @@ merge_interfaces(struct area *a, struct
> > if_fsm(i, IF_EVT_UP);
> > }
> >
> > + if (i->p2p != xi->p2p) {
> > + /* re-add interface to enable or disable DR election */
> > + if (ospfd_process == PROC_OSPF_ENGINE)
> > + if_fsm(i, IF_EVT_DOWN);
> > + else if (ospfd_process == PROC_RDE_ENGINE)
> > + rde_nbr_iface_del(i);
> > + LIST_REMOVE(i, entry);
> > + if_del(i);
> > + LIST_REMOVE(xi, entry);
> > + LIST_INSERT_HEAD(>iface_list, xi, entry);
> > + xi->area = a;
> > + if (ospfd_process == PROC_OSPF_ENGINE)
> > + xi->state = IF_STA_NEW;
> > + continue;
> > + }
>
> This is one big hammer. Would be nice to be a bit softer, also should this
> code be before
> log_debug("merge_interfaces: proc %d area %s merging "
> "interface %s", ospfd_process, inet_ntoa(a->id), i->name);
>
> Since it re-adds an interface. If so it should also have its own
> log_debug(). At least I think it makes little sense to merge most of the
> interface to just remove it and re-add it.
I somehow added this with my first attempt and didn't re-evaluate. It turns
out that a restart is actually sufficient.
>
> > +
> > strlcpy(i->dependon, xi->dependon,
> > sizeof(i->dependon));
> > i->depend_ok = xi->depend_ok;
>
> Unrelated but I feel this code should be moved up before
> if (i->passive != xi->passive) {
> ...
> }
Yes, I'll send a separate diff for that later.
OK for the new diff?
Index: hello.c
===
RCS file: /cvs/src/usr.sbin/ospfd/hello.c,v
retrieving revision 1.24
diff -u -p -r1.24 hello.c
--- hello.c 12 Aug 2019 20:21:58 - 1.24
+++ hello.c 16 Nov 2019 14:52:10 -
@@ -191,12 +191,16 @@ recv_hello(struct iface *iface, struct i
nbr->priority = hello.rtr_priority;
XHCI support for bulk xfers >64k
While recently testing UDL on XHCI I faced a lot of USB timeouts, and
therefore screen rendering issues.
The reason is that XHCI currently only supports single bulk transfers
up to 64k, while UDL can schedule a bulk transfer up to 1m.
The following diff adds XHCI bulk transfer support >64k and makes UDL
work fine for me on XHCI.
mpi@ already did an initial re-view, and I have adapted some of his
comments already in this diff.
More testing and comments welcome.
Index: xhci.c
===
RCS file: /cvs/src/sys/dev/usb/xhci.c,v
retrieving revision 1.106
diff -u -p -u -p -r1.106 xhci.c
--- xhci.c 6 Oct 2019 17:30:00 - 1.106
+++ xhci.c 17 Nov 2019 11:22:22 -
@@ -816,9 +816,29 @@ xhci_event_xfer_generic(struct xhci_soft
uint8_t code, uint8_t slot, uint8_t dci)
{
struct xhci_xfer *xx = (struct xhci_xfer *)xfer;
-
+ int trb0_idx;
+
switch (code) {
case XHCI_CODE_SUCCESS:
+ if (trb_idx == 0)
+ trb0_idx = xp->ring.ntrb - 2;
+ else
+ trb0_idx = trb_idx - 1;
+
+ if (xp->ring.trbs[trb0_idx].trb_flags & XHCI_TRB_CHAIN) {
+ xfer->actlen += XHCI_TRB_LEN(xp->ring.trbs[trb0_idx].
+ trb_status) - remain;
+ }
+ xfer->actlen += XHCI_TRB_LEN(xp->ring.trbs[trb_idx].
+ trb_status) - remain;
+
+ DPRINTF(("XHCI_CODE_SUCCESS: "
+ "index=%d, trb_idx=%d, actlen=%d, length=%d, remain=%d\n"
+ xx->index, trb_idx, xfer->actlen, xfer->length, remain));
+
+ if (xx->index != trb_idx)
+ return (1);
+
/*
* This might be the last TRB of a TD that ended up
* with a Short Transfer condition, see below.
@@ -2856,68 +2876,93 @@ xhci_device_generic_start(struct usbd_xf
struct xhci_trb *trb0, *trb;
uint32_t len, remain, flags;
uint32_t mps = UGETW(xfer->pipe->endpoint->edesc->wMaxPacketSize);
- uint64_t paddr = DMAADDR(>dmabuf, 0);
+ uint64_t paddr;
uint8_t toggle;
- int s, i, ntrb;
+ int s, i, j, ntrb;
+ int chlengths[XHCI_MAX_BULK_CHUNKS];
+ int nchunks;
KASSERT(!(xfer->rqflags & URQ_REQUEST));
if (sc->sc_bus.dying || xp->halted)
return (USBD_IOERROR);
- /* How many TRBs do we need for this transfer? */
- ntrb = howmany(xfer->length, XHCI_TRB_MAXSIZE);
+ /* Split the payload in chunks of XHCI_TRB_MAXSIZE. */
+ nchunks = xfer->length / XHCI_TRB_MAXSIZE;
+ remain = xfer->length % XHCI_TRB_MAXSIZE;
- /* If the buffer crosses a 64k boundary, we need one more. */
- len = XHCI_TRB_MAXSIZE - (paddr & (XHCI_TRB_MAXSIZE - 1));
- if (len < xfer->length)
- ntrb++;
- else
- len = xfer->length;
+ if ((nchunks + (remain ? 1 : 0)) >= XHCI_MAX_BULK_CHUNKS)
+ return (USBD_NOMEM);
- /* If we need to append a zero length packet, we need one more. */
- if ((xfer->flags & USBD_FORCE_SHORT_XFER || xfer->length == 0) &&
- (xfer->length % UE_GET_SIZE(mps) == 0))
- ntrb++;
+ for (i = 0; i < nchunks; i++)
+ chlengths[i] = XHCI_TRB_MAXSIZE;
+ if (remain != 0) {
+ chlengths[i++] = remain;
+ nchunks++;
+ }
+
+ paddr = DMAADDR(>dmabuf, 0);
+
+ /* How many TRBs do for all Transfers? */
+ for (i = 0, ntrb = 0; i < nchunks; i++) {
+ /* How many TRBs do we need for this transfer? */
+ ntrb += howmany(chlengths[i], XHCI_TRB_MAXSIZE);
+
+ /* If the buffer crosses a 64k boundary, we need one more. */
+ len = XHCI_TRB_MAXSIZE - (paddr & (XHCI_TRB_MAXSIZE - 1));
+ if (len < chlengths[i])
+ ntrb++;
+
+ /* If we need to append a zero length packet, we need 1 more. */
+ if ((xfer->flags & USBD_FORCE_SHORT_XFER || xfer->length == 0)
+ && (xfer->length % UE_GET_SIZE(mps) == 0))
+ ntrb++;
+
+ paddr += chlengths[i];
+}
if (xp->free_trbs < ntrb)
return (USBD_NOMEM);
- /* We'll toggle the first TRB once we're finished with the chain. */
- trb0 = xhci_xfer_get_trb(sc, xfer, , (ntrb == 1));
- flags = XHCI_TRB_TYPE_NORMAL | (toggle ^ 1);
- if (usbd_xfer_isread(xfer))
- flags |= XHCI_TRB_ISP;
- flags |= (ntrb == 1) ? XHCI_TRB_IOC : XHCI_TRB_CHAIN;
-
- trb0->trb_paddr = htole64(DMAADDR(>dmabuf, 0));
- trb0->trb_status = htole32(
- XHCI_TRB_INTR(0) | XHCI_TRB_LEN(len) |
- xhci_xfer_tdsize(xfer, xfer->length, len)
- );
- trb0->trb_flags = htole32(flags);
Re: [PATCH] [src] bin/ed/README - fix quote/comma
On Sun, Nov 17, 2019 at 10:23:38AM GMT, Otto Moerbeek wrote: > On Sun, Nov 17, 2019 at 08:31:00AM +, Raf Czlonka wrote: > > > Hi all, > > > > Pretty straightforward - comma snuck in inside the quoted book title. > > This is how I learned it. Myabe a bit old-fashinoed, but not wrong. > > -Otto Hi Otto, Unless I'm misunderstanding CMOS (i.e. american style), comma would indeed be *inside* quotes, when we are actually "using" quotes, i.e. quoting text, or quotes are a part of a boot title itself. Here, however, quotes are used *instead of* italics to represent the book title itself, so, i.e. in print, they wouldn't be present at all. The below is a bibliographical reference (of sorts) so the comma should merely separate the book title from the publisher. Unfortunately, the finer details of CMOS are behind a paywall so I can't confirm that categorically. Chances are, I might be wrong, though. In which case, I'd appreciate pointing me to the source :^) Cheers, Raf > > > > > Regards, > > > > Raf > > > > Index: bin/ed/README > > === > > RCS file: /cvs/src/bin/ed/README,v > > retrieving revision 1.5 > > diff -u -p -r1.5 README > > --- bin/ed/README 15 Jun 2018 08:46:24 - 1.5 > > +++ bin/ed/README 17 Nov 2019 08:29:14 - > > @@ -16,4 +16,4 @@ The ./test directory contains regression > > file in that directory explains how to run these. > > > > For a description of the ed algorithm, see Kernighan and Plauger's book > > -"Software Tools in Pascal," Addison-Wesley, 1981. > > +"Software Tools in Pascal", Addison-Wesley, 1981. > >
Re: [PATCH] [src] bin/ed/README - fix quote/comma
On Sun, Nov 17, 2019 at 08:31:00AM +, Raf Czlonka wrote: > Hi all, > > Pretty straightforward - comma snuck in inside the quoted book title. This is how I learned it. Myabe a bit old-fashinoed, but not wrong. -Otto > > Regards, > > Raf > > Index: bin/ed/README > === > RCS file: /cvs/src/bin/ed/README,v > retrieving revision 1.5 > diff -u -p -r1.5 README > --- bin/ed/README 15 Jun 2018 08:46:24 - 1.5 > +++ bin/ed/README 17 Nov 2019 08:29:14 - > @@ -16,4 +16,4 @@ The ./test directory contains regression > file in that directory explains how to run these. > > For a description of the ed algorithm, see Kernighan and Plauger's book > -"Software Tools in Pascal," Addison-Wesley, 1981. > +"Software Tools in Pascal", Addison-Wesley, 1981. >
[PATCH] [src] bin/ed/README - fix quote/comma
Hi all, Pretty straightforward - comma snuck in inside the quoted book title. Regards, Raf Index: bin/ed/README === RCS file: /cvs/src/bin/ed/README,v retrieving revision 1.5 diff -u -p -r1.5 README --- bin/ed/README 15 Jun 2018 08:46:24 - 1.5 +++ bin/ed/README 17 Nov 2019 08:29:14 - @@ -16,4 +16,4 @@ The ./test directory contains regression file in that directory explains how to run these. For a description of the ed algorithm, see Kernighan and Plauger's book -"Software Tools in Pascal," Addison-Wesley, 1981. +"Software Tools in Pascal", Addison-Wesley, 1981.
