efifb(4) improvements

On most modern hardware reading from a framebuffer is much slower than writing to it. This is why when I added code to the rasops code to remember the characters written and simply redraw them when we scroll the console. That code only works when RI_VCONS was specified, because that code already

pm_stats.resident_count for kernel pmap

I just committed a diff that adds a little bit more mpsafeness to the sparc64 pmap. The commit message reads: Make pmap_kenter_pa(9) and pmap_kremove(9) mpsafe. This required me to use atomic operations to operate on pm_stats.resident_count. Is it really necessary to keep track of that

Re: Interrupt handler synchronization

> Date: Sat, 12 Sep 2015 14:38:05 +0200 (CEST) > From: Mark Kettenis <mark.kette...@xs4all.nl> > > Since interrupt handlers are running asynchronously it is difficult to > make sure that one isn't running on another cpu while you're frobbing > data s

OpenBSD/powerpc switched to use Secure-PLT ABI

Hi All, I just switched the OpenBSD/powerpc ports (macppc and socppc) over to the "new" Secure-PLT. This improves the W^X support. If you're not following -current closely, you might want to avoid updating from source and install a snapshot instead. If you decide to update from source, make

Re: Brainy: a few bugs

> From: Maxime Villard > Date: Fri, 11 Sep 2015 21:18:18 +0200 > > _22/ OVERLAP: sys/arch/sparc64/dev/vdsp.c rev1.2 Thanks, fixed!

Interrupt handler synchronization

Since interrupt handlers are running asynchronously it is difficult to make sure that one isn't running on another cpu while you're frobbing data structures that you share with it. This is an issue for example in our network drivers, where we want to clean up the rings when we bring the interface

Unlocking em(4) a bit further

This diff makes the tx completion path run without the kernel lock held. With this change, the interrupt handler will not grab the kernel lock under normal circumstances. The diff follows the same approach as dlg@ took with vmx(4). The diff removes the code that tries to reclaim tx descriptors

Unlocking ix(4) a bit further

Since people seemed to like my diff for em(4), here is one for ix(4). In addition to unlocking the rx completion path, this one also uses intr_barrier() and removes the rx mutex that claudio@ put in recently. I don't have any ix(4) hardware. So the only guarantee is that this compiles ;).

Re: CVS: cvs.openbsd.org: src

> Date: Sun, 4 Oct 2015 14:10:18 +0200 > From: Joerg Jung > > On Wed, Sep 30, 2015 at 06:07:54PM +0200, Joerg Jung wrote: > > On Wed, Sep 30, 2015 at 05:13:31PM +0200, Martijn van Duren wrote: > > > > > > What I find somewhat strange is that although the dmesg says it has "2 > >

locking the page queues

The diff below (re)introduces the active/inactive page queue lock. This will be necessary to make progress with remove the need for grabbing the kernel lock in more parts of uvm, such as the pagedaemon and the uvm_fault(). This was tried once before. And subsequently backed out because:

Re: Dubious loop logic in pciide(4)

> Date: Wed, 30 Sep 2015 11:35:36 -0400 > From: Michael McConville > > Yesterday, I ran a Coccinelle script to find useless continue statements > and sent a few to tedu@. He pointed out that, based on the loop above > it, the one below probably meant to continue the

Re: Brainy: a few bugs

> From: Maxime Villard > Date: Fri, 11 Sep 2015 21:18:18 +0200 > > _23/ USE-AFTER-FREE: sys/dev/sun/z8530ms.c rev1.2 This one's fixed now as well. Thanks.

Re: Black screen with inteldrm and recent snapshots

> Date: Fri, 25 Sep 2015 12:47:15 +0200 > From: Gregor Best > > Hi people, > > I just updated to a recent snapshot and once inteldrm attaches to my > > vga1 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07 > > the screen turns blank. Disabling inteldrm with boot

Re: Black screen with inteldrm and recent snapshots

> Date: Fri, 25 Sep 2015 14:05:50 +0200 > From: Gregor Best <g...@unobtanium.de> > > On Fri, Sep 25, 2015 at 01:32:07PM +0200, Mark Kettenis wrote: > > [...] > > I'm already onto that one. For some reason the G45/GM45 chipset goes > > down a codepath

