less(1): tab completion for tags
Hi, The ability to jump to a tag in less is such a powerful feature that deserves a better interface. Especially in combination with mandoc which emits tags. Here's a diff that adds tab completion for tags, similar to the existing completion for file names. Some notes about the diff: - As I read the POSIX specification for ctags[1], the pattern part in the output file must be enclosed in either // or ??. The current implementation accepts any delimiter and this behavior is kept as is but with the added requirement of a trailing delimiter to be present. - The diff is quite large but could be split up into chunks, for instance: extracting the parsetagent function as a first step. Comments and feedback are much appreciated. [1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ctags.html Index: cmd.h === RCS file: /cvs/src/usr.bin/less/cmd.h,v retrieving revision 1.10 diff -u -p -r1.10 cmd.h --- cmd.h 6 Nov 2015 15:58:01 - 1.10 +++ cmd.h 3 May 2017 14:24:37 - @@ -79,6 +79,9 @@ #defineA_EXTRA 0200 +/* Command completion modes */ +#defineCOMPL_FILE 1 +#defineCOMPL_TAG 2 /* Line editing characters */ Index: cmdbuf.c === RCS file: /cvs/src/usr.bin/less/cmdbuf.c,v retrieving revision 1.16 diff -u -p -r1.16 cmdbuf.c --- cmdbuf.c17 Sep 2016 15:06:41 - 1.16 +++ cmdbuf.c3 May 2017 14:24:38 - @@ -80,6 +80,11 @@ struct mlist mlist_shell = void * const ml_shell = (void *) &mlist_shell; /* + * Current mca completion mode. + */ +static int curr_mca_comp; + +/* * History for the current command. */ static struct mlist *curr_mlist = NULL; @@ -729,6 +734,7 @@ static int cmd_edit(int c) { int action; + int comp; int flags; #definenot_in_completion() in_completion = 0 @@ -748,6 +754,15 @@ cmd_edit(int c) */ flags |= EC_NOCOMPLETE; + /* +* Disable in_completion on completion mode change. +* This will ensure that any previous completion becomes unavailable. +*/ + comp = mca_comp(); + if (curr_mca_comp != comp) + not_in_completion(); + curr_mca_comp = comp; + action = editchar(c, flags); switch (action) { @@ -908,6 +923,19 @@ delimit_word(void) return (word); } +static char * +complete(char *s) +{ + switch (curr_mca_comp) { + case COMPL_FILE: + return (fcomplete(s)); + case COMPL_TAG: + return (tcomplete(s)); + default: + return (NULL); + } +} + /* * Set things up to enter completion mode. * Expand the word under the cursor into a list of filenames @@ -946,13 +974,13 @@ init_compl(void) c = *cp; *cp = '\0'; if (*word != openquote) { - tk_text = fcomplete(word); + tk_text = complete(word); } else { char *qword = shell_quote(word+1); if (qword == NULL) - tk_text = fcomplete(word+1); + tk_text = complete(word+1); else - tk_text = fcomplete(qword); + tk_text = complete(qword); free(qword); } *cp = c; Index: command.c === RCS file: /cvs/src/usr.bin/less/command.c,v retrieving revision 1.31 diff -u -p -r1.31 command.c --- command.c 12 Jan 2017 20:32:01 - 1.31 +++ command.c 3 May 2017 14:24:39 - @@ -104,6 +104,18 @@ in_mca(void) } /* + * Returns the completion mode for the current mca. + */ +int +mca_comp(void) +{ + if (curropt != NULL && curropt->oletter == 't') + return (COMPL_TAG); + + return (COMPL_FILE); +} + +/* * Set up the display to start a new search command. */ static void Index: funcs.h === RCS file: /cvs/src/usr.bin/less/funcs.h,v retrieving revision 1.18 diff -u -p -r1.18 funcs.h --- funcs.h 19 Jan 2016 06:14:54 - 1.18 +++ funcs.h 3 May 2017 14:24:39 - @@ -83,6 +83,7 @@ char *cmd_lastpattern(void); void init_cmdhist(void); void save_cmdhist(void); int in_mca(void); +int mca_comp(void); void dispversion(void); int getcc(void); void ungetcc(int); @@ -275,6 +276,7 @@ void psignals(void); void cleantags(void); void findtag(char *); off_t tagsearch(void); +char *tcomplete(const char *); char *nexttag(int); char *prevtag(int); int ntags(void); Index: tags.c === RCS file: /cvs/src/usr.bin/less/tags.c,v retrieving revision 1.19 diff -u -p -r1.19 tags.c --- tags.c 3 May 2017 11:59:25 - 1.19 +++ tags.c 3 May 2017 14:2
Re: vmd: interface rdomains
On Wed, May 03, 2017 at 12:06:01PM +0200, Reyk Floeter wrote: > Hi, > > the attached diff adds support for rdomains in vmd. > > In vm.conf, add an interface to a specified rdomain. local interfaces > work as expected, but the host-side routing and PF has to be done in > the non-default rdomain as well. > > vm "foo" { > local interface rdomain 1 > interface { > rdomain 2 > } > ... > } > > Or add all VM interfaces on a switch to a specified rdomain: > > switch "bar" { > rdomain 1 > ... > } > > OK? > no objections, ok mlarkin if you didn't already get to this > Reyk > > Index: usr.sbin/vmd/config.c > === > RCS file: /cvs/src/usr.sbin/vmd/config.c,v > retrieving revision 1.30 > diff -u -p -u -p -r1.30 config.c > --- usr.sbin/vmd/config.c 21 Apr 2017 07:03:26 - 1.30 > +++ usr.sbin/vmd/config.c 3 May 2017 10:02:58 - > @@ -282,6 +282,9 @@ config_setvm(struct privsep *ps, struct > } > } > > + /* non-default rdomain (requires VMIFF_RDOMAIN below) */ > + vif->vif_rdomain = vmc->vmc_ifrdomain[i]; > + > /* Set the interface status */ > vif->vif_flags = > vmc->vmc_ifflags[i] & (VMIFF_UP|VMIFF_OPTMASK); > Index: usr.sbin/vmd/parse.y > === > RCS file: /cvs/src/usr.sbin/vmd/parse.y,v > retrieving revision 1.28 > diff -u -p -u -p -r1.28 parse.y > --- usr.sbin/vmd/parse.y 3 May 2017 08:21:57 - 1.28 > +++ usr.sbin/vmd/parse.y 3 May 2017 10:02:59 - > @@ -116,7 +116,7 @@ typedef struct { > > %token INCLUDE ERROR > %token ADD BOOT DISABLE DISK DOWN ENABLE GROUP INTERFACE LLADDR LOCAL > LOCKED > -%token MEMORY NIFS OWNER PATH PREFIX SIZE SWITCH UP VM VMID > +%token MEMORY NIFS OWNER PATH PREFIX RDOMAIN SIZE SWITCH UP VM VMID > %token NUMBER > %token STRING > %type lladdr > @@ -263,6 +263,14 @@ switch_opts : disable { > | LOCKED LLADDR { > vsw->sw_flags |= VMIFF_LOCKED; > } > + | RDOMAIN NUMBER{ > + if ($2 < 0 || $2 > RT_TABLEID_MAX) { > + yyerror("invalid rdomain: %lld", $2); > + YYERROR; > + } > + vsw->sw_flags |= VMIFF_RDOMAIN; > + vsw->sw_rdomain = $2; > + } > | updown{ > if ($1) > vsw->sw_flags |= VMIFF_UP; > @@ -532,6 +540,14 @@ iface_opts : SWITCH string { > vmc.vmc_ifflags[vcp_nnics] |= VMIFF_LOCKED; > memcpy(vcp->vcp_macs[vcp_nnics], $3, ETHER_ADDR_LEN); > } > + | RDOMAIN NUMBER{ > + if ($2 < 0 || $2 > RT_TABLEID_MAX) { > + yyerror("invalid rdomain: %lld", $2); > + YYERROR; > + } > + vmc.vmc_ifflags[vcp_nnics] |= VMIFF_RDOMAIN; > + vmc.vmc_ifrdomain[vcp_nnics] = $2; > + } > | updown{ > if ($1) > vmc.vmc_ifflags[vcp_nnics] |= VMIFF_UP; > @@ -645,6 +661,7 @@ lookup(char *s) > { "memory", MEMORY }, > { "owner", OWNER }, > { "prefix", PREFIX }, > + { "rdomain",RDOMAIN }, > { "size", SIZE }, > { "switch", SWITCH }, > { "up", UP }, > Index: usr.sbin/vmd/priv.c > === > RCS file: /cvs/src/usr.sbin/vmd/priv.c,v > retrieving revision 1.8 > diff -u -p -u -p -r1.8 priv.c > --- usr.sbin/vmd/priv.c 21 Apr 2017 07:03:26 - 1.8 > +++ usr.sbin/vmd/priv.c 3 May 2017 10:02:59 - > @@ -88,6 +88,7 @@ priv_dispatch_parent(int fd, struct priv > switch (imsg->hdr.type) { > case IMSG_VMDOP_PRIV_IFDESCR: > case IMSG_VMDOP_PRIV_IFCREATE: > + case IMSG_VMDOP_PRIV_IFRDOMAIN: > case IMSG_VMDOP_PRIV_IFADD: > case IMSG_VMDOP_PRIV_IFUP: > case IMSG_VMDOP_PRIV_IFDOWN: > @@ -124,6 +125,12 @@ priv_dispatch_parent(int fd, struct priv > errno != EEXIST) > log_warn("SIOCIFCREATE"); > break; > + case IMSG_VMDOP_PRIV_IFRDOMAIN: > + strlcpy(ifr.ifr_name, vfr.vfr_name, sizeof(ifr.ifr_name)); > + ifr.ifr_rdomainid = vfr.vfr_id; > + if (ioctl(env->vmd_fd, SIOCSI
Re: arm64 lock: no userland progress, several procs in wchan "vp"
> Date: Wed, 3 May 2017 21:05:24 +0100 > From: Stuart Henderson > > On 2017/05/03 15:12, Mark Kettenis wrote: > > > Date: Wed, 3 May 2017 13:51:22 +0100 > > > From: Stuart Henderson > > > > > > On 2017/05/01 22:18, Mark Kettenis wrote: > > > > > Date: Mon, 1 May 2017 20:58:29 +0100 > > > > > From: Stuart Henderson > > > > > > > > > > Userland is non-responsive, machine is pingable, tcp connections open > > > > > but no banner from ssh. No failed pool requests. This kernel is from > > > > > today's snapshot but I saw the same with one from a couple of days > > > > > ago. Is there anything else I can get that might be useful? > > > > > > > > .. > > > > > 71034 186155 65198 0 30x11 vpperl > > > .. > > > > > > > > The diff below might fix thise. Or it might actually turn this into a > > > > hard hang... > > > > > > > > Nevertheless, could you try running with it? > > > > > > I haven't seen this happen again with your diff, and haven't seen any > > > hangs. Probably still too early to say for sure that it fixes things, > > > but it looks promising so far. > > > > Thanks. Since Dale ok'ed it and I had been running with it for a > > while already, I committed it last night. > > > > Ha. As is traditional, not long after sending that message I've hit > a hard lock - no DDB. I'm sure it wouldn't have happened if I hand't committed it ;). Could you change the PR_NOWAIT back into P_WAITOK and see if you can reproduce the hang and break into ddb? Meanwhile I'll think about what information to print once you've hit it ;).
Re: Official OpenBSD 6.1 CD !
On Wed, May 3, 2017 at 10:33 PM, Bob Beck wrote: > So. There *Is* an official OpenBSD 6.1 CD > > Just One. > > If you are interested, please bid on ebay : > > http://www.ebay.com/itm/The-only-Official-OpenBSD-6-1-CD- > set-to-be-made-For-auction-for-the-project-/252910718452? > hash=item3ae2a74df4:g:SJQAAOSwrhBZBqkd > > (It's a pretty cool little CD set!) > Fantastic idea, I hope you raise a lot of money selling it.
Official OpenBSD 6.1 CD !
So. There *Is* an official OpenBSD 6.1 CD Just One. If you are interested, please bid on ebay : http://www.ebay.com/itm/The-only-Official-OpenBSD-6-1-CD-set-to-be-made-For-auction-for-the-project-/252910718452?hash=item3ae2a74df4:g:SJQAAOSwrhBZBqkd (It's a pretty cool little CD set!)
Re: OpenBSD Errata: May 2nd, 2017
On Tue, May 02, 2017 at 10:26:02PM -0400, T.J. Townsend wrote: > Errata patches for dhcpd, vmm, LibreSSL and softraid have been released > for OpenBSD 6.1 today. > > Details can be found on this page: https://www.openbsd.org/errata61.html > > Binary updates for the amd64 and i386 platforms are also available via > the syspatch utility. Note that syspatch uses the mirror configured in > /etc/installurl, so all mirrors may not have the files yet. Hi folks. Due to a mistake in creating the syspatch archives, a multi-processor machine would not default to the MP kernel. New syspatches have been re-rolled and you're advised to revert and re-apply them (even on non-MP machines). Make sure your mirror (/etc/installurl) has the new syspatches first (dated May 3rd). As root: while true; do syspatch -r || break; done syspatch If you're running on a multi-processor machine, you may also remove the extra /bsd.mp kernel. Sorry about that and thank you all for your report and feedback. -- Antoine
Re: arm64 lock: no userland progress, several procs in wchan "vp"
On 2017/05/03 15:12, Mark Kettenis wrote: > > Date: Wed, 3 May 2017 13:51:22 +0100 > > From: Stuart Henderson > > > > On 2017/05/01 22:18, Mark Kettenis wrote: > > > > Date: Mon, 1 May 2017 20:58:29 +0100 > > > > From: Stuart Henderson > > > > > > > > Userland is non-responsive, machine is pingable, tcp connections open > > > > but no banner from ssh. No failed pool requests. This kernel is from > > > > today's snapshot but I saw the same with one from a couple of days > > > > ago. Is there anything else I can get that might be useful? > > > > > > .. > > > > 71034 186155 65198 0 30x11 vpperl > > .. > > > > > > The diff below might fix thise. Or it might actually turn this into a > > > hard hang... > > > > > > Nevertheless, could you try running with it? > > > > I haven't seen this happen again with your diff, and haven't seen any > > hangs. Probably still too early to say for sure that it fixes things, > > but it looks promising so far. > > Thanks. Since Dale ok'ed it and I had been running with it for a > while already, I committed it last night. > Ha. As is traditional, not long after sending that message I've hit a hard lock - no DDB.
Re: what does "internet stream tcp 0x0 *:0" mean?
On 2017/05/03 10:33, Stuart Henderson wrote: > I've got an amd64 web app server running 6.0/tomcat 7.0/jdk 1.8. > Occasionally I get a lot of FDs building up, looking like this in > fstat: > > $ fstat | grep internet.stream.tcp | head -1500 |tail -5 > _tomcat java 88950 1585* internet stream tcp 0x0 *:0 > _tomcat java 88950 1586* internet stream tcp 0x0 *:0 > _tomcat java 88950 1587* internet stream tcp 0x0 *:0 > _tomcat java 88950 1588* internet stream tcp 0x0 *:0 > _tomcat java 88950 1589* internet stream tcp 0x0 *:0 I should add: these entries are still 0x0 if fstat is run as root. I have some on my workstation and colo server too (chrome, nginx, slrn - not just threaded things).
Re: arm64 lock: no userland progress, several procs in wchan "vp"
> Date: Wed, 3 May 2017 13:51:22 +0100 > From: Stuart Henderson > > On 2017/05/01 22:18, Mark Kettenis wrote: > > > Date: Mon, 1 May 2017 20:58:29 +0100 > > > From: Stuart Henderson > > > > > > Userland is non-responsive, machine is pingable, tcp connections open > > > but no banner from ssh. No failed pool requests. This kernel is from > > > today's snapshot but I saw the same with one from a couple of days > > > ago. Is there anything else I can get that might be useful? > > > > .. > > > 71034 186155 65198 0 30x11 vpperl > .. > > > > The diff below might fix thise. Or it might actually turn this into a > > hard hang... > > > > Nevertheless, could you try running with it? > > I haven't seen this happen again with your diff, and haven't seen any > hangs. Probably still too early to say for sure that it fixes things, > but it looks promising so far. Thanks. Since Dale ok'ed it and I had been running with it for a while already, I committed it last night.
Re: arm64 lock: no userland progress, several procs in wchan "vp"
On 2017/05/01 22:18, Mark Kettenis wrote: > > Date: Mon, 1 May 2017 20:58:29 +0100 > > From: Stuart Henderson > > > > Userland is non-responsive, machine is pingable, tcp connections open > > but no banner from ssh. No failed pool requests. This kernel is from > > today's snapshot but I saw the same with one from a couple of days > > ago. Is there anything else I can get that might be useful? > > .. > > 71034 186155 65198 0 30x11 vpperl .. > > The diff below might fix thise. Or it might actually turn this into a > hard hang... > > Nevertheless, could you try running with it? I haven't seen this happen again with your diff, and haven't seen any hangs. Probably still too early to say for sure that it fixes things, but it looks promising so far.
Re: less(1): plug memory leak
On Wed, 03 May 2017 08:03:06 +0200, Anton Lindqvist wrote: > On Mon, May 01, 2017 at 01:36:51PM +0100, Nicholas Marriott wrote: > > > > looks good, ok nicm > > Anyone willing to commit? Committed. - todd
rdate(8): correctly specify supported NTP versions
Hello tech@, On receiving a packet with unsupported versions rdate(8) says that "Received NTP version %u, need 4 or lower". This is not quite true. Supported versions are 1, 2, 3, 4 and not 0. Index: ntp.c === RCS file: /cvs/src/usr.sbin/rdate/ntp.c,v retrieving revision 1.33 diff -u -p -r1.33 ntp.c --- ntp.c 16 Jan 2015 06:40:20 - 1.33 +++ ntp.c 3 May 2017 10:26:10 - @@ -347,8 +347,8 @@ retry: if (data->version < NTP_VERSION_MIN || data->version > NTP_VERSION_MAX) { - warnx("Received NTP version %u, need %u or lower", - data->version, NTP_VERSION); + warnx("Received NTP version %u, need at least %u or at most %u", + data->version, NTP_VERSION_MIN, NTP_VERSION_MAX); return (1); }
vmd: interface rdomains
Hi, the attached diff adds support for rdomains in vmd. In vm.conf, add an interface to a specified rdomain. local interfaces work as expected, but the host-side routing and PF has to be done in the non-default rdomain as well. vm "foo" { local interface rdomain 1 interface { rdomain 2 } ... } Or add all VM interfaces on a switch to a specified rdomain: switch "bar" { rdomain 1 ... } OK? Reyk Index: usr.sbin/vmd/config.c === RCS file: /cvs/src/usr.sbin/vmd/config.c,v retrieving revision 1.30 diff -u -p -u -p -r1.30 config.c --- usr.sbin/vmd/config.c 21 Apr 2017 07:03:26 - 1.30 +++ usr.sbin/vmd/config.c 3 May 2017 10:02:58 - @@ -282,6 +282,9 @@ config_setvm(struct privsep *ps, struct } } + /* non-default rdomain (requires VMIFF_RDOMAIN below) */ + vif->vif_rdomain = vmc->vmc_ifrdomain[i]; + /* Set the interface status */ vif->vif_flags = vmc->vmc_ifflags[i] & (VMIFF_UP|VMIFF_OPTMASK); Index: usr.sbin/vmd/parse.y === RCS file: /cvs/src/usr.sbin/vmd/parse.y,v retrieving revision 1.28 diff -u -p -u -p -r1.28 parse.y --- usr.sbin/vmd/parse.y3 May 2017 08:21:57 - 1.28 +++ usr.sbin/vmd/parse.y3 May 2017 10:02:59 - @@ -116,7 +116,7 @@ typedef struct { %token INCLUDE ERROR %token ADD BOOT DISABLE DISK DOWN ENABLE GROUP INTERFACE LLADDR LOCAL LOCKED -%token MEMORY NIFS OWNER PATH PREFIX SIZE SWITCH UP VM VMID +%token MEMORY NIFS OWNER PATH PREFIX RDOMAIN SIZE SWITCH UP VM VMID %token NUMBER %token STRING %typelladdr @@ -263,6 +263,14 @@ switch_opts: disable { | LOCKED LLADDR { vsw->sw_flags |= VMIFF_LOCKED; } + | RDOMAIN NUMBER{ + if ($2 < 0 || $2 > RT_TABLEID_MAX) { + yyerror("invalid rdomain: %lld", $2); + YYERROR; + } + vsw->sw_flags |= VMIFF_RDOMAIN; + vsw->sw_rdomain = $2; + } | updown{ if ($1) vsw->sw_flags |= VMIFF_UP; @@ -532,6 +540,14 @@ iface_opts : SWITCH string { vmc.vmc_ifflags[vcp_nnics] |= VMIFF_LOCKED; memcpy(vcp->vcp_macs[vcp_nnics], $3, ETHER_ADDR_LEN); } + | RDOMAIN NUMBER{ + if ($2 < 0 || $2 > RT_TABLEID_MAX) { + yyerror("invalid rdomain: %lld", $2); + YYERROR; + } + vmc.vmc_ifflags[vcp_nnics] |= VMIFF_RDOMAIN; + vmc.vmc_ifrdomain[vcp_nnics] = $2; + } | updown{ if ($1) vmc.vmc_ifflags[vcp_nnics] |= VMIFF_UP; @@ -645,6 +661,7 @@ lookup(char *s) { "memory", MEMORY }, { "owner", OWNER }, { "prefix", PREFIX }, + { "rdomain",RDOMAIN }, { "size", SIZE }, { "switch", SWITCH }, { "up", UP }, Index: usr.sbin/vmd/priv.c === RCS file: /cvs/src/usr.sbin/vmd/priv.c,v retrieving revision 1.8 diff -u -p -u -p -r1.8 priv.c --- usr.sbin/vmd/priv.c 21 Apr 2017 07:03:26 - 1.8 +++ usr.sbin/vmd/priv.c 3 May 2017 10:02:59 - @@ -88,6 +88,7 @@ priv_dispatch_parent(int fd, struct priv switch (imsg->hdr.type) { case IMSG_VMDOP_PRIV_IFDESCR: case IMSG_VMDOP_PRIV_IFCREATE: + case IMSG_VMDOP_PRIV_IFRDOMAIN: case IMSG_VMDOP_PRIV_IFADD: case IMSG_VMDOP_PRIV_IFUP: case IMSG_VMDOP_PRIV_IFDOWN: @@ -124,6 +125,12 @@ priv_dispatch_parent(int fd, struct priv errno != EEXIST) log_warn("SIOCIFCREATE"); break; + case IMSG_VMDOP_PRIV_IFRDOMAIN: + strlcpy(ifr.ifr_name, vfr.vfr_name, sizeof(ifr.ifr_name)); + ifr.ifr_rdomainid = vfr.vfr_id; + if (ioctl(env->vmd_fd, SIOCSIFRDOMAIN, &ifr) < 0) + log_warn("SIOCSIFRDOMAIN"); + break; case IMSG_VMDOP_PRIV_IFADD: if (priv_getiftype(vfr.vfr_value, type, NULL) == -1) fatalx("%s: rejected to add interface: %s", @@ -272,6 +279,17 @@ vm_
what does "internet stream tcp 0x0 *:0" mean?
I've got an amd64 web app server running 6.0/tomcat 7.0/jdk 1.8. Occasionally I get a lot of FDs building up, looking like this in fstat: $ fstat | grep internet.stream.tcp | head -1500 |tail -5 _tomcat java 88950 1585* internet stream tcp 0x0 *:0 _tomcat java 88950 1586* internet stream tcp 0x0 *:0 _tomcat java 88950 1587* internet stream tcp 0x0 *:0 _tomcat java 88950 1588* internet stream tcp 0x0 *:0 _tomcat java 88950 1589* internet stream tcp 0x0 *:0 While I'm trying to figure out from the other side what's triggering them, does anyone have an idea what these "*:0" entries are? They don't show up in netstat. If I capture earlier fstat output and match up the FD numbers they're just outgoing connections from the web app (e.g. HTTP API fetches etc) and at some point "something" happens and they change to the "*:0" entries. $ fstat | fgrep -c "internet stream tcp 0x0 *:0" 4678 $ fstat | grep -c internet.*tcp 5031 $ netstat -anfinet | grep -c tcp 570 $ netstat -anfinet | grep tcp | cut -c70- | sort | uniq -c 166 CLOSE_WAIT 126 ESTABLISHED 4 FIN_WAIT_2 23 LISTEN 251 TIME_WAIT Any clues greatly appreciated! OpenBSD 6.0 (GENERIC.MP) #2: Mon Oct 17 10:22:47 CEST 2016 r...@stable-60-amd64.mtier.org:/binpatchng/work-binpatch60-amd64/src/sys/arch/amd64/compile/GENERIC.MP RTC BIOS diagnostic error 80 real mem = 8562929664 (8166MB) avail mem = 8298942464 (7914MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe6720 (57 entries) bios0: vendor Dell Inc. version "1.2.3" date 07/21/2011 bios0: Dell Inc. PowerEdge R210 II acpi0 at bios0: rev 2 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP SPMI ASF! HPET APIC MCFG BOOT SSDT ASPT SSDT SSDT SPCR HEST ERST BERT EINJ acpi0: wakeup devices P0P1(S4) GLAN(S0) EHC1(S4) EHC2(S4) PXSX(S4) RP01(S5) PXSX(S4) RP02(S5) PXSX(S4) RP03(S5) PXSX(S4) RP04(S5) PXSX(S4) RP05(S5) PXSX(S4) RP06(S5) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz, 3100.51 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 100MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz, 3100.02 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz, 3100.02 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz, 3100.02 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 3 (P0P1) acpiprt2 at acpi0: bus 2 (RP01) acpiprt3 at acpi0: bus -1 (RP02) acpiprt4 at acpi0: bus -1 (RP03) acpiprt5 at acpi0: bus -1 (RP04) acpiprt6 at acpi0: bus -1 (RP05) acpiprt7 at acpi0: bus -1 (RP06) acpiprt8 at acpi0: bus -1 (RP07) acpiprt9 at acpi0: bus -1 (RP08) acpiprt10 at acpi0: bus 1 (PEG0) acpiprt11 at acpi0: bus -1 (PEG1) acpiprt12 at acpi0: bus -1 (PEG2) acpiprt13 at acpi0: bus -1 (PEG3) acpicpu0 at acpi0: C3(350@104 mwait.1@0x20), C2(500@80 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(350@104 mwait.1@0x20), C2(500@80 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C3(350@104 mwait.1@0x20), C2(500@80 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C3(350@104 mwait.1@0x20), C2(500@80 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi
Re: Fix umb(4) on big-endian machines
On Wed, May 03, 2017 at 10:12:04AM +0200, Gerhard Roth wrote: > Hi, > > all MBIM values are in litte-endian encoding but somewhere in the fine > print it reads that "the addresses will be in network byte order". > > So applying letoh32() on addresses is just plain wrong. On little-endian > machines, we didn't notice since letoh32() is a no-op there. But one > big-endian ones, the driver used IP addresses in the wrong byte order. > > Cheers, > > Gerhard > ok I don't have a big-endian machine with umb(4) to test with, though. > > > Index: sys/dev/usb/if_umb.c > === > RCS file: /cvs/src/sys/dev/usb/if_umb.c,v > retrieving revision 1.11 > diff -u -p -u -p -r1.11 if_umb.c > --- sys/dev/usb/if_umb.c 18 Apr 2017 13:27:55 - 1.11 > +++ sys/dev/usb/if_umb.c 2 May 2017 14:41:32 - > @@ -1646,7 +1646,6 @@ umb_decode_ip_configuration(struct umb_s > > /* Only pick the first one */ > memcpy(&ipv4elem, data + off, sizeof (ipv4elem)); > - ipv4elem.addr = letoh32(ipv4elem.addr); > ipv4elem.prefixlen = letoh32(ipv4elem.prefixlen); > > memset(&ifra, 0, sizeof (ifra)); > @@ -1660,8 +1659,7 @@ umb_decode_ip_configuration(struct umb_s > sin->sin_len = sizeof (ifra.ifra_dstaddr); > if (avail & MBIM_IPCONF_HAS_GWINFO) { > off = letoh32(ic->ipv4_gwoffs); > - sin->sin_addr.s_addr = > - letoh32(*((uint32_t *)(data + off))); > + sin->sin_addr.s_addr = *((uint32_t *)(data + off)); > } > > sin = (struct sockaddr_in *)&ifra.ifra_mask; > @@ -1690,7 +1688,7 @@ umb_decode_ip_configuration(struct umb_s > while (n-- > 0) { > if (off + sizeof (uint32_t) > len) > break; > - val = letoh32(*((uint32_t *)(data + off))); > + val = *((uint32_t *)(data + off)); > if (i < UMB_MAX_DNSSRV) > sc->sc_info.ipv4dns[i++] = val; > off += sizeof (uint32_t); >
Fix umb(4) on big-endian machines
Hi, all MBIM values are in litte-endian encoding but somewhere in the fine print it reads that "the addresses will be in network byte order". So applying letoh32() on addresses is just plain wrong. On little-endian machines, we didn't notice since letoh32() is a no-op there. But one big-endian ones, the driver used IP addresses in the wrong byte order. Cheers, Gerhard Index: sys/dev/usb/if_umb.c === RCS file: /cvs/src/sys/dev/usb/if_umb.c,v retrieving revision 1.11 diff -u -p -u -p -r1.11 if_umb.c --- sys/dev/usb/if_umb.c18 Apr 2017 13:27:55 - 1.11 +++ sys/dev/usb/if_umb.c2 May 2017 14:41:32 - @@ -1646,7 +1646,6 @@ umb_decode_ip_configuration(struct umb_s /* Only pick the first one */ memcpy(&ipv4elem, data + off, sizeof (ipv4elem)); - ipv4elem.addr = letoh32(ipv4elem.addr); ipv4elem.prefixlen = letoh32(ipv4elem.prefixlen); memset(&ifra, 0, sizeof (ifra)); @@ -1660,8 +1659,7 @@ umb_decode_ip_configuration(struct umb_s sin->sin_len = sizeof (ifra.ifra_dstaddr); if (avail & MBIM_IPCONF_HAS_GWINFO) { off = letoh32(ic->ipv4_gwoffs); - sin->sin_addr.s_addr = - letoh32(*((uint32_t *)(data + off))); + sin->sin_addr.s_addr = *((uint32_t *)(data + off)); } sin = (struct sockaddr_in *)&ifra.ifra_mask; @@ -1690,7 +1688,7 @@ umb_decode_ip_configuration(struct umb_s while (n-- > 0) { if (off + sizeof (uint32_t) > len) break; - val = letoh32(*((uint32_t *)(data + off))); + val = *((uint32_t *)(data + off)); if (i < UMB_MAX_DNSSRV) sc->sc_info.ipv4dns[i++] = val; off += sizeof (uint32_t);