Re: Crash in vm_terminate > vm_teardown > uvm_map_deallocate > uvm_unmap_remove

On Tue, Oct 02, 2018 at 08:21:39PM -0700, Greg Steuck wrote: > > Oh, if this is the issue then it's not "spinning". > > This is a different issue. This is a host crash rather than VMs getting > lost. > I'll give an update when I catch the spin. In the meantime, did the logs > describe the GCP

Re: Crash in vm_terminate > vm_teardown > uvm_map_deallocate > uvm_unmap_remove

On Tue, Oct 02, 2018 at 07:35:29PM -0700, Greg Steuck wrote: > We got "lucky" in a different way after enabling VMM_DEBUG. I captured some > details of a > crash. The fault address seems to be vm_map(=0x80b44200) + 0x100. > > The kernel is built with this config: > ci-openbsd$ cat

Re: vmd losing VMs

On Tue, Oct 02, 2018 at 11:02:57AM -0700, Greg Steuck wrote: > Dmitry, is there an easy way get at the VMs output? > > Here's dmesg from VMM_DEBUG-enabled kernel (built at "Add support for > RT3290 chipset by James Hastings."). No lockup thus far. > Yeah the output below shows normal behaviour.

Re: vmd losing VMs

On Mon, Oct 01, 2018 at 10:16:24PM -0700, Greg Steuck wrote: > Thanks Mike. > > I've upgraded from Sep 27th to Sep 29th snapshot and so far I haven't seen > the problem with: > > OpenBSD 6.4-beta (GENERIC.MP) #336: Sat Sep 29 08:13:15 MDT 2018 >

Re: vmd losing VMs

On Fri, Sep 28, 2018 at 05:01:27PM -0700, Greg Steuck wrote: > I've been running syzkaller for about a day now. It launches/kills VMs all > the time. Somewhere along the way vmd seems to have lost track of one of > its VMs. Notice how syzkaller ci-openbsd-main-1 is conspicuously missing > from

Re: add explanations of vmctl send command in vmctl.8

On Wed, Sep 19, 2018 at 12:22:21PM +0200, Solene Rapenne wrote: > Solene Rapenne wrote: > > This diff explains a little more about the send commands. > > send pauses the VM and send its memory + the start parameters. > > > > new diff with some changes, also thx bentley@ for telling me sentences

Re: Allow building amd64/i386 kernel with lld

On Fri, Sep 14, 2018 at 12:25:42AM +0200, Christian Weisgerber wrote: > Currently, building an amd64 or i386 kernel with lld breaks in > makegap.sh. It turns out that we already have the missing pieces > (gapdummy) on some other archs, so we can just copy them. > > With this, I can successfully

Re: vmd: add some NULL checks after {c,m}alloc()

On Tue, Sep 11, 2018 at 03:36:49PM +0800, Michael Mikonos wrote: > Hello, > > Sometimes vmd doesn't seem to check the result of malloc/calloc. > I tried to preserve the existing behavour w.r.t. return values > for the functions modified; some functions returned 1 on error > while others return

Re: vmd close stdin

On Mon, Sep 10, 2018 at 01:25:24AM +0200, Alexander Bluhm wrote: > Hi, > > vmd(8) may close file descriptor 0 as not all fd fields are properly > initialized with -1. While there avoid closing -1. > > ok? > ok mlarkin > bluhm > > Index: usr.sbin/vmd/vmd.c >

Re: vmd stdio /dev/null

On Sun, Sep 09, 2018 at 11:45:07PM +0200, Alexander Bluhm wrote: > Hi, > > Like the other proc.c daemons, vmd(8) children do not detach from > the terminal properly. > > ok? > Reads ok to me but reyk@ should approve. > bluhm > > Index: src/usr.sbin/vmd/proc.c >

Re: 6.4-current fatal protection fault in supervisor mode (under qemu)

On Tue, Sep 04, 2018 at 12:31:11AM -0700, Greg Steuck wrote: > I'm trying to build an OpenBSD image for deployment on GCE. Towards this > end I'm running a script on Debian which runs OpenBSD-snapshot in qemu. The > script worked a few times for 6.3 release and then failed once and worked > once

Re: polish prtc(4) slightly

On Wed, Aug 29, 2018 at 09:53:59AM +1000, David Gwynne wrote: > this has autoconf(9) allocatethe todr struct thing as part of a softc > instead of allocting it separately during attach. > > no functional change, just a shuffling of the deck chairs. > > ok? > ok mlarkin > Index: prtc.c >

Re: Match ACPI devices on both _HID and _CID

On Fri, Aug 24, 2018 at 11:21:01PM +0200, Mark Kettenis wrote: > ACPI devices typically have two methods that identify the device. > _HID returns a "hardware ID" and _CID returns a "compatible ID". The > idea is that _HID return an ID for the specific hardware. But if the > device is compatible