Re: deprecating USRTEXT

> Date: Fri, 25 Sep 2015 18:44:07 + > From: Miod Vallat > > USRTEXT used to be the address of the beginning of the a.out code > segment. Today's world is ELF and PIE binaries, and USRTEXT has no > meaning. > > The following diff removes it, as well as trivial or no longer

Re: [patch] ld linker problem with -shared and -z defs

> Date: Sat, 19 Sep 2015 18:50:41 +0200 > From: Sebastien Marie > > Hi, > > While working on building llvm 3.7.0 on openbsd (-current amd64 and > i386), I encounter a problem when linking a shared library, while > -Wl,-z,defs was passed on command-line. > > I build a

Re: remove SIGALRM handling from sleep(1)

> Date: Mon, 21 Sep 2015 01:37:27 -0700 > From: Philip Guenther > > POSIX no longer requires sleep(1) to exit with status zero when sent > SIGALRM: > > > If the sleep utility receives a SIGALRM signal, one of the following > actions shall be taken: > >1.

Re: Possible em(4) fix

> From: Mike Belopuhov <m...@belopuhov.com> > Date: Tue, 6 Oct 2015 14:18:39 +0200 > > On 5 October 2015 at 22:45, Mark Kettenis <mark.kette...@xs4all.nl> wrote: > > Several people seem to complain on misc@ that they're seeing watchdog > > timeouts on em(4)

Re: use m_defrag in fxp

> Date: Tue, 1 Dec 2015 19:30:44 +0100 > From: Claudio Jeker > > Use m_defrag in fxp to make it nicer and simpler. > > works for me with > fxp0 at pci6 dev 6 function 0 "Intel 8255x" rev 0x08, i82559: apic 6 int 21, > address 00:d0:b7:4c:36:c4 > inphy0 at fxp0 phy 1:

Re: bridge_output() and KERNEL_LOCK

> Date: Fri, 4 Dec 2015 11:48:57 +0100 > From: Martin Pieuchot > > Now that if_start() will take the KERNEL_LOCK itself if the driver is > not marked as IFXF_MPSAFE if_enqueue() is almost mpsafe. > > The missing piece is addressed by the diff below. We want to ensure >

Make ix(4) mpsafe: take 2

Here is a new diff to make ix(4) mpsafe. Should now longer get stuck in the OACTIVE state. Tests more than welcome. Index: if_ix.c === RCS file: /cvs/src/sys/dev/pci/if_ix.c,v retrieving revision 1.129 diff -u -p -r1.129 if_ix.c

Re: Use off_t for lineno in csplit

> Date: Tue, 8 Dec 2015 13:00:49 -0500 > From: Michael McConville > > I thought I'd look for other examples after the grep fix. > > ok? It really is confusing to use off_t for something that's not a byte offset. If integer overflow really is an issue you care about, use

Re: ifq serialisation, was Re: taskctx and revisiting if_start serialisation

> Date: Tue, 8 Dec 2015 21:58:49 +1000 > From: David Gwynne > > On Sun, Dec 06, 2015 at 02:00:16PM +1000, David Gwynne wrote: > > the current code for serialising if_start calls for mpsafe nics does what > > it says. > > as per mpi@s suggestion, this makes the ifq code

Re: Does grep need a version?

> From: Bob Beck > Date: Mon, 7 Dec 2015 22:58:03 -0700 > > Since I can't think of a sane reason to check this and care in any > script, yes, kill it. Unfortunately you can't apply your rules about sanity to this thing called autoconf.

Re: patch 3/4 add generic keyboard backlight support

> Date: Mon, 7 Dec 2015 23:44:13 +0100 > From: Joerg Jung > > Hi, > > here comes the third part of the series for generic keyboard backlight > support. > > Please find below a diff which adds they key(code)s for keyboard > backlight control, as found on all recent Intel based

Re: rm bge supported devices

> Date: Wed, 2 Dec 2015 12:32:52 + > From: Stuart Henderson > > On 2015/12/02 12:09, jus...@postgresql.org wrote: > > On 2015-12-02 11:37, Ted Unangst wrote: > > >2. If you have picked a driver and are trying to find a device, these > > >are very incomplete guides. Most of

Thinkpad display brightness control

