> Date: Tue, 21 May 2019 21:04:33 +0200 (CEST)
> From: Mark Kettenis
>
> Logic error. If pa->pa_pmemex is NULL we want to try allocating from
> pa->pa_memex. But if both of them are NULL we need to assume that the
> provided base address is correct.
>
> ok?
patr
> Date: Wed, 22 May 2019 20:02:14 +0200
> From: Alexander Bluhm
>
> On Wed, May 22, 2019 at 05:54:35PM +0200, Mark Kettenis wrote:
> > Should we also fix biosboot? The machines that are affected are all
> > fairly recent and should boot using UEFI by default...
>
> Date: Tue, 29 Oct 2019 11:31:31 +0100
> From: Stefan Sperling
>
> On Mon, Oct 28, 2019 at 08:48:41PM +0100, Mark Kettenis wrote:
> > > Date: Mon, 28 Oct 2019 19:28:29 +0100
> > > From: Stefan Sperling
> > >
> > > Newer iwm(4) firmware versi
> Date: Thu, 31 Oct 2019 11:31:50 +0100
> From: Patrick Wildt
>
> Hi,
>
> some machines have no _BQC method, which is used to query the
> current display backlight level. We can still work on those by
> starting with the highest level (when there's no _BQC method)
> and keeping track of the cur
> From: "Ted Unangst"
> Date: Fri, 01 Nov 2019 00:18:35 -0400
>
> Theo de Raadt wrote:
> > In uvm_map_inentry_fix(), two variables in the map are now being read
> > without a per-map read lock, this was previously protected by the
> > kernel lock
> >
> > if (addr < map->min_offset || add
> Date: Fri, 1 Nov 2019 00:18:43 +0100
> From: Martin Pieuchot
>
> When a userland program triggers a fault or does a syscall its SP and/or
> PC are checked to be sure they are in expected regions. The result of
> this check is cached in the "struct proc" such that a lookup isn't
> always necess
> Date: Fri, 1 Nov 2019 14:13:26 +0100
> From: Martin Pieuchot
>
> On 01/11/19(Fri) 13:12, Mark Kettenis wrote:
> > > From: "Ted Unangst"
> > > Date: Fri, 01 Nov 2019 00:18:35 -0400
> > >
> > > Theo de Raadt wrote:
> > > >
> Date: Sat, 2 Nov 2019 10:55:30 +0100
> From: Martin Pieuchot
>
> This function is just a wrapper on top of uvm_unmap(), it has its own
> file and is called only 3 times in the kernel. Getting rid of it makes
> the overall UVM simpler, ok?
>
> Index: sys/conf/files
> ==
> From: Andrew Grillet
> Date: Sun, 3 Nov 2019 16:39:42 +
>
> I have been running my T1000 for almost a year on a config generated with
> (I think) OBDS6.3.
> I upgraded to 6.6 current on the day before it was released (2 October?).
>
> I built a new config with minor changes (names of guest
> Date: Sun, 3 Nov 2019 18:03:19 +0100
> From: Martin Pieuchot
>
> For profiling purposes, it would be useful to know where assembly
> symbols end.
>
> Diff below adds many END() for libkern and locore.s on sparc64.
>
> ok?
ok kettenis@
> Index: arch/sparc64/sparc64/locore.s
> ==
> Date: Tue, 5 Nov 2019 10:07:36 +0100
> From: Martin Pieuchot
>
> Diff below reintroduce the `kv_executable' flag for km_alloc(9) with a
> different meaning. Instead of mapping the pages RWX, the flags allows
> the caller to change the protection of the mapping to include PROT_EXEC.
>
> This a
> Date: Sun, 10 Nov 2019 13:09:44 +0100
> From: Martin Pieuchot
>
> 'db_expr_t' is defined as 'long' on all platforms. I'd like to use some
> of the ddb interfaces without having to pull all the type & cast mess into
> non-DDB code.
>
> Here's an example of getting rid of in MI code
> and usin
> Date: Sat, 16 Nov 2019 19:08:05 +0100
> From: Stefan Sperling
>
> On Sat, Nov 16, 2019 at 11:44:03AM -0600, joshua stein wrote:
> > Awesome, thanks guys. It's working great on the 9560 on my ThinkPad
> > X1C7. A speed test showed 44/18 Mbps and it continues to work fine
> > after an S3 cycl
> From: "Theo de Raadt"
> Date: Tue, 19 Nov 2019 22:32:39 -0700
>
> Seems accidentally left over from development. As a rule we don't
> ship with -g.
Indeed. I don't see why these should be different.
> Klemens Nanni wrote:
>
> > As of now, `export DEBUG=... ; make' will ignore my flags.
>
> Date: Wed, 20 Nov 2019 13:49:33 +0100
> From: Martin Pieuchot
>
> Two fixes to reduce difference with other BSDs and make NetBSD's
> t_ptrace.c regress pass:
>
> - Return EBUSY when calling PT_TRACE_ME more than once, both FreeBSD and
> NetBSD do that.
fine
> - Return EPERM instead of EINV
> Date: Tue, 26 Nov 2019 23:22:14 +0100
> From: Alexander Bluhm
>
> Hi,
>
> I am currently debugging an UEFI boot problem. A hexdump in the
> boot loader would be convenient.
>
> boot> hexdump 0x10 20
> 0010 53 ff 00 f0 54 ff 00 f0 53 ff 00 f0 53 ff 00 f0 |S...T...S...S...|
> 0020
The inteldrm(4) driver keeps a cache of graphics objects, allegedly to
make things faster by avoiding cache flushes. But those graphics
objects consume memory that we want to free if we need it for
something else.
The diff below hooks up the "shrinker" code in inteldrm(4) and calls
it from the pa
an-readable scale, using the format described in
> +.Xr scan_scaled 3 .
> .It Ic iodevice Ar path
> Assign the specified PCIe device to the guest domain.
> This keyword can be used multiple times.
> Index: ldomctl/ldom_util.h
> =
> Date: Thu, 28 Nov 2019 03:48:04 +0100
> From: Klemens Nanni
>
> On Thu, Nov 28, 2019 at 01:05:43AM +0100, Klemens Nanni wrote:
> > With that, the next step is to implement `ldomctl console guest01' in
> > analogy to vmctl(8).
> Here's a complete diff for updating the status output and implement
> Date: Sat, 7 Dec 2019 14:24:14 +1100
> From: Jonathan Gray
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> While we don't have C11's quick_exit() we do have timespec_get() and
> struct timespec/aligned_alloc().
ok kettenis@
> Index: include/__config
> ==
> Date: Mon, 9 Dec 2019 17:52:17 +0100
> From: Klemens Nanni
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> This fixes
>
> # ldomctl status
> primary -running OpenBSD running
> 0%
> guest1
> Date: Sat, 14 Dec 2019 10:20:52 +1100
> From: Jonathan Gray
>
> On Fri, Dec 13, 2019 at 10:34:59PM +0100, Patrick Wildt wrote:
> > Hi,
> >
> > I have a ThingM blink(1) USB RGB device that shows up as uhid(4).
> > The tooling is "interesting", especially with all those libusb and
> > HID librar
> Date: Mon, 16 Dec 2019 12:37:51 +0100
> From: Claudio Jeker
>
> This diff should add support for newer smbus controllers used on newer AMD
> chipsets. Especially Hudson-2 and Kerncz based chipsets. On my Ryzen 5 the
> iic(4) busses attach but there is nothing detected on them (well possible
> t
> Date: Mon, 16 Dec 2019 21:05:47 +0100
> From: Claudio Jeker
> Cc: tech@openbsd.org
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Mon, Dec 16, 2019 at 08:02:55PM +0100, Mark Kettenis wrote:
> > > Date: Mon, 16 Dec 2019 12:37:51 +
Hit the
KASSERT(curcpu()->ci_inatomic == 0);
in pagefault_disable(). Analysis of the code in i915_gem_execbuffer.c
shows that pagefault_disable() may be called when page faults are
already disabled, i.e. from eb_relocate_slow() where eb_relocate_vma()
is called after pagefault_disable().
Diff
While playing with ipmi(4) attaching to acpi(4) I found out that using
an int for storing addresses isn't a good idea. If you use it to
store large addresses, the number becomes negative and will be sign
extended when converted into a 64-bit adddress. The appropriate type
to use here is bus_addr_
+.Nm amdgpio
> +.Nd AMD GPIO controller
> +.Sh SYNOPSIS
> +.Cd "amdgpio* at acpi?"
> +.Sh DESCRIPTION
> +The
> +.Nm
> +driver provides support for the GPIO controller found on AMD chipsets.
> +It does not provide direct device driver entry points but makes
Currently my mini-PC with AMD Ryzen CPU shows:
spdmem0 at iic0 addr 0x50: 0MB DDR4 SDRAM PC4-21300 SO-DIMM
problem here is in the calculation of the DIMM size:
dimm_size = datawidth - (chipwidth + 2);
dimm_size = ddr4_chipsize[chipsize] * (1 << dimm_size) *
(physban
On arm64 systems, IPMI can actually attach using mmio. The diff below
implements this. It also sets the IPMI revision based on the _SRV
method if present.
I can't actually test this properly. The firmware I'm using on my
od1000 has the IPMI device in its ACPI tables. But I'm 99% certain
there
> Date: Sat, 21 Dec 2019 13:42:43 +0100
> From: Alexander Bluhm
>
> On Sat, Dec 21, 2019 at 04:10:03PM +0900, YASUOKA Masahiko wrote:
> > When I debug kernel with kernel core, backtrace command ends around
> > alltraps_kern_meltdown(). The following diff fixes this problem.
>
> I remember havin
The diff below contains a couple of improvements to dwiic(4). They're
mostly for making ipmi(4) on the Ampere/Lenovo arm64 boxes work
better. But they need testing on x86 machines with
keyboards.touchpads/touchscreens connected over i2c.
Most of the diff is there to properly implement SMBus bloc
ok?
Index: etc/etc.arm64/MAKEDEV.md
===
RCS file: /cvs/src/etc/etc.arm64/MAKEDEV.md,v
retrieving revision 1.4
diff -u -p -r1.4 MAKEDEV.md
--- etc/etc.arm64/MAKEDEV.md17 Dec 2019 13:08:55 - 1.4
+++ etc/etc.arm64/MAKEDEV.md
> Date: Thu, 26 Dec 2019 07:38:47 +0100
> From: Klemens Nanni
>
> Hardware RAID volume bootpaths are similar to Fibre channel ones in that
> they use the disk's WWID (lower 16 bit only) as SCSI target, e.g.
>
> /pci@400/pci@2/pci@0/pci@e/scsi@0/disk@w3aa32290d5dcd16c,0:a
>
> Currently dev
> Date: Thu, 26 Dec 2019 17:55:24 +0100
> From: Klemens Nanni
>
> On Thu, Dec 26, 2019 at 09:50:16AM +0100, Mark Kettenis wrote:
> > What happens if the bootpath doesn't specify a partition? Currently
> > we end up with bp->val[2] being zero in that case, which
> Date: Thu, 26 Dec 2019 19:02:26 +0100
> From: Klemens Nanni
>
> On Thu, Dec 26, 2019 at 06:25:10PM +0100, Mark Kettenis wrote:
> > Hmm, you really shouldn't end up there if you're booting by WWN. I
> > guess the
> >
> > bp->val[0] == sl
> From: Jeremie Courreges-Anglas
> Date: Sat, 28 Dec 2019 14:40:27 +0100
>
> We have a few ports (~12) patched because of shell script constructs
> like
>
> function usage()
> {
What is the #! for those scripts?
> which are rejected by our ksh. Indeed ksh only supports either
>
> usage
> Date: Mon, 30 Dec 2019 01:13:56 +0100
> From: Klemens Nanni
>
> Now that `ldomctl console ...' is implemented there is actually no need
> to print the device any longer, it is an implementation detail that
> should be hidden just like it is the case with vmctl.
>
> That also makes it fit nicel
> Date: Mon, 30 Dec 2019 18:59:35 +1000
> From: Jonathan Matthew
>
> On Sun, Dec 29, 2019 at 05:58:02AM +0100, Klemens Nanni wrote:
> > On Sun, Dec 29, 2019 at 01:59:38PM +1000, Jonathan Matthew wrote:
> > > I think we have the wrong size for the volume name, hence the difference
> > > between th
> Date: Mon, 30 Dec 2019 21:07:59 +0100
> From: Klemens Nanni
>
> The example in the manual implies that the download command also selects
> it:
>
> # ldomctl init-system ldom.conf
> # cd ..
> # ldomctl delete openbsd
> # ldomctl download openbsd
> # ldomctl list
>
> Date: Mon, 30 Dec 2019 22:14:20 +0100
> From: Klemens Nanni
>
> `ldomctl start|stop primary" silently exits zero not doing anything,
> `ldomctl panic primary" makes primary panic (and pulls guests down with
> it).
>
> The manual explicitly documents those commands for "guest" domains,
> code c
> Date: Tue, 31 Dec 2019 09:12:56 +1000
> From: Jonathan Matthew
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Mon, Dec 30, 2019 at 03:36:54PM +0100, Klemens Nanni wrote:
> > On Mon, Dec 30, 2019 at 06:59:35PM +1000, Jonathan Matthew wrote:
> > > Here's the Sol
> Date: Tue, 31 Dec 2019 03:26:13 +0100
> From: Klemens Nanni
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> This moves setup code from main() into its own function so instead of
> upfront it can be used only when and where needed.
>
> With the exception of `creat
> Date: Wed, 1 Jan 2020 09:53:39 -0500
> From: Todd Mortimer
>
> My CPU has a CCP that isn't in the known list, so add it and tell ccp
> about it.
>
> Tested on Ryzen 3900x.
>
> ok?
ok kettenis@
> Will commit a pcidevs regen immediately after.
>
>
> diff --git a/sys/dev/pci/ccp_pci.c b/sys/
> Date: Fri, 3 Jan 2020 20:18:46 +0100
> From: Klemens Nanni
>
> On Fri, Jan 03, 2020 at 08:04:10PM +0100, Mark Kettenis wrote:
> > No. If you messed this up in a previous commit, please fix it some
> > other way.
> The purpose of this diff is not to fix previously
> Date: Fri, 3 Jan 2020 20:42:11 +0100
> From: Klemens Nanni
>
> On Fri, Jan 03, 2020 at 08:28:54PM +0100, Mark Kettenis wrote:
> > Please no. Stupid sysadmins should stay away from that command ;).
> Do you want to scare them away?
>
> Fine with me, your call.
Th
> Date: Fri, 3 Jan 2020 21:46:29 +0100
> From: Klemens Nanni
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> With the hv_config() now in, `ldomctl init-system -n ldom.conf' to only
> parse configuration is trivial.
>
> It is usable as unprivileged user, no devices
> Date: Sat, 4 Jan 2020 16:15:22 +0100
> From: Martin Pieuchot
>
> `delay' is expressed in ms, however since tsleep_nsec(9) doesn't add a
> tick the conversions below might result in shorter sleeps. I'd
> appreciate if uthum(4) owners could test this diff and report back.
I'm not sure I underst
> Date: Fri, 3 Jan 2020 19:26:22 +
> From: Miod Vallat
>
> Although Open Firmware supports it, there is no way from OpenBSD to
> reboot with a specified boot command line, so drop vestigial support for
> it from boot().
Hmm, reboot(2) does allow us to pass flags. But you're right that
there
> Date: Sat, 4 Jan 2020 20:01:59 +0100
> From: Klemens Nanni
>
> On Fri, Jan 03, 2020 at 08:40:56PM +0100, Klemens Nanni wrote:
> > Manual update below for convenience but I want to hear feedback from
> > users of above mentioned machines before changing this either way.
> kettenis confirmed that
> Date: Sat, 21 Dec 2019 12:30:50 +0100 (CET)
> From: Mark Kettenis
>
> On arm64 systems, IPMI can actually attach using mmio. The diff below
> implements this. It also sets the IPMI revision based on the _SRV
> method if present.
>
> I can't actually test thi
> Date: Sun, 22 Dec 2019 16:55:59 +0100 (CET)
> From: Mark Kettenis
>
> The diff below contains a couple of improvements to dwiic(4). They're
> mostly for making ipmi(4) on the Ampere/Lenovo arm64 boxes work
> better. But they need testing on x86 machines wit
> Date: Sun, 5 Jan 2020 00:45:12 +0100
> From: Klemens Nanni
>
> On Thu, Dec 26, 2019 at 10:02:42PM +0100, Klemens Nanni wrote:
> > Solaris supports booting fallback images from "retained memory" which
> > is a relatively new feature introduced, it requires recent versions of
> > Solaris as well
> Date: Mon, 6 Jan 2020 17:21:01 -0600
> From: Scott Cheloha
>
> Sorry for the delay. I needed to think on this.
>
> On Fri, Jan 03, 2020 at 11:15:20AM +0100, Martin Pieuchot wrote:
> > On 02/01/20(Thu) 14:29, Scott Cheloha wrote:
> > > > On Jan 2, 2020, at 9:02 AM, Martin Pieuchot wrote:
> >
> Date: Thu, 9 Jan 2020 10:42:55 +0100
> From: Alexander Bluhm
>
> On Thu, Dec 26, 2019 at 08:12:50PM +0100, Alexander Bluhm wrote:
> > Any more concerns or can this be commited?
>
> Any ok?
>
> > Index: arch/amd64/amd64/db_trace.c
> > ===
> Date: Thu, 9 Jan 2020 14:01:32 +0100
> From: Alexander Bluhm
>
> On Thu, Jan 09, 2020 at 12:01:07PM +0100, Mark Kettenis wrote:
> > By splitting this out, the "retain the kernel lock" bit of the
> > comment doesn't make a lot of sense anymore...
>
&
> Date: Thu, 9 Jan 2020 21:53:09 +0100
> From: Klemens Nanni
>
> Each guest needs vcpu and memory, otherwise it's invalid.
> Each guest also needs at least one of vdisk, vnet or iodevice, otherwise
> it has nothing to boot from.
>
> Consider this example:
>
> # cat foo.conf
> domain
> Date: Fri, 10 Jan 2020 12:07:51 +0100
> From: Claudio Jeker
>
> On Sun, Dec 22, 2019 at 04:55:59PM +0100, Mark Kettenis wrote:
> > The diff below contains a couple of improvements to dwiic(4). They're
> > mostly for making ipmi(4) on the Ampere/Lenovo arm64 box
> Date: Sat, 11 Jan 2020 17:41:00 +0100
> From: Martin Pieuchot
>
> Before converting network timeouts to run in a thread context they were
> executed in a soft-interrupt handler. This design implied that timeouts
> were serialized.
>
> The current "softclock" thread runs on CPU0 to limit borde
The calculation uses 'char' to store a signed value. But on some
platforms 'char' is unsigned, and the calculation yields bogus results.
Fixed by the diff below.
ok?
Index: dev/ipmi.c
===
RCS file: /cvs/src/sys/dev/ipmi.c,v
retrie
> Date: Sun, 12 Jan 2020 11:40:23 +0100
> From: Klemens Nanni
>
> On Sat, Jan 04, 2020 at 09:27:30PM +0100, Klemens Nanni wrote:
> > CPU strides provide means to effectively bind guests to certain specific
> > phsyical cores by overallocating virtual CPUs (hardware threads) such
> > that the sum
> Date: Sun, 12 Jan 2020 13:09:23 +0100
> From: Martin Pieuchot
>
> Now that tsleep_nsec(9) has the same behavior as tsleep(9) the
> conversion be low should be safe.
>
> Ok?
ok kettenis@
> Index: uthum.c
> ===
> RCS file: /cvs/sr
> Date: Mon, 13 Jan 2020 10:59:30 +0100
> From: Klemens Nanni
>
> On Fri, Jan 03, 2020 at 08:30:42PM +0100, Mark Kettenis wrote:
> > Can we leave out the #ifdef __sparc64__? Unless somebody can come up
> > with a really good reason for it...
> The code should be safe
> From: Hrvoje Popovski
> Date: Mon, 13 Jan 2020 11:53:36 +0100
>
> Hi all,
>
> with today's snapshot i'm seeing acpipci log below in dmesg. is this ok?
> do i need to report it ?
Not if everything on these machines works ;)
The messages are debug information that will help diagnosing problems
> Date: Mon, 13 Jan 2020 13:20:45 +0100
> From: Martin Pieuchot
>
> vdsp(4) uses a workaround to not block forever in case the hypervisor
> doesn't generate an interrupt. The current behavior is to wait the
> smallest possible interval: one tick.
The hypervisor is known not to generate an inter
> Date: Mon, 13 Jan 2020 17:02:12 +0100
> From: Martin Pieuchot
>
> I'm facing a lock ordering issue while profiling the scheduler which
> cannot be solved without using a different lock for the global sleepqueue
> and the runqueues.
>
> The SCHED_LOCK() currently protects both data structures a
> Date: Tue, 14 Jan 2020 10:34:05 +1100
> From: Jonathan Gray
>
> On Mon, Jan 13, 2020 at 05:02:12PM +0100, Martin Pieuchot wrote:
> > I'm facing a lock ordering issue while profiling the scheduler which
> > cannot be solved without using a different lock for the global sleepqueue
> > and the run
> Date: Thu, 16 Jan 2020 10:52:06 +0100
> From: Martin Pieuchot
>
> Found while compiling sgi kernel:
>
> /sys/netinet/igmp.c:140:22: error: implicit conversion from 'int' to 'int8_t'
> (aka 'signed char') changes value from 148 to -108
> [-Werror,-Wconstant-conversion]
> ra-
> Date: Thu, 16 Jan 2020 14:27:42 +0100
> From: Klemens Nanni
>
> Just like vmctl(8), this implements the little convenience for ldomctl:
>
> $ doas ./obj/ldomctl start -c guest4
> Connected to /dev/ttyV3 (speed 9600)
> ...
>
> To avoid duplicate code, I moved the now comm
> Date: Thu, 16 Jan 2020 15:26:13 +0100
> From: Klemens Nanni
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Thu, Jan 16, 2020 at 02:27:42PM +0100, Klemens Nanni wrote:
> > Just like vmctl(8), this implements the little convenience for ldomctl:
> >
> > $ do
> Date: Fri, 17 Jan 2020 12:23:04 +0100
> From: Klemens Nanni
> Cc: tech
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Fri, Jan 17, 2020 at 10:01:08AM +, Andrew Grillet wrote:
> > Is there any possibility that the same -c option could be added to
> > > ldo
> Date: Thu, 16 Jan 2020 19:37:54 +0100
> From: Martin Pieuchot
>
> I'd like to import this new MI pseudo-driver and the framework it
> provides to instrument and inspect kernel internals.
>
> It is still under development and all the code is guarded under NDT, so
> it shouldn't impact GENERIC.
The attached diff fixes amdgpu(4) and might very well fix radeondrm(4)
as well. The problems with the hardware cursor are gone, various screen
corruptions no longer seem to happen and the laptop I have here suspends
and resumes now.
I still occasionally see some glitches playing youtube videos,
Todd C. Miller schreef op 2020-01-22 17:25:
On Wed, 22 Jan 2020 03:10:01 +0100, Mark Kettenis wrote:
The attached diff fixes amdgpu(4) and might very well fix radeondrm(4)
as well. The problems with the hardware cursor are gone, various
screen
corruptions no longer seem to happen and the
Theo de Raadt schreef op 2020-01-22 23:20:
this is not actually surprising. there are only about 3 majors which
can't
move around without problem. It is a MD detail, which is why tables
have
to know about it
ok
I sometimes wish we'd split the majors into MI and MD "ranges", but
that'd nee
Martin Pieuchot schreef op 2020-01-23 11:28:
I'd like to make progress towards interrupting multiple CPUs in order
to
one day make use of multiple queues in some network drivers. The road
towards that goal is consequent and I'd like to proceed in steps to
make
it easier to squash bugs. I'm cu
Patrick Wildt schreef op 2020-01-23 08:26:
Hi,
this is the second attempt of a diff that prepares acpivout(4) to work
with the X395. The previous one broke due to recursive ACPI locking.
So apparently we cannot change the brightness using the acpivout(4)
ACPI
methods. Instead we need to cal
Mike Larkin and I came up with the folowing diff that keeps mapping the
framebuffer early. We tested this on a small number of machines here
that have the framebuffer < 4GB.
It'd be great if we can confirm this also works on machine where it is >
4GB.
Thanks,
Mark? arch/amd64/compile/GENERIC.
David Gwynne schreef op 2020-01-25 01:28:
On 23 Jan 2020, at 10:38 pm, Mark Kettenis
wrote:
Martin Pieuchot schreef op 2020-01-23 11:28:
I'd like to make progress towards interrupting multiple CPUs in order
to
one day make use of multiple queues in some network drivers. The
road
to
Ted Unangst schreef op 2020-01-25 05:53:
Sometimes (particuarly if you are using apmd -z) the default polling
interval
of 10 minutes is a bit lazy and we fail to respond to low battery
situations
before they become no battery situations.
Perhaps something smarter could be done, but the simples
On 2020-02-08 20:15, Scott Cheloha wrote:
On Sun, Dec 22, 2019 at 01:17:56PM -0600, Scott Cheloha wrote:
lcd_softc.sc_delay's unit appears to be microseconds.
ok?
1 month bump.
While the diff looks ok to me, I can't test this until I have physical
access to my hppa machines.
Index: dev/lc
Stefan Sperling schreef op 2020-02-06 12:45:
At 36c3 I noticed roaming failures with iwm(4) where we would get stuck
trying to roam to a different AP. Debugging this with bluhm@ we found
that the reason it gets stuck is a non-zero refcount on the ic_bss
node.
When roaming, we wait for this ref
Nathanael Rensen schreef op 2020-01-29 15:47:
The diff below adds gpio(4) support to wbsio(4) for Nuvoton NCT5104D
(pcengines APU2). It is based on Matt Dainty's diff posted to this list
in November 2018:
https://marc.info/?l=openbsd-tech&m=154134941027009&w=2
A key difference from Matt Daint
Klemens Nanni schreef op 2020-02-05 21:35:
Straight forward diff to allow calling disks names:
$ cat ldom.conf
domain guest {
vcpu 4
memory 8G
vnet
vdisk "/var/ldom/guest.img"
vdisk "/var/ldom/miniroo
Jonathan Matthew schreef op 2020-02-10 13:19:
I'm trying to use aggr on top of nep(4), which has turned up a few
bugs.
Firstly, the nic appears to report rx errors in the second interrupt
state vector, which the driver doesn't expect, so I get this:
nep3: nep_intr 0 8 0
and then, since the int
Patrick Wildt schreef op 2020-01-26 06:50:
Hi,
on the Pinebook Pro the trackpad isn't working. The reason is that the
Y-coordinate is extracted twice. The first location has thevalue
correctly, the second location has it zeroed or garbage. This is
because when we iterate over the report, the
In order to fix a speculative execution issue on various ARM CPUs, the
OpenBSD/arm64 system call ABI has been changed. System calls now skip
the two instructions immediately following the system call
instruction. This allows us to insert a barrier that blocks the CPU
from speculating further with
> Date: Tue, 18 Feb 2020 15:08:49 +0100
> From: Martin Pieuchot
>
> ends up being included by 532 files. On amd64 this
> represents almost 1/3 of the 1674 kernel source files. So any change
> in a header it includes will result in a large number of rebuild.
>
> is one of these headers. In d
> Date: Fri, 21 Feb 2020 11:36:19 +0100
> From: Otto Moerbeek
>
> On Thu, Feb 20, 2020 at 09:02:32PM +0100, Otto Moerbeek wrote:
>
> > On Thu, Feb 20, 2020 at 08:20:13PM +0100, Otto Moerbeek wrote:
> >
> > > On Thu, Feb 20, 2020 at 07:48:25PM +0100, Otto Moerbeek wrote:
> > >
> > > > On Thu, F
> Date: Sat, 22 Feb 2020 12:44:12 +0100
> From: Stefan Sperling
>
> This is another attempt at improving usability with non-ASCII network IDs.
>
> Previous attempts have been rejected in part because entering UTF-8 strings
> is difficult to do for Americans and, to a lesser extent, Canadians.
>
> Date: Sat, 22 Feb 2020 10:40:13 +0900 (JST)
> From: YASUOKA Masahiko
>
> Hi,
>
> efiboot is using ACPI UID to determine the minor number of comX.
>
> In sys/arch/amd64/stand/efiboot/efiboot.c:
> 646 for (i = 0; i < sz / sizeof(EFI_HANDLE); i++) {
> 647 /*
> 648
> Date: Sun, 23 Feb 2020 18:50:54 +0900 (JST)
> From: YASUOKA Masahiko
>
> On Sat, 22 Feb 2020 13:02:48 +1100
> Jonathan Gray wrote:
> > On Fri, Feb 21, 2020 at 02:09:07PM +0900, YASUOKA Masahiko wrote:
> >> When efiboot starts the kernel, the video display becomes distorted
> >> and never recov
> Date: Sun, 1 Mar 2020 14:02:53 +0100
> From: Alexander Bluhm
>
> Hi,
>
> I had a 6.6 machine where a lot of git processes got stuck sleeping
> on "futex". The process holding the futex rwlock was this one.
>
> 33293 332235 1 2734 30x800483 fsleepgit
>
> It called mi_s
> Date: Sat, 9 May 2009 12:20:25 +0200
> From: Joachim Schipper
>
> The bioctl(8) man page helpfully suggests dd for zeroing out the
> disklabel etc. on the new disk. However, the command doesn't work, since
> OpenBSD's dd doesn't understand '1M'.
Uh, indeed it doesn't, but it does understand '1
> Date: Wed, 13 May 2009 12:20:44 +0200
> From: Otto Moerbeek
>
> On Wed, May 13, 2009 at 12:11:35PM +0200, Peter J. Philipp wrote:
>
> > On Wed, May 13, 2009 at 10:40:13AM +0200, Otto Moerbeek wrote:
> > > Come to think of it, why don't you just putchar(tolower(hf->name[i]))
> > > in a loop? Sa
> Date: Wed, 13 May 2009 14:28:06 +0200
> From: Otto Moerbeek
>
> On Wed, May 13, 2009 at 02:16:49PM +0200, Mark Kettenis wrote:
>
> > > Date: Wed, 13 May 2009 12:20:44 +0200
> > > From: Otto Moerbeek
> > >
> > > On Wed, May 1
While looking at eephy(4) I noticed that we're toggling the wrong bit
to enable auto crossover on the 88E3016 and 88E3082 PHYs. This diff
fixes that, but since this changes the bits we set, I'd like some
people to test this. Note that this only needs to be tested on
machines with 100baseTX varian
> Date: Sun, 5 Jul 2009 21:58:35 +0200
> From: Ingo Schwarze
>
> The header uses quad_t and uid_t.
> The type quad_t is a non-POSIX type defined in .
> The type uid_t is required by POSIX in .
>
> The header uses size_t.
> The type size_t is required by POSIX in .
>
> > no one has replied to
> Date: Sun, 05 Jul 2009 14:48:14 -0600
> From: Theo de Raadt
>
> > > If i understand correctly, headers using types from
> > > ought to include
> > > - unconditionally, if they are POSIX headers and the use of the
> > >type is mandated by POSIX
> > > - protected by __BSD_VISIBLE or the a
> Date: Sat, 18 Jul 2009 04:40:47 +0100
> From: Edd Barrett
>
> Hi Guys,
>
> I have managed to accelerate an Elite3D card on a Blade 1000. It
> requires a binary blob in order to work, the utility to do so is called
> afbinit and the port can be found here:
>
> http://students.dec.bmth.ac.uk/eb
> Date: Sat, 18 Jul 2009 14:10:39 +0100
> From: Edd Barrett
>
> On Sat, Jul 18, 2009 at 10:43:49AM +0200, Mark Kettenis wrote:
> > int newmode, oldmode;
> >
> > ioctl(fd, WSDISPLAYIO_GMODE, &oldmode);
> > newmode = WSDISPLAYIO_MODE_MAPP
1301 - 1400 of 3190 matches
Mail list logo
