Re: usb_init_task(9): correct type
On 1/16/21 8:00 AM, Anton Lindqvist wrote: Hi, The usb_init_task(9) macro accepts a `struct usb_task'. If it's macro, is it even correct to show the types it accepts in it's "prototype"? Other parts of the documentation (kqueue(2) EV_SET for example) leave all types out.
Re: ugen(4) and uhidev(4) data toggle problem
Hi Marcus,
Marcus Glocker writes:
> There are a few threads going on related to problems with ugen(4) and
> uhidev(4) devices on xhci(4). This is related to the issue patrick@
> already explained; while ehci(4) can save the last data toggle state,
> xhci(4) resets it on every open/close cycle, getting out of sync with
> the device.
Is this related to the terrible contortions we go through in
src/lib/libfido2/src/hid_openbsd.c:terrible_ping_kludge? Same code
is also included into firefox and our chromium to get fido(4) to work.
Security keys work no better or worse with your patch. If you believe
there's a chance to remove terrible_ping_kludge, I'll try.
> This diff addresses a possible solution for ugen(4) and uhidev(4).
> For ugen(4) we already did some positive testing related to scanner
> devices, see e.g.:
>
> https://marc.info/?l=openbsd-bugs&m=161056827312265&w=2
>
> I would appreciate some regression testing and feedback. On xhci(4)
> it might resolve issues related to that, and on ehci(4) it shouldn't
> break your existing setup.
I tested with xhci. Other than this message I see no changes in behavior:
uhidev_clear_iface_eps: clear endpoints failed 3!
uhidev_clear_iface_eps: clear endpoints failed 3!
uhidev_clear_iface_eps: clear endpoints failed 3!
To make this a little more useful, I applied a bit more diagnostics on
top of your patch:
diff --git a/sys/dev/usb/uhidev.c b/sys/dev/usb/uhidev.c
index 4ddf9425170..6296684fa8d 100644
--- a/sys/dev/usb/uhidev.c
+++ b/sys/dev/usb/uhidev.c
@@ -966,6 +966,7 @@ uhidev_clear_iface_eps(struct uhidev_softc *sc, struct
usbd_interface *iface)
usb_endpoint_descriptor_t *ed;
uint8_t xfertype;
int i;
+ int reason = 0;
/* Only clear interface endpoints when none are in use. */
if (sc->sc_ipipe || sc->sc_opipe)
@@ -973,22 +974,28 @@ uhidev_clear_iface_eps(struct uhidev_softc *sc, struct
usbd_interface *iface)
DPRINTFN(1,("%s: clear interface eps\n", __func__));
id = usbd_get_interface_descriptor(iface);
- if (id == NULL)
+ if (id == NULL) {
+ reason = 1;
goto bad;
+ }
for (i = 0; i < id->bNumEndpoints; i++) {
ed = usbd_interface2endpoint_descriptor(iface, i);
- if (ed == NULL)
+ if (ed == NULL) {
+ reason = 2;
goto bad;
+ }
xfertype = UE_GET_XFERTYPE(ed->bmAttributes);
if (xfertype == UE_BULK || xfertype == UE_INTERRUPT) {
if (usbd_clear_endpoint_feature(sc->sc_udev,
- ed->bEndpointAddress, UF_ENDPOINT_HALT))
+ ed->bEndpointAddress, UF_ENDPOINT_HALT)) {
+ reason = 3;
goto bad;
+ }
}
}
return;
bad:
- printf("%s: clear endpoints failed!\n", __func__);
+ printf("%s: clear endpoints failed %d!\n", __func__, reason);
}
dmesg with your original patch:
xhci0 at pci0 dev 20 function 0 "Intel 8 Series xHCI" rev 0x04: msi, xHCI 1.0
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00
addr 1
usb1 at ehci0: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00
addr 1
uhidev0 at uhub3 port 3 configuration 1 interface 0 "Microsoft Microsoft
3-Button Mouse with IntelliEye(TM)" rev 1.10/3.00 addr 5
uhidev0: iclass 3/1
ums0 at uhidev0: 3 buttons, Z dir
uhidev1 at uhub3 port 1 configuration 1 interface 0 "Google Inc. hg_0004" rev
2.00/1.00 addr 9
uhidev1: iclass 3/0
fido0 at uhidev1: input=64, output=64, feature=0
uhidev2 at uhub3 port 4 configuration 1 interface 0 "Kinesis Advantage2
Keyboard" rev 2.00/1.00 addr 10
uhidev2: iclass 3/1
ums1 at uhidev2: 3 buttons, Z dir
uhidev3 at uhub3 port 4 configuration 1 interface 1 "Kinesis Advantage2
Keyboard" rev 2.00/1.00 addr 10
uhidev3: iclass 3/1
ukbd0 at uhidev3: 8 variable keys, 6 key codes
uhidev4 at uhub3 port 4 configuration 1 interface 2 "Kinesis Advantage2
Keyboard" rev 2.00/1.00 addr 10
uhidev4: iclass 3/0, 2 report ids
uhid0 at uhidev4 reportid 1: input=1, output=0, feature=0
uhid1 at uhidev4 reportid 2: input=1, output=0, feature=0
uhidev_clear_iface_eps: clear endpoints failed!
uhidev_clear_iface_eps: clear endpoints failed!
uhidev_clear_iface_eps: clear endpoints failed!
uhidev5 at uhub0 port 2 configuration 1 interface 0 "Yubico Security Key by
Yubico" rev 2.00/3.33 addr 11
uhidev5: iclass 3/0
fido1 at uhidev5: input=64, output=64, feature=0
fido1 detached
uhidev5 detached
uhidev_clear_iface_eps: clear endpoints failed!
uhidev_clear_iface_eps: clear endpoints failed!
uhidev_clear_iface_eps: clear endpoints failed!
uhidev5 at uhub0 port 2 configuration 1 interface 0 "Yubico Security Key by
Yubico" rev 2.00/3.33 addr 11
uhidev5: iclass 3/0
fido1 at
Re: sysctl ip.forwarding 2
Alexander Bluhm writes:
> As documented in sysctl(2) net.inet.ip.forwarding can be 2.
...
>
> Index: netinet/ip_input.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/ip_input.c,v
> retrieving revision 1.353
> diff -u -p -r1.353 ip_input.c
> --- netinet/ip_input.c11 Jan 2021 13:28:53 - 1.353
> +++ netinet/ip_input.c15 Jan 2021 12:45:41 -
> @@ -115,7 +115,7 @@ const struct sysctl_bounded_args ipctl_v
> #ifdef MROUTING
> { IPCTL_MRTPROTO, &ip_mrtproto, 1, 0 },
> #endif
> - { IPCTL_FORWARDING, &ipforwarding, 0, 1 },
Sorry, that's my mistake. OTOH, we gained some insight into how often
this feature is used. The bug is in 6.8 and you are seem to be the first
one to notice.
Thanks
Greg
Re: all platforms: isolate hardclock(9) from statclock()
On Thu, Jan 14, 2021 at 12:46:38PM -0600, Scott Cheloha wrote: > Still need tests on these platforms: > > - alpha > - i386 > - mips64 (octeon will be sufficient) > - sgi > - sh Tested sys/kern/kern_clock.c and sys/arch/mips64/mips64/clock.c on loongson (also arch/loongson/dev/glxclk.c), octeon and sgi/IP30. sys/arch/sgi/localbus/int.c is still untested due to lack of hardware. However, unless someone has the relevant hardware right at hand, I think this particular case can be skipped.
Re: bpf_mtap_ether doesnt need to encode packet priority
ok mvs@ > On 15 Jan 2021, at 04:14, David Gwynne wrote: > > bpf should be showing what will be or has been on the wire, which is > what the ether_vtag in the mbuf has. the prio is either about to be > decoded from the tag on the wya into the stack, or has been encoded by > vlan(4) on the way out of the stack. > > ok? > > Index: bpf.c > === > RCS file: /cvs/src/sys/net/bpf.c,v > retrieving revision 1.201 > diff -u -p -r1.201 bpf.c > --- bpf.c 2 Jan 2021 07:25:42 - 1.201 > +++ bpf.c 15 Jan 2021 01:12:31 - > @@ -1444,7 +1444,6 @@ bpf_mtap_ether(caddr_t arg, const struct > #if NVLAN > 0 > struct ether_vlan_header evh; > struct m_hdr mh, md; > - uint8_t prio; > > if ((m->m_flags & M_VLANTAG) == 0) > #endif > @@ -1455,15 +1454,10 @@ bpf_mtap_ether(caddr_t arg, const struct > #if NVLAN > 0 > KASSERT(m->m_len >= ETHER_HDR_LEN); > > - prio = m->m_pkthdr.pf.prio; > - if (prio <= 1) > - prio = !prio; > - > memcpy(&evh, mtod(m, char *), ETHER_HDR_LEN); > evh.evl_proto = evh.evl_encap_proto; > evh.evl_encap_proto = htons(ETHERTYPE_VLAN); > - evh.evl_tag = htons(m->m_pkthdr.ether_vtag | > - (prio << EVL_PRIO_BITS)); > + evh.evl_tag = htons(m->m_pkthdr.ether_vtag); > > mh.mh_flags = 0; > mh.mh_data = (caddr_t)&evh; >
man: help pagers recognise HTML files as such
On rare occasions I'd like to use the following idiom to read manuals in
browsers, mostly to better readability and navigation of long sections:
MANPAGER=netsurf-gtk3 man -Thtml jq
(jq(1) has lots of examples and HTML is nicer to read when it comes to
literal input and output for example.)
My problem is that browsers fail to render HTML as such in case the
temporary file generated by mandoc(1) lack a file extension, i.e.
`$browser /tmp/man.abc123' will show literal HTML code whereas
`$browser /tmp/man.abc123.html' will actually render it.
HTML is the only output type I've encountered problem with so far.
PDF/mupdf(1) for example works fine with arbitrary file names:
MANPAGER=mupdf man -Tpdf jq
Diff below makes mandoc produce temporary files with the ".html" suffix
in case `-Thtml' was specified.
It feels a bit off to do this for HTML only, but it greatly improves
accessibility for me and is simple enough. If need be, the suffix
handling could be easily extended to cover more output types in the
future.
Feedback? Objections? OK?
Index: main.c
===
RCS file: /cvs/src/usr.bin/mandoc/main.c,v
retrieving revision 1.255
diff -u -p -r1.255 main.c
--- main.c 21 Jul 2020 15:08:48 - 1.255
+++ main.c 16 Jan 2021 09:03:09 -
@@ -824,7 +824,7 @@ process_onefile(struct mparse *mp, struc
if (outst->use_pager) {
outst->use_pager = 0;
outst->tag_files = term_tag_init(conf->output.outfilename,
- conf->output.tagfilename);
+ conf->output.tagfilename, outst->outtype == OUTT_HTML);
if ((conf->output.outfilename != NULL ||
conf->output.tagfilename != NULL) &&
pledge("stdio rpath cpath", NULL) == -1) {
Index: term_tag.c
===
RCS file: /cvs/src/usr.bin/mandoc/term_tag.c,v
retrieving revision 1.5
diff -u -p -r1.5 term_tag.c
--- term_tag.c 21 Jul 2020 15:08:49 - 1.5
+++ term_tag.c 16 Jan 2021 09:10:33 -
@@ -45,11 +45,13 @@ static struct tag_files tag_files;
* but for simplicity, create it anyway.
*/
struct tag_files *
-term_tag_init(const char *outfilename, const char *tagfilename)
+term_tag_init(const char *outfilename, const char *tagfilename, int ishtml)
{
struct sigaction sa;
int ofd; /* In /tmp/, dup(2)ed to stdout. */
int tfd;
+ char*suffix = ishtml ? ".html" : "";
+ size_t suffixlen = strlen(suffix);
ofd = tfd = -1;
tag_files.tfs = NULL;
@@ -83,9 +85,9 @@ term_tag_init(const char *outfilename, c
/* Create both temporary output files. */
if (outfilename == NULL) {
- (void)strlcpy(tag_files.ofn, "/tmp/man.XX",
- sizeof(tag_files.ofn));
- if ((ofd = mkstemp(tag_files.ofn)) == -1) {
+ (void)snprintf(tag_files.ofn, sizeof(tag_files.ofn),
+ "/tmp/man.XX%s", suffix);
+ if ((ofd = mkstemps(tag_files.ofn, suffixlen)) == -1) {
mandoc_msg(MANDOCERR_MKSTEMP, 0, 0,
"%s: %s", tag_files.ofn, strerror(errno));
goto fail;
Index: term_tag.h
===
RCS file: /cvs/src/usr.bin/mandoc/term_tag.h,v
retrieving revision 1.3
diff -u -p -r1.3 term_tag.h
--- term_tag.h 21 Jul 2020 15:08:49 - 1.3
+++ term_tag.h 16 Jan 2021 09:03:30 -
@@ -28,7 +28,7 @@ structtag_files {
};
-struct tag_files *term_tag_init(const char *, const char *);
+struct tag_files *term_tag_init(const char *, const char *, int);
voidterm_tag_write(struct roff_node *, size_t);
int term_tag_close(void);
voidterm_tag_unlink(void);
Re: 68.html: fix typo
On Fri, Jan 15, 2021 at 01:56:19AM +, Yifei ZHAN wrote: > I spotted a typo in www/68.html and this patch will fix it. Committed, thanks. > Index: 68.html > === > RCS file: /cvs/www/68.html,v > retrieving revision 1.85 > diff -u -r1.85 68.html > --- 68.html 3 Jan 2021 14:19:20 - 1.85 > +++ 68.html 14 Jan 2021 23:14:45 - > @@ -925,7 +925,7 @@ > > > To install, write install68.img or miniroot68.img to a > -USB stick, plug it into the machine and coose the OpenBSD > +USB stick, plug it into the machine and choose the OpenBSD > install menu item in Petitboot. > Refer to the instructions in INSTALL.powerpc64 for more details. > >
Re: Update model and resolution details for Loongson Lynloong
On Fri, Jan 15, 2021 at 01:38:14AM +, Yifei ZHAN wrote: > The following patches will update the hardware note file and loongson.html > with the corrent screen resolution and model details for Loongson > Lynloong. Thanks, committed with a rewrapped line in loongson.html. > Index: distrib/notes/loongson/hardware > === > RCS file: /cvs/src/distrib/notes/loongson/hardware,v > retrieving revision 1.11 > diff -u -r1.11 hardware > --- distrib/notes/loongson/hardware 10 Aug 2019 17:58:57 - 1.11 > +++ distrib/notes/loongson/hardware 15 Jan 2021 01:19:47 - > @@ -6,9 +6,9 @@ > onboard display is only supported in the video mode setup by > the firmware (usually 640x400x8), without acceleration. > > - Lemote Lynloong > + Lemote Lynloong (LM9001 and LM9002 models) > onboard audio, USB and Ethernet are supported; > - onboard display is only supported in the 1360x768x16 video mode > + onboard display is only supported in the 1368x768x16 video mode > set up by the firmware, without acceleration. > > Lemote Yeeloong (8.9" and 10.1" models) > > Index: loongson.html > === > RCS file: /cvs/www/loongson.html,v > retrieving revision 1.67 > diff -u -r1.67 loongson.html > --- loongson.html 18 Oct 2020 02:37:42 - 1.67 > +++ loongson.html 15 Jan 2021 01:01:19 - > @@ -80,8 +80,8 @@ > to the 640x400x8 video mode set up by the firmware. > href="http://zkml.lemote.com/en/products/all-in-one/2010/0311/122.html";>Lemote > Lynloong all-in-one-PC > > -All on-board devices are supported, but the framebuffer is currently limited > -to the 1360x768x16 video mode set up by the firmware. > +All on-board devices on LM9001/LM9002 are supported, but the framebuffer is > currently limited > +to the 1368x768x16 video mode set up by the firmware. > href="http://zkml.lemote.com/en/products/Notebook/2010/0310/112.html";>Lemote > Yeeloong > netbook > >
Re: loongson.html: update link for PMON repository
On Fri, Jan 15, 2021 at 12:53:35AM +, Yifei ZHAN wrote: > The following patch will update the link for PMON on loongson.html. The > existing site for PMON seems to be abandoned now and development of pmon > on loongson continues in Loongnix's git repository. Thanks, I have updated the link. > Index: loongson.html > === > RCS file: /cvs/www/loongson.html,v > retrieving revision 1.67 > diff -u -r1.67 loongson.html > --- loongson.html 18 Oct 2020 02:37:42 - 1.67 > +++ loongson.html 15 Jan 2021 00:50:52 - > @@ -21,7 +21,7 @@ > OpenBSD/loongson is a port intended to run on systems based upon the > Loongson (also known as Godson) 2E and 2F MIPS-compatible processors, > using the > -http://www.opsycon.se/PMON2000/Main";>PMON firmware and boot > loader. > +http://cgit.loongnix.org/cgit/pmon-2HSoc/";>PMON firmware and > boot loader. > > > >
Re: usb_init_task(9): correct type
On Sat, Jan 16, 2021 at 08:00:25AM +0100, Anton Lindqvist wrote: > The usb_init_task(9) macro accepts a `struct usb_task'. This matches the manuals wording The usb_init_task() macro prepares the task structure task [...] where "task" is marked up but fails to show up in the synopsis; surely just a copy/paste mistake. /usr/include/dev/usb/usbdi.h as well as all the users check out, OK kn.
