Re: patch 1/4 add generic keyboard backlight support

On 11 December 2015 at 10:36, Joerg Jung wrote: > Ping. Anyone? > > > On 07 Dec 2015, at 23:39, Joerg Jung wrote: > > > > Hi, > > > > here comes a series of small diffs which add generic support for > > keyboard backlights. > > > > Please find below the first

Re: UTF-8 support for uniq(1)

Oh well. If something is supposedly simple... I got three OKs on this code, including one senior developer calling it simple and saying it shows how something like this should be done. Fortunately, Patrick Keshishian privately mailed me that he suspected a regression. Even though the

Re: Make em(4) more mpsafe again

On 05/12/15(Sat) 15:41, Claudio Jeker wrote: > So Mark and I spent some time to figure out what the issue was with ix(4) > based on that info I resurected the em(4) mpsafe diff that got backed out > and I applied the same fix. It is somewhat unclear if this fixes the > watchdog timeouts since in

Re: Make ix(4) mpsafe: take 2

On 04/12/15(Fri) 12:47, Mark Kettenis wrote: > Here is a new diff to make ix(4) mpsafe. Should now longer get stuck > in the OACTIVE state. Tests more than welcome. Like for em(4) it is the right time to put this in, ok mpi@ > Index: if_ix.c >

pfctl(8) detect multiple root queues on one interface

pfctl(8) doesn't check that there is at most one root queue per interface. For example: queue r0 on $if bandwidth 100M default queue r1 on $if bandwidth 100M default # pfctl -f /etc/pf.conf pfctl: DIOCXCOMMIT: Invalid argument Below is a diff for pfctl(8) to detect and report this situation

radeon_ring_test_lockup / radeon_sa_bo_manager_fini *ERROR*

Hi Everybody, After upgraded from snapshots/amd64 12/09/2015 (previous was 12/04/2015), I got this error (2 times) after trying to browse with chromium: drm:pid25286:radeon_ring_test_lockup *ERROR* GPU lockup CP stall for more than 1msec drm:pid25286:radeon_fence_wait_seq *WARNING* GPU

Re: Pull tmpfs fix from NetBSD

On Fri, Dec 11, 2015 at 01:09:30AM -0500, Michael McConville wrote: > Here's the PR: > > https://gnats.netbsd.org/50381 > > And the commit: > > https://marc.info/?l=netbsd-source-changes=144694603617544=2 > > We have very few local changes to tmpfs and we share the > KASSERT(de->td_node ==

Re: radeon_ring_test_lockup / radeon_sa_bo_manager_fini *ERROR*

You likely want to remove the radeonsi binary built against an older version of Mesa. rm /usr/X11R6/lib/modules/dri/radeonsi_dri.so Building a new one requires a newer llvm than ports has and building Mesa itself with gcc 4.9. On Fri, Dec 11, 2015 at 02:46:22PM +0100, Alexis de BRUYN

Re: Pull tmpfs fix from NetBSD

Bob Beck wrote: > Stability before performance. Tmpfs does not have the former yet. ok mmcc@ for your PR_ZERO diff, as long as there's a comment added about the performance impact and the potential to back out in the future. I think it'd still be worthwhile to add the NULL assignment from

Re: Pull tmpfs fix from NetBSD

On Fri, Dec 11, 2015 at 04:47:16PM -0500, Michael McConville wrote: > Stefan Sperling wrote: > > On Fri, Dec 11, 2015 at 04:05:49PM -0500, Michael McConville wrote: > > > Bob Beck wrote: > > > > Stability before performance. Tmpfs does not have the former yet. > > > > > > ok mmcc@ for your

Re: initial 802.11n implementation

Here's an updated diff, which applies to -current, for testing. I'll spend some time tomorrow splitting this up into smaller chunks for review with explanations of the changes. No known problems exist with this diff. Please test anywhere, even without iwm(4). Thanks. Index: dev/pci/if_iwm.c

Re: Pull tmpfs fix from NetBSD

> That said, using M_ZERO does sound like a safety improvement. However, > that also looks like a big struct (in the process of getting an actual > number). Thoughts on the performance impact? No performance impact at all. until the next time an uninitialized field occurs in there! then maybe