Re: Claiming framebuffers

On Sat, Aug 25, 2018 at 03:57:09PM +0200, Mark Kettenis wrote: > The last issue that keeps me from enabling radeondrm(4) on arm64 is > that I need to prevent simplefb(4) and radeondrm(4) from fighting over > te same framebuffer. We already have an ad-hoc solution for efifb(4) > on amd64. But I

Re: Allocate PCI BAR for radeondrm(4)

On Thu, Aug 23, 2018 at 10:59:58PM +0200, Mark Kettenis wrote: > > Date: Tue, 21 Aug 2018 23:34:38 +0200 (CEST) > > From: Mark Kettenis > > > > If firmware doesn't initialize the device, the BAR will be zero and > > mapping that address leads to "interesting" issues on many machines. > > This

Re: vmd/vmctl: allow to boot cdrom-only VMs

On Thu, Aug 23, 2018 at 11:05:40AM -0500, Todd T. Fries wrote: > This makes me wonder. Does it make sense to support booting a kernel without > disks? Some people have heard of the phrase 'diskless' ;-) > > Penned by Reyk Floeter on 20180822 13:35.23, we have: > | Hi, > | > | vmctl doesn't

Re: vmd/vmctl: allow to boot cdrom-only VMs

On Wed, Aug 22, 2018 at 08:35:23PM +0200, Reyk Floeter wrote: > Hi, > > vmctl doesn't allow to boot VMs with only a CDROM. I see no reason > for it and vmd already allows CDROM-only. > > OK? No objection, ok mlarkin. -ml > > Via https://twitter.com/wizardishungry/status/1032327323125727232

Re: vmctl: add unveil

On Tue, Aug 21, 2018 at 09:51:52PM -0700, Carlos Cardenas wrote: > Patch to unveil vmctl. > > Comments/OK? > > +--+ > Carlos reads ok to me > Index: main.c > === > RCS file: /home/los/cvs/src/usr.sbin/vmctl/main.c,v > retrieving

Re: Pass more EFI related information from bootloader to kernel

On Mon, Aug 06, 2018 at 11:38:28PM +0200, Mark Kettenis wrote: > I suspect that at some point in the future we'll have to bite the > bullet and call into EFI runtime services on amd64 as well. The diff > below paves the road by passing the necessary information from our > bootloader to the

Re: ahci@acpi: match on _CLS

On Mon, Jul 30, 2018 at 06:20:21PM +0200, Mark Kettenis wrote: > It seems that ARM SoC every vendor invents their own _HID/_CID for the > their AHCI implementation. Instead of adding all of these to an ever > growing list, we can match on _CLS instead which return the "PCI" >

Re: adding __func__ identifier to panic() calls in vmm.c

On Mon, Jul 09, 2018 at 07:08:14AM -0600, nayden wrote: > > Hi, > > Would this change make it simpler to diagnose a vmm crash? > > Nayden > sure, go ahead. > Index: arch/amd64/amd64/vmm.c > === > RCS file:

Re: vmctl: improve error message

On Tue, Jul 03, 2018 at 08:59:29AM -0600, Theo de Raadt wrote: > This incorrect codepath occurs in other places also. I think it > ends up using an EINVAL from some other operation. Quite a ways > earlier inside vmmaction(). Which is unrelated to the actual failure. > > The same problem is in

Re: xhci@acpi

On Mon, Jul 02, 2018 at 11:36:59AM +0200, Mark Kettenis wrote: > Totally straightforward. > > ok? > > ok mlarkin Just wondering if you need to update the man pages for ahci(4) and xhci(4) to include the "at acpi0" attachments? -ml > Index: arch/arm64/conf/GENERIC >

Re: arm64 acpi(4)

On Sun, Jul 01, 2018 at 06:13:43PM +0200, Mark Kettenis wrote: > Diff below actually enables acpi(4) on arm64. Mostly stubs for bits of code > that isn't needed on hardware-reduced ACPI. But the functions have to be > there for things to compile. > > This is enough to boot my MACCHIATOBin

Re: acpi(4) attach glue for amd64/i386

On Sun, Jul 01, 2018 at 04:59:47PM +0200, Mark Kettenis wrote: > Diff below moves the attach glue from acpi.c into acpi_machdep.c. > Gets rid of an #ifdef and helps me avoid an ugly hack on arm64. There > is some additional code duplication, but I think this is acceptable. > > ok? > ok

Re: pluart@acpi

On Sun, Jul 01, 2018 at 04:38:35PM +0200, Mark Kettenis wrote: > Since the ARM SBSA Generic UART is effectively a PL011 UART, the > expectation is that most arm64 servers will actually have pluart(4) as > their serial console instead of com(4). So we need a glue for > acpi(4). This provides that

