Speedup sdhc(4)

The diff below implements some speedups for sdhc(4). In particular: * Implement high speed mode * Implement support for 4-bit and 8-bit busses * Use DMA for block transfers High speed mode and wider bus support are only used for (e)MMC for now, but DMA support should benefit SD cards as well.

Re: Speedup sdhc(4)

> Date: Thu, 28 Apr 2016 12:28:59 +0200 (CEST) > From: Mark Kettenis <mark.kette...@xs4all.nl> > > The diff below implements some speedups for sdhc(4). In particular: > > * Implement high speed mode > * Implement support for 4-bit and 8-bit busses > * Use DMA for b

Re: static in ze kernel

> Date: Thu, 28 Apr 2016 13:50:53 +0200 > From: Martin Pieuchot > > The reason why we do not use 'static' in the kernel is no longer valid > since all our platforms are ELF. ddb(4) handle them just fine. > > Here's an example after setting 'static' in the uhci(4) driver: > >

Re: static in ze kernel

> Date: Fri, 29 Apr 2016 13:41:00 +0200 > From: Martin Pieuchot <m...@openbsd.org> > > On 28/04/16(Thu) 14:49, Mark Kettenis wrote: > > > Date: Thu, 28 Apr 2016 13:50:53 +0200 > > > From: Martin Pieuchot <m...@openbsd.org> > > > > &

Re: sched_init_cpu() fix

> Date: Fri, 29 Apr 2016 13:59:50 +0200 > From: Martin Pieuchot > > 3 architectures make the scheduler aware of secondary CPUs before they > can really execute anything. This is bad because during the boot > process threads will be put on their run queues. That means that on

longjmp without sigreturn on sparc64

Diff below simplifies setjmp(3) and longjmp(3) on sparc64 by not using sigreturn(2). This basically uses the logic from _setjmp(3) and _longjmp(3) to save and restore the state (but additionally saves and restores the signal mask). I believe this may make us lose the capability to longjmp() out

Re: Speedup sdhc(4)

> From: John Troy <j...@noxi.us> > Date: Fri, 29 Apr 2016 11:56:24 -0400 > > On 4/28/16 2:30 PM, Mark Kettenis wrote: > > So here are just the bits that add DMA support. Since Theo likes this > > so much, I'd like to move forward with this. > > > > ok?

Re: machine slow with latest snapshot (bufcache related?) on sparc64

> Date: Sat, 30 Apr 2016 11:34:59 +0100 > Content-Disposition: inline > > Try sp...@openbsd.org Markus. Not a particularly useful suggestion for something that doesn't look like an problem that is specific to sparc64.

sdmmc bus width support

The diff below adds support for changing the bus width to the sdmmc subsystem and the sdhc(4) controller. By default controllers and card use a 1-bit bus. But most SD cards actually have support fora 4-bit bus. This can be checked by looking atthe SCR register. In theory using the 4-bit bus

Re: Speedup sdhc(4)

> Date: Thu, 28 Apr 2016 12:28:59 +0200 (CEST) > From: Mark Kettenis <mark.kette...@xs4all.nl> > > The diff below implements some speedups for sdhc(4). In particular: > > * Implement high speed mode > * Implement support for 4-bit and 8-bit busses > * Use DMA for b

Re: net80211: support devices which scan all bands

> Date: Fri, 20 May 2016 11:19:26 +0200 > From: Stefan Sperling > > The new iwm(4) firmware (see [1]) scans 2GHz and 5 GHz bands in one go. > [1] http://marc.info/?l=openbsd-tech=146356530605833=2 > > Our net80211 stack isn't set up to handle this correctly. > With the new

Match boot/root disk based on DUID

Diff below changes setroot() such that if bootduid is initialized (by MD code) it tries to find a disk with a matching DUID. If it finds such a disk, it will use that disk as the root device. Perhaps it should only do this if bootdv == NULL? Thoughts? ok? Index: subr_disk.c

Re: wsmouse_input: hidms, pms

> From: Ulf Brosziewski > Date: Sat, 14 May 2016 16:46:55 +0200 > > The new input-processing functions of wsmouse seem to work well > for touchpads, and it might be time to update the mouse drivers > now. I start with the two drivers that I could test myself, hidms >

Two fixes for eeprom -p