Re: Pull tmpfs fix from NetBSD

Stefan Sperling wrote: > On Fri, Dec 11, 2015 at 04:05:49PM -0500, Michael McConville wrote: > > Bob Beck wrote: > > > Stability before performance. Tmpfs does not have the former yet. > > > > ok mmcc@ for your PR_ZERO diff, as long as there's a comment added > > about the performance impact and

Re: Pull tmpfs fix from NetBSD

On Fri, Dec 11, 2015 at 04:05:49PM -0500, Michael McConville wrote: > Bob Beck wrote: > > Stability before performance. Tmpfs does not have the former yet. > > ok mmcc@ for your PR_ZERO diff, as long as there's a comment added about > the performance impact and the potential to back out in the

Re: Pull tmpfs fix from NetBSD

tmpfs actrually already must diverege from netbsd. we can not just blithly accept changes from there.. our kernel midlayers are very different. tmpfs actually does not work very well right now. On Fri, Dec 11, 2015 at 2:47 PM, Michael McConville wrote: > Stefan Sperling

Re: initial 802.11n implementation

On Sat, Dec 12, 2015 at 12:09:17AM +0100, Stefan Sperling wrote: > Here's an updated diff, which applies to -current, for testing. > I'll spend some time tomorrow splitting this up into smaller > chunks for review with explanations of the changes. > > No known problems exist with this diff. >

Re: patch 1/4 add generic keyboard backlight support

Ping. Anyone? > On 07 Dec 2015, at 23:39, Joerg Jung wrote: > > Hi, > > here comes a series of small diffs which add generic support for > keyboard backlights. > > Please find below the first diff, which adds new ioctls to wskbd(4) to > control keyboard backlights. > > In

2D acceleration for Nvidia

Without hardware acceleration my PowerBook G4 12'' with a NVIDIA GeForce FX Go 5200 is unusable. Since XAA is no longer supported, here's a simple EXA backend for nv(4) based on the XAA sources and Nouveau. It only implements Solid and Copy but that already makes a huge difference. To test it

Re: patch 1/4 add generic keyboard backlight support

> Am 11.12.2015 um 10:27 schrieb Ville Valkonen : > >> On 11 December 2015 at 10:36, Joerg Jung wrote: >> Ping. Anyone? >> >> > On 07 Dec 2015, at 23:39, Joerg Jung wrote: >> > >> > Hi, >> > >> > here comes a series of small diffs which

Re: Pull tmpfs fix from NetBSD

Bob Beck wrote: > On Fri, Dec 11, 2015 at 01:09:30AM -0500, Michael McConville wrote: > > Here's the PR: > > > > https://gnats.netbsd.org/50381 > > > > And the commit: > > > > https://marc.info/?l=netbsd-source-changes=144694603617544=2 > > > > We have very few local changes to tmpfs and we

uvm: remove unused args in uvm_mapent_fork*()

Index: uvm/uvm_map.c === RCS file: /cvs/src/sys/uvm/uvm_map.c,v retrieving revision 1.204 diff -u -p -r1.204 uvm_map.c --- uvm/uvm_map.c 14 Nov 2015 14:53:14 - 1.204 +++ uvm/uvm_map.c 11 Dec 2015 18:47:51 - @@

Re: 2D acceleration for Nvidia

On Fri, Dec 11, 2015 at 10:09:20AM +0100, Martin Pieuchot wrote: > Without hardware acceleration my PowerBook G4 12'' with a NVIDIA > GeForce FX Go 5200 is unusable. Since XAA is no longer supported, > here's a simple EXA backend for nv(4) based on the XAA sources and > Nouveau. It only

Re: Pull tmpfs fix from NetBSD

Stability before performance. Tmpfs does not have the former yet. On Fri, Dec 11, 2015 at 12:59 PM, Michael McConville wrote: > Bob Beck wrote: >> On Fri, Dec 11, 2015 at 01:09:30AM -0500, Michael McConville wrote: >> > Here's the PR: >> > >> > https://gnats.netbsd.org/50381