Scott Cheloha wrote:
> On Sat, May 22, 2021 at 01:35:53AM +0200, Alexander Bluhm wrote:
> > On Fri, May 21, 2021 at 02:00:54PM -0500, Scott Cheloha wrote:
> > > Given all of this, would it be better if secondary CPUs spin in
> > > panic(9) instead of trying to print anything?
> >
> > The panic c
On Mon, May 24, 2021 at 10:12:53PM -0500, Scott Cheloha wrote:
> On Sat, May 22, 2021 at 01:35:53AM +0200, Alexander Bluhm wrote:
> > On Fri, May 21, 2021 at 02:00:54PM -0500, Scott Cheloha wrote:
> > > Given all of this, would it be better if secondary CPUs spin in
> > > panic(9) instead of trying
On Sat, May 22, 2021 at 01:35:53AM +0200, Alexander Bluhm wrote:
> On Fri, May 21, 2021 at 02:00:54PM -0500, Scott Cheloha wrote:
> > Given all of this, would it be better if secondary CPUs spin in
> > panic(9) instead of trying to print anything?
>
> The panic code should be as primitive as possi
I'm working on some vio(4) stuff and found that the virtio_alloc_vq
function defined in sys/dev/pv/virtiovar.h contains a vestigal function
arg "int maxsegsize" that was inherited from the original NetBSD code
imported.
It's original use was to set a vq_maxsegsize struct member to advise
drivers o
> Date: Mon, 24 May 2021 22:37:14 +0200
> From: Peter Hessler
>
> After the recent uaudio dma fixes, I tried out audio playing on my armv7
> system. Tested on the built-in audio port on hw.product=Tinker-RK3288,
> sounds fine.
>
> OK?
>
> (N.B. 'twrget' is not a typo, even if it looks like one
After the recent uaudio dma fixes, I tried out audio playing on my armv7
system. Tested on the built-in audio port on hw.product=Tinker-RK3288,
sounds fine.
OK?
(N.B. 'twrget' is not a typo, even if it looks like one)
Index: etc/etc.armv7/MAKEDEV.md
On Mon, May 24, 2021 at 05:07:50PM BST, Theo de Raadt wrote:
> Raf Czlonka wrote:
>
> > On Mon, May 24, 2021 at 04:10:00PM BST, Theo de Raadt wrote:
> > > But does it matter?
> >
> > Did this[0] matter?
>
> If you aren't curious enough to read the Makefile, devlist2h.awk,
> usbdevs.h, and usbde
Raf Czlonka wrote:
> On Mon, May 24, 2021 at 04:10:00PM BST, Theo de Raadt wrote:
> > But does it matter?
>
> Did this[0] matter?
If you aren't curious enough to read the Makefile, devlist2h.awk,
usbdevs.h, and usbdevs_data.h to recognize the full production
of your changes (to wit, #defines AN
Ping.
On Sun, May 09, 2021 at 01:07:15PM BST, Raf Czlonka wrote:
> Hello,
>
> This is both a general question and specific example of removal of
> old users and groups.
>
> With the release of 6.7, rebound(8) got tedued[0] ;^)
> However, there were no specific instructions regarding removal of
>
Ping.
On Sun, May 16, 2021 at 07:10:22PM BST, Raf Czlonka wrote:
> Hello,
>
> During recent services(5)-related threads, I glanced over the file
> and noticed a duplicate - namely(sic!), "nameserver" is being used
> both as the a service name, as well as an alias for "domain".
>
> nameserv
On Mon, May 24, 2021 at 04:37:57PM BST, Stuart Henderson wrote:
> On 2021/05/24 16:27, Raf Czlonka wrote:
> > On Mon, May 24, 2021 at 04:10:00PM BST, Theo de Raadt wrote:
> > > But does it matter?
> >
> > Did this[0] matter?
>
> > [0]
> > https://cvsweb.openbsd.org/src/sys/dev/usb/usbdevs.diff?r
On Mon, May 24, 2021 at 04:28:36PM BST, Jonathan Gray wrote:
> On Mon, May 24, 2021 at 03:52:44PM +0100, Raf Czlonka wrote:
> > Hello,
> >
> > Pretty self-explanatory - add "SHARKOON Technologies GmbH" vendor ID.
>
> 0x1ea7 / 7847 is 'SEMITEK INTERNATIONAL (HK) HOLDING LTD.' in
> https://usb.org/
On Sun, May 23, 2021 at 09:50:46PM -0400, Dave Voutila wrote:
> Seems only right that vio.4 mention it's the driver used for the virtio
> networking device provided by vmd(8).
>
> OK?
>
ok mlarkin
>
> Index: vio.4
> ===
> RCS file: /
On 2021/05/24 16:27, Raf Czlonka wrote:
> On Mon, May 24, 2021 at 04:10:00PM BST, Theo de Raadt wrote:
> > But does it matter?
>
> Did this[0] matter?
> [0]
> https://cvsweb.openbsd.org/src/sys/dev/usb/usbdevs.diff?r1=1.698&r2=1.699&sortby=date&f=h
Yes, that one is used in a driver.
On Mon, May 24, 2021 at 08:25:04AM +0200, Claudio Jeker wrote:
> On Sun, May 23, 2021 at 10:25:38PM -0400, Dave Voutila wrote:
> > The following diff adds in virtio 1.1's VIRTIO_NET_F_MTU feature support
> > to vmd(8)'s virtio networking device. This allows for communicating an MTU
> > to the guest
On Mon, May 24, 2021 at 03:52:44PM +0100, Raf Czlonka wrote:
> Hello,
>
> Pretty self-explanatory - add "SHARKOON Technologies GmbH" vendor ID.
0x1ea7 / 7847 is 'SEMITEK INTERNATIONAL (HK) HOLDING LTD.' in
https://usb.org/sites/default/files/vendor_ids033021.pdf
>
> Regards,
>
> Raf
>
> Index
On Mon, May 24, 2021 at 04:10:00PM BST, Theo de Raadt wrote:
> But does it matter?
Did this[0] matter?
Well, in the grand scheme of things, not many things do, really.
Or is it just about the length of the vendor ID?
If the latter, then yes - a bit unfortunate that it's on the longer
side... I
> Date: Mon, 24 May 2021 15:52:44 +0100
> From: Raf Czlonka
>
> Hello,
>
> Pretty self-explanatory - add "SHARKOON Technologies GmbH" vendor ID.
Not really self-explanatory. Why do you need this? We typically
don't add strings for devices unless we need the vendor ID or device
ID in a driver.
But does it matter?
It adds sizeof pointer + 28 bytes to every OpenBSD kernel.
I have seriously considered deleting usbdevs device-naming support,
because the cost keeps growing without bound.
Raf Czlonka wrote:
> On Mon, May 24, 2021 at 04:00:20PM BST, Theo de Raadt wrote:
> > Without proof i
On Mon, May 24, 2021 at 04:00:20PM BST, Theo de Raadt wrote:
> Without proof it is required, no.
Sure - hope this will suffice.
Before:
uhidev1 at uhub3 port 2 configuration 1 interface 0 "vendor 0x1ea7 2.4G
Mouse" rev 1.10/2.00 addr 4
After:
uhidev1 at uhub3 port 2 configurat
Without proof it is required, no.
Raf Czlonka wrote:
> Hello,
>
> Pretty self-explanatory - add "SHARKOON Technologies GmbH" vendor ID.
>
> Regards,
>
> Raf
>
> Index: sys/dev/usb/usbdevs
> ===
> RCS file: /cvs/src/sys/dev/usb/u
Hello,
Pretty self-explanatory - add "SHARKOON Technologies GmbH" vendor ID.
Regards,
Raf
Index: sys/dev/usb/usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.740
diff -u -p -r1.740 usbdevs
--- sys/dev/usb/
This is useful for parsing the report descriptor with a different
tool to find issues with our HID parser.
I've found https://eleccelerator.com/usbdescreqparser/ to be
helpful.
diff --git usr.bin/usbhidctl/usbhid.c usr.bin/usbhidctl/usbhid.c
index 921f211a280..bd0b5da0222 100644
--- usr.bin/us
A bug was reported where a Kensington USB trackball didn't work
properly:
uhidev4 at uhub0 port 6 configuration 1 interface 0 "Kensington Expert
Wireless TB" rev 2.00/1.02 addr 9
uhidev4: iclass 3/1, 3 report ids
ums3 at uhidev4 reportid 1
ums3: mouse has no X report
ums4 at
When tinkering with ld.so crashes due to file corruption the other day
I tested a few changes but did not want to replace /usr/libexec/ld.so
and since recompiling executable to change their interpreter is not
always an option, I went for https://github.com/NixOS/patchelf which
allows me to manipula
25 matches
Mail list logo