Most, if not all, somewhat recent Thinkpads have some subtle issues with display brightness control. For example,if you change the display brightness using wsconsctl(8) or cbacklight(1), and later use the brightness control buttons on the keyboard, you're likely to see a big jump in brightness.

Re: 11n: Finish A-MSDU receive

> Date: Sat, 12 Dec 2015 15:32:58 +0100 > From: Stefan Sperling <s...@stsp.name> > > On Sat, Dec 12, 2015 at 03:08:00PM +0100, Mark Kettenis wrote: > > > @@ -1072,6 +1079,10 @@ ieee80211_amsdu_decap(struct ieee80211co > > > } > > &g

Re: 11n: Finish A-MSDU receive

> Date: Sat, 12 Dec 2015 14:26:19 +0100 > From: Stefan Sperling > > A-MSDU frames are aggregates which contain MSDUs (ethernet frames) as > subframes, rather than MPDUs (802.11 frames) as A-MPDUs do. > Each subframe has a header containing sender and target MAC address > and the

Re: Use off_t for lineno in csplit

> Date: Sat, 12 Dec 2015 16:26:30 -0500 > From: Michael McConville <mm...@mykolab.com> > > Mark Kettenis wrote: > > It really is confusing to use off_t for something that's not a byte > > offset. If integer overflow really is an issue you care about, use > >

USB keyboards with multiple displays

OpenBSD/amd64 and OpenBSD/i386 have been supporting multiple wsdisplay(4) devices for a while now. Somewhat recently it became also possible to use inteldrm(4) as a secondary display device. There have always been some issues with pairing wskbd(4) keyboard devices with wsdisplay(4) devices. But

Re: Fix support for early SATA drives on ahci(4)

> Date: Sun, 3 Jan 2016 12:30:08 -0800 > From: Mike Larkin > > Catching up on holiday email, not sure if this already went in, but there > is a typo (drives not drivers) in the previous line. Thanks. Fixed.

Re: Checking MAC address of incoming unicast packets

> Date: Mon, 4 Jan 2016 21:30:31 +0100 > From: Claudio Jeker <cje...@diehard.n-r-g.com> > > On Sat, Jan 02, 2016 at 04:04:33PM +0100, Mark Kettenis wrote: > > > Date: Sat, 2 Jan 2016 10:57:41 +0100 > > > From: Martin Pieuchot <m...@openbsd.org> > &

Re: Another mpsafe ix(4) diff

> From: Hrvoje Popovski <hrv...@srce.hr> > Date: Tue, 22 Dec 2015 23:45:49 +0100 > > On 22.12.2015. 22:08, Mark Kettenis wrote: > > Anybody willing to give this a spin? I don't have access to hardware > > currently... > > > > Thanks, >

Re: OpenBSD 5.8 on Xeon-D (1540) systems

> From: Dale Ghent <da...@elemental.org> > Date: Thu, 31 Dec 2015 15:02:11 -0500 > > > On Dec 31, 2015, at 2:43 PM, Mark Kettenis <mark.kette...@xs4all.nl> wrote: > > > > Can you please send me a dmesg as well as the acpidump output for this > > mac

Re: dead assignements in usr.bin/systat

> Date: Sat, 2 Jan 2016 18:21:07 +0100 > From: Sebastian Benoit > > an earlier commit today prompted florian@ to run clang, these fixes are a > result of issues found. > > ok? sure > [PATCH 1/4] remove unused variable cur. code probably c from > print_bar_title(). > > diff

Re: Checking MAC address of incoming unicast packets

> Date: Sat, 2 Jan 2016 10:57:41 +0100 > From: Martin Pieuchot > > If it's acceptable performance-wise to do the check unconditionally I > believe that's the way to go. If not I'm a bit afraid of introducing > a flag/capability for a single driver. Do you know if any other

getentropy(2) in ports

Hi Robert, Noticed the following commit: > CVSROOT:/cvs > Module name:ports > Changes by: rob...@cvs.openbsd.org 2016/01/02 06:57:12 > > Modified files: > mail/zarafa/zarafa: Makefile > mail/zarafa/zarafa/patches: patch-common_platform_linux_cpp >

Re: Fix acpibtn(4) LID sensor