I'm making eeprom(8) work on FDT-enabled armv7 platforms. Those are little-endian, but the FDT is defined to be big-endian. So eeprom(8) needs to byteswap 32-bit "cells" for printing. The second bit makes sure we zero the op_name when we start enumerating properties. Without this we run the

Re: maxds(4) return on attach error

> Date: Thu, 12 May 2016 22:31:37 +0200 > From: Marcus Glocker > > On my G5 the maxds(4) control register read fails. I guess because > there is no such chip on the mainboard though the eeprom -p claims > there is one (or it's broken). > > In case maxds(4) can't read the

Re: iwm: rx dma init fix

> Date: Tue, 17 May 2016 18:34:19 +0200 > From: Stefan Sperling > > According to a comment in iwlwifi: > > * Clearing FH_MEM_RCSR_CHNL0_CONFIG_REG to 0 turns off Rx DMA. > * Driver should poll FH_MEM_RSSR_RX_STATUS_REG for > * FH_RSSR_CHNL0_RX_STATUS_CHNL_IDLE (bit 24)

Re: iwm nitpicks

> Date: Tue, 17 May 2016 19:03:05 +0200 > From: Stefan Sperling > > This diff addresses some of my nitpicks in iwm: > > Move some declarations to if_iwmreg.h so we can use iwm_phy_db_* prototypes. > Remove redundant declaration of iwm_send_phy_db_data(). > Remove pointless

Re: opendev and pledge: "privsep" for dumpfs(8)

> Date: Sat, 14 May 2016 17:07:45 +0200 > From: Theo Buehler > > Here's a new version with lots of help and input from semarie, thanks! > Besides lots of small tweaks, the main improvements are: > > * fork one pledged child per fs which reads the data. > * pipe the data to

armv7 bus_dmamap_sync(9) fix

So Theo's SROP mitigation diff made my armv7 machine completely unstable. Filesystem-related panics, random core dumps, files with blocks of zeroes on them, etc. Looking at the changes in question, there is no way they're responsible for this behavior. This smells like cache-related bug

Re: armv7 bus_dmamap_sync(9) fix

> Date: Mon, 16 May 2016 18:32:53 +1000 > From: Jonathan Gray > > After consulting an older version of the ARM ARM it seems the cp15 > barriers were introduced with armv6 so just do the compiler hint. ok kettenis@ > Index: atomic.h >

Re: Headers cleanup + use getprogname() for test(1)

> Date: Sat, 14 May 2016 13:08:54 +0200 > From: Frederic Cambus > > Hi tech@, > > Headers cleanup + use getprogname() for test(1) *Never* include directly. And despite some of the noises guenther@ made recenly, I don't think we have made the decision to drop __progname in

MSI-X support

Today mpi@ reminded me that I had written support for MSI-X some time ago. Since he is interested in using multiple vectors, I extended the code I had a bit to support that feature as well. This introduces a new function: int pci_intr_map_msix(struct pci_attach_args *, int, pci_intr_handle_t

Re: smu(4) fan speed

> Date: Tue, 3 May 2016 21:20:55 +0200 > From: Marcus Glocker > > On Mon, Apr 18, 2016 at 10:31:27AM +0200, Martin Pieuchot wrote: > > > On 18/04/16(Mon) 00:22, Marcus Glocker wrote: > > > On Sun, Apr 17, 2016 at 11:33:18PM +0200, Olivier Cherrier wrote: > > > > > > > With

Re: Return ESRCH instead of zero result for KERN_FILE sysctl

> Date: Tue, 3 May 2016 22:47:51 +0300 (MSK) > Cc: tech@openbsd.org > > So, after initial input, here is improved version. Changelist: > > - Simplified handling of "matched" variable in sysctl_file(), > from kettenis@. > > - ERRORS section for kvm_getfiles.2 (to be committed

Re: sdmmc scsi inquiry emulation

> Date: Sun, 1 May 2016 23:21:18 +0200 (CEST) > From: Mark Kettenis <mark.kette...@xs4all.nl> > > Diff below provides a bit more meaningful information in the SCSI > INQUIRY emulation. It decodes the JDEC manufacturer ID code and > provides the product string and revi

Re: armv7: remove unused match function

> Date: Sun, 1 May 2016 21:31:41 +0200 > From: Patrick Wildt > > Hi, > > the armv7_match() function is unused as every platform implements its > own (e.g. imx_match(), exynos_match()). > > Ok to remove? sure

Re: print sdmmc features

> > To helpdebugging sdmmc problems, it would be useful if we printed a > bit more information about the controller. The diff below does this, > and this is whatitlooks like on the APU2. > > sdhc0 at pci0 dev 20 function 7 "AMD Bolton SD/MMC" rev 0x01: apic 4 int 16 > sdhc0: 63 MHz base clock >

Re: Speedup sdhc(4)

> Date: Sat, 30 Apr 2016 13:31:21 +0200 (CEST) > From: Mark Kettenis <mark.kette...@xs4all.nl> > > > From: John Troy <j...@noxi.us> > > Date: Fri, 29 Apr 2016 11:56:24 -0400 > > > > On 4/28/16 2:30 PM, Mark Kettenis wrote: > > > So here are

print sdmmc features

To helpdebugging sdmmc problems, it would be useful if we printed a bit more information about the controller. The diff below does this, and this is whatitlooks like on the APU2. sdhc0 at pci0 dev 20 function 7 "AMD Bolton SD/MMC" rev 0x01: apic 4 int 16 sdhc0: 63 MHz base clock sdmmc0 at sdhc0:

sdmmc scsi inquiry emulation

Diff below provides a bit more meaningful information in the SCSI INQUIRY emulation. It decodes the JDEC manufacturer ID code and provides the product string and revision number as read from the card. For example: scsibus1 at sdmmc2: 2 targets, initiator 0 sd0 at scsibus1 targ 1 lun 0:

Re: arm: new FDT-enabled mainbus

> Date: Sun, 1 May 2016 13:27:29 +0200 > From: Patrick Wildt > > Hi, > > I updated the diff with the feedback received. This basically adds > a tree-like topology by making mainbus FDT aware and implementing > a simplebus that can span the tree's roots into more branches. >

Re: sdmmc bus width support

> Date: Sun, 1 May 2016 22:45:44 +1000 > From: Jonathan Gray <j...@jsg.id.au> > > On Sun, May 01, 2016 at 01:50:59PM +0200, Mark Kettenis wrote: > > > Date: Sun, 1 May 2016 13:40:31 +1000 > > > From: Jonathan Gray <j...@jsg.id.au> > > > &

Re: sdmmc bus width support

> Date: Sun, 1 May 2016 13:40:31 +1000 > From: Jonathan Gray <j...@jsg.id.au> > > On Sat, Apr 30, 2016 at 09:50:15PM +0200, Mark Kettenis wrote: > > The diff below adds support for changing the bus width to the sdmmc > > subsystem and the sdhc(4) controller. B

Re: FW: Re: watchdog suport for new hardware

> Date: Wed, 4 May 2016 09:41:18 -0500 > From: Chase Davis > > It looks like other devices have: Name (_HID, EisaId ("PNP0501") > instead of: Name (_HID, "SEL0002") > > I'm not sure what the significance of EisaId is, but it doesn't show > up for our device. Shouldn't be

Re: sdmmc scsi inquiry emulation

> Date: Mon, 2 May 2016 14:25:51 +1000 > From: Jonathan Gray <j...@jsg.id.au> > > On Sun, May 01, 2016 at 11:21:18PM +0200, Mark Kettenis wrote: > > Diff below provides a bit more meaningful information in the SCSI > > INQUIRY emulation. It decodes the JDEC manufac

Re: DMA overruns and iommu's

> From: "Ted Unangst" <t...@tedunangst.com> > Date: Mon, 02 May 2016 14:35:05 -0400 > > Mark Kettenis wrote: > > It is pretty clear that the DMA engine on the Davicom dc(4) hardware > > is broken and will read beyond the end of the buffer that we pa

Re: apmd: report battery time left in hour-minutes format

> From: Theo de Raadt > Date: Tue, 03 May 2016 06:17:43 -0600 > > I don't like this, and especially since you choce a totally nonstandard > format to show this. > > It is fine how it is right now. I like the current way as well. I fear that if we print it the way Paul

Re: MSI-X support

> Date: Wed, 4 May 2016 07:14:15 -0700 > From: Mike Larkin <mlar...@azathoth.net> > > On Wed, May 04, 2016 at 04:01:54PM +0200, Mike Belopuhov wrote: > > On Tue, May 03, 2016 at 21:40 +0200, Mark Kettenis wrote: > > > Today mpi@ reminded me that I had written supp

Re: FW: Re: watchdog suport for new hardware

> Date: Wed, 4 May 2016 15:00:03 -0500 > From: Chase Davis > > Forgive my ignorance, but what bearing does -release and -current have > on whether or not the HID is found by the match function? Because the code that the HID matching depends on was reworked after 5.9 was

Re: Return ESRCH instead of zero result for KERN_FILE sysctl

> Date: Tue, 3 May 2016 00:04:13 +0200 > From: Alexander Bluhm > > On Sun, May 01, 2016 at 01:24:19AM +0300, Vadim Zhukov wrote: > > When matching by PID, we'd better return ESRCH expicitly rather > > than zero entries. This makes, for example, fstat(1) behaviour > >

Re: MSI-X support

> Date: Tue, 3 May 2016 15:23:07 -0700 > From: Mike Larkin <mlar...@azathoth.net> > > On Tue, May 03, 2016 at 09:40:28PM +0200, Mark Kettenis wrote: > > Today mpi@ reminded me that I had written support for MSI-X some time > > ago. Since he is interested in usin

Re: FW: Re: watchdog suport for new hardware

> Authentication-Results: xs4all.nl; spf=pass smtp.mailfrom=gmail.com; > dkim=pass header.d=gmail.com; dmarc=pass header.from=gmail.com > DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; > d=gmail.com; s=20120113; >

Re: Moving away from softnet interrupts

> Date: Mon, 2 May 2016 11:27:36 +0200 > From: Martin Pieuchot > > On 18/04/16(Mon) 10:50, Martin Pieuchot wrote: > > The current goal of the Network SMP effort is to have a single CPU > > process the IP forwarding path in a process context without holding > > the

Re: libc/sparc64 ABI cleanup

> Date: Sat, 7 May 2016 22:58:23 -0700 > From: Philip Guenther > > Currently, the soft-float bits in libc on sparc64 export not just the > sparc ABI symbols _Q_* and _Qp_*, but also the internal implementation > bits, __fpu_* > > AFAICT, the __fpu_* names are not required

inteldrm diff that requires testing

The diff below makes the HDMI output on Intel Bay Trail machines work. Very useful for machines like the Lenovo Ideacentre Stick 300. But this needs to be tested on other hardware as well. Especially on machines with external displays. Index: intel_i2c.c

Re: APU1 ethernet LEDs

> Date: Tue, 19 Apr 2016 18:57:47 +0200 > From: Christian Weisgerber > > Stuart Henderson: > > > Looking at unique "RTL8168E/8111E (0x2c00)" entries from dmesglog > > back to Feb 2013, there are 7 APUs (=21 NICs), and 20 non-APUs. > > Do we care if we change led state for

Re: uvm: remove am_maxslot from amap

> Date: Sat, 16 Apr 2016 16:36:11 +0200 > From: Stefan Kempf > > am_maxslot represents the total number of slots an amap can be extended > to. Since we do not extend amaps, this field as well as rounding the > number of slots to the next malloc bucket is not useful. > > This

Re: smu(4) fan speed

> Date: Fri, 15 Apr 2016 20:41:53 +0200 > From: Marcus Glocker > > Yesterday I've installed macppc -current on a G5. > Since OF_getprop() for the 'unmanage-value' parameter fails on it, > smu(4) sets the fan speed to 'max-value' instead, which is 3200RPM > in my case. This

Re: arm: new FDT-enabled mainbus

> Date: Sun, 10 Apr 2016 20:49:48 +0200 > From: Patrick Wildt > > > > /* > > > - * void mainbusattach(struct device *parent, struct device *self, void > > > *aux) > > > + * Usually you should be able to attach devices in the order > > > + * specified in the device tree. Due

Re: Moving away from softnet interrupts

> Date: Mon, 18 Apr 2016 10:50:46 +0200 > From: Martin Pieuchot > > The current goal of the Network SMP effort is to have a single CPU > process the IP forwarding path in a process context without holding > the KERNEL_LOCK(). To achieve this goal we're progressively moving >

sparc64 pmap diff

Ran into an interesting problem with the sparc64 pmap bootstrapping code. Early on, we ask the firmware what physical memory is available. Later we use this memory to set up the kernel page tables, kernel stack and per-cpu data structures. We explicitly tell the firmware about the mappings of

sdio fixes

The Lenovo Ideacentre Stick 300 I recently acquired has a Realtek RTL8723BS wireless chip which uses an SDIO interface. This made me look at our SDIO support code again. I noticed that reading the per-function CIS wasn't implemented, so I wrote the missing code. The diff below fixes a couple of

Re: mpsafe aesni

> From: Mike Belopuhov > Date: Tue, 12 Apr 2016 15:33:42 +0200 > > >> > Another question I have is why are you using an IPL_HIGH mutex? > >> > >> The crypto code may be called from any subsystem, so that is the only > >> safe choice. > > > > Well, it's not called from all

Re: ifconfig(8): Do not print MPSAFE

> Date: Sat, 7 May 2016 18:44:34 +0200 > From: Peter Hessler > > SINCE THIS IS UNDER HEAVY DEVELOPMENT: as a user, I want to know if my > interface is marked as MP safe or not. > > I don't care if this is done in dmesg, or in ifconfig. > > once it stabilizes, I'm happy for

Re: ifconfig(8): Do not print MPSAFE

> Date: Sat, 7 May 2016 16:56:02 +0200 > From: Martin Pieuchot > > IFXF_MPSAFE is a hint for the network stack. When it is set, the kernel > knows that it doesn't need to grab the KERNEL_LOCK() to call the start() > routine of an interface. > > Exposing this flag to users in

Re: SROP mitigation

> From: Miod Vallat > Date: Mon, 9 May 2016 18:08:03 + (UTC) > > > This is just a draft. > > > > Index: arch/hppa/hppa/machdep.c > > > @@ -1329,11 +1330,31 @@ sys_sigreturn(struct proc *p, void *v, r > > struct trapframe *tf = p->p_md.md_regs; > > int error; > > >

Re: libedit: reduce build system idiosyncracy

> Date: Mon, 9 May 2016 14:47:39 -0700 > From: Philip Guenther > > On Mon, 9 May 2016, Ingo Schwarze wrote: > > The libedit build system is unusual in so far as it compiles almost all > > C files (but not all of them) as a single compilation unit, editline.c, > > that

Re: libedit: reduce build system idiosyncracy

> Date: Tue, 10 May 2016 00:48:12 +0200 > From: Ingo Schwarze <schwa...@usta.de> > > Hi Mark, > > Mark Kettenis wrote on Tue, May 10, 2016 at 12:31:05AM +0200: > > Philip Guenther wrote: > >> On Mon, 9 May 2016, Ingo Schwarze wrote: > > >

Re: mmap crash

> From: Tim Newsham > Date: Tue, 26 Jul 2016 08:57:12 -1000 > > > The following program triggers the crash on my small VM's (64M, amd64) as > > well as my medium VM (1G ram). When triggered, it reports > > "panic: malloc: out of space in kmem_map". > > > > I should have

armv7 early boot code cleanup

Stop pretending we still support booting without an FDT. The board ID is still initialized as some platforms still need it. This adds code to support multiple memory blocks, such that we an support boards with multiple memory banks. This cleans up some comments as well to reflect the new

Re: always reset mt state in wsmouse_mt_init

> From: Ulf Brosziewski > Date: Tue, 12 Jul 2016 23:17:34 +0200 > > It seems that if an MT device is disabled and reenabled, > remnants of the previous MT state can lead to problems. > wsmouse_mt_init should always reset that state completely > (thanks to jcs@ for

Re: Add hotkey support for Asus Zenbook UX31A

> Date: Thu, 14 Jul 2016 19:15:46 +0200 > From: Frank Groeneveld > > Attached patch adds hotkey support for the Zenbook UX31A. I wasn't sure > what to name the magic string, so please rename to whatever you find > more suitable. > > Next step in getting

Re: armv7/imx: imxpcie(4) driver & device tree problem

> Date: Thu, 14 Jul 2016 11:56:47 +0200 (CEST) > From: Mark Kettenis <mark.kette...@xs4all.nl> > > > > Time to investigate the > > > > > > sdmmc0: can't enable card > > > > > > message I see on my CuBox-i4Pro once more. > >

Re: acpiec: handle burst mode failure

> Date: Thu, 14 Jul 2016 16:41:10 -0500 > From: joshua stein > > On Thu, 14 Jul 2016 at 16:31:32 -0500, joshua stein wrote: > > Also, I just checked FreeBSD and they appear to do something similar > > to my patch, where they check that the EC burst mode flag is set in > > the

Re: armv7 kernel load address

> Date: Sun, 24 Jul 2016 23:35:05 +0200 > From: Patrick Wildt <patr...@blueri.se> > > On Fri, Jul 22, 2016 at 12:05:57AM +0200, Mark Kettenis wrote: > > Currently armv7 kernels expect to be loaded at the bottom of physical > > ram. The diff

Re: armv7 diff for testing

> Date: Mon, 25 Jul 2016 10:58:09 -0300 > From: Daniel Bolgheroni > > On Thu, Jul 21, 2016 at 01:06:50PM +1000, Jonathan Gray wrote: > > > > Actually the pad configuration in those commits may mean this isn't > > enough. > > Hi, > > I saw the r1.9 for if_fec.c and then

Re: arm: pmap uvm_fault findings

> Date: Wed, 27 Jul 2016 20:06:57 +0200 > From: Patrick Wildt > > On Tue, Jul 26, 2016 at 06:43:18PM +0200, Patrick Wildt wrote: > > Hi, > > > > I've been trying to debug a pmap issue on ARM. I have no solution, but > > I would like to share my findings so far. > > > >

Re: armv7 early boot code cleanup

> Date: Wed, 27 Jul 2016 21:24:20 +0200 > From: Patrick Wildt <patr...@blueri.se> > > On Wed, Jul 27, 2016 at 11:53:24AM +0200, Mark Kettenis wrote: > > Stop pretending we still support booting without an FDT. The board ID > > is still initialize

Fix potential integer overflows in uvm address selection code

The diff below fixes a couple of potential integer overflows in the uvm address selection code. Most of these are in code that is disabled, such as uaddr_lin_select and the sruff dealing with guard pages (guard_sz/guardsz is currently always 0). But I think the overflow in uvm_addr_fitspace()

Re: arm: pmap uvm_fault findings

> Date: Thu, 28 Jul 2016 09:47:42 +0200 > From: Patrick Wildt > > There is something I missed in the previous diff. When the PTE is not > valid, the mapping behind the virtual address of course isn't valid. > A flush to an unmapped page will give us a translation fault. So

Re: Fix potential integer overflows in uvm address selection code

> From: "Ted Unangst" > Date: Fri, 29 Jul 2016 18:38:20 -0400 > > I'm a little confused about the following. > > > @@ -520,7 +522,7 @@ uaddr_lin_select(struct vm_map *map, str > > /* Deal with guardpages: search for space with one extra page. */ > > guard_sz =

Use m_devget(9) in smsc(4)

Removes a couple of lines of code from the driver. ok? Index: if_smsc.c === RCS file: /cvs/src/sys/dev/usb/if_smsc.c,v retrieving revision 1.27 diff -u -p -r1.27 if_smsc.c --- if_smsc.c 13 Apr 2016 11:03:37 - 1.27 +++

Re: acpials

> Date: Sat, 30 Jul 2016 10:49:10 -0500 > From: joshua stein > > On Tue, 26 Jul 2016 at 21:31:49 -0500, joshua stein wrote: > > ACPI driver for ambient light sensors conforming to the spec, shows > > up as sysctl hw.sensors.acpials0.illuminance0. > > > > Tested on a Chromebook

armv7 and unified TLBs

So the ARMv7 ARM says in B4.2.2: - on an implementation with separate data and instruction TLBs, any unified TLB operation operates on both TLBs - on an implementation with a unified TLB, any instruction TLB operation, and any data TLB operation, operates on the unified TLB - ARM

Re: arm: pmap uvm_fault findings

> From: Philip Guenther <guent...@gmail.com> > Date: Fri, 29 Jul 2016 15:41:48 -0700 > > On Fri, Jul 29, 2016 at 3:31 PM, Mark Kettenis <mark.kette...@xs4all.nl> > wrote: > >> Date: Thu, 28 Jul 2016 09:47:42 +0200 > >> From: Patrick Wildt <patr...@

armv7 pmap fix for Cortex A53 (and Cortex A7?)

The ARMv7 ARM says in B3.9 that The architecture guarantees that a translation table entry that generates a Translation fault or an Access flag fault is not held in the TLB. However a translation table entry that generates a Domain fault or a Permission fault might be held in the TLB.

Re: armv7 and unified TLBs

> Date: Tue, 2 Aug 2016 02:02:57 +1000 > From: Jonathan Gray <j...@jsg.id.au> Adding back tech@ just in case a knwoledgable person there wants to chime in... > On Mon, Aug 01, 2016 at 05:10:48PM +0200, Mark Kettenis wrote: > > So the ARMv7 ARM says in B4.2.2: > > &

Re: C startup code: make crtbegin code safe for clang

> From: j...@wxcvbn.org (Jeremie Courreges-Anglas) > Date: Mon, 01 Aug 2016 20:30:33 +0200 > > Stefan Kempf writes: > > > The constructor and destructor tables are declared as arrays with one > > non-NULL element. Walking those until a NULL element is reached looks > > like

Re: [Bug 64] Any user can trigger a panic in mmap with an overlapping mapping

> From: Jesse Hertz > Date: Mon, 1 Aug 2016 14:38:19 -0400 > > Hi All, > > Is a fix for this in the works? We'd like to be able to point to a > fix before posting to oss-sec :) Hi Jesse, The fix suggested in the analysis has been committed, and we have committed

Re: armv7 and unified TLBs

> Date: Wed, 3 Aug 2016 10:34:08 +1000 > From: Jonathan Gray <j...@jsg.id.au> > > On Tue, Aug 02, 2016 at 01:43:10PM +0200, Mark Kettenis wrote: > > > Date: Tue, 2 Aug 2016 02:02:57 +1000 > > > From: Jonathan Gray <j...@jsg.id.au> > > > >

Re: grab global lock during acpi_powerdown

> Date: Wed, 3 Aug 2016 13:22:33 +0300 > From: Paul Irofti > > Hi, > > I was looking at fixing powerdown on the x260 Skylake machine and ran > into the EC XXX comment from acpi_powerdown(). > > I think that grabbing the global lock before doing the AML calls is a > good start.

Re: x260 skip_hids

> Date: Wed, 10 Aug 2016 15:51:23 +0300 > From: Paul Irofti > > Hi, > > Here's a list of device HIDs that can be skipped on the x260 models. > > Keyboard and mouse are working fine. The Synaptics soft buttons work > without requiring an sbtn_table entry. > > The ACPI system

armv7 Cortex-A7 fix

Finally found the pmap bug that kept Cortex-A7 from working. Turns out we have to flush the TLB when removing a L1 slot as well. Already committed the diff, but here it is for those that are interested. Index: arch/arm/arm/pmap7.c

Shuffle armv7 access permission bits

This diff changes the access permission bits we use in our page tables to something that is compatible with setting the Access Flag Enable bit in the System Control Register. The main thing that changes is that this changes userland read-only pages to be no longer writable from the kernel. And I

Re: imxtemp(4), a temperature sensor for i.MX6

rmv7/imx/imxtemp.c14 Aug 2016 17:44:14 - @@ -0,0 +1,210 @@ +/* + * Copyright (c) 2014 Patrick Wildt <patr...@blueri.se> + * Copyright (c) 2016 Mark Kettenis <kette...@openbsd.org> + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereb

imxtemp(4), a temperature sensor for i.MX6

: arch/armv7/imx/imxtemp.c === RCS file: arch/armv7/imx/imxtemp.c diff -N arch/armv7/imx/imxtemp.c --- /dev/null 1 Jan 1970 00:00:00 - +++ arch/armv7/imx/imxtemp.c14 Aug 2016 16:23:39 - @@ -0,0 +1,203 @@ +/* + * Copyright (c) 2014 Patrick Wildt <patr...@blueri.se> + *

Two sunxi driver diffs

Here are two diffs for the sunxi armv7 platform that I can't test myself. The first one is for sxiahci(4), and changes it to use the regulator API to power on the bus. The second one is for sxie(4), and changes it to use the pinctrl API to select the appropriate pins. If anybody with a

Re: sixuart fifo fix

> Date: Sun, 14 Aug 2016 14:02:21 +0200 > From: Marcus Glocker <mar...@nazgul.ch> > > On Sun, Aug 14, 2016 at 12:08:14AM +0200, Mark Kettenis wrote: > > > > Date: Sat, 13 Aug 2016 23:06:45 +0200 > > > From: Marcus Glocker <mar...@nazgul.ch> > >

Re: Two sunxi driver diffs

> Date: Sun, 14 Aug 2016 13:59:00 +0200 (CEST) > From: Mark Kettenis <mark.kette...@xs4all.nl> > > Here are two diffs for the sunxi armv7 platform that I can't test > myself. The first one is for sxiahci(4), and changes it to use the > regulator API to power on

Re: [PATCH] let the mbufs use more then 4gb of memory

> Date: Fri, 12 Aug 2016 14:26:34 +0200 > From: Claudio Jeker > > On Fri, Aug 12, 2016 at 04:38:45PM +1000, David Gwynne wrote: > > > > > On 1 Aug 2016, at 21:07, Simon Mages wrote: > > > > > > I sent this message to dlg@ directly to

Fix relro coredumps

With relro, certain bits of a process that were mapped into memory as writable are revreted back to read-only after making some initial changes. Since the kernel coredump code only writes out writable pieces of memory, these relro bits are not written out. Unfortunately these bits contain

Re: [PATCH] let the mbufs use more then 4gb of memory

> From: David Gwynne > Date: Fri, 12 Aug 2016 16:38:45 +1000 > > > On 1 Aug 2016, at 21:07, Simon Mages wrote: > > > > I sent this message to dlg@ directly to discuss my modification of his > > diff to make the > > bigger mbuf clusters work. i

Re: kill FUSE_ROOT_ID

> Date: Sat, 13 Aug 2016 13:02:19 +0200 > From: Martin Natano > > Kill FUSE_ROOT_ID and use FUSE_ROOTINO instead for the only place where > it was used. Also, remove one (ino_t) cast from FUSE_ROOTINO, as it is > already included in the #define. Ok? > > natano ok kettenis@

Re: acpiec: handle burst mode failure

> Date: Fri, 12 Aug 2016 08:58:19 -0500 > From: joshua stein > > On Fri, 08 Jul 2016 at 18:51:17 -0500, joshua stein wrote: > > If the EC fails to go into burst mode for whatever reason, the Burst > > Acknowledge byte will not be there to read, which means the status > > won't

Make Cortex-A7 go fast

On Cortex-A7 there is a magic SMP bit in the Auxiliary Control Register that "Enables coherent requests to the processor". The Cortex-A7 Technical Reference Manual mentions that: When coherent requests are disabled: * loads to cacheable memory are not cached by the processor. So

bus_dmamap_sync() of size zero

OpenBSD/arm seems to be the only port that doesn't like it when you pass its bus_dmamap_sync() a size of zero. While it is indeed a bit silly to do so, adding checks for this in the drivers might be overkill. In fact if you read the bus_dma_sync(9) man page, you could could interpret from

Re: sixuart fifo fix

> Date: Sat, 13 Aug 2016 23:06:45 +0200 > From: Marcus Glocker > > When I currently boot the allwinner,sun5i-r8 board with an UART cable > connected for console but no terminal attached, the boot hangs as soon > the driver switches from the console output routines to

Re: armv7 Cortex-A7 fix

> Date: Wed, 10 Aug 2016 23:11:52 -0700 > From: Chris Cappuccio <ch...@nmedia.net> > > Tinker [ti...@openmailbox.org] wrote: > > On 2016-08-11 08:30, Mark Kettenis wrote: > > > Finally found the pmap bug that kept Cortex-A7 from working. Turns > > >

Re: armv7/sxipio ofw_gpio

> Date: Thu, 11 Aug 2016 13:44:06 +1000 > From: Jonathan Gray > > On Thu, Aug 11, 2016 at 05:41:35AM +0300, Artturi Alm wrote: > > Hi, > > > > what's the plan for solving ordering issues for these devices? > > could this be attached 'manually' from sunxi_platform_init_mainbus()

Re: per cpu memory in the kernel

> From: Martin Pieuchot > Date: Fri, 12 Aug 2016 20:44:04 +0200 > > On 08/11/16 06:43, David Gwynne wrote: > > ive been tinkering with per cpu memory in the kernel > > [...] > > I'd like to have more people comment on this because we need an MP-safe > way to handle counters in

<    5   6   7   8   9   10   11   12   13   14   >