The diff below adds support for higher speeds as supported by UHS-I SD
cards to the generic sdmmc(4) layer. The diff in itself does not
enable the use of those modes. That needs separate changes to the
SD/MMC controller drivers. I have such a diff for amlmmc(4) that
allows me to use SDR50 mode.
This diff makes sdmmc(4) print ddr52 and hs200 capabilities, making it
possible to see whether a controller supports these high-speed eMMC
modes.
ok?
Index: dev/sdmmc/sdmmc.c
===
RCS file: /cvs/src/sys/dev/sdmmc/sdmmc.c,v
retrieving
> Date: Sat, 15 Aug 2020 20:21:09 +1000
> From: Jonathan Gray
>
> On Fri, Aug 14, 2020 at 11:06:59PM +0200, Mark Kettenis wrote:
> > > Date: Fri, 14 Aug 2020 14:40:23 +0200 (CEST)
> > > From: Mark Kettenis
> > >
> > > I suppose a way to
> Date: Fri, 14 Aug 2020 14:40:23 +0200 (CEST)
> From: Mark Kettenis
>
> I suppose a way to test this properly is to pick a system call and
> replace a copyin() with a direct access? That will succeed without
> PAN but should fail with PAN enabled right?
So that does indeed w
> Date: Fri, 14 Aug 2020 12:29:51 +1000
> From: Jonathan Gray
>
> On Thu, Aug 13, 2020 at 09:17:41PM +0200, Mark Kettenis wrote:
> > ARMv8.1 introduced PAN (Priviliged Access Never) which prevents the
> > kernel from accessing userland data. This can be bypas
Miod noticed that the powerpc64 version talked about AArch64. I don't
think the "for all XXX platforms" makes sense so simply drop it from
all three versions of this header.
ok?
Index: arch/arm/include/softintr.h
===
RCS file: /cvs
> Date: Thu, 13 Aug 2020 22:52:57 +0200
> From: Patrick Wildt
>
> On Thu, Aug 13, 2020 at 09:17:41PM +0200, Mark Kettenis wrote:
> > ARMv8.1 introduced PAN (Priviliged Access Never) which prevents the
> > kernel from accessing userland data. This can be bypas
ARMv8.1 introduced PAN (Priviliged Access Never) which prevents the
kernel from accessing userland data. This can be bypassed by using
special instructions which we already use in copyin(9) and friends.
So we can simply turn this feature on if the CPU supports it.
Tested on an Odroid-C4 which has
This diff lays the groundwork for HS200 mode for eMMC. This mode
supports data transfer modes of up to 200 MB/s. The crucial bit here
is that using this mode requires tuning which is done by calling a
chip-specific execute_tuning function. I have an implementation for
amlmmc(4) that seems to wor
> Date: Wed, 5 Aug 2020 16:39:06 -0500
> From: joshua stein
> Content-Type: text/plain; charset=utf-8
> Content-Disposition: inline
>
> In 2018 I added support for Exar XR17V35x serial ports:
>
> The Exar XR17V354 has 4 com ports that have a 256-byte FIFO, use a
> frequency of 125Mhz, an
> Date: Sun, 9 Aug 2020 10:02:38 -0500
> From: Scott Cheloha
>
> On Sun, Aug 09, 2020 at 04:43:24PM +0200, Mark Kettenis wrote:
> > > Date: Sat, 8 Aug 2020 19:46:14 -0500
> > > From: Scott Cheloha
> > >
> > > Hi,
> > >
> > >
> Date: Sun, 9 Aug 2020 06:54:53 -0500
> From: Scott Cheloha
>
> Hi,
>
> We update the ITIMER_VIRTUAL and ITIMER_PROF per-process interval
> timers from hardclock(9). If a timer is enabled we call itimerdecr()
> to update and reload it as needed. If a timer has expired we then set
> a flag on
> Date: Sat, 8 Aug 2020 19:46:14 -0500
> From: Scott Cheloha
>
> Hi,
>
> I want to annotate the locking for the per-process interval timers.
>
> In the process struct, the ITIMER_REAL itimerspec and the ps_itimer_to
> timeout are protected by the kernel lock. These should be annotated
> with "
> Date: Wed, 5 Aug 2020 17:10:37 +1000
> From: Jonathan Matthew
>
> This came out of the work on supporting ACPI0007 devices in acpicpu(4), but
> it's independent of that and I'd like to get it in the tree separately.
>
> Since it was first added, acpicpu stores instances of itself in an array,
> Date: Sat, 1 Aug 2020 18:23:08 +1000
> From: Jonathan Matthew
> Cc: tech@openbsd.org
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Wed, Jul 29, 2020 at 08:29:31PM +1000, Jonathan Matthew wrote:
> > On Wed, Jul 29, 2020 at 10:0
> Date: Sat, 1 Aug 2020 20:54:28 +0100
> From: Stuart Henderson
>
> I've just been building a machine with serial console to go to colo
> tomorrow and have noticed that there's no output on glass console
> after the "switching console to com0" message. The only getty running
> after boot is the o
> Date: Wed, 29 Jul 2020 13:03:43 -0700
> From: Mike Larkin
>
> Hi,
>
> I'm seeing crashes on amd64 GENERIC.MP on a few VMs recently. This happens
> on GENERIC.MP regardless of whether or not the VM has one cpu or more than
> one. It does not happen on GENERIC kernels.
>
> The crash will happ
> Date: Wed, 29 Jul 2020 10:38:55 +1000
> From: Jonathan Matthew
>
> On Tue, Jul 28, 2020 at 07:30:36PM +0200, Mark Kettenis wrote:
> > > Date: Tue, 28 Jul 2020 21:42:46 +1000
> > > From: Jonathan Matthew
> > >
> > > On Tue, Jul 28, 2020 at 11:12
> Date: Tue, 28 Jul 2020 21:42:46 +1000
> From: Jonathan Matthew
>
> On Tue, Jul 28, 2020 at 11:12:21AM +0200, Mark Kettenis wrote:
> > > Date: Tue, 28 Jul 2020 13:46:34 +1000
> > > From: Jonathan Matthew
> > >
> > > On Mon, Jul 27, 2020 at 05:16
> Date: Tue, 28 Jul 2020 11:16:56 +0100
> From: Jason McIntyre
>
> On Tue, Jul 28, 2020 at 11:12:21AM +0200, Mark Kettenis wrote:
> > > Date: Tue, 28 Jul 2020 13:46:34 +1000
> > > From: Jonathan Matthew
> > >
> > > On Mon, Jul 27, 2020 at 05:16
> Date: Tue, 28 Jul 2020 13:46:34 +1000
> From: Jonathan Matthew
>
> On Mon, Jul 27, 2020 at 05:16:47PM +0200, Mark Kettenis wrote:
> > > Date: Mon, 27 Jul 2020 17:02:41 +0200 (CEST)
> > > From: Mark Kettenis
> > >
> > > Recent ACPI versions
> Date: Mon, 27 Jul 2020 17:14:21 +0200
> From: Christian Weisgerber
>
> Scott Cheloha:
>
> > --- lib/libc/arch/amd64/gen/usertc.c8 Jul 2020 09:17:48 -
> > 1.2
> > +++ lib/libc/arch/amd64/gen/usertc.c25 Jul 2020 17:50:38 -
> > @@ -21,9 +21,12 @@
> > static inline
> Date: Mon, 27 Jul 2020 11:10:42 -0400
> From: Bryan Steele
>
> On Mon, Jul 27, 2020 at 05:02:41PM +0200, Mark Kettenis wrote:
> > Recent ACPI versions have deprecated "Processor()" nodes in favout of
> > "Device()" nodes with a _HID() method that
> Date: Mon, 27 Jul 2020 17:02:41 +0200 (CEST)
> From: Mark Kettenis
>
> Recent ACPI versions have deprecated "Processor()" nodes in favout of
> "Device()" nodes with a _HID() method that returns "ACPI0007". This
> diff tries to support machines w
Recent ACPI versions have deprecated "Processor()" nodes in favout of
"Device()" nodes with a _HID() method that returns "ACPI0007". This
diff tries to support machines with firmware that implements this. If
you see something like:
"ACPI0007" at acpi0 not configured
please try the following d
Booted up the old v210 to test something and noticed that it prints a
couple of:
bge0: nvram lock timed out
warnings when booting up. These are the on-board network interfaces
and we already established in the past that these come without
EEPROM/NVRAM and instead rely on the firmware to provid
> Date: Tue, 21 Jul 2020 19:33:21 +1000
> From: Jonathan Gray
>
> Change from using timevals for ktime to 64 bit count of nanoseconds
> to closer match linux. From a discussion with cheloha@
ok kettenis@
> Index: sys/dev/pci/drm/drm_vblank.c
> ==
> Date: Wed, 15 Jul 2020 20:36:04 -0500
> From: Scott Cheloha
>
> On Sat, Jul 11, 2020 at 01:16:43PM +0200, Mark Kettenis wrote:
> > > From: Paul Irofti
> > > Date: Sat, 11 Jul 2020 13:50:37 +0300
> > >
> > > On 2020-07-11 13:46, Mark Kettenis
> Date: Wed, 15 Jul 2020 17:05:57 +0200
> From: Jan Stary
>
> This is in the vein of
> https://marc.info/?l=openbsd-cvs&m=158170787221615&w=2
>
> declares "extern int optind" and friends,
> so there is no need to declare them again.
> Still builds on current/amd64.
>
> Leaving out gnu, nsd, un
> Date: Tue, 14 Jul 2020 20:17:30 -0500
> From: Scott Cheloha
> Cc: Mark Kettenis , tech@openbsd.org, p...@irofti.net
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Tue, Jul 14, 2020 at 08:21:24PM -0400, George Koehler wrote:
> > O
> Date: Tue, 14 Jul 2020 20:21:24 -0400
> From: George Koehler
>
> On Tue, 14 Jul 2020 11:59:14 +0200 (CEST)
> Mark Kettenis wrote:
>
> > Yeah, one possible approach would be to increment ogen by two. A
> > little bit easier to check that they can never be the sa
The firmware on the POWER9 machines provides an energy sensor. This
sensor measures the energy on/in/at the chip. I'm not sure what that
actually means. But it is different from the energy content of a
battery which is measured in Watthours.
Should I add this? Or should I just skip these senso
> Date: Mon, 13 Jul 2020 17:07:31 -0400
> From: George Koehler
>
> On Mon, 13 Jul 2020 01:18:14 -0500
> Scott Cheloha wrote:
>
> > To review, the update protocol is:
> >
> > 1. Set tk_generation to zero; the update has begun.
> >
> > 2. Memory barrier. The side effects of step (1) are "visib
> Date: Sun, 12 Jul 2020 19:30:38 +0200
> From: Christian Weisgerber
>
> Mark Kettenis:
>
> > > Date: Sun, 12 Jul 2020 18:12:39 +0200
> > > From: Christian Weisgerber
> > >
> > > The PowerPC/Power ISA Time Base is a 64-bit register. We ca
> Date: Sun, 12 Jul 2020 18:23:09 +0200
> From: Christian Weisgerber
>
> Christian Weisgerber:
>
> > - tb_get_timecount, NULL, 0x7fff, 0, "tb", 0, NULL, 0
> > + tb_get_timecount, NULL, 0x, 0, "tb", 0, NULL, 0
>
> PS: Do we prefer ~0u over 0x?
I prefer 0x. We ty
> Date: Sun, 12 Jul 2020 18:12:39 +0200
> From: Christian Weisgerber
>
> The PowerPC/Power ISA Time Base is a 64-bit register. We can use
> the full lower 32 bits.
>
> OK?
Sure, but this needs to be coordinated with the userland diff. And
we'd better change it quick because doing it later is
> Date: Sun, 12 Jul 2020 18:21:48 +0200
> From: Christian Weisgerber
>
> There is the strong suspicion that the 0x7fff mask in the various
> armv7 timecounters was simply copied from powerpc, and that these really
> are full 32-bit counters.
>
> I wanted to verify this from the data sheets,
While working on the OpenBSD/powerpc64 pmap I noticed that the code we
use for the G5 machines has a bug and doesn't remove execute
permission from mappings when it should.
Since I don't have a G5 machine readily available, can somebody test
this diff for me?
Index: arch/powerpc/powerpc/pmap.c
=
> Date: Sun, 12 Jul 2020 00:06:21 +0200
> From: Christian Weisgerber
>
> Mark Kettenis:
>
> > Nevertheless, here is a different take on the problem. Since the
> > timecounter only uses the low 32 bits we don't need the double read.
> > This version
> Date: Thu, 9 Jul 2020 11:29:05 -0500
> From: Scott Cheloha
> Cc: tech@openbsd.org
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Thu, Jul 09, 2020 at 10:35:46AM +0200, Mark Kettenis wrote:
> >
> > Here is the arm64 version.
> Date: Sat, 11 Jul 2020 19:29:17 +0200
> From: Stefan Sperling
>
> When a wifi interface acts as a client, ifconfig will currently display
> the default value 'ccmp' for the wpagroupcipher parameter, even while
> associated to a WPA2 access point which uses TKIP as the group cipher
> for WPA1 co
> From: Paul Irofti
> Date: Sat, 11 Jul 2020 13:50:37 +0300
>
> On 2020-07-11 13:46, Mark Kettenis wrote:
> >> From: Paul Irofti
> >> Date: Sat, 11 Jul 2020 13:32:22 +0300
> >>
> >> Hi,
> >>
> >> Getting lots of messages about
> From: Paul Irofti
> Date: Sat, 11 Jul 2020 13:32:22 +0300
>
> Hi,
>
> Getting lots of messages about people loving the new timekeep
> functionality, which I am very happy about, but also some that have the
> skew too large for it to be enabled.
>
> I plan on sending a diff next week to impr
> Date: Sat, 11 Jul 2020 14:45:44 +1000
> From: Jonathan Gray
>
> In drm linux spinlocks are mapped to mutex(9).
>
> Locks without calls to spin_lock_irqsave(), spin_lock_irq() and the like
> (which block interrupts) can be changed to IPL_NONE.
This shouldn't really make a difference, although
> From p...@irofti.net Sat Jul 11 01:23:20 2020
> Date: Sat, 11 Jul 2020 02:22:33 +0300
>
> În 11 iulie 2020 02:15:27 EEST, Mark Kettenis a
> scris:
> >> Date: Fri, 10 Jul 2020 19:03:58 -0400
> >> From: George Koehler
> >>
> >> On Wed,
> Date: Fri, 10 Jul 2020 19:03:58 -0400
> From: George Koehler
>
> On Wed, 8 Jul 2020 14:26:02 +0200 (CEST)
> Mark Kettenis wrote:
>
> > > From: Paul Irofti
> > > Reads OK to me. Please make the adjustments to static functions that
> > > ketteni
So it seems that hardware reference and change bit updates are busted
on POWER9 CPUs. Or at least they don't work the way I'm reading the
specs. So I've changed the pmap for OpenBSD/powerpc64 to emulate them
instead.
While implementing this code I wondered how this is supposed to work
for pages
> Date: Thu, 9 Jul 2020 19:43:52 +0200
> From: Ingo Schwarze
>
> Hi Theo,
>
> Theo de Raadt wrote on Thu, Jul 09, 2020 at 11:08:38AM -0600:
> > Ingo Schwarze wrote:
>
> >> So, what about
> >> LD_KTRACE_GETTIME
> >> or a similar environment variable name?
>
> > That naming seems logical.
> >
> From: "Theo de Raadt"
> Date: Thu, 09 Jul 2020 09:13:24 -0600
>
> Ted Unangst wrote:
>
> > On 2020-07-08, Theo de Raadt wrote:
> > > I think we need something like this.
> > >
> > > Documenting it will be a challenge.
> > >
> > > I really don't like the name as is too generic, when the cont
> From: "Ted Unangst"
> Date: Thu, 09 Jul 2020 11:07:02 -0400
>
> On 2020-07-08, Mark Kettenis wrote:
> > > From: "Ted Unangst"
> > > Date: Wed, 08 Jul 2020 05:20:23 -0400
> > >
> > > On 2020-07-08, Ted Unangst wrote:
> >
arch/aarch64/gen/usertc.c 6 Jul 2020 13:33:05 - 1.1
+++ lib/libc/arch/aarch64/gen/usertc.c 9 Jul 2020 08:12:44 -
@@ -1,6 +1,6 @@
-/* $OpenBSD: usertc.c,v 1.1 2020/07/06 13:33:05 pirofti Exp $ */
+/* $OpenBSD$ */
/*
- * Copyright (c) 2020 Paul Irofti
+ * Copyrig
> From: "Ted Unangst"
> Date: Wed, 08 Jul 2020 05:20:23 -0400
>
> On 2020-07-08, Ted Unangst wrote:
> > I think this makes sem_init(pshared) work.
>
> Whoops, need more context to include the header file changes.
It is a bit of a pity that we have to expose the internals here, but I
don't see a
> Date: Wed, 8 Jul 2020 18:02:06 +0200
> From: Frederic Cambus
>
> Hi tech@,
>
> Here is a diff to enable spleen16x32 and spleen32x64 on armv7 for
> GENERIC kernels, like on arm64.
>
> I'm using the 16x32 version on my Cubieboard2.
>
> I'm not sure if any armv7 devices we support is actually c
> From: "Theo de Raadt"
> Date: Wed, 08 Jul 2020 09:42:41 -0600
>
> I think we need something like this.
>
> Documenting it will be a challenge.
>
> I really don't like the name as is too generic, when the control is only
> for a narrow set of "current time" system calls.
I'm not sure we shoul
> From: Paul Irofti
> Date: Wed, 8 Jul 2020 12:05:04 +0300
>
> On 2020-06-26 06:22, George Koehler wrote:
> > On Mon, 22 Jun 2020 19:12:22 +0300
> > Paul Irofti wrote:
> >
> >> New iteration:
> >>
> >>- ps_timekeep should not coredump, pointed by deraadt@
> >>- set ps_timekeep to 0 befo
> Date: Tue, 7 Jul 2020 23:46:00 +0200 (CEST)
> From: Mark Kettenis
>
> > Date: Tue, 7 Jul 2020 23:13:06 +0200
> > From: Christian Weisgerber
> >
> > Mark Kettenis:
> >
> > > > --- lib/libc/arch/alpha/gen/usertc.c6 Jul 2020 13:33:05 -
> Date: Tue, 7 Jul 2020 23:13:06 +0200
> From: Christian Weisgerber
>
> Mark Kettenis:
>
> > > --- lib/libc/arch/alpha/gen/usertc.c 6 Jul 2020 13:33:05 -
> > > 1.1
> > > +++ lib/libc/arch/alpha/gen/usertc.c 7 Jul 2020 20:40:37 -
> Date: Tue, 7 Jul 2020 22:49:31 +0200
> From: Christian Weisgerber
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> Userland gettime support for alpha.
>
> Alas, completely untested since I don't have access to that arch.
>
> Index: lib/libc/arch/alpha/gen/usertc.
> Date: Tue, 7 Jul 2020 17:55:32 +0200
> From: Frederic Cambus
>
> On Wed, Jul 08, 2020 at 12:06:27AM +1000, Jonathan Gray wrote:
> > On Tue, Jul 07, 2020 at 03:16:33PM +0200, Frederic Cambus wrote:
> > > Hi tech@,
> > >
> > > The recent spike of interest around framebuffer consoles has prompted
> From: "Theo de Raadt"
> Date: Tue, 07 Jul 2020 08:49:41 -0600
>
> Jonathan Gray wrote:
>
> > On Tue, Jul 07, 2020 at 03:16:33PM +0200, Frederic Cambus wrote:
> > > Hi tech@,
> > >
> > > The recent spike of interest around framebuffer consoles has prompted
> > > me to revisit a proposal I sen
> Date: Tue, 7 Jul 2020 15:16:33 +0200
> From: Frederic Cambus
>
> Hi tech@,
>
> The recent spike of interest around framebuffer consoles has prompted
> me to revisit a proposal I sent back in early 2017 [1].
>
> Aesthetics considerations aside, kettenis@ raised the concern that colors
> from t
> From: Vitaliy Makkoveev
> Date: Tue, 7 Jul 2020 01:34:33 +0300
>
> > On 5 Jul 2020, at 20:31, Paul Irofti wrote:
> >
> > On Fri, Jul 03, 2020 at 06:36:39PM +0300, Paul Irofti wrote:
> >>
> >>
> >> În 3 iulie 2020 17:55:25 EEST, Mark Ke
> Date: Mon, 6 Jul 2020 16:40:35 -0500
> From: Scott Cheloha
>
> On Fri, Jul 03, 2020 at 10:52:15AM +0200, Otto Moerbeek wrote:
> > On Thu, Jul 02, 2020 at 08:27:58PM -0500, Scott Cheloha wrote:
> >
> > > Hi,
> > >
> > > When we recompute the scaling factor during tc_windup() there is an
> > >
IEEE1275 a.k.a. Open Firmware clearly states that property name
strings can have a length of up to 31 characters. That same limit is
mentioned in various documents on the flattened device tree format.
Unfortunately that limit seems to be ignored. The device tree on the
POWER9 machines has propert
> Date: Sun, 5 Jul 2020 20:31:19 +0300
> From: Paul Irofti
>
> On Fri, Jul 03, 2020 at 06:36:39PM +0300, Paul Irofti wrote:
> >
> >
> > În 3 iulie 2020 17:55:25 EEST, Mark Kettenis a
> > scris:
> > >> Date: Fri, 3 Jul 2020 15:13:22 +0200
>
> Date: Fri, 3 Jul 2020 12:42:58 -0500
> From: Scott Cheloha
>
> On Fri, Jul 03, 2020 at 02:34:20PM +0300, Paul Irofti wrote:
> > On 2020-07-03 00:40, Scott Cheloha wrote:
> > > On Fri, Jun 26, 2020 at 04:53:14PM +0300, Paul Irofti wrote:
> > > > On Wed, Jun 24, 2020 at 11:53:23AM +0200, Robert N
> Date: Fri, 3 Jul 2020 15:13:22 +0200
> From: Robert Nagy
>
> On 02/07/20 00:31 +0100, Stuart Henderson wrote:
> > running on 38 of these, btw.
>
> been running with this on all my workstations and laptops and on 3 build
> servers as well
Are the issue that naddy@ saw solved?
Did anybody do a
> Date: Sun, 28 Jun 2020 13:38:37 +0200
> From: Klemens Nanni
>
> On Sun, Jun 28, 2020 at 12:59:10PM +0200, Mark Kettenis wrote:
> > Would be nice if we could give a hint about the firmware revisions
> > that are known to work.
> https://www.oracle.com/servers/te
> Date: Sun, 28 Jun 2020 12:36:25 +0200
> From: Klemens Nanni
>
> As Koakuma confirmed on bugs@, their machine exhibited strange behaviour
> with such outdated firmware while at least the latest version runs fine
> as expected.
>
> I'd like to mention this in the FAQ.
>
> Feedack? OK?
Would be
TCHABLE flag set. So that has to be fixed
as well.
> Original Message
> Subject: RE: [PATCH} Optimized rasops32 putchar
> From:
> Date: Sat, June 27, 2020 11:13 am
> To: "Mark Kettenis"
> Cc: "tech@openbsd.org"
>
> I believe it is mapp
> From:
> Date: Fri, 26 Jun 2020 07:42:50 -0700
>
> Optimized 32 bit character rendering with unrolled rows and pairwise
> foreground / background pixel rendering.
>
> If it weren't for the 5x8 font, I would have just assumed everything
> was an even width and made the fallback path also pairwis
> Date: Thu, 25 Jun 2020 23:05:36 +0200
> From: Christian Weisgerber
>
> Trying again, this time with powerpc64 added:
>
> This adds the optimized ffs(3) versions on aarch64, powerpc, and
> powerpc64 to libc. Also add a brief regression test.
Not yet in the position to test the powerpc64 imple
> Date: Mon, 22 Jun 2020 13:53:25 +0300
> From: Paul Irofti
>
> > Still uses uint instead of u_int in places. Still has the pointless
> > extra NULL and 0 for timecounters in files that are otherwise
>
> If you don't like uint, then let's fix what's in the tree in amd64
> (which is how uint got
> Date: Mon, 22 Jun 2020 02:06:39 +0300
> From: Paul Irofti
>
> În 22 iunie 2020 00:15:59 EEST, Christian Weisgerber a
> scris:
> >Paul Irofti:
> >
> >[Unrelated, just to mark where we're at]
> >> Right. Just reproduced it here. This moves the check at the top so
> >that
> >> each CPU checks it
> Date: Sun, 21 Jun 2020 16:55:56 +0100
> From: Stuart Henderson
>
> On 2020/06/21 18:46, Paul Irofti wrote:
> >
> >
> > În 21 iunie 2020 16:30:43 EEST, Theo de Raadt a scris:
> > >Paul Irofti wrote:
> > >
> > >> If you change the name to rdtsc_ordered(), OK.
> > >
> > >That is a weaker name.
> From: "Theo de Raadt"
> Date: Sun, 21 Jun 2020 07:30:43 -0600
>
> Paul Irofti wrote:
>
> > If you change the name to rdtsc_ordered(), OK.
>
> That is a weaker name.
>
> Ordered in what way, at what level; ordered against what?
>
> This is using a specific pipeline ordering known as lfence.
> From: Christian Weisgerber
> Date: Sat, 20 Jun 2020 19:57:06 - (UTC)
>
> On 2020-06-19, Paul Irofti wrote:
>
> > I have addressed your comments bellow, except for the CPU skew one. That
> > code disables TSC for all CPUs, not just for PRIMARY. Would you like to
> > walk and add code for e
RDTSC is not a serializing instruction; to make sure we get the TSC
value corresponding to the position of RDTSC in te instruction stream
we need a barrier. Linux uses LFENCE on machines where it is
available. FreeBSD seems to prefer MFENCE for AMD CPUs but uses
LFENCE for Intel CPUs. For now my
> From: Al Poole
> Date: Sat, 13 Jun 2020 20:33:11 +0100
>
> Hi,
>
> This introduces temperature driver for the Raspberry PI 4 named bcmtmon.
>
> bcmtmon because of bcmtemp(4) and (!strncmp("bcmt", snsrdev.xname, 4))
>
> @kettenis has been advising me and answering questions.
Thanks,
I made
> From: Christian Weisgerber
> Date: Sat, 20 Jun 2020 01:20:33 - (UTC)
>
> On 2020-06-19, Mark Kettenis wrote:
>
> > I'm talking about *skew*, not drift. If there is a significant drift
> > you already knock out the TSC.
> >
> > What's n
> Date: Fri, 19 Jun 2020 16:14:45 +1000
> From: David Gwynne
>
> the network stack doesnt really block timeouts from firing anymore. this
> is especially true on MP systems, because timeouts fire on cpu0 and the
> nettq thread could be somewhere else entirely. this means network
> activity doesn'
> Date: Fri, 19 Jun 2020 23:16:26 +0300
> From: Paul Irofti
>
> În 19 iunie 2020 22:49:32 EEST, Mark Kettenis a
> scris:
> >> Date: Fri, 19 Jun 2020 20:28:58 +0300
> >> From: Paul Irofti
> >>
> >> On Fri, Jun 19, 2020 at 06:52:40PM +0200, M
> Date: Fri, 19 Jun 2020 20:28:58 +0300
> From: Paul Irofti
>
> On Fri, Jun 19, 2020 at 06:52:40PM +0200, Mark Kettenis wrote:
> > > Date: Fri, 19 Jun 2020 14:31:17 +0300
> > > From: Paul Irofti
> > >
> > > Hi,
> > >
> > > Here
> From: "Todd C. Miller"
> Date: Fri, 19 Jun 2020 12:24:33 -0600
>
> On Fri, 19 Jun 2020 18:52:40 +0200, Mark Kettenis wrote:
>
> > There is one other issue that I wanted to raise. An that is whether
> > we really need to implement CLOCK_UPTINME as a userla
> Date: Fri, 19 Jun 2020 14:31:17 +0300
> From: Paul Irofti
>
> Hi,
>
> Here is another iteration of the diff that addresses all issues raised
> in the meantime:
>
> - Switch tc to uint
The request was to use u_int, like we de in the kernel. The uint type
should not be used in OpenBSD code.
Mostly cosmetic, but it removes an "unknown" from dmesg which may
spook some of our users.
ok?
Index: dev/pci/if_bge.c
===
RCS file: /cvs/src/sys/dev/pci/if_bge.c,v
retrieving revision 1.388
diff -u -p -r1.388 if_bge.c
--- dev/pci/i
> Date: Tue, 16 Jun 2020 11:20:05 +1000
> From: David Gwynne
>
> there's been discussions for years (and even some diffs!) about how we
> should let drivers establish interrupts on multiple cpus.
>
> the simple approach is to let every driver look at the number of cpus in
> a box and just pin an
> Content-Type: text/plain; charset="utf-8"
> From:
>
> What would be a good system with CoreBoot to get for OpenBSD testing?
>
> It looks like there are some edge cases where the CoreBoot framebuffer
> support won't behave the same as the EFI framebuffer.
Not sure what a good machine is, but j
> Date: Sat, 13 Jun 2020 00:03:14 +0200
> From: Klemens Nanni
>
> DDB's "show struct" on sparc64 does not work because the boot loader
> does not load the kernel's ELF section ".SUNW_ctf".
>
> Adapt ofwboot to do so just like libsa already does on other platforms
> (such as amd64) and therefore
> From: Paul Irofti
> Date: Fri, 12 Jun 2020 12:30:22 +0300
>
> On 12.06.2020 10:48, Robert Nagy wrote:
> > On 11/06/20 20:10 +0200, Mark Kettenis wrote:
> >>> Date: Thu, 11 Jun 2020 19:38:48 +0200
> >>> From: Christian Weisgerber
> >>>
> Date: Thu, 11 Jun 2020 19:38:48 +0200
> From: Christian Weisgerber
>
> Theo de Raadt:
>
> > The diff is growing complexity to support a future which wouldn't
> > exist if attempts at *supporting all* architectures received priority.
>
> Adding support for more archs is very simple, since you
> Date: Thu, 11 Jun 2020 17:29:44 +0200
> From: Christian Weisgerber
>
> Paul Irofti:
>
> > > Paul, that tk_nclocks addition isn't useful. You need to do the
> > > bounds checking against the number of clocks you have implemented in
> > > libc. How many clocks the kernel has implemented doesn'
> Date: Thu, 11 Jun 2020 16:27:03 +0300
> From: Paul Irofti
>
> On Thu, Jun 11, 2020 at 02:49:54PM +0200, Marc Espie wrote:
> > On Thu, Jun 11, 2020 at 03:42:27PM +0300, Paul Irofti wrote:
> > > On Thu, Jun 11, 2020 at 02:05:44PM +0200, Marc Espie wrote:
> > > > On Thu, Jun 11, 2020 at 01:13:07PM
> Date: Thu, 11 Jun 2020 14:49:54 +0200
> From: Marc Espie
>
> On Thu, Jun 11, 2020 at 03:42:27PM +0300, Paul Irofti wrote:
> > On Thu, Jun 11, 2020 at 02:05:44PM +0200, Marc Espie wrote:
> > > On Thu, Jun 11, 2020 at 01:13:07PM +0300, Paul Irofti wrote:
> > > > On 2020-06-11 02:46, Christian Wei
> Date: Thu, 11 Jun 2020 11:42:23 +0200
> From: Stefan Sperling
>
> On Thu, Jun 11, 2020 at 11:00:30AM +0200, Mark Kettenis wrote:
> > > Date: Thu, 11 Jun 2020 10:48:09 +0200
> > > From: Stefan Sperling
> > >
> > > I spotted this while working o
> Date: Thu, 11 Jun 2020 10:48:09 +0200
> From: Stefan Sperling
>
> I spotted this while working on iwx(4).
>
> Setting up ic_myaddr when we're about to scan for APs is rather late in
> the game. All these drivers are already setting up ic_myaddr during the
> device initialization phase, long be
> Date: Wed, 10 Jun 2020 20:08:31 +0200
> From: Christian Weisgerber
>
> Next try.
> Optimized versions for kernel ffs(3) on arm64, powerpc, powerpc64.
>
> I have tested arm64; cwen@ has tested powerpc in userland.
> powerpc64 is copied from powerpc.
>
> ok?
ok kettenis@
> Index: lib/libkern/
> Date: Tue, 9 Jun 2020 23:43:50 +0200
> From: Christian Weisgerber
>
> Mark Kettenis:
>
> > Unfortunately that doesn't quite work. At least in my build it
> > doesn't pick up .c files in the linker/arch directories.
> >
> > > Index: l
> From: Jaromír Doleček
> Date: Wed, 3 Jun 2020 14:16:47 +0200
>
> Hello,
>
> I'm working on porting xmm7360 device driver from Linux to OpenBSD,
> the Linux code:
> https://github.com/xmm7360/xmm7360-pci/
>
> Most of device driver communication with the device is already
> working, but current
> From: Christian Weisgerber
> Date: Tue, 9 Jun 2020 18:39:45 - (UTC)
>
> Here are optimized ffs(3) implementations for
> * arm64 (superseding the earlier ffs.S)
> * powerpc
> * powerpc64
>
> arm64 tested by myself, powerpc tested by cwen@.
>
> OK?
>
> (Some other archs fell through. spa
701 - 800 of 3190 matches
Mail list logo
