Hello,
The following diff enables FIDO/U2F keys on riscv64.
I've tested this with a Yubikey 5 Nano and was able to successfully
generate an ed25519-sk key pair with ssh-keygen (which is my usecase):
icarus$ uname -a
OpenBSD icarus.fagg.id.au 7.0 GENERIC.MP#1 riscv64
icarus$ ssh-keygen -t
Stuart Henderson writes:
> That FreeBSD commit prevents using their "hw.ahci.force" tunable on the
> device, it's used for attaching as AHCI to certain known chips even if
> they're set in legacy IDE mode.
>
> Does it work to just add the vid/pid to the ahci_devices[] array
> without a specific
The following diffs adds iwm(4) to the riscv64 kernel config.
I tested this with the following device:
iwm0 at pci5 dev 0 function 0 "Intel Dual Band Wireless-AC 9260" rev 0x29, intx
icarus$ ifconfig iwm0
iwm0: flags=808843 mtu 1500
lladdr bc:54:2f:cb:3b:21
index 2 priority 4
I have two devices here based on the JMicron JMB585 chipset. This diff
adds the required pcidev IDs and sets disables native command queuing in
the driver. FreeBSD does something similar for this device:
https://github.com/freebsd/freebsd-src/commit/16b766eed443043f4216d50e40ba283e74f992c2
I've
Jonathan Matthew writes:
> Yes, on second look that makes sense. Here's a better diff with that
> change, and that also doesn't break arches without __HAVE_PCI_MSIX.
> ok?
Jonathan/Mark,
Thank you for your help here.
Just confirming that does indeed work for me.
Any chance the other part of
Friendly ping.
Ashton Fagg writes:
> I have been working on fixing an issue (which was partially fixed by a
> diff I sent in earlier this year) with iscsid. With iscsi disks in
> /etc/fstab, sometimes the devices aren't fully up and ready before fsck
> tries to run - causing the m
Found this while poking around - an extra newline in if_iwx.c.
Index: sys/dev/pci/if_iwx.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwx.c,v
retrieving revision 1.69
diff -u -p -u -p -r1.69 if_iwx.c
--- sys/dev/pci/if_iwx.c 18 Jul 2021
I have an Intel 82599 10 gigabit ethernet card I wanted to get working
on my SiFive Unmatched board.
I found the ix(4) driver has some weirdness around MSI-X
interrupts. While the driver supports operating both with and without
MSI-X support, it's hard-coded via a flag rather than dynamically
Friendly weekly ping. Patches reattached.
- ajf
Ashton Fagg writes:
> I have been working on fixing an issue (which was partially fixed by a
> diff I sent in earlier this year) with iscsid. With iscsi disks in
> /etc/fstab, sometimes the devices aren't fully up and ready before fsc
Friendly weekly ping.
Ashton Fagg writes:
> Original thread and discussion here:
>
> https://marc.info/?l=openbsd-tech=162000231914017=2
>
> I started this a couple of months ago but realized I never actually
> finished this and submitted the full diff. So here it is, fo
Ping again. Diffs re-attached below.
Ashton Fagg writes:
> Friendly ping, really hoping someone can take a look. Diffs re-attached.
>
> Thanks,
>
> Ash
>
> Ashton Fagg writes:
>
>> Updated diffs attached.
>>
>> - I read style(9) a little more closely a
Original thread and discussion here:
https://marc.info/?l=openbsd-tech=162000231914017=2
I started this a couple of months ago but realized I never actually
finished this and submitted the full diff. So here it is, for whole
src tree.
I've run this through a `make build` here locally to ensure
Friendly ping, really hoping someone can take a look. Diffs re-attached.
Thanks,
Ash
Ashton Fagg writes:
> Updated diffs attached.
>
> - I read style(9) a little more closely and worked out I had some
> issues, so I corrected those.
>
> - Revisited the wording in my prop
Found these while tinkering with my CPU scaling issue the other day. Two
instances of trailing white-space.
Index: sys/arch/amd64/amd64/identcpu.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/identcpu.c,v
retrieving revision 1.118
Mark Kettenis writes:
> Sounds like Intel changed the way CPU frequency scaling is implemented
> on these new CPUs. Somebody will have to look into this, but many
> OpenBSD developers prefer to buy machines with AMD CPU which is
> probably why this hasn't happened yet.
For those joining us on
diffs.
Thanks,
ajf
Ashton Fagg writes:
> I have been working on fixing an issue (which was partially fixed by a
> diff I sent in earlier this year) with iscsid. With iscsi disks in
> /etc/fstab, sometimes the devices aren't fully up and ready before fsck
> tries to r
A friendly weekly ping.
Thanks,
Ash
Ashton Fagg writes:
> I have been working on fixing an issue (which was partially fixed by a
> diff I sent in earlier this year) with iscsid. With iscsi disks in
> /etc/fstab, sometimes the devices aren't fully up and ready before fsck
>
Jonathan Gray writes:
> I can't find 0xf0c8 in the datasheets either.
>
> I've committed this but moved the added line in pcidevs to maintain
> ordering by device id. Thanks for the patch.
Great, thank you!
Friendly ping.
Ashton Fagg writes:
> My new Intel Z590-based machine seems to have some different kind of
> Intel audio device onboard.
>
> I couldn't find very much online about it (all the usual pci id
> databases don't seem to have it yet). The only really useful
I have been working on fixing an issue (which was partially fixed by a
diff I sent in earlier this year) with iscsid. With iscsi disks in
/etc/fstab, sometimes the devices aren't fully up and ready before fsck
tries to run - causing the machine to go into single user mode on boot.
The diff that
My new Intel Z590-based machine seems to have some different kind of
Intel audio device onboard.
I couldn't find very much online about it (all the usual pci id
databases don't seem to have it yet). The only really useful thing I
found was this:
Ping.
Ashton Fagg writes:
> I noticed this when looking through the nvme.c code the other day.
>
> Currently, nvme_poll() has a loop like this:
>
> while (!ISSET(state.c.flags, htole16(NVME_CQE_PHASE))) {
> if (nvme_q_complete(sc, q) == 0)
>
Found this while poking around.
diff --git a/sys/scsi/scsi_base.c b/sys/scsi/scsi_base.c
index 2ba6a702fbc..6769449e2fa 100644
--- a/sys/scsi/scsi_base.c
+++ b/sys/scsi/scsi_base.c
@@ -478,7 +478,7 @@ scsi_io_get(struct scsi_iopool *iopl, int flags)
return NULL;
/* otherwise sleep until we
joshua stein writes:
> I'm glad I could inspire you to repost the work I already did years
> ago.
I'm not sure if you're being sarcastic.
> But either way, if a driver is causing a panic because it responds
> before it is ready, the same thing would happen without hotplug if
> it was
Ping?
Ashton Fagg writes:
> I noticed this when looking through the nvme.c code the other day.
>
> Currently, nvme_poll() has a loop like this:
>
> while (!ISSET(state.c.flags, htole16(NVME_CQE_PHASE))) {
> if (nvme_q_complete(sc, q) == 0)
>
"Theo de Raadt" writes:
> We don't need a new subsystem.
>
> We just the operation changed, so it sends the event when the device is ready,
> rather than before it is ready.
Ok fair enough. More curiosity than anything on my part.
I need to find a way to make this information available for
On May 11, 2021, at 22:53, Theo de Raadt wrote:
> This is because the design of hotplug is completely broken.
Thank you, Theo, for the comprehensive reply. This was just the sort of
feedback I’d hoped to get.
Ok so we have established this is a terrible idea because of the way hotplug
works.
Attached is a diff that implements device cloning to allow the
/dev/hotplug device to be cloned (to allow multiple concurrent readers).
Rationale:
Currently, iscsid/iscsictl cannot see when the connections it initiates
results in a device (disk) being attached. Recently, Claudio Jeker
committed
I noticed this when looking through the nvme.c code the other day.
Currently, nvme_poll() has a loop like this:
while (!ISSET(state.c.flags, htole16(NVME_CQE_PHASE))) {
if (nvme_q_complete(sc, q) == 0)
delay(10);
/* XXX no timeout?
Ashton Fagg writes:
> Ok splendid. I've regenerated these, this time including dhcpleased and
> slaacd since Florian requested I do this in private mail.
>
> I went for err(1, "unveil %s", path) per Theo's suggestion - nice and
> clear. This is now everything in sbin
"Theo de Raadt" writes:
> No, it is either:
>
> err(1, "unveil %s", path)
>
> or
>
> err(1, "unveil: %s", path)
>
> I remain undecided between those two, i don't particularily like two :: in
> a error message.
Ok splendid. I've regenerated these, this time including dhcpleased and
slaacd since
On Mon, 3 May 2021 at 10:17, Theo de Raadt wrote:
> So if the messages were just 'unveil %s: error' or 'unveil: %s: error'
> I would be thrilled, as this allows users to realize why the program is
> not working right.
Florian/Theo,
Thanks for the reviews.
So it sounds like err(1, "unveil: %s
Ashton Fagg writes:
> Hi all,
>
> I saw a discussion on here a while ago about the use of patterns like:
>
> if (unveil(some_path, "r") == -1)
>err(1, "unveil");
>
> And why that's maybe not preferable for debugging and troubleshooting
> purpose
"Theo de Raadt" writes:
> Showing the symbolic name is not doing anywhere else in the tree.
>
> Most likely they should be
>
> err(1, "unveil: %s", path);
Per Theo's advice, updated diffs are attached.
diff --git a/sbin/dhclient/dhclient.c b/sbin/dhclient/dhclient.c
index
"unveil: %s", path);
>
>
> Ashton Fagg wrote:
>
> > Ashton Fagg writes:
> >
> > > Hi all,
> > >
> > > I saw a discussion on here a while ago about the use of patterns like:
> > >
> > > if (unveil(some_path, &qu
Ashton Fagg writes:
> Hi all,
>
> I saw a discussion on here a while ago about the use of patterns like:
>
> if (unveil(some_path, "r") == -1)
>err(1, "unveil");
>
> And why that's maybe not preferable for debugging and troubleshooting
> purpose
Fixes the following warning:
sysctl.c:835:18: warning: format specifies type 'char *' but the argument has
type 'void *' [-Wformat]
string, newval);
^~
sysctl.c:840:18: warning: format specifies
Hi all,
I saw a discussion on here a while ago about the use of patterns like:
if (unveil(some_path, "r") == -1)
err(1, "unveil");
And why that's maybe not preferable for debugging and troubleshooting
purposes for programs which have multiple unveil calls (which happens
fairly often).
Hi all,
Attached is a diff which update iscsictl.8 to reflect the recent change in
behavior of
iscsictl's reload command.
Thanks,
Ash
diff --git a/usr.sbin/iscsictl/iscsictl.8 b/usr.sbin/iscsictl/iscsictl.8
index 5886a0f8f1b..1d27978eac5 100644
--- a/usr.sbin/iscsictl/iscsictl.8
+++
Claudio Jeker writes:
> Hi Ashton,
>
> I adjusted your diff a bit (mainly cleanup of spacing and other style
> changes). Please have a look. I think this version should be
> committed.
>
> Cheers
Hi Claudio,
Apologies for the late reply. Thank you for the review and I'm very
pleased this has
Hello.
Pinging on this one hoping to get some feedback. I've reattached the
diff below.
Thanks.
Ashton Fagg writes:
> Hello tech,
>
> Recently I encountered a problem with automounting iscsi volumes at boot
> time. This came down to a timing issue, where iscsictl reload was
*);
+
/* logmsg.c */
void log_hexdump(void *, size_t);
void log_pdu(struct pdu *, int);
diff --git a/usr.sbin/iscsid/poll.c b/usr.sbin/iscsid/poll.c
new file mode 100644
index 000..8eb08107f39
--- /dev/null
+++ b/usr.sbin/iscsid/poll.c
@@ -0,0 +1,100 @@
+/*
+ * Copyright (c) 2021 Dr Ashton
Jonathan Gray writes:
> pcidevs.h is a generated file. After pcidevs is modified 'make' is run
> in sys/dev/pci then pcidevs.h and pcidevs_data.h are created based on
> that. In this case it is already there though so you don't need to
> change it.
Thanks for the review. Updated patch
Ashton Fagg writes:
> (My first OpenBSD patch - sorry if it's terrible)
>
> Attached is a patch to make the audio chipset (Realtek ALC257) in a
> Thinkpad T14s get recognized by Azalia. It also sets the usual bits
> that get set for most other devices.
>
> Additionally, th
(My first OpenBSD patch - sorry if it's terrible)
Attached is a patch to make the audio chipset (Realtek ALC257) in a
Thinkpad T14s get recognized by Azalia. It also sets the usual bits
that get set for most other devices.
Additionally, this also enabled pci-e snooping for the Renoir HDA
45 matches
Mail list logo