Re: ahci@acpi

On Sun, Jul 01, 2018 at 02:15:04PM +0200, Mark Kettenis wrote: > Diff below makes it possible to attach ahci(4) at acpi(4) as required by > arm64 machines like the MACCHIATOBin and Overdrive 1000. > > ok? > ok mlarkin > > Index: dev/acpi/ahci_acpi.c >

Re: Another acpidump(4) fix

On Sat, Jun 30, 2018 at 08:43:18PM +0200, Mark Kettenis wrote: > The pointer to the DSDT may be 64-bit as well. In that case the > 32-bit field will be zero and we have to use the 64-bit field. > > ok? > > > Index: acpidump.c >

Re: com@acpi

On Sat, Jun 30, 2018 at 02:41:02PM +0200, Mark Kettenis wrote: > Diff below adds support for the com(4) driver to attach to acpi(4). > This is needed to support serial console on arm64 ACPI machines. This > diff is fairly complete. It looks at the SPCR table if present to > determine if the

acpi: don't fail GPE handler re-registration

Linux seems to permit GPE re-assignment (at least from what I can tell, the code is a bit convoluted). In the Surface Book AML, Microsoft provides an _L50 method as well as a _GPE method on the EC object that also returns 0x50. This makes no sense, since EC GPEs must be edge-triggered (and an _Lxx

Re: Test needed: Unlock 12 network-related syscalls

On Mon, Jun 25, 2018 at 01:29:36PM +0200, Martin Pieuchot wrote: > On 20/06/18(Wed) 13:13, Martin Pieuchot wrote: > > Diff below unlocks the following syscalls: > > > > recvmsg(2), recvfrom(2), accept(2), getpeername(2), getsockname(2), > > accept4(2), connect(2), bind(2), setsockopt(2),

Re: Add XSDT and arm64 support to acpidump(8)

On Sat, Jun 23, 2018 at 04:48:14PM +0200, Mark Kettenis wrote: > The diff below adds arm64 support to acpidump(8). It renames > bios_acpi_addr() into efi_acpi_addr() and duplicates the function > because on arm64 I just need to read a 64-bit integer I'm considering > changing amd64 to use a

Re: ACPI on OpenBSD/arm64

On Sat, Jun 23, 2018 at 04:32:21PM +0200, Mark Kettenis wrote: > The lates generation of 64-bit ARM server hardware seems to be > ACPI-only. This obviously fills me with a tremendous amount of joy. > ACPi is clearly superior to device trees. So much more superior that > they you have to embed

Re: [PATCH] vmm.c: missing comma

On Thu, Jun 21, 2018 at 01:15:57PM +0800, Kevin Lo wrote: > Hi, > > The diff below adds missing comma. This fixes compilation if we enable > VMM_DEBUG macro. > > Index: sys/arch/amd64/amd64/vmm.c > === > RCS file:

Re: dwiic(4) fix

On Tue, May 22, 2018 at 05:43:01PM +0200, Mark Kettenis wrote: > > Date: Mon, 21 May 2018 17:25:47 -0700 > > From: Mike Larkin <mlar...@azathoth.net> > > > > On Mon, May 21, 2018 at 12:44:47PM +0200, Mark Kettenis wrote: > > > The diff below fixes I2C_OP_WR

Re: SMCCC 1.1 support for psci(4)

On Tue, May 22, 2018 at 07:35:59PM +0200, Mark Kettenis wrote: > > Date: Fri, 4 May 2018 20:14:38 +0200 (CEST) > > From: Mark Kettenis > > > > > Date: Tue, 1 May 2018 11:55:00 +0200 (CEST) > > > From: Mark Kettenis > > > > > > So after adding a

Re: dwiic(4) fix

On Mon, May 21, 2018 at 12:44:47PM +0200, Mark Kettenis wrote: > The diff below fixes I2C_OP_WRITE_WITH_STOP operations. Currently we > run the read completion code for those operations, but since there is > no data to read, this fails. Instead, this waits until a stop is > detected. That

Re: acpithinkpad(4): port-replicator hkey event

On Mon, May 21, 2018 at 12:55:13PM +0200, Tobias Tschinkowitz wrote: > On Mon, May 21, 2018 at 11:56:37AM +0200, Stefan Sperling wrote: > > On Mon, May 21, 2018 at 11:35:54AM +0200, Tobias Tschinkowitz wrote: > > > As the last diff still had formatting issues i fixed that. > > > > OK by me. > >

Re: sdhc(4) ACPI improvements

On Mon, May 21, 2018 at 01:22:50AM +0200, Mark Kettenis wrote: > Diff below does two things: > > 1. Put controllers and child devices into _PS0. It seems the BIOS is >supposed to deliver them to us in that state, but apparently some >BIOSen don't do that. > > 2. Override the card detect

Re: dwiic acpi improvement

On Sun, May 20, 2018 at 08:51:03PM +0200, Mark Kettenis wrote: > > Date: Sat, 19 May 2018 18:48:15 -0700 > > From: Mike Larkin <mlar...@azathoth.net> > > > > On Sat, May 19, 2018 at 09:44:22PM +0200, Mark Kettenis wrote: > > > I'm working on some i2

Re: Wake the acpi thread up for gpio events

On Sun, May 20, 2018 at 11:28:14AM +0200, Mark Kettenis wrote: > > Date: Sun, 20 May 2018 10:44:49 +0200 > > From: Martin Pieuchot > > > > On 19/05/18(Sat) 21:39, Mark Kettenis wrote: > > > Without the wakeup, the event doesn't get scheduled until some other > > > event wakes

Re: dwiic acpi improvement

On Sat, May 19, 2018 at 09:44:22PM +0200, Mark Kettenis wrote: > I'm working on some i2c drivers that are closely tied to acpi. These > drivers need to call into acpi and need to know their acpi node. The > diff below makes dwiic(4) pass the acpi node as the cookie to its > children. This

Re: vmctl: sync usage with manual page

On Sat, May 19, 2018 at 03:26:36PM +0200, Klemens Nanni wrote: > Sort vmctl's usage alphabetically, use "path" instead of "filename", > "image" or "disk" and "id" instead of "name" as argument name to be > consistent and in sync with vmctl.8. > > Zap a trailing asterisk as well as double qoutes

Re: Fix acpi(4) GeneralSerialBus implementation

On Sat, May 19, 2018 at 09:25:47AM +0200, Mark Kettenis wrote: > > Date: Fri, 18 May 2018 22:21:06 -0700 > > From: Mike Larkin <mlar...@azathoth.net> > > > > > @@ -2564,6 +2564,14 @@ aml_rwgsb(struct aml_value *conn, int bp > > > cmdl

Re: Fix acpi(4) GeneralSerialBus implementation

On Fri, May 18, 2018 at 08:53:41PM +0200, Mark Kettenis wrote: > Turns out there is an alternate way to encode > AttribBytes/AttribRawBytes (and AttribRawProcessBytes) that I didn't > implement. In fact our parsing of fields has always been wrong when > this alternative encoding is present. But

Re: acpi(4): GenericSerialBus OperationRegion support

is known to have something different related to > enumerating devices and management of battery that gave some trouble on past > kernels" https://github.com/stockmind/gpd-pocket-ubuntu-respin/issues/63 > > 2018-05-17 15:09 GMT+08:00 Mike Larkin <mlar...@azathoth.net>: > > Just to follow up, this did not fix the battery issue (still "absent" and > > 0%) on the GPD.

Re: acpi(4): GenericSerialBus OperationRegion support

On Mon, May 14, 2018 at 08:22:47PM +0200, Mark Kettenis wrote: > > Date: Sun, 13 May 2018 22:27:09 -0700 > > From: Mike Larkin <mlar...@azathoth.net> > > > > On Sun, May 13, 2018 at 03:57:50PM +0200, Mark Kettenis wrote: > > > The diff below implemen

Re: acpi(4): GenericSerialBus OperationRegion support

On Mon, May 14, 2018 at 08:22:47PM +0200, Mark Kettenis wrote: > > Date: Sun, 13 May 2018 22:27:09 -0700 > > From: Mike Larkin <mlar...@azathoth.net> > > > > On Sun, May 13, 2018 at 03:57:50PM +0200, Mark Kettenis wrote: > > > The diff below implemen

Re: Implement LoadTable() in our AML interpreter

On Wed, May 16, 2018 at 10:32:27PM +0200, Mark Kettenis wrote: > Diff below implements LoadTable(). The implementation is somewhat > incomplete and will error out if the RootPathString or > ParameterPathString arguments are given. It is not entirely clear > what we should do in that case and I

Re: acpi(4): GenericSerialBus OperationRegion support

On Sun, May 13, 2018 at 03:57:50PM +0200, Mark Kettenis wrote: > The diff below implements functionality that allows AML access to > devices that sit on an I2C bus. Only a subset of the various access > methods is implemented; some of the missing ones are not a very good > fit for our AML

Re: Spinning time is not System time

On Wed, May 09, 2018 at 01:36:08PM +0200, Martin Pieuchot wrote: > On 08/05/18(Tue) 18:03, Martin Pieuchot wrote: > > Diff below, gypped from jmatthew@, allows us to see how much time CPUs > > spend spinning on a mutex or on the KERNEL_LOCK(). > > > > On my sparc64 with 16 CPUs, top(1) now

Re: acpithinkpad(4): port-replicator hkey event

On Fri, May 04, 2018 at 08:28:04PM +0200, Tobias Tschinkowitz wrote: > Hi @tech, > > i thought it would be a good idea to delegate the port-replicator > docking event to the sysctl(2) hw.sensors substree so that if the > thinkpad gets docked/undocked one could react to it by using > sensorsd(8).

Re: vmd: def nitems() locally

On Mon, Apr 30, 2018 at 07:49:20PM -0300, Gleydson Soares wrote: > hi, > > following diff defines nitems locally and stop > including Has this been done elsewhere in the tree? Is this the new paradigm we will be adopting? I don't have a strong opinion one way or the other, just want to be

Re: [vmd] recevied -> received in error message

On Fri, Apr 20, 2018 at 09:56:58PM +0200, llgx...@gmail.com wrote: > Hi, > > There seems to be a typo in vmd.c: > > Index: vmd.c > === > RCS file: /cvs/src/usr.sbin/vmd/vmd.c,v > retrieving revision 1.82 > diff -u -p -u -p -r1.82

Re: Add AMD 15h/3xh and Kaveri to pcidevs

On Thu, Apr 19, 2018 at 11:26:10AM -0700, Carlos Cardenas wrote: > Howdy. > > This patch adds AMD 15h/3xh (i.e. A8-7670K) and Kaveri devices. > > dmesg and patch attached. > > Comments. Ok? > > +--+ > Carlos ok mlarkin but you might check with jsg to see if he is ok with the graphics parts

Re: vmd: drive i8253 with monotonic clock

On Fri, Apr 06, 2018 at 06:46:22PM -0500, Scott Cheloha wrote: > 1 month bump. > Sorry for the delay. ok mlarkin@ > > On Mar 9, 2018, at 2:31 PM, Scott Cheloha <scottchel...@gmail.com> wrote: > > > >> On Sun, Feb 18, 2018 at 09:34:50PM -0800, Mike Larkin wrote:

Re: vmd(4) close vmm parent socket

On Fri, Apr 13, 2018 at 11:29:06AM +0200, Martijn van Duren wrote: > Hello tech@, > > Playing with vmd I noticed that a vm process has vmm's socket to the > parent process still open. > > Patch below works for me. > > OK? > > martijn@ > > Index: vmm.c >

Re: try to map 64-bit mem space first

On Mon, Apr 09, 2018 at 08:27:49PM +0200, Mark Kettenis wrote: > > Date: Mon, 9 Apr 2018 18:31:49 +0200 > > From: Patrick Wildt > > > > Hi, > > > > some (probably newer) re(4) cards don't have the 32-bit memory BAR that > > we try to map first. Instead there's a 64-bit

Re: Make pcidump(8) print BARs for PCI bridges too

On Sun, Apr 08, 2018 at 01:57:25PM +0200, Mark Kettenis wrote: > ok? > > Index: pcidump.c > === > RCS file: /cvs/src/usr.sbin/pcidump/pcidump.c,v > retrieving revision 1.46 > diff -u -p -r1.46 pcidump.c > --- pcidump.c 31 Aug 2017

Re: Looking for testers for em(4) quirks patch

On Mon, Apr 02, 2018 at 11:52:08AM +0200, Stefan Fritsch wrote: > Hi, > > We have seen problems with em on i219V and i219LM. For example, "Hardware > Initialization Failed" if no cable is plugged in during boot, or watchdog > timeouts / hangs until next boot if the cable is removed while data

Re: sparc64 softraid boot: workaround for memory leak

On Thu, Mar 29, 2018 at 09:21:16AM +0200, Mark Kettenis wrote: > > Date: Wed, 28 Mar 2018 23:46:49 -0700 > > From: Mike Larkin <mlar...@azathoth.net> > > > > On Thu, Mar 29, 2018 at 08:40:27AM +0200, Stefan Sperling wrote: > > > On Mon, Mar 12, 2018 at

Re: sparc64 softraid boot: workaround for memory leak

On Thu, Mar 29, 2018 at 09:21:16AM +0200, Mark Kettenis wrote: > > Date: Wed, 28 Mar 2018 23:46:49 -0700 > > From: Mike Larkin <mlar...@azathoth.net> > > > > On Thu, Mar 29, 2018 at 08:40:27AM +0200, Stefan Sperling wrote: > > > On Mon, Mar 12, 2018 at

Re: sparc64 softraid boot: workaround for memory leak

On Thu, Mar 29, 2018 at 08:40:27AM +0200, Stefan Sperling wrote: > On Mon, Mar 12, 2018 at 11:38:14AM +0100, Stefan Sperling wrote: > > I haven't had any feedback on the previous diff. However, I felt it > > was a bit of a hack, so I tried to come up with a cleaner solution. > > Anyone? Can this

Re: acpicmos(4) adding support for SystemCMOS OperationRegions

On Sat, Mar 24, 2018 at 12:04:06PM +0100, Mark Kettenis wrote: > I have a HP laptop that unconditionally reads from a SystemCMOS > OperationRegion. That's a bug in the AML; it should check whether the > region is available before accessing it. But crashing is a bit harsh. > There have been a

Re: Kernel size beyond 16 MB on amd64

On Tue, Mar 13, 2018 at 04:15:23PM +0100, Franco Fichtner wrote: > > > On 13. Mar 2018, at 4:04 PM, Ted Unangst wrote: > > > > Franco Fichtner wrote: > >> What can we do to help? > > > > Write smaller code... > > Fair enough. ;) > > On a more serious note, I'm referring

Re: Kernel size beyond 16 MB on amd64

On Mon, Mar 12, 2018 at 05:50:42PM +0100, Franco Fichtner wrote: > Hi, > > With regard to a commit[1] by Theo in 2013, several questions > in the years before and a partial lift of the limitation on > i386 a while back (2015?) I'd like to ask what the future plans > are for OpenBSD. > > Peeking

Re: workaround for buggy bios_memmap?

On Tue, Mar 06, 2018 at 01:46:58PM +0900, Naoki Fukaumi wrote: > Hi tech@, > > I'm using FreeBSD bhyve to run OpenBSD/amd64 VM for testing biosboot. > (well, I know efiboot works fine on bhyve, but I want to try biosboot) > > it seems bhyve's BIOS has buggy(?) entry in bios_memmap(E820 table). >

Re: vmctl: clarify console error message

On Sun, Feb 25, 2018 at 06:30:10PM -0800, Carlos Cardenas wrote: > Attached patch clears up an ambiguous error message when attaching to a > console fails. > > The vm id is not guaranteed to be populated. > > Comments? Ok? > > +--+ > Carlos > Index: vmctl.c >

Re: vmd: drive i8253 with monotonic clock

On Sun, Feb 18, 2018 at 07:42:10PM -0600, Scott Cheloha wrote: > On Sun, Feb 18, 2018 at 02:44:43PM -0800, Mike Larkin wrote: > > On Sun, Feb 18, 2018 at 12:00:01PM -0600, Scott Cheloha wrote: > > > Hi, > > > > > > Is it bad if the olatch counts up if the hos

Re: vmd: drive i8253 with monotonic clock

On Sun, Feb 18, 2018 at 12:00:01PM -0600, Scott Cheloha wrote: > Hi, > > Is it bad if the olatch counts up if the host's wall clock > is set backward? Or if the olatch makes a big jump for > the same reason? > > Serious question: I don't have any EPT hardware to test > this (sorry). > > While

Re: rc.d/vmd - wait for vms to shutdown

On Sat, Feb 17, 2018 at 08:36:41PM +, Stuart Henderson wrote: > On 2018/02/17 10:47, Mike Larkin wrote: > > On Sat, Feb 17, 2018 at 10:10:37AM +, Stuart Henderson wrote: > > > On 2018/02/16 17:55, Aaron Bieber wrote: > > > > Hola, > > > > >

Re: rc.d/vmd - wait for vms to shutdown

On Sat, Feb 17, 2018 at 10:10:37AM +, Stuart Henderson wrote: > On 2018/02/16 17:55, Aaron Bieber wrote: > > Hola, > > > > Here is a stab at telling /etc/rc.d/vmd to wait for vms to shutdown > > before killing vmd. > > > > Since there is no linux vmmci layer - linux machines still get

Re: vmctl show

On Sun, Feb 11, 2018 at 12:51:57AM +0100, Peter Hessler wrote: > My fingers have typed "vmctl show" instead of "vmctl status" for over a > year now, so add it as an alias. > > OK? > > > Index: main.c > === > RCS file:

Re: tidy up get_hibernate_io_function

On Sat, Feb 10, 2018 at 02:51:55PM +1000, Jonathan Matthew wrote: > It's hard to see exactly what the dv->dv_parent->etc. checks are doing. > Before adding sdmmc I'd like to tidy up a bit. > > ok? > Reads ok to me, and thanks for the cleanup. ok mlarkin if you didn't already commit this. >

Re: Kill old x86 ASM mutex code

On Fri, Feb 09, 2018 at 09:06:21PM +0100, Martin Pieuchot wrote: > i386 and amd64 have been using the MI mutex code for some time now > without problem. Time to remove the old assembly code, ok? > no objection here. ok mlarkin > Index: arch/amd64/amd64/genassym.cf >

Re: Additional AMD CPUID bits

On Fri, Feb 09, 2018 at 01:11:41PM +1100, Jonathan Gray wrote: > Additional AMD CPUID bits documented in > "Processor Programming Reference (PPR) for AMD Family 17h > Model 01h, Revision B1 Processors" > sure > Index: i386/include/specialreg.h >

Re: fixing kvm lapic hangs

On Thu, Feb 08, 2018 at 04:32:29PM +1300, Jonathan Matthew wrote: > This diff (most of which has been around for a while) changes delay_func > when running in KVM to use pvclock (effectively the TSC) to determine when to > stop spinning. Since this is done in a KVM-specific driver, it won't have

Re: fixing kvm lapic hangs

On Thu, Feb 08, 2018 at 04:32:29PM +1300, Jonathan Matthew wrote: > This diff (most of which has been around for a while) changes delay_func > when running in KVM to use pvclock (effectively the TSC) to determine when to > stop spinning. Since this is done in a KVM-specific driver, it won't have

Re: amd64: much earlier Intel microcode loading

On Mon, Feb 05, 2018 at 11:02:27AM +1300, Patrick Wildt wrote: > On Wed, Jan 31, 2018 at 05:12:03PM +0100, Patrick Wildt wrote: > > Hi, > > > > this diff allows us to load the Intel microcode much earlier. So far > > we load it after the CPUs have identified and then have to update the > > CPU

Re: ifconfig: actually enable WPA if 802.1x is requested

On Thu, Feb 01, 2018 at 09:50:09PM +0100, Stefan Sperling wrote: > mlarkin found the hard way that 'ifconfig iwn0 wpaakms 802.1x' doesn't > actually enable WPA, which means instead people need to type this to > make it work: ifconfig iwn0 wpa wpaakms 802.1x > > This diff saves 802.1x users 4

Re: amd64: much earlier Intel microcode loading

On Wed, Jan 31, 2018 at 05:12:03PM +0100, Patrick Wildt wrote: > Hi, > > this diff allows us to load the Intel microcode much earlier. So far > we load it after the CPUs have identified and then have to update the > CPU flags afterwards. This is not good since we have to assume that > those

Re: VMD: vioscsi - fix large iso support

On Thu, Jan 18, 2018 at 10:32:31PM -0800, Carlos Cardenas wrote: > Howdy. > > Attached is a patch to fix handling images > 4GB support in Linux. I > confused image size vs blocks to determine when to send UINT32_MAX > and trigger a READ_CAPACITY_16. > > Identified by mlarkin@ > > Comments? Ok?

Re: inteldrm(4) tests needed

On Sun, Jan 14, 2018 at 11:15:39PM -0800, Mike Larkin wrote: > On Mon, Jan 15, 2018 at 01:02:58AM +0100, Mark Kettenis wrote: > > The diff below adopts more of the Linux code to manage i2c > > transactions on hardware supported by inteldrm(4). The i2c stuff is > > reponsible

Re: VMD: vioscsi - add REPORT_LUNS opcode

On Mon, Jan 15, 2018 at 08:55:26PM -0800, Carlos Cardenas wrote: > Howdy. > > Attached is a patch that includes handling the REPORT_LUNS opcode which > is used by SeaBIOS 1.11.x . > > Comments? Ok? > > +--+ > Carlos lgtm, go for it (and thanks!) > Index: vioscsi.c >

Re: inteldrm(4) tests needed

On Mon, Jan 15, 2018 at 01:02:58AM +0100, Mark Kettenis wrote: > The diff below adopts more of the Linux code to manage i2c > transactions on hardware supported by inteldrm(4). The i2c stuff is > reponsible for detecting panels and monitors, so it is somewhat > important that this works right.

Re: VMD: vioscsi refactor

On Sun, Jan 14, 2018 at 05:15:54PM -0800, Carlos Cardenas wrote: > Howdy. > > Attached is a patch that refactors the vioscsi driver (in particular, > the vioscsi_notifyq function). > > Each opcode is now handled in it's respective function > (vioscsi_handle_xxx). Which means, it's now easier to

Re: vmd: allow vm with "cdrom" but no disk

On Wed, Jan 10, 2018 at 02:00:57PM +, Stuart Henderson wrote: > Currently we require either "kernel" or "disk", but there may be > some viable use cases where just a CDROM image is given. This adjusts > the check to avoid bailing in that case. > > OK? > sure > Index: vmd.c >

Re: VMD: add regress tests for cdrom keyword

On Sat, Jan 06, 2018 at 07:33:16PM -0800, Carlos Cardenas wrote: > Attached are regress tests for the cdrom keyword. > > Comments? Ok? > > +--+ > Carlos seems ok to me > Index: Makefile > === > RCS file:

Re: VMD: revise check for regular files on disks

On Fri, Jan 05, 2018 at 08:26:21AM +0100, Jeremie Courreges-Anglas wrote: > On Wed, Jan 03 2018, Carlos Cardenas wrote: > > Howdy. > > > > Attached is a patch to address a TOCTOU issue with checking to > > ensure disks are regular files, reported by jca@ . > > > > Comments?

Re: VMD: revise check for regular files on disks

On Thu, Jan 04, 2018 at 07:14:54AM -0800, Carlos Cardenas wrote: > Mike Larkin <mlar...@azathoth.net> wrote: > > > On Wed, Jan 03, 2018 at 08:03:56PM -0800, Carlos Cardenas wrote: > > > Howdy. > > > > > > Attached is a patch to address a TOC

Re: VMD: revise check for regular files on disks

On Wed, Jan 03, 2018 at 08:03:56PM -0800, Carlos Cardenas wrote: > Howdy. > > Attached is a patch to address a TOCTOU issue with checking to > ensure disks are regular files, reported by jca@ . > > Comments? Ok? > > +--+ > Carlos > Index: config.c >

Re: llvm: fix i386 floating point compiler bug

On Mon, Dec 25, 2017 at 12:52:56AM +0100, Patrick Wildt wrote: > Hi, > > gerhard@ found a bug in LLVM's i386 code. He noticed that some floating > point instructions were "optimized" and thus reordered between other FP > instructions that changed floating point modes, so that those reordered >

Re: efiboot: boot i386 kernel (part 1)

On Sun, Dec 17, 2017 at 12:17:26PM -0800, Mike Larkin wrote: > On Sun, Dec 17, 2017 at 08:34:52PM +0100, Patrick Wildt wrote: > > Hi, > > > > I had been looking into booting a 32-bit kernel with efiboot and the > > first thing I stumbled upon is that when we jump b

Re: efiboot: boot i386 kernel (part 1)

On Sun, Dec 17, 2017 at 08:34:52PM +0100, Patrick Wildt wrote: > Hi, > > I had been looking into booting a 32-bit kernel with efiboot and the > first thing I stumbled upon is that when we jump back into 32-bit mode > we don't disable the Long Mode Extension. Thus when the i386 kernel > turns on

Re: clock_gettime: add CLOCK_BOOTTIME clockid

On Thu, Dec 14, 2017 at 06:47:02PM -0600, Scott Cheloha wrote: > Hi, > > Attached is a diff adding a new clockid, CLOCK_BOOTTIME, for use with > clock_gettime(2). The value of CLOCK_BOOTTIME is the time elapsed > since the system booted, i.e. the system uptime. The diff puts it to > use in

Re: background scan for iwn(4)

On Wed, Dec 13, 2017 at 05:17:41PM +0100, Stefan Sperling wrote: > Since nobody is reporting problems with iwm(4), I took some time to write the > corresponding diff for iwn(4) as well. I hope this increases test coverage :) > > Works for me on: > iwn0 at pci3 dev 0 function 0 "Intel Centrino