> Date: Wed, 6 Jan 2016 10:05:48 +0100 > From: Martin Pieuchot > > My x220 never generates an event when the LID opens. So after > suspending by closing the lid the corresponding sensors will always > report a closed lid: > > $ sysctl hw.sensors.acpibtn0 >

Re: Fix acpibtn(4) LID sensor

> Date: Wed, 6 Jan 2016 01:16:38 -0800 > From: Mike Larkin > > On Wed, Jan 06, 2016 at 10:05:48AM +0100, Martin Pieuchot wrote: > > My x220 never generates an event when the LID opens. So after > > suspending by closing the lid the corresponding sensors will always > >

Re: OpenBSD 5.8 on Xeon-D (1540) systems

> > > On Jan 1, 2016, at 5:13 PM, Mark Kettenis <mark.kette...@xs4all.nl> wrote: > > > > Thanks. This strange. I don't quite understand what's happening here > > as the ACPI MADT table lists the CPUs in the expected order and cpu0 > > attaches as

Re: Xen virtual network (Netfront) driver

> From: Mike Belopuhov > Date: Thu, 7 Jan 2016 12:02:23 +0100 > > On 6 January 2016 at 17:58, Stefan Fritsch wrote: > > On Wed, 6 Jan 2016, Mike Belopuhov wrote: > > > >> There's still stuff to do, but it receives and transmits reliably > >> (at least on

Re: i386/nvram.c uiomove() conversion