Re: Change bcopy to memcpy (i386 VIA PadLock driver)

On Wed, Dec 13, 2017 at 10:23:46PM +0100, Frederic Cambus wrote: > Hi tech@, > > This diff changes bcopy to memcpy in the i386 version of the VIA PadLock > driver. It was done a while ago in the amd64 version of the driver. > > Comments? OK? > ok mlarkin > Index: sys/arch/i386/i386/via.c >

Re: ddb(4) userland trace and SMAP

On Thu, Dec 07, 2017 at 11:43:09AM +0100, Martin Pieuchot wrote: > On 05/12/17(Tue) 14:52, Visa Hankala wrote: > > On Tue, Dec 05, 2017 at 11:32:53AM +0100, Martin Pieuchot wrote: > > > On 04/12/17(Mon) 12:24, Martin Pieuchot wrote: > > > > Since SMAP is enabled ddb(4)'s 'trace /u' and 'trace /p'

Re: ddb(4) userland trace and SMAP

On Mon, Dec 04, 2017 at 12:24:00PM +0100, Martin Pieuchot wrote: > Since SMAP is enabled ddb(4)'s 'trace /u' and 'trace /p' for a userland > processes result, as expected, in page faults. > > Diff below disable SMAP for the duration of the command. This allows us > to see any possible frame

Re: Driver for Bosch motion sensors

On Thu, Nov 30, 2017 at 02:29:58AM +0100, Mark Kettenis wrote: > Driver name is bgw(4). Found on a Lenovo 2-in-1 laptop. > > ok? > Man page? Otherwise ok mlarkin. -ml > Index: dev/i2c/bmc150.c > === > RCS file: dev/i2c/bmc150.c

<    1   2   3   4   5   6   7   >