> Date: Thu, 7 Jan 2016 09:36:02 +0100 > From: Stefan Kempf > > Martin Natano wrote: > > Below a diff to convert i386/nvram.c to use uiomove(). A similar diff > > for amd64 has already been committed. (See > > https://marc.info/?l=openbsd-tech=142860367111291) Also, pos is >

Re: dev/rnd.c uiovmove() conversion

> Date: Thu, 7 Jan 2016 09:41:46 +0100 > From: Stefan Kempf > > Martin Natano wrote: > > Below, a diff to convert dev/rnd.c to use uiomove(). > > We also did this something similar for sosend(), although uiomovei() > would also have worked since n was guaranteed to be

Re: eeprom does not compile on current/macppc

> From: "Todd C. Miller" <todd.mil...@courtesan.com> > Date: Thu, 31 Dec 2015 12:01:10 -0700 > > On Thu, 31 Dec 2015 19:53:01 +0100, Mark Kettenis wrote: > > > Fallout from -Werror-implicit-function-declaration. > > > > Diff below fixes it.

Re: OpenBSD 5.8 on Xeon-D (1540) systems

> From: Dale Ghent > Date: Thu, 31 Dec 2015 13:45:49 -0500 > > > Read my message again. I'm suggesting to turn xhci off in the kernel, > > not the BIOS. > > Alright, so here's an update. This Xeon-D system is able to be booted and > installed using your suggestions: > >

Re: eeprom does not compile on current/macppc

> From: "Todd C. Miller" > Date: Thu, 31 Dec 2015 12:13:05 -0700 > > On Thu, 31 Dec 2015 11:02:01 -0800, Philip Guenther wrote: > > > Wouldn't it better to have yacc's skeleton.c provide a prototype so > > that it's fixed for all .y files? I see that bison's output

Re: eeprom does not compile on current/macppc

> Date: Thu, 31 Dec 2015 13:18:13 +0100 > From: Jan Stary > > ===> usr.sbin/eeprom > cc -O2 -pipe -Werror-implicit-function-declaration -c getdate.c > /usr/src/usr.sbin/eeprom/getdate.y: In function 'get_date': > /usr/src/usr.sbin/eeprom/getdate.y:860: error: implicit

Re: ksh another home/end pair

> From: "Ted Unangst" > Date: Tue, 29 Dec 2015 12:11:25 -0500 > > In tmux, home and end send different bytes. I don't know why, but I want > things to just work. We already have two different keys here, so what's one > more? (how many can there be...?) Isn't that somehowa

Re: allocation simplifications in yacc

> Date: Wed, 30 Dec 2015 11:30:11 -0500 > From: Michael McConville > > Christian Weisgerber wrote: > > Christian Weisgerber: > > > > > The removal of the casts causes a problem in ports/devel/mico, where > > > the yacc output is used in C++: > > > > Also: > > graphics/grap

Re: Add C11 stdalign.h and stdnoreturn.h

This makes no sense as our base compiler doesn't support C11.

Re: OpenBSD 5.8 on Xeon-D (1540) systems

> From: Dale Ghent > Date: Wed, 30 Dec 2015 14:49:58 -0500 > > Has anyone used or otherwise been able to boot 5.8 on a Xeon-D 1540 = > system? We're experimenting with a SuperMicro Xeon-D 1540 system = > (http://www.supermicro.com/products/system/1U/5018/SYS-5018D-FN4T.cfm)

Re: OpenBSD 5.8 on Xeon-D (1540) systems

> From: Dale Ghent <da...@elemental.org> > Date: Wed, 30 Dec 2015 15:35:42 -0500 > > > On Dec 30, 2015, at 3:21 PM, Mark Kettenis <mark.kette...@xs4all.nl> = > wrote: > >=20 > >> From: Dale Ghent <da...@elemental.org> > >> Date:

Re: drm_drv.c uiomove() conversion

> Date: Sat, 9 Jan 2016 11:03:13 +0100 > From: Martin Natano > > Below the uiomove() conversion for drm_drv.c. ev->event->length is a > u_int32_t, thus the implicit conversion to size_t should be > non-problematic. Thanks. That fact is enshrined in the Linux userland API, so

Re: uvm_io.c uiomove() conversion

> Date: Sat, 9 Jan 2016 11:00:32 +0100 > From: Martin Natano > > Below the conversion for uvm_io.c. The sz variable is already a size_t. Thanks. Committed. > Index: uvm/uvm_io.c > === > RCS file:

Re: rate selection fixes for iwm and iwn

> Date: Tue, 5 Jan 2016 15:06:00 +0100 > From: Stefan Sperling > > iwm adjusts the firmware's Tx rate retry table dynamically such > that the first slot in this table always reflects the current > rate chosen by AMRR. > The table starts off looking like this: > > 0 1

Sensible default interrupt polarity on amd64 and i386

The sensible default polarity is active-low for level-triggered interrupts whereas it is active-high for edge-triggered ones. We do this correctly when the BIOS explicitly tells us that it wants defaults. But we also should do it when the BIOS gives us no information. Fortunately this is easy.

asmc(4) improvements

The asmc(4) driver is a bit slow. On my MacBookPro12,1 it takes a couple of minutes to probe all the sensors. And changing the keyboard backlight takes a couple of seconds. This is especially annoying when you're writing a diff to bind that functionality to the keys reserved for this purpose on

Another mpsafe ix(4) diff

Anybody willing to give this a spin? I don't have access to hardware currently... Thanks, Mark Index: if_ix.c === RCS file: /cvs/src/sys/dev/pci/if_ix.c,v retrieving revision 1.130 diff -u -p -r1.130 if_ix.c --- if_ix.c 18

Re: asmc(4) improvements

> Date: Tue, 22 Dec 2015 12:42:38 +0100 > From: Joerg Jung <m...@umaxx.net> > > On Mon, Dec 21, 2015 at 10:38:24PM +0100, Mark Kettenis wrote: > > There were two reasons for this slowness: > > > > 1. The asmc_command() function does additional reads as a &q

Re: memory leak in libc

> Date: Fri, 25 Dec 2015 11:56:33 +0100 > From: frit...@alokat.org > > Hi tech@, > > it looks like there is a memory leak in libc. In file > "src/lib/libc/stdio/makebuf.c" line 62 malloc(3) is called, but > never freed, when printf(3) is called. Not really a leak. That buffer gets freed when

Re: allocation simplifications in yacc

> Date: Fri, 25 Dec 2015 14:17:19 +0100 > From: Theo Buehler > > On Thu, Dec 24, 2015 at 12:41:28PM -0500, Michael McConville wrote: > > 1. realloc acts like malloc when ptr == NULL > > Why not > > "#endif", > - "if (newsize && YY_SIZE_MAX / newsize < sizeof

Re: AGP on macppc (again)

> Date: Fri, 18 Dec 2015 15:11:35 +0100 > From: Martin Pieuchot > > Without AGP support radeondrm(4) does not work on my G5. The machine > freezes when X starts and it's impossible to debug. > > So I'd like to enable agp(4) in GENERIC again... but leaving it disable > for

Re: Remove redundant continue

> Date: Sun, 27 Dec 2015 13:48:19 -0500 > From: Michael McConville > > A trivial simplification, but it's a false positive for an > inner-loop-continue bug, so it'd be nice to take care of it. > > ok? The code is easier to understand the way it is now. > Index:

Re: Potential continue bug in mii(4)

> Date: Sun, 27 Dec 2015 13:36:29 -0500 > From: Michael McConville > > The continue statement below is a nop. It seems that it meant to > continue the outer loop. This is an educated guess based on the logic > and the inner loop's comments. Thoughts? Looks like this is a bug

Fix support for early SATA drives on ahci(4)

I have an old Maxtor 7Y250M0 SATA drive that didn't quite work when attached to an Intel AHCI controller. The drive was properly detected, but any attempt to read from the drive failed. It worked fine if I switched the SATA controller into IDE mode in the BIOS, so the drive was fine. Turns out

Re: ipmi(4) - Remove unused code

> Date: Mon, 21 Dec 2015 22:31:22 +0900 > From: Masao Uebayashi > > This is the first part of the big ipmi(4) patch I sent in another thread. > > This removes complicate polling timeout code. Serial communication > with BMC is slow but considered as reliable.

Re: ipmi(4) - Don't check threshold erroneously

> Date: Mon, 21 Dec 2015 22:47:19 +0900 > From: Masao Uebayashi > > ipmi(4) has checked thresholds of some sensing values and reported false > alarms. This patch reverts those checks. > > This also changes ipmi(4) to handle disabled sensors while allowing them to >

Re: ipmi(4) - Stop watchdog internal timer properly

> Date: Mon, 21 Dec 2015 22:43:46 +0900 > From: Masao Uebayashi > > When stopiing ipmi(4) watchdog, not only set action to disabled but also stop > internal timer (clear don't stop flag). Without this our NEC servers fail > to stop IPMI watchdog and reset during shutdown

Get PCI resources from ACPI

It seems more and more server machines ship in a "64-bit" configuration where the BIOS assigns addresses above the 4GB mark to 64-bit BARs. We have a hack in arch/amd64/pci_machdep.c:pci_init_extents() to deal with some of these configurations: /* * ...

Re: Thinkpad display brightness control

> From: Christian Weisgerber <na...@mips.inka.de> > Date: Thu, 17 Dec 2015 11:50:53 + (UTC) > > On 2015-12-16, Mark Kettenis <mark.kette...@xs4all.nl> wrote: > > > The downside of this diff is that number of levels is limited to 16 > > whereas we curren

Re: mpsafe tx for bge(4)

> Date: Tue, 29 Dec 2015 07:59:12 +1000 > From: David Gwynne > > this tweaks the bge tx code and marks it mpsafe. > > ok? ok kettenis@ > Index: if_bge.c > === > RCS file: /cvs/src/sys/dev/pci/if_bge.c,v >

Re: Swap random with arcrandom on trek(6)

> Date: Wed, 25 Nov 2015 20:44:31 + > From: Ricardo Mestre > > While checking if there was still a score file on trek(6) I found that it was > still using random(), and inspired by the code on NetBSD and OpenBSD relevant > manpages I came up with this diff. Let's

ppb diff for testing

The diff below teaches ppb(4) how to configure PCI bridges that are left unconfigured by firmware. This happens for example on Apple hardware, where devices connected through Thunderbolt are left unconfigured. And since Thunderbolt is basically a bunch of PCI bridges (or more correctly PCIe

Re: Debugging cardbus issues

> Date: Sat, 28 Nov 2015 17:12:03 + > From: Tati Chevron > > cbb0 at pci1 dev 9 function 0 "ENE CB-1410 CardBus" rev 0x01: apic 1 int 22, > CardBus support disabled > cardslot0 at cbb0 slot 0 flags 0 > pcmcia0 at cardslot0 > > The host interface attaches, but my

Re: taskq_barrier(9)

> Date: Mon, 30 Nov 2015 16:28:55 +1000 > From: David Gwynne > > while playing with some options around running an interfaces send > queue, i came up with the following. if you've deferred work to a > taskq and you're not reference counting, this can help you guarantee > that

Completely disable 2D acceleration on Broadwell

As tedu@ reported (and some pople on misc@ confirmed) partly disabling 2D acceleration on Broadwell made X unstable. It really looks like the alternative BLT path isn't well tested and therefore buggy. So here is a diff that disables 2D acceleration completely. Those who don't care about

Re: serious watchdog timeout issues with em driver

> Date: Fri, 20 Nov 2015 14:12:52 +0100 > From: Martin Pieuchot > > On 19/11/15(Thu) 17:54, Sonic wrote: > > Have serious problems for over 7 weeks now with em driver, > > specifically any rev of if_em.c > 1.305. Starting with rev 1.306, > > released on 2015/09/30 and

Enable deep C-states on AMD CPUs

Except for the really old ones, all AMD CPUs keep the APIC running in low-power mode. They don't have the ARAT flag that Intel CPUs have though. The diff below sets that flag on family 12h and later, such that acpicpu(4) enables the deeper C states on these CPUs. This matches what Linux does.

Re: make IFF_OACTIVE mpsafe

> Date: Tue, 24 Nov 2015 00:09:34 +1000 > From: David Gwynne > > by replacing it. > > hrvoje popovski was prescient in predicting this. > > anyway. there are two things shared between the network stack and > drivers in the send path: the send queue and the IFF_OACTIVE flag.

Re: remove net80211 turbo mode

> Date: Mon, 11 Jan 2016 10:30:27 +0100 > From: Stefan Sperling > > This diff removes turbo mode, which is a proprietary extension offered > by Atheros devices of the ath(4) 11a/b/g generation. This seems to be > a channel bonding technique, similar to 11n 40 MHz channels but not

Fix aml_find_node(9)

This function is really weird. It looks for nodes with a specific name, and calls a callback function if a match is found. But it doesn't just look at the children of the passed node, it also looks atthe passed node itself and all of its children. That is really unexpected, and jcs@ fell into

Fix uvm bug

The fix below fixes the following panic that mglocker@ was seeing on macppc: panic: uvm_addr_invoke: address selector 0xfe8000 (uaddr_bestfit 0xe000-0xee00) returned unavailable address 0xe8a59000 This happened immediately after a failed malloc(9). What is happening here is that we

Re: remove unused spls in sparc64

> Date: Tue, 7 Jun 2016 12:57:16 +1000 > From: David Gwynne > > nothing using splsoftfd or splausoft on sparc64 so we can remove them. > > ok? ok kettenis@ > Index: dev/fd.c > === > RCS file:

Re: afterboot(8) ethernet device name

> Date: Wed, 8 Jun 2016 11:10:56 +0200 > From: Stefan Sperling > > I find le0 and lo0 too close to be easily distinguishable, especially > with a small font. This way, the difference should be more obvious. ok kettenis@ > Index: afterboot.8 >

Re: IP_SENDSRCADDR [2/2] : add cmsg support

> Date: Sun, 12 Jun 2016 14:59:55 +0200 > From: Vincent Gross > > This diff adds support for IP_SENDSRCADDR cmsg on UDP sockets. As for > udp6_output(), we check that the source address+port is available only > if inp_laddr != * > > Ok ? Why do we need this? cmsg stuff is

Re: MBIM Patch (Round 3)

> Date: Fri, 10 Jun 2016 17:20:18 +0100 > From: Stuart Henderson <s...@spacehopper.org> > > On 2016/06/10 16:05, Mark Kettenis wrote: > > In any case this is something we can figure out once the code hits the > > tree. Unless mpi@ is still unhappy with the way the

Re: cbfb: coreboot framebuffer console

> Date: Fri, 10 Jun 2016 14:38:05 -0500 > From: joshua stein > > This implements a new framebuffer console (based on efifb) for amd64 > devices running Coreboot, which do not have otherwise working EFI, > VGA text, inteldrm, or serial console. So mostly just Skylake >

Re: MBIM Patch (Round 3)

> Date: Wed, 8 Jun 2016 15:08:52 +0200 > From: Gerhard Roth > > Here comes the next version of the MBIM driver. > > Changes since last version: > > - incorporated suggestions from mpi@ > > - renamed to "umb" > Only file "mbim.h" which contains MBIM protocol

Re: MBIM Patch (Round 3)

> Date: Thu, 9 Jun 2016 22:59:28 +0200 (CEST) > From: Mark Kettenis <mark.kette...@xs4all.nl> > > > Date: Wed, 8 Jun 2016 15:08:52 +0200 > > From: Gerhard Roth <gerhard_r...@genua.de> > > > > I would be glad to hear from some people trying this with

Re: MBIM Patch (Round 3)

> From: Gerhard Roth <gerhard_r...@genua.de> > Date: Thu, 9 Jun 2016 23:48:23 +0200 > > On 09.06.2016 23:42, Mark Kettenis wrote: > >> Date: Thu, 9 Jun 2016 22:59:28 +0200 (CEST) > >> From: Mark Kettenis <mark.kette...@xs4all.nl> > >> > >&g

Re: MBIM Patch (Round 3)

> From: Gerhard Roth <gerhard_r...@genua.de> > Date: Fri, 10 Jun 2016 00:31:44 +0200 > > On 10.06.2016 00:22, Stuart Henderson wrote: > > On 2016/06/10 00:10, Mark Kettenis wrote: > >>> From: Gerhard Roth <gerhard_r...@genua.de> > >>> Date: Th

Re: pool_setipl for src/sys/uvm

> Date: Mon, 13 Jun 2016 14:27:53 +1000 > From: David Gwynne > > this adds pool_setipl to the pools in src/sys/uvm. > > this assumes that the various things are only allocated and freed > from a process context. if any of these are released from an interrupt > we should

Re: cbfb: coreboot framebuffer console

> Date: Sun, 12 Jun 2016 11:47:37 -0500 > From: joshua stein > > Here's a new version with feedback from Miod and Ted. > > It also fixes a bug on a Broadwell Chromebook (tested by Edward > Wandasiewicz) which has proper inteldrm but no vga, so cbfb was > getting chosen as the

Re: Fix return value of OF_getprop() when name has a '@' in it

> Date: Tue, 14 Jun 2016 14:33:14 +0100 (BST) > From: Tom Cosgrove > > >>> Tom Cosgrove 12-Jun-16 22:05 >>> > > > > In OF_getprop(), if the "name" property doesn't exist it is synthesised > > from the unit name. If that synthesised property has an "@" in it,

fdt_node_property() fix

Currently it is not possible to figure out whether a property isn't there, or whether it has a length of zero. Zero-length properties do exist (both in the FDT world and the OFW world), so we need to fix this. The most logical way to do this is to make fdt_node_property() return -1 if a property

Re: cbfb: coreboot framebuffer console

> From: Bryan Vyhmeister > Date: Wed, 15 Jun 2016 09:54:08 -0700 > > On Wed, Jun 15, 2016, at 09:34 AM, Bryan Steele wrote: > > On Wed, Jun 15, 2016 at 12:32:00PM -0400, Bryan Steele wrote: > > > On Wed, Jun 15, 2016 at 11:23:53AM -0500, joshua stein wrote: > > > > Any

Re: armv7 / efi failure on imx6q SabreLite

> Date: Sun, 12 Jun 2016 19:48:24 +0200 > From: Matthieu Herrb > > Hi, > > I'm trying to convert my SabreLite board to boot via efiboot, but > without success so far. > > I'm using the nitrogen6q u-boot from ports > > the boot loader is loaded and runs but it > fails to

Re: ptrace PT_IO write bug

Mathieu - schreef op 2016-05-28 13:05: Martin Natano wrote: The diff reads fine to me, however it is incomplete. There are some callers of process_domem() in arch/. They will need to be changed too. req seems to be in sync with uio_rw in all the cases, so just removing the last argument should

Re: libc/amd64: stop using sigblock/sigsetmask in setjmp/longjmp

Philip Guenther schreef op 2016-05-29 05:01: This converts setjmp/longjmp and their sig* versions to use the sigprocmask syscall directly instead of the obsolete sigblock/sigsetmask APIs. No change in the results of the regress/lib/libc/*setjmp* tests. Ok? ok kettenis@ Index: setjmp.S

<    3   4   5   6   7   8   9   10   11   12   >