date:20160327

Re: acpi gpio support

2016-03-27 Thread Philip Guenther

On Sun, Mar 27, 2016 at 12:28 PM, Mark Kettenis  wrote:
> The diff below is a first stab at adding support for GPIOs as defined
> in ACPI 5.0.  The primary target for this new ACPI feature is hardware
> reduced platforms like those based on Intel's Bay Trail SoC.  The diff
> adds a bytgpio(4) driver for the hardware found on that SoC.  This
> driver registers itself with the acpi framework by setting the struct
> acpi_gpio pointer on the AML node for the device.  Then this gets used
> by the acpi sdhc(4) frontend to use the appropriate gpio as the card
> detect signal.  This makes it possible to detectwhether a card is
> inserted when the kernel boots.  Support for GPIO-based interrupts is
> still missing, so hotplugging SD cards doesn't work yet.
>
> There are some debug printfs here that will disappear eventually.
>
> ok?

Not really specific to this driver, but should we be using letoh16()
and similar when accessing the fields like pin_off?  We do so in a few
acpi drivers, but many do not and I'm not aware of any big-endian
archs that are looking to use ACPI ("here, have another albatross!").

...
> +/*
> + * The pads for the pins are randomly ordered.
> + */
> +
> +const int byt_score_pins[] = {

These values from some Intel doc?


...
> +   switch (uid) {
> +   case 1:
> +   sc->sc_pins = byt_score_pins;
> +   sc->sc_npins = nitems(byt_score_pins);

ok...

> +   break;
> +   case 2:
> +   sc->sc_pins = byt_score_pins;
> +   sc->sc_npins = nitems(byt_ncore_pins);

Uh, mismatch here and on the next.  Shouldn't sc_pins be set to
byt_ncore_pins and byt_sus_pins?

> +   break;
> +   case 3:
> +   sc->sc_pins = byt_score_pins;
> +   sc->sc_npins = nitems(byt_sus_pins);


Philip Guenther

Aq macro replacements

2016-03-27 Thread Christian Heckendorf

Hi,
There was some discussion last year[1] regarding abuse of Aq macros
in mdoc where plain characters or other macros (eg, "In") would be
more appropriate. Here are some additional places where I believe
replacing Aq would make sense.

Notes:
 - spamd-setup(8) is referring to pf tables. syslogd(8) and tcpdump(8)
   use Aq to format program I/O examples. None of these instances use
   mathematical unicode symbols in practice.
 - sysctl(8) mentions header files and tries to format them like C
   #includes. In the context of this command line utility, you
   wouldn't be including them, but the formatting close enough that I
   think .In was intended.
 - mk.conf(5) mentions the behaviour when including bsd.own.mk. It's not
   a C header, but again it has similar formatting so it changed to .In.

[1] http://marc.info/?l=openbsd-tech=142399113828201=2

--
Christian


Index: libexec/spamd-setup/spamd-setup.8
===
RCS file: /cvs/src/libexec/spamd-setup/spamd-setup.8,v
retrieving revision 1.20
diff -u -p -r1.20 spamd-setup.8
--- libexec/spamd-setup/spamd-setup.8   15 Sep 2013 20:02:33 -  1.20
+++ libexec/spamd-setup/spamd-setup.8   28 Mar 2016 01:55:19 -
@@ -46,9 +46,17 @@ is run in blacklist only mode,
 it also sends blacklist data to the
 .Xr pf 4
 table
-.Aq Ar spamd .
+.Sm off
+<
+.Ar spamd
+>.
+.Sm on
 The
-.Aq Ar spamd
+.Sm off
+<
+.Ar spamd
+>
+.Sm on
 table must then be used in conjunction with a
 .Xr pf 4
 redirection rule to selectively redirect mail connections
Index: sbin/sysctl/sysctl.8
===
RCS file: /cvs/src/sbin/sysctl/sysctl.8,v
retrieving revision 1.192
diff -u -p -r1.192 sysctl.8
--- sbin/sysctl/sysctl.83 Mar 2016 12:41:30 -   1.192
+++ sbin/sysctl/sysctl.828 Mar 2016 01:55:20 -
@@ -425,45 +425,45 @@ Use of the
 flag lists all the filesystems compiled into the running kernel.
 .Sh FILES
 .Bl -tag -width  -compact
-.It Aq Pa sys/sysctl.h
+.It In sys/sysctl.h
 definitions for top level identifiers and second level kernel and hardware
 identifiers
-.It Aq Pa dev/rndvar.h
+.It In dev/rndvar.h
 definitions for
 .Xr random 4
 device's statistics structure
-.It Aq Pa sys/socket.h
+.It In sys/socket.h
 definitions for second level network identifiers
-.It Aq Pa sys/gmon.h
+.It In sys/gmon.h
 definitions for third level profiling identifiers
-.It Aq Pa uvm/uvm_param.h
+.It In uvm/uvm_param.h
 definitions for second level virtual memory identifiers
-.It Aq Pa uvm/uvm_swap_encrypt.h
+.It In uvm/uvm_swap_encrypt.h
 definitions for third level virtual memory identifiers
-.It Aq Pa netinet/in.h
+.It In netinet/in.h
 definitions for third level IPv4/v6 identifiers and
 fourth level IPv4/v6 identifiers
-.It Aq Pa netinet/ip_divert.h
+.It In netinet/ip_divert.h
 definitions for fourth level divert identifiers
-.It Aq Pa netinet/icmp_var.h
+.It In netinet/icmp_var.h
 definitions for fourth level ICMP identifiers
-.It Aq Pa netinet6/icmp6.h
+.It In netinet6/icmp6.h
 definitions for fourth level ICMPv6 identifiers
-.It Aq Pa netinet/tcp_var.h
+.It In netinet/tcp_var.h
 definitions for fourth level TCP identifiers
-.It Aq Pa netinet/udp_var.h
+.It In netinet/udp_var.h
 definitions for fourth level UDP identifiers
-.It Aq Pa ddb/db_var.h
+.It In ddb/db_var.h
 definitions for second level ddb identifiers
-.It Aq Pa sys/mount.h
+.It In sys/mount.h
 definitions for second level vfs identifiers
-.It Aq Pa nfs/nfs.h
+.It In nfs/nfs.h
 definitions for third level NFS identifiers
-.It Aq Pa miscfs/fuse/fusefs.h
+.It In miscfs/fuse/fusefs.h
 definitions for third level fusefs identifiers
-.It Aq Pa ufs/ffs/ffs_extern.h
+.It In ufs/ffs/ffs_extern.h
 definitions for third level FFS identifiers
-.It Aq Pa machine/cpu.h
+.It In machine/cpu.h
 definitions for second level CPU identifiers
 .El
 .Sh EXAMPLES
Index: share/man/man5/mk.conf.5
===
RCS file: /cvs/src/share/man/man5/mk.conf.5,v
retrieving revision 1.30
diff -u -p -r1.30 mk.conf.5
--- share/man/man5/mk.conf.526 Oct 2015 10:43:42 -  1.30
+++ share/man/man5/mk.conf.528 Mar 2016 01:55:20 -
@@ -34,7 +34,7 @@
 .Fd .include 
 .Sh DESCRIPTION
 To get system-specific configuration parameters,
-.Aq bsd.own.mk
+.In bsd.own.mk
 will try to include the file specified by the
 .Ev MAKECONF
 variable.
@@ -50,7 +50,7 @@ and details of the format of make files,
 see
 .Xr make 1 .
 .Pp
-.Aq bsd.own.mk
+.In bsd.own.mk
 is generally useful when building Makefiles, so that
 they use the same default owners, etc. as the rest of the tree.
 These files may define any of the variables described below.
@@ -61,7 +61,7 @@ for a list of variables that can be set 
 subsystem.
 .Sh VARIABLES
 The following variables are set by
-.Aq bsd.own.mk ,
+.In bsd.own.mk ,
 if they are not already defined.
 Defaults are in brackets.
 .Bl -tag -width INSTALL_STRIP
@@

Re: wsdisplay_compat_usl/KDENABIO: no need to specisal case i386

2016-03-27 Thread Todd C. Miller

On Sun, 27 Mar 2016 22:47:38 +0200, Matthieu Herrb wrote:

> OpenBSD has stopped using the SVr4 KDENABIO/KDDISABIO ioctls for at
> least 10 years. No need for special treatement on i386.

OK millert@

 - todd

gdb on landisk

2016-03-27 Thread Miod Vallat

There is a fallout from the switch to binutils 2.17: the binaries
created by 2.17 aren't recognized by the in-tree gdb because it's built
with the bfd code from 2.15.

My understanding is that the in-tree gdb can't be made to run with bfd
from 2.17 without significant non-trivial changes, so I'd suggest the
following diff.

Index: gnu/usr.bin/binutils/bfd/elf32-sh.c
===
RCS file: /OpenBSD/src/gnu/usr.bin/binutils/bfd/elf32-sh.c,v
retrieving revision 1.3
diff -u -p -r1.3 elf32-sh.c
--- gnu/usr.bin/binutils/bfd/elf32-sh.c 22 Dec 2014 14:09:58 -  1.3
+++ gnu/usr.bin/binutils/bfd/elf32-sh.c 20 Nov 2015 20:56:20 -
@@ -6849,6 +6849,7 @@ sh_elf_set_mach_from_flags (bfd *abfd)
   break;
 case EF_SH_UNKNOWN:
 case EF_SH4:
+case 23: /* EF_SH2A_SH4 */
   bfd_default_set_arch_mach (abfd, bfd_arch_sh, bfd_mach_sh4);
   break;
 case EF_SH4_NOFPU:

Re: uvm: enable amap per-page refcounting unconditionally

2016-03-27 Thread Miod Vallat


> It seems per-page reference counting is used since forever. I think
> there's no reason to ever turn it off (and track referenced pages
> with less accuracy, causing leaks).

Actually, assuming the #undef code path works, it might work keeping
this and only defining UVM_AMAP_PPREF iff defined(SMALL_KERNEL).

Re: Scheduler hack for multi-threaded processes

2016-03-27 Thread Edd Barrett

On Thu, Mar 24, 2016 at 12:09:39PM +, Edd Barrett wrote:
> On Wed, Mar 23, 2016 at 09:35:50PM +0100, Mark Kettenis wrote:
> > So here is a diff that keeps yield() the same and adds the code in the
> > sched_yield(2) implementation instead.
> 
> I'm going to now run with this diff for a while. On first glance,
> browser performance is good. Video seems to work well in firefox.

Just to follow this up. Zero problems in the last 4 days. Good browser
experience.

I can't vouch for the code though.

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

wsdisplay_compat_usl/KDENABIO: no need to specisal case i386

2016-03-27 Thread Matthieu Herrb

Hi,

OpenBSD has stopped using the SVr4 KDENABIO/KDDISABIO ioctls for at
least 10 years. No need for special treatement on i386.

ok?

Index: wsdisplay_compat_usl.c
===
RCS file: /cvs/OpenBSD/src/sys/dev/wscons/wsdisplay_compat_usl.c,v
retrieving revision 1.29
diff -u -r1.29 wsdisplay_compat_usl.c
--- wsdisplay_compat_usl.c  3 Mar 2016 18:00:49 -   1.29
+++ wsdisplay_compat_usl.c  27 Mar 2016 20:44:59 -
@@ -392,14 +392,6 @@
 #undef d
return (0);
 
-#if defined(__i386__)
-   case KDENABIO:
-   if (suser(p, 0) || securelevel > 0)
-   return (EPERM);
-   /* FALLTHROUGH */
-   case KDDISABIO:
-   return (0);
-#else
case KDENABIO:
case KDDISABIO:
/*
@@ -407,7 +399,7 @@
 * issue these ioctls anyway.
 */
return (0);
-#endif
+
case KDSETRAD:
/* XXX ignore for now */
return (0);

-- 
Matthieu Herrb


signature.asc
Description: PGP signature

Re: Possible kernel function with stack frame > 2048 bytes

2016-03-27 Thread Michael McConville

Michael McConville wrote:
> Clang 3.7 gives this warning when building the kernel:
> 
> > ../../../../dev/audio.c:1852:1: warning: stack frame size of 2504 bytes in 
> > function 'wskbd_initvol' [-Wframe-larger-than=]
> > wskbd_initvol(struct audio_softc *sc, struct wskbd_vol *vol, char *cn, char 
> > *dn)
> > ^
> 
> -Wframe-larger-than was backported to base GCC, so maybe there's a bug
> that caused it to erroneously overlook this one. It's also possible that
> Clang just compiles this function differently, but >450 bytes seems like
> a really big difference.
> 
> Maybe it isn't worth fixing, but I thought it was worth pointing out. It
> seems like it may have been introduced by the simplifications last June:
> 
> https://marc.info/?t=14340075202=1=2

I broke out objdump (should have done that initially) and, if I'm
reading the asm right, the stack frame is only 1,688 bytes with base
GCC. Maybe there's more aggressive stack space reuse.

Re: mpsafe aesni

2016-03-27 Thread mxb

Not sure how much I can test here, but my tunnels are up.
As well as my bgp sessions (this is "ART box” now) on top.

I use aes-128-gcm.
This is vmware.

//mxb

> On 26 mars 2016, at 16:25, Mike Belopuhov  wrote:
> 
> On Fri, Mar 25, 2016 at 22:43 +0100, Mark Kettenis wrote:
>>> From: Mike Belopuhov 
>>> Date: Thu, 24 Mar 2016 21:33:25 +0100
>>> 
>>> On 24 March 2016 at 20:53, Mark Kettenis  wrote:
 Diff below makes aesni crypto "mpsafe".  It adds a CRYPTOCAP_F_MPSAFE
 flag that makes the crypto framework dispatch to an mpsafe taskq if it
 is set.  In order to make the aesni_process() function that does the
 actual crypto work mpsafe, it moves the code over to a per-session
 working buffer.  This obviously increases the cost of setting up a
 session a bit.  Directly invoked crypto operations remain locked.  My
 main laptop seem to do ipsec fine with this, but I'm not sure if there
 is an actual performance gain.  So it would probably be good if
 somebody could benchmark this.
 
 Comments?
>>> 
>>> It should be fairly simple to use SRP for the session list so that you
>>> don't have to take the mutex in the aesni_process.  Other than that I
>>> think this should go in once tests are made and people a happy with
>>> the results.
>> 
>> Actually, I'm not sure that's possible.  I think aesni_newsession()
>> and aesni_freesession() can be called from interrupt context or at
>> least are not supposed to sleep. 
> 
> I thought that it's not possible, but it looks like at least tdb_free
> can be called anywhere and it will trigger freesession, which is a tad
> unfortunate IMO, yet understandable.
> 
>> They would call
>> SRPL_INSERT_HEAD_LOCKED() and SRPL_REMOVE_LOCKED(), which can only be
>> called from process context.
>> 
> 
> Not process context though, but under a lock, which wouldn't save
> us the mtx_enter anyway.
> 
>>> 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 subsystems, just those that use
> IPL_BIO and IPL_NET for interrupts and IPL_HIGH just includes
> AUDIO and CLOCK which don't call any crypto(9) code.  So what
> are you trying to protect it from or is it just a placeholder
> value?  I'm fine if it is, just curious.

Possible kernel function with stack frame > 2048 bytes

2016-03-27 Thread Michael McConville

Clang 3.7 gives this warning when building the kernel:

> ../../../../dev/audio.c:1852:1: warning: stack frame size of 2504 bytes in 
> function 'wskbd_initvol' [-Wframe-larger-than=]
> wskbd_initvol(struct audio_softc *sc, struct wskbd_vol *vol, char *cn, char 
> *dn)
> ^

-Wframe-larger-than was backported to base GCC, so maybe there's a bug
that caused it to erroneously overlook this one. It's also possible that
Clang just compiles this function differently, but >450 bytes seems like
a really big difference.

Maybe it isn't worth fixing, but I thought it was worth pointing out. It
seems like it may have been introduced by the simplifications last June:

https://marc.info/?t=14340075202=1=2

xhci wedges on Supermicro X11SSL-F (Intel C232)

2016-03-27 Thread Paul B. Henson

I'm trying to install OpenBSD on a Supermicro X11SSL-F board (which has
an Intel C232 chipset, the kernel wedges after displaying:

xhci0 at pci0 dev 20 function 0 "Intel 100 Series xHCI" rev 0x31: msi
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 "Intel xHCI root hub" rev 3.00/1.00 addr 1

I tried the latest 5.9 snapshot and also compiled the latest
openbsd-current kernel with the same outcome. I enabled XHCI_DEBUG and
UHUB_DEBUG and tried again, which gave the following output:

xhci0 at pci0 dev 20 function 0 "Intel 100 Series xHCI" rev 0x31: msi
xhci0: xHCI version 1.0
xhci0: CAPLENGTH=0x80
xhci0: DOORBELL=0x3000
xhci0: RUNTIME=0x2000
xhci0: 32 bytes context
xhci0: supported page size 0x0001
xhci0: 22 ports and 64 slots
xhci0: 2 scratch pages
xhci0: USB3PRM / USB3.0 configurable ports: 0x0018
xhci0: USB3_PSSEN / Enabled USB3.0 ports under xHCI: 0x
xhci0: XUSB2PRM / USB2.0 ports can switch from EHCI to xHCI:0x
xhci0: XUSB2PR / USB2.0 ports under xHCI: 0x
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 "Intel xHCI root hub" rev 3.00/1.00 addr 1
uhub0: 22 ports with 22 removable, self powered
xhci0: DCBAAP=00x7d459000
xhci0: CRCR=00 (7d45a000)
xhci0: ERSTBA=00x7d0a8000
xhci0: ERDP=00x7d45b000

If I boot -c and disable xhci, it works fine, but with no usb support.
Any thoughts? I don't really need usb on this server, but it would be
nice to have it working in general. Here is the full dmesg from the
-current kernel with xhci disabled:

OpenBSD 5.9-current (GENERIC.MP) #0: Sat Mar 26 21:09:30 PDT 2016
r...@lisa.pbhware.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16976416768 (16189MB)
avail mem = 16457695232 (15695MB)
User Kernel Config
UKC> disable xhci
137 xhci* disabled
UKC> quit
Continuing...
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7fb95000 (59 entries)
bios0: vendor American Megatrends Inc. version "1.0b" date
12/29/2015
bios0: Supermicro Super Server
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT SPMI MCFG HPET SSDT LPIT SSDT
SSDT SSDT DBGP DBG2 SSDT SSDT UEFI SSDT DMAR EINJ ERST BERT HEST
acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4)
PEG2(S4) PXSX(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4)
PXSX(S4) RP12(S4) PXSX(S4) RP13(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E3-1240L v5 @ 2.10GHz, 2100.85 MHz
cpu0:

FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 23MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E3-1240L v5 @ 2.10GHz, 2100.00 MHz
cpu1:

FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU E3-1240L v5 @ 2.10GHz, 2100.00 MHz
cpu2:

FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Xeon(R) CPU E3-1240L v5 @ 2.10GHz, 2100.00 MHz
cpu3:

acpi gpio support

2016-03-27 Thread Mark Kettenis

The diff below is a first stab at adding support for GPIOs as defined
in ACPI 5.0.  The primary target for this new ACPI feature is hardware
reduced platforms like those based on Intel's Bay Trail SoC.  The diff
adds a bytgpio(4) driver for the hardware found on that SoC.  This
driver registers itself with the acpi framework by setting the struct
acpi_gpio pointer on the AML node for the device.  Then this gets used
by the acpi sdhc(4) frontend to use the appropriate gpio as the card
detect signal.  This makes it possible to detectwhether a card is
inserted when the kernel boots.  Support for GPIO-based interrupts is
still missing, so hotplugging SD cards doesn't work yet.

There are some debug printfs here that will disappear eventually.

ok?


Index: acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.305
diff -u -p -r1.305 acpi.c
--- acpi.c  17 Jan 2016 09:04:18 -  1.305
+++ acpi.c  27 Mar 2016 19:18:31 -
@@ -2801,6 +2801,8 @@ acpi_foundhid(struct aml_node *node, voi
!strcmp(dev, ACPI_DEV_TOSHIBA_SPA40)) {
aaa.aaa_name = "acpitoshiba";
acpi_toshiba_enabled = 1;
+   } else if (!strcmp(dev, "INT33FC")) {
+   aaa.aaa_name = "bytgpio";
} else if (!strcmp(dev, "80860F14") || !strcmp(dev, "PNP0FFF")) {
aaa.aaa_name = "sdhc";
} else if (!strcmp(dev, ACPI_DEV_DWIIC1) ||
Index: amltypes.h
===
RCS file: /cvs/src/sys/dev/acpi/amltypes.h,v
retrieving revision 1.40
diff -u -p -r1.40 amltypes.h
--- amltypes.h  7 Sep 2012 19:19:59 -   1.40
+++ amltypes.h  27 Mar 2016 19:18:31 -
@@ -364,6 +364,11 @@ struct acpi_pci {
int _s4w;
 };
 
+struct acpi_gpio {
+   void*cookie;
+   int (*read_pin)(void *, int);
+};
+
 struct aml_node {
struct aml_node *parent;
 
@@ -377,6 +382,7 @@ struct aml_node {
 
struct aml_value *value;
struct acpi_pci  *pci;
+   struct acpi_gpio *gpio;
 };
 
 #define aml_bitmask(n) (1L << ((n) & 0x7))
Index: bytgpio.c
===
RCS file: bytgpio.c
diff -N bytgpio.c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ bytgpio.c   27 Mar 2016 19:18:31 -
@@ -0,0 +1,242 @@
+/* $OpenBSD$   */
+/*
+ * Copyright (c) 2016 Mark Kettenis
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define BYTGPIO_PAD_VAL0x0001
+
+struct bytgpio_softc {
+   struct device sc_dev;
+   struct acpi_softc *sc_acpi;
+   struct aml_node *sc_node;
+
+   bus_space_tag_t sc_memt;
+   bus_space_handle_t sc_memh;
+   bus_addr_t sc_addr;
+   bus_size_t sc_size;
+
+   int sc_irq;
+   int sc_irq_flags;
+   void *sc_ih;
+
+   const int *sc_pins;
+   int sc_npins;
+
+   struct acpi_gpio sc_gpio;
+};
+
+intbytgpio_match(struct device *, void *, void *);
+void   bytgpio_attach(struct device *, struct device *, void *);
+
+struct cfattach bytgpio_ca = {
+   sizeof(struct bytgpio_softc), bytgpio_match, bytgpio_attach
+};
+
+struct cfdriver bytgpio_cd = {
+   NULL, "bytgpio", DV_DULL
+};
+
+const char *bytgpio_hids[] = {
+   "INT33FC",
+   0
+};
+
+/*
+ * The pads for the pins are randomly ordered.
+ */
+
+const int byt_score_pins[] = {
+   85, 89, 93, 96, 99, 102, 98, 101, 34, 37, 36, 38, 39, 35, 40,
+   84, 62, 61, 64, 59, 54, 56, 60, 55, 63, 57, 51, 50, 53, 47,
+   52, 49, 48, 43, 46, 41, 45, 42, 58, 44, 95, 105, 70, 68, 67,
+   66, 69, 71, 65, 72, 86, 90, 88, 92, 103, 77, 79, 83, 78, 81,
+   80, 82, 13, 12, 15, 14, 17, 18, 19, 16, 2, 1, 0, 4, 6, 7, 9,
+   8, 33, 32, 31, 30, 29, 27, 25, 28, 26, 23, 21, 20, 24, 22, 5,
+   3, 10, 11, 106, 87, 91, 104, 97, 100
+};
+
+const int byt_ncore_pins[] = {
+   19, 18, 17, 20, 21, 22, 24, 25, 23, 16, 14, 15, 12, 26, 27,
+   1, 4, 8, 11, 0, 3, 6, 10, 13, 2, 5, 9, 7
+};
+
+const int byt_sus_pins[] = {
+29, 33, 30, 31, 32, 34, 36, 35, 38, 37, 18, 7, 11, 20, 17, 1,
+   8, 10, 19,

Re: ffs_read() tweak

2016-03-27 Thread Martin Pieuchot

On 07/03/16(Mon) 12:46, Martin Pieuchot wrote:
> bread_cluster() can be called unconditionally.  The sequential check is
> a leftover of the read-ahead mechanism that FFS no longer used since the
> introduction of the Dynamic Buffer cache.
> 
> ok?

Anyone?

> 
> Index: ufs/ffs/ffs_vnops.c
> ===
> RCS file: /cvs/src/sys/ufs/ffs/ffs_vnops.c,v
> retrieving revision 1.80
> diff -u -p -r1.80 ffs_vnops.c
> --- ufs/ffs/ffs_vnops.c   14 Mar 2015 03:38:52 -  1.80
> +++ ufs/ffs/ffs_vnops.c   3 Jan 2016 21:42:22 -
> @@ -242,14 +242,11 @@ ffs_read(void *v)
>  
>   if (lblktosize(fs, nextlbn) >= DIP(ip, size))
>   error = bread(vp, lbn, size, );
> - else if (lbn - 1 == ip->i_ci.ci_lastr) {
> + else
>   error = bread_cluster(vp, lbn, size, );
> - } else
> - error = bread(vp, lbn, size, );
>  
>   if (error)
>   break;
> - ip->i_ci.ci_lastr = lbn;
>  
>   /*
>* We should only get non-zero b_resid when an I/O error
>

Re: multitouch support again

2016-03-27 Thread Alexandr Shadchin

On Sat, Mar 26, 2016 at 10:37:08PM +0100, Martin Pieuchot wrote:
> On 25/03/16(Fri) 13:23, Ulf Brosziewski wrote:
> > Again, my mail client insisted on the "flowed" text format,
> > sorry. Here is a clean version of the diff.
> 
> Tested with:
> 
>   pms0: Synaptics clickpad, firmware 8.0
> 
> In think this should go in, then we can polish it in-tree and wait for
> regression before converting mice.
> 
> ok mpi@
> 

Also tested with:
 pms0: Synaptics touchpad, firmware 7.4

I support, ok shadchin@

-- 
Alexandr Shadchin

[Patch/bgpd] Remove unused argument from community_ext_*

2016-03-27 Thread Denis Fondras

Hi,

I noticed that multiple functions from OpenBGPd declared an argument "u_int16_t
neighas" that is never used.
Here is a patch to remove it.

Denis

Index: parse.y
===
RCS file: /cvs/src/usr.sbin/bgpd/parse.y,v
retrieving revision 1.286
diff -u -p -r1.286 parse.y
--- parse.y 27 Oct 2015 18:19:33 -  1.286
+++ parse.y 27 Mar 2016 16:22:42 -
@@ -783,7 +783,7 @@ rdomainopts : RD STRING {
 * RD is almost encode like an ext-community,
 * but only almost so convert here.
 */
-   if (community_ext_conv(, 0, )) {
+   if (community_ext_conv(, )) {
yyerror("bad encoding of rd");
YYERROR;
}
Index: rde.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
retrieving revision 1.345
diff -u -p -r1.345 rde.c
--- rde.c   22 Dec 2015 21:36:57 -  1.345
+++ rde.c   27 Mar 2016 16:22:43 -
@@ -2429,7 +2429,7 @@ rde_rdomain_import(struct rde_aspath *as
struct filter_set   *s;
 
TAILQ_FOREACH(s, >import, entry) {
-   if (community_ext_match(asp, >action.ext_community, 0))
+   if (community_ext_match(asp, >action.ext_community))
return (1);
}
return (0);
Index: rde.h
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.h,v
retrieving revision 1.149
diff -u -p -r1.149 rde.h
--- rde.h   6 Nov 2015 16:23:26 -   1.149
+++ rde.h   27 Mar 2016 16:22:43 -
@@ -368,13 +368,12 @@ intcommunity_match(struct rde_aspath 
 int community_set(struct rde_aspath *, int, int);
 voidcommunity_delete(struct rde_aspath *, int, int);
 int community_ext_match(struct rde_aspath *,
-   struct filter_extcommunity *, u_int16_t);
+   struct filter_extcommunity *);
 int community_ext_set(struct rde_aspath *,
-   struct filter_extcommunity *, u_int16_t);
+   struct filter_extcommunity *);
 voidcommunity_ext_delete(struct rde_aspath *,
-   struct filter_extcommunity *, u_int16_t);
-int community_ext_conv(struct filter_extcommunity *, u_int16_t,
-   u_int64_t *);
+   struct filter_extcommunity *);
+int community_ext_conv(struct filter_extcommunity *, u_int64_t *);
 
 /* rde_decide.c */
 voidprefix_evaluate(struct prefix *, struct rib_entry *);
Index: rde_attr.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde_attr.c,v
retrieving revision 1.95
diff -u -p -r1.95 rde_attr.c
--- rde_attr.c  24 Oct 2015 08:00:42 -  1.95
+++ rde_attr.c  27 Mar 2016 16:22:44 -
@@ -971,7 +971,7 @@ aspath_lenmatch(struct aspath *a, enum a
  * Functions handling communities and extended communities.
  */
 
-int community_ext_matchone(struct filter_extcommunity *, u_int16_t, u_int64_t);
+int community_ext_matchone(struct filter_extcommunity *, u_int64_t);
 
 int
 community_match(struct rde_aspath *asp, int as, int type)
@@ -1112,8 +1112,7 @@ community_delete(struct rde_aspath *asp,
 }
 
 int
-community_ext_match(struct rde_aspath *asp, struct filter_extcommunity *c,
-u_int16_t neighas)
+community_ext_match(struct rde_aspath *asp, struct filter_extcommunity *c)
 {
struct attr *attr;
u_int8_t*p;
@@ -1128,7 +1127,7 @@ community_ext_match(struct rde_aspath *a
p = attr->data;
for (len = attr->len / sizeof(ec); len > 0; len--) {
memcpy(, p, sizeof(ec));
-   if (community_ext_matchone(c, neighas, ec))
+   if (community_ext_matchone(c, ec))
return (1);
p += sizeof(ec);
}
@@ -1137,8 +1136,7 @@ community_ext_match(struct rde_aspath *a
 }
 
 int
-community_ext_set(struct rde_aspath *asp, struct filter_extcommunity *c,
-u_int16_t neighas)
+community_ext_set(struct rde_aspath *asp, struct filter_extcommunity *c)
 {
struct attr *attr;
u_int8_t*p = NULL;
@@ -1146,7 +1144,7 @@ community_ext_set(struct rde_aspath *asp
unsigned int i, ncommunities = 0;
u_int8_t f = ATTR_OPTIONAL|ATTR_TRANSITIVE;
 
-   if (community_ext_conv(c, neighas, ))
+   if (community_ext_conv(c, ))
return (0);
 
attr = attr_optget(asp, ATTR_EXT_COMMUNITIES);
@@ -1185,8 +1183,7 @@ community_ext_set(struct rde_aspath *asp
 }
 
 void
-community_ext_delete(struct rde_aspath *asp, struct filter_extcommunity *c,
-u_int16_t neighas)
+community_ext_delete(struct rde_aspath *asp, struct filter_extcommunity *c)
 {

Re: /etc/netstart: route delete 224.0.0.0/4

2016-03-27 Thread Todd C. Miller

On Sun, 27 Mar 2016 16:20:18 +0100, Stuart Henderson wrote:

> /etc/netstart has a "route -qn delete 224.0.0.0/4" before it adds
> the multicast reject route:
> 
> 270 # Multicast routing.
> 271 route -qn delete 224.0.0.0/4 >/dev/null 2>&1
> 272 [[ $multicast != YES ]] &&
> 273 route -qn add -net 224.0.0.0/4 -interface 127.0.0.1 -reject >/dev
> /null
> 
> So there's no way to hook in to create the route before daemons start.
> You can't set it in hostname.if because the "route delete" will zap it.
> You can add it in /etc/rc.local but that's a bit late, really. Should
> we just get rid of the "delete"?

That makes sense to me.

 - todd

Re: /etc/netstart: route delete 224.0.0.0/4

2016-03-27 Thread Martin Pieuchot

On 27/03/16(Sun) 16:20, Stuart Henderson wrote:
> Noticed while looking at the minidlna problem with ART, but this is
> not responsible for the problem.
> 
> /etc/netstart has a "route -qn delete 224.0.0.0/4" before it adds
> the multicast reject route:
> 
> 270 # Multicast routing.
> 271 route -qn delete 224.0.0.0/4 >/dev/null 2>&1
> 272 [[ $multicast != YES ]] &&
> 273 route -qn add -net 224.0.0.0/4 -interface 127.0.0.1 -reject 
> >/dev/null
> 
> So there's no way to hook in to create the route before daemons start.
> You can't set it in hostname.if because the "route delete" will zap it.
> You can add it in /etc/rc.local but that's a bit late, really. Should
> we just get rid of the "delete"?

I think that keeping the delete makes sense if we say that running
/etc/netstart should "restore" your network configuration to what's
defined in /etc.

So I'm ok with your diff.

> Index: netstart
> ===
> RCS file: /cvs/src/etc/netstart,v
> retrieving revision 1.167
> diff -u -p -r1.167 netstart
> --- netstart  29 Dec 2015 19:37:31 -  1.167
> +++ netstart  27 Mar 2016 15:18:06 -
> @@ -268,9 +268,10 @@ done
>  done
>  
>  # Multicast routing.
> -route -qn delete 224.0.0.0/4 >/dev/null 2>&1
> -[[ $multicast != YES ]] &&
> +if [[ $multicast != YES ]]; then
> + route -qn delete 224.0.0.0/4 >/dev/null 2>&1
>   route -qn add -net 224.0.0.0/4 -interface 127.0.0.1 -reject >/dev/null
> +fi
>  
>  # Configure PPPoE, GIF, GRE, TUN and PFLOW interfaces, delayed because they
>  # require routes to be set. TUN might depend on PPPoE, and GIF or GRE may
> 
> 
> Here's the code before simplification - i.e. if you set multicast_host
> to an interface name, it would add the -interface route at this point
> during startup.
> 
> 270 # Multicast routing.
> 271 #
> 272 # The routing to the 224.0.0.0/4 net is setup according to these rules:
> 273 # multicast_hostmulticast_routerroute   comment
> 274 # NONO  -reject no 
> multicast
> 275 # NOYES none installed  daemon 
> will run
> 276 # YES/interface NO  -interface  YES=def. 
> iface
> 277 #  Any other combination-reject config 
> error
> 278 route -qn delete 224.0.0.0/4 >/dev/null 2>&1
> 279 case "$multicast_host:$multicast_router" in
> 280 NO:NO)
> 281 route -qn add -net 224.0.0.0/4 -interface 127.0.0.1 -reject 
> >/dev/null
> 282 ;;
> 283 NO:YES)
> 284 ;;
> 285 *:NO)
> 286 maddr=$(if [[ $multicast_host == YES ]]; then
> 287 ed -s '!route -qn show -inet' < 288 /^default/p
> 289 EOF
> 290 else
> 291 ed -s "!ifconfig $multicast_host" < 292 /^  inet /p
> 293 EOF
> 294 fi 2>/dev/null)
> 295 if [[ -n $maddr ]]; then
> 296 set $maddr
> 297 route -qn add -net 224.0.0.0/4 -interface $2 >/dev/null
> 298 else
> 299 route -qn add -net 224.0.0.0/4 -interface \
> 300 127.0.0.1 -reject >/dev/null
> 301 fi
> 302 ;;
> 303 *:*)
> 304 echo 'config error, multicasting disabled until rc.conf is fixed'
> 305 route -qn add -net 224.0.0.0/4 -interface 127.0.0.1 -reject 
> >/dev/null
> 306 ;;
> 307 esac
>

/etc/netstart: route delete 224.0.0.0/4

2016-03-27 Thread Stuart Henderson

Noticed while looking at the minidlna problem with ART, but this is
not responsible for the problem.

/etc/netstart has a "route -qn delete 224.0.0.0/4" before it adds
the multicast reject route:

270 # Multicast routing.
271 route -qn delete 224.0.0.0/4 >/dev/null 2>&1
272 [[ $multicast != YES ]] &&
273 route -qn add -net 224.0.0.0/4 -interface 127.0.0.1 -reject 
>/dev/null

So there's no way to hook in to create the route before daemons start.
You can't set it in hostname.if because the "route delete" will zap it.
You can add it in /etc/rc.local but that's a bit late, really. Should
we just get rid of the "delete"?

Index: netstart
===
RCS file: /cvs/src/etc/netstart,v
retrieving revision 1.167
diff -u -p -r1.167 netstart
--- netstart29 Dec 2015 19:37:31 -  1.167
+++ netstart27 Mar 2016 15:18:06 -
@@ -268,9 +268,10 @@ done
 done
 
 # Multicast routing.
-route -qn delete 224.0.0.0/4 >/dev/null 2>&1
-[[ $multicast != YES ]] &&
+if [[ $multicast != YES ]]; then
+   route -qn delete 224.0.0.0/4 >/dev/null 2>&1
route -qn add -net 224.0.0.0/4 -interface 127.0.0.1 -reject >/dev/null
+fi
 
 # Configure PPPoE, GIF, GRE, TUN and PFLOW interfaces, delayed because they
 # require routes to be set. TUN might depend on PPPoE, and GIF or GRE may


Here's the code before simplification - i.e. if you set multicast_host
to an interface name, it would add the -interface route at this point
during startup.

270 # Multicast routing.
271 #
272 # The routing to the 224.0.0.0/4 net is setup according to these rules:
273 # multicast_hostmulticast_routerroute   comment
274 # NONO  -reject no multicast
275 # NOYES none installed  daemon will 
run
276 # YES/interface NO  -interface  YES=def. 
iface
277 #  Any other combination-reject config error
278 route -qn delete 224.0.0.0/4 >/dev/null 2>&1
279 case "$multicast_host:$multicast_router" in
280 NO:NO)
281 route -qn add -net 224.0.0.0/4 -interface 127.0.0.1 -reject 
>/dev/null
282 ;;
283 NO:YES)
284 ;;
285 *:NO)
286 maddr=$(if [[ $multicast_host == YES ]]; then
287 ed -s '!route -qn show -inet' /dev/null
298 else
299 route -qn add -net 224.0.0.0/4 -interface \
300 127.0.0.1 -reject >/dev/null
301 fi
302 ;;
303 *:*)
304 echo 'config error, multicasting disabled until rc.conf is fixed'
305 route -qn add -net 224.0.0.0/4 -interface 127.0.0.1 -reject 
>/dev/null
306 ;;
307 esac

Re: ART regression, multicast

2016-03-27 Thread Stuart Henderson

On 2016/03/27 12:28, Martin Pieuchot wrote:
> On 26/03/16(Sat) 23:25, Stuart Henderson wrote:
> > On 2016/03/26 23:21, Stuart Henderson wrote:
> > >   Sorry I don't have a simple test method,
> > 
> > oh, there are some example programs in p5-IO-Socket-Multicast (in
> > /usr/local/share/examples/p5-IO-Socket-Multicast), can't reboot
> > again right now to test that they fail with ART, but they work ok
> > without ART and it looks like they might be an easier way..just
> > run server.pl on one box, client.pl on another.
> 
> Thanks for the report unfortunately I don't understand the problem.
> 
> p5-IO-Socket-Multicast server & client work just fine here with ART,
> w/ and w/o default route for multicast addresses.
> 
> avahi-based services also work fine here (group is 224.0.0.251).
> 

Hmmm. OK yes it does seem to be working with client.pl/server.pl here
as well. So I'm only seeing the problem with minidlna. There aren't any
unexpected messages in minidlna's log.

Restarting minidlna at runtime doesn't help (though if it is restarted
while gupnp-universal-cp is actually running it *does* show up;
at least until you restart gupnp-universal-cp: most of these clients
seem to cache the endpoints until restarted). Adding/removing
routes at runtime (in various different orders) doesn't seem to help.

I had an offlist report that minidlna was working with a recent snap,
so I think it may well be connected with the -interface route that
I mentioned I'm using, "route add 224/4 -interface 10.15.5.2".
But looking at captures on the minidlna box itself it doesn't make
sense, tcpdump shows the same "contentdirectory" udp packet from
239.255.255.250.1900 > 10.15.5.27.$client_port going out on vlan5
with either kernel (I checked the MAC addresses etc too), but with
the ART one we don't see a subsequent TCP request on the location
given in the udp packet..

I'm building my own kernels to test, the only difference is ART/not,
so it's not some unrelated change. I am totally confused, next step
I guess is to try and figure out if my switch can mirror the port
and find another machine to capture on, to see if it does actually
get transmitted...

Re: Scheduler hack for multi-threaded processes

2016-03-27 Thread Stuart Henderson

On 2016/03/27 14:32, Mark Kettenis wrote:
> > From: attila 
> > Date: Sat, 26 Mar 2016 17:47:38 -0600
> > 
> > Jyri Hovila [Turvamies.fi]  writes:
> > 
> > > I can report significant usability improvement on a single core
> > > ThinkPad T42 and a dual core ThinkPad X60.
> > 
> > I hate to crap on this wonderful parade, but on my T60 (i386, dmesg at
> > bottom) running 25 march snap the heat has bumped a full 10DegC from
> > what was "normal" before.  I'm sorry for the lack of science here and
> > I have no hard numbers w/wo patch yet but in the past my steady state
> > on this machine w/o firefox was something like 70DegC, w/just some
> > xterms and emacs (aka life).  Starting firefox generally added 10DegC
> > before I did anything at all and I always had to watch the heat and
> > kill firefox when we crossed 95DegC or Bad Things Happened; thus I
> > live with w3m in one hand and treat firefox as some kind of
> > luxury... tor-browser was, strangely, less hard on things but maybe
> > that's just because I never have too many tabs there (also, maybe
> > firefox-esr is a little lighter, not sure).
> > 
> > Now it will be a challenge to see if I can cvs up, back out the patch
> > and build a kernel without ringing the bell (100DegC).  I freely admit
> > this is an old, P.O.S. laptop and that there might be some HW issue
> > (fan seems fine but I haven't taken it apart and really looked).  It
> > does seem like the difference in the scheduler has a remarkable effect
> > on heat in my case.
> 
> If you're not running any multi-threaded code the diff should have
> zero impact.  And I expect the diff to actually decrease the CPU load
> when running such code, and therefore lower the temperature.  This is
> most likely a hardware issue, i.e. dust or a failing fan.
> 

Some Thinkpads don't run the fan properly after a suspend+resume
when running OpenBSD.  It couldn't be that, could it?

ehci_device_clear_toggle

2016-03-27 Thread Martin Pieuchot

Diff below changes when QH are added and removed to/from the async list.
It allows to cancel a transfer by simply unlinking its QH.

This should be enough to prevent the race in ehci_abort_xfer() resulting
in the infamous ehci_device_clear_toggle() panic.

I'd appreciate if people could test this on various controllers,
including suspend/resume, and report back.

Index: ehci.c
===
RCS file: /cvs/src/sys/dev/usb/ehci.c,v
retrieving revision 1.190
diff -u -p -r1.190 ehci.c
--- ehci.c  11 Dec 2015 12:23:09 -  1.190
+++ ehci.c  27 Mar 2016 12:35:33 -
@@ -189,12 +189,11 @@ int   ehci_alloc_sitd_chain(struct ehci_s
 void   ehci_abort_isoc_xfer(struct usbd_xfer *xfer,
usbd_status status);
 
-usbd_statusehci_device_setintr(struct ehci_softc *, struct ehci_soft_qh *,
-   int ival);
+struct ehci_soft_qh * ehci_intr_get_sqh(struct usbd_pipe *);
 
-void   ehci_add_qh(struct ehci_soft_qh *, struct ehci_soft_qh *);
-void   ehci_rem_qh(struct ehci_softc *, struct ehci_soft_qh *);
-void   ehci_set_qh_qtd(struct ehci_soft_qh *, struct ehci_soft_qtd *);
+void   ehci_add_qh(struct usbd_pipe *, struct ehci_soft_qh *,
+   struct ehci_soft_qtd *);
+void   ehci_rem_qh(struct ehci_softc *, struct usbd_pipe *);
 void   ehci_sync_hc(struct ehci_softc *);
 
 void   ehci_close_pipe(struct usbd_pipe *);
@@ -414,7 +413,6 @@ ehci_init(struct ehci_softc *sc)
sqh->qh.qh_qtd.qtd_next = htole32(EHCI_LINK_TERMINATE);
sqh->qh.qh_qtd.qtd_altnext = htole32(EHCI_LINK_TERMINATE);
sqh->qh.qh_qtd.qtd_status = htole32(EHCI_QTD_HALTED);
-   sqh->sqtd = NULL;
usb_syncmem(>dma, sqh->offs, sizeof(sqh->qh),
BUS_DMASYNC_PREWRITE | BUS_DMASYNC_PREREAD);
}
@@ -445,7 +443,6 @@ ehci_init(struct ehci_softc *sc)
sqh->qh.qh_qtd.qtd_next = htole32(EHCI_LINK_TERMINATE);
sqh->qh.qh_qtd.qtd_altnext = htole32(EHCI_LINK_TERMINATE);
sqh->qh.qh_qtd.qtd_status = htole32(EHCI_QTD_HALTED);
-   sqh->sqtd = NULL;
usb_syncmem(>dma, sqh->offs, sizeof(sqh->qh),
BUS_DMASYNC_PREWRITE | BUS_DMASYNC_PREREAD);
 
@@ -733,6 +730,7 @@ ehci_check_qh_intr(struct ehci_softc *sc
return;
}
  done:
+   ehci_rem_qh(sc, xfer->pipe);
TAILQ_REMOVE(>sc_intrhead, ex, inext);
timeout_del(>timeout_handle);
usb_rem_task(xfer->pipe->device, >abort_task);
@@ -865,7 +863,7 @@ ehci_idone(struct usbd_xfer *xfer)
 {
struct ehci_xfer *ex = (struct ehci_xfer *)xfer;
struct ehci_soft_qtd *sqtd;
-   u_int32_t status = 0, nstatus = 0;
+   uint32_t status = 0, nstatus = 0;
int actlen, cerr;
 
 #ifdef DIAGNOSTIC
@@ -1175,13 +1173,7 @@ ehci_freex(struct usbd_bus *bus, struct 
 void
 ehci_device_clear_toggle(struct usbd_pipe *pipe)
 {
-   struct ehci_pipe *epipe = (struct ehci_pipe *)pipe;
-
-#ifdef DIAGNOSTIC
-   if ((epipe->sqh->qh.qh_qtd.qtd_status & htole32(EHCI_QTD_ACTIVE)) != 0)
-   panic("ehci_device_clear_toggle: queue active");
-#endif
-   epipe->sqh->qh.qh_qtd.qtd_status &= htole32(~EHCI_QTD_TOGGLE_MASK);
+   pipe->endpoint->savedtoggle = 0;
 }
 
 #ifdef EHCI_DEBUG
@@ -1378,29 +1370,17 @@ ehci_open(struct usbd_pipe *pipe)
struct usbd_device *dev = pipe->device;
struct ehci_softc *sc = (struct ehci_softc *)dev->bus;
usb_endpoint_descriptor_t *ed = pipe->endpoint->edesc;
-   u_int8_t addr = dev->address;
u_int8_t xfertype = ed->bmAttributes & UE_XFERTYPE;
struct ehci_pipe *epipe = (struct ehci_pipe *)pipe;
struct ehci_soft_qh *sqh;
usbd_status err;
-   int s;
-   int ival, speed, naks;
-   int hshubaddr, hshubport;
 
-   DPRINTFN(1, ("ehci_open: pipe=%p, addr=%d, endpt=%d\n",
+   DPRINTFN(1, ("%s: pipe=%p, addr=%d, endpt=%d\n", __func__,
pipe, addr, ed->bEndpointAddress));
 
if (sc->sc_bus.dying)
return (USBD_IOERROR);
 
-   if (dev->myhsport) {
-   hshubaddr = dev->myhsport->parent->address;
-   hshubport = dev->myhsport->portno;
-   } else {
-   hshubaddr = 0;
-   hshubport = 0;
-   }
-
/* Root Hub */
if (pipe->device->depth == 0) {
switch (ed->bEndpointAddress) {
@@ -1416,59 +1396,11 @@ ehci_open(struct usbd_pipe *pipe)
return (USBD_NORMAL_COMPLETION);
}
 
-   /* XXX All this stuff is only valid for async. */
-   switch (dev->speed) {
-   case USB_SPEED_LOW:
-   speed = EHCI_QH_SPEED_LOW;
-   break;
-   case USB_SPEED_FULL:
-   speed = EHCI_QH_SPEED_FULL;
-   break;
-   case USB_SPEED_HIGH:
-   speed =

Re: uvm: remove unused(?) amap_extend

2016-03-27 Thread Mark Kettenis

> Date: Sat, 26 Mar 2016 23:02:52 +0100
> From: Martin Pieuchot 
> 
> On 26/03/16(Sat) 19:19, Stefan Kempf wrote:
> > Stefan Kempf wrote:
> > > amap_extend is called when merging two adjacent areas of virtual address
> > > space. However, merging is done only for kernel
> > > virtual address space. It's not done for user space:
> > > 
> > > uvm/uvm_map.c:1359
> > >   /*
> > >* Try to merge entry.
> > >*
> > >* Userland allocations are kept separated most of the time.
> > >* Forego the effort of merging what most of the time can't be merged
> > >* and only try the merge if it concerns a kernel entry.
> > >*/
> > >   if ((flags & UVM_FLAG_NOMERGE) == 0 &&
> > >   (map->flags & VM_MAP_ISVMSPACE) == 0)
> > >   uvm_mapent_tryjoin(map, entry, );
> > > 
> > > 
> > > As far as I can tell, kernel vm_map_entries do not use amaps. So
> > > amap_extend should never be called. Can we remove it?
> > 
> > Any objections against committing this diff?
> > 
> > Merging vm map entries for userspace was turned off a long time
> > ago in r1.104 of uvm/uvm_map.c.
> > 
> > The kernel doesn't use amaps either. Removing this would make the amap
> > shrink diffs simpler.
> 
> If it should never happen, what about putting a KASSERT() rather than
> returning NULL?

I think that would make sense.

> > > Index: uvm/uvm_amap.c
> > > ===
> > > RCS file: /cvs/src/sys/uvm/uvm_amap.c,v
> > > retrieving revision 1.62
> > > diff -u -p -r1.62 uvm_amap.c
> > > --- uvm/uvm_amap.c16 Mar 2016 16:53:43 -  1.62
> > > +++ uvm/uvm_amap.c23 Mar 2016 17:03:53 -
> > > @@ -279,174 +279,6 @@ amap_free(struct vm_amap *amap)
> > >  }
> > >  
> > >  /*
> > > - * amap_extend: extend the size of an amap (if needed)
> > > - *
> > > - * => called from uvm_map when we want to extend an amap to cover
> > > - *a new mapping (rather than allocate a new one)
> > > - * => to safely extend an amap it should have a reference count of
> > > - *one (thus it can't be shared)
> > > - * => XXXCDC: support padding at this level?
> > > - */
> > > -int
> > > -amap_extend(struct vm_map_entry *entry, vsize_t addsize)
> > > -{
> > > - struct vm_amap *amap = entry->aref.ar_amap;
> > > - int slotoff = entry->aref.ar_pageoff;
> > > - int slotmapped, slotadd, slotneed, slotalloc;
> > > -#ifdef UVM_AMAP_PPREF
> > > - int *newppref, *oldppref;
> > > -#endif
> > > - u_int *newsl, *newbck, *oldsl, *oldbck;
> > > - struct vm_anon **newover, **oldover;
> > > - int slotadded;
> > > -
> > > - /*
> > > -  * first, determine how many slots we need in the amap.  don't
> > > -  * forget that ar_pageoff could be non-zero: this means that
> > > -  * there are some unused slots before us in the amap.
> > > -  */
> > > - AMAP_B2SLOT(slotmapped, entry->end - entry->start); /* slots mapped */
> > > - AMAP_B2SLOT(slotadd, addsize);  /* slots to add */
> > > - slotneed = slotoff + slotmapped + slotadd;
> > > -
> > > - /*
> > > -  * case 1: we already have enough slots in the map and thus
> > > -  * only need to bump the reference counts on the slots we are
> > > -  * adding.
> > > -  */
> > > - if (amap->am_nslot >= slotneed) {
> > > -#ifdef UVM_AMAP_PPREF
> > > - if (amap->am_ppref && amap->am_ppref != PPREF_NONE) {
> > > - amap_pp_adjref(amap, slotoff + slotmapped, slotadd, 1);
> > > - }
> > > -#endif
> > > - return (0);
> > > - }
> > > -
> > > - /*
> > > -  * case 2: we pre-allocated slots for use and we just need to
> > > -  * bump nslot up to take account for these slots.
> > > -  */
> > > - if (amap->am_maxslot >= slotneed) {
> > > -#ifdef UVM_AMAP_PPREF
> > > - if (amap->am_ppref && amap->am_ppref != PPREF_NONE) {
> > > - if ((slotoff + slotmapped) < amap->am_nslot)
> > > - amap_pp_adjref(amap, slotoff + slotmapped, 
> > > - (amap->am_nslot - (slotoff + slotmapped)),
> > > - 1);
> > > - pp_setreflen(amap->am_ppref, amap->am_nslot, 1, 
> > > -slotneed - amap->am_nslot);
> > > - }
> > > -#endif
> > > - amap->am_nslot = slotneed;
> > > - /*
> > > -  * no need to zero am_anon since that was done at
> > > -  * alloc time and we never shrink an allocation.
> > > -  */
> > > - return (0);
> > > - }
> > > -
> > > - /*
> > > -  * case 3: we need to malloc a new amap and copy all the amap
> > > -  * data over from old amap to the new one.
> > > -  *
> > > -  * XXXCDC: could we take advantage of a kernel realloc()?  
> > > -  */
> > > - if (slotneed >= UVM_AMAP_LARGE)
> > > - return E2BIG;
> > > -
> > > - if (slotneed > UVM_AMAP_CHUNK)
> > > - slotalloc = malloc_roundup(slotneed * MALLOC_SLOT_UNIT) /
> > > - MALLOC_SLOT_UNIT;
> > > - else
> > > - slotalloc = slotneed;
> > >

Re: Double resched_proc() in setrunnable()

2016-03-27 Thread Martin Pieuchot

On 27/03/16(Sun) 14:42, Mark Kettenis wrote:
> > Date: Sun, 27 Mar 2016 12:00:04 +0200
> > From: Martin Pieuchot 
> > 
> > Diff below moves resetpriority() out of updatepri() and resched_proc()
> > out of resetpriority() in order to expose a double resched_proc() call
> > in setrunnable().
> >
> > This happens when a thread has slept for more than 1 second.  Since
> > p_usrpri is equal or bigger than p_priority, if the first call
> > triggers a need_resched() then the second will also do so.
> 
> Is this a big issue?  It might cause an additional IPI, but how often
> does this really happen?

No it's not a big issue but it doesn't hurt to remove a useless case
and make this code simpler.

> > I'd like to commit this diff which does not introduce any behavior
> > change then remove the first resched_proc() in setrunnable().
> 
> I think that would be wrong.  Even if the process didn't sleep for
> more than a second, it might have a higher priority than the process
> that is currently running on the CPU.

If the process didn't sleep for more than a second the first
resched_proc() won't be called, so there's not change here.

Sure it might have a higher priority but that doesn't contradict what
I'm doing here.  Does that mean you are ok?

> > Index: kern/sched_bsd.c
> > ===
> > RCS file: /cvs/src/sys/kern/sched_bsd.c,v
> > retrieving revision 1.43
> > diff -u -p -r1.43 sched_bsd.c
> > --- kern/sched_bsd.c9 Mar 2016 13:38:50 -   1.43
> > +++ kern/sched_bsd.c24 Mar 2016 11:37:34 -
> > @@ -246,6 +246,7 @@ schedcpu(void *arg)
> > newcpu = (u_int) decay_cpu(loadfac, p->p_estcpu);
> > p->p_estcpu = newcpu;
> > resetpriority(p);
> > +   resched_proc(p, p->p_usrpri);
> > if (p->p_priority >= PUSER) {
> > if (p->p_stat == SRUN &&
> > (p->p_priority / SCHED_PPQ) !=
> > @@ -284,7 +285,6 @@ updatepri(struct proc *p)
> > newcpu = (int) decay_cpu(loadfac, newcpu);
> > p->p_estcpu = newcpu;
> > }
> > -   resetpriority(p);
> >  }
> >  
> >  /*
> > @@ -454,7 +454,7 @@ mi_switch(void)
> >  #endif
> >  }
> >  
> > -static __inline void
> > +void
> >  resched_proc(struct proc *p, u_char pri)
> >  {
> > struct cpu_info *ci;
> > @@ -509,8 +509,11 @@ setrunnable(struct proc *p)
> > p->p_stat = SRUN;
> > p->p_cpu = sched_choosecpu(p);
> > setrunqueue(p);
> > -   if (p->p_slptime > 1)
> > +   if (p->p_slptime > 1) {
> > updatepri(p);
> > +   resetpriority(p);
> > +   resched_proc(p, p->p_usrpri);
> > +   }
> > p->p_slptime = 0;
> > resched_proc(p, p->p_priority);
> >  }
> > @@ -531,7 +534,6 @@ resetpriority(struct proc *p)
> > NICE_WEIGHT * (p->p_p->ps_nice - NZERO);
> > newpriority = min(newpriority, MAXPRI);
> > p->p_usrpri = newpriority;
> > -   resched_proc(p, p->p_usrpri);
> >  }
> >  
> >  /*
> > @@ -556,6 +558,7 @@ schedclock(struct proc *p)
> > SCHED_LOCK(s);
> > p->p_estcpu = ESTCPULIM(p->p_estcpu + 1);
> > resetpriority(p);
> > +   resched_proc(p, p->p_usrpri);
> > if (p->p_priority >= PUSER)
> > p->p_priority = p->p_usrpri;
> > SCHED_UNLOCK(s);
> > Index: kern/kern_resource.c
> > ===
> > RCS file: /cvs/src/sys/kern/kern_resource.c,v
> > retrieving revision 1.55
> > diff -u -p -r1.55 kern_resource.c
> > --- kern/kern_resource.c5 Dec 2015 10:11:53 -   1.55
> > +++ kern/kern_resource.c24 Mar 2016 11:30:32 -
> > @@ -194,8 +194,10 @@ donice(struct proc *curp, struct process
> > return (EACCES);
> > chgpr->ps_nice = n;
> > SCHED_LOCK(s);
> > -   TAILQ_FOREACH(p, >ps_threads, p_thr_link)
> > -   (void)resetpriority(p);
> > +   TAILQ_FOREACH(p, >ps_threads, p_thr_link) {
> > +   resetpriority(p);
> > +   resched_proc(p, p->p_usrpri);
> > +   }
> > SCHED_UNLOCK(s);
> > return (0);
> >  }
> > Index: sys/sched.h
> > ===
> > RCS file: /cvs/src/sys/sys/sched.h,v
> > retrieving revision 1.41
> > diff -u -p -r1.41 sched.h
> > --- sys/sched.h 17 Mar 2016 13:18:47 -  1.41
> > +++ sys/sched.h 24 Mar 2016 11:35:38 -
> > @@ -166,6 +166,7 @@ void sched_stop_secondary_cpus(void);
> >  #define cpu_is_idle(ci)((ci)->ci_schedstate.spc_whichqs == 0)
> >  
> >  void sched_init_runqueues(void);
> > +void resched_proc(struct proc *p, u_char);
> >  void setrunqueue(struct proc *);
> >  void remrunqueue(struct proc *);
> >  
> > 
> > 
>

Re: Double resched_proc() in setrunnable()

2016-03-27 Thread Mark Kettenis

> Date: Sun, 27 Mar 2016 12:00:04 +0200
> From: Martin Pieuchot 
> 
> Diff below moves resetpriority() out of updatepri() and resched_proc()
> out of resetpriority() in order to expose a double resched_proc() call
> in setrunnable().
>
> This happens when a thread has slept for more than 1 second.  Since
> p_usrpri is equal or bigger than p_priority, if the first call
> triggers a need_resched() then the second will also do so.

Is this a big issue?  It might cause an additional IPI, but how often
does this really happen?

> I'd like to commit this diff which does not introduce any behavior
> change then remove the first resched_proc() in setrunnable().

I think that would be wrong.  Even if the process didn't sleep for
more than a second, it might have a higher priority than the process
that is currently running on the CPU.

> ok?
> 
> Index: kern/sched_bsd.c
> ===
> RCS file: /cvs/src/sys/kern/sched_bsd.c,v
> retrieving revision 1.43
> diff -u -p -r1.43 sched_bsd.c
> --- kern/sched_bsd.c  9 Mar 2016 13:38:50 -   1.43
> +++ kern/sched_bsd.c  24 Mar 2016 11:37:34 -
> @@ -246,6 +246,7 @@ schedcpu(void *arg)
>   newcpu = (u_int) decay_cpu(loadfac, p->p_estcpu);
>   p->p_estcpu = newcpu;
>   resetpriority(p);
> + resched_proc(p, p->p_usrpri);
>   if (p->p_priority >= PUSER) {
>   if (p->p_stat == SRUN &&
>   (p->p_priority / SCHED_PPQ) !=
> @@ -284,7 +285,6 @@ updatepri(struct proc *p)
>   newcpu = (int) decay_cpu(loadfac, newcpu);
>   p->p_estcpu = newcpu;
>   }
> - resetpriority(p);
>  }
>  
>  /*
> @@ -454,7 +454,7 @@ mi_switch(void)
>  #endif
>  }
>  
> -static __inline void
> +void
>  resched_proc(struct proc *p, u_char pri)
>  {
>   struct cpu_info *ci;
> @@ -509,8 +509,11 @@ setrunnable(struct proc *p)
>   p->p_stat = SRUN;
>   p->p_cpu = sched_choosecpu(p);
>   setrunqueue(p);
> - if (p->p_slptime > 1)
> + if (p->p_slptime > 1) {
>   updatepri(p);
> + resetpriority(p);
> + resched_proc(p, p->p_usrpri);
> + }
>   p->p_slptime = 0;
>   resched_proc(p, p->p_priority);
>  }
> @@ -531,7 +534,6 @@ resetpriority(struct proc *p)
>   NICE_WEIGHT * (p->p_p->ps_nice - NZERO);
>   newpriority = min(newpriority, MAXPRI);
>   p->p_usrpri = newpriority;
> - resched_proc(p, p->p_usrpri);
>  }
>  
>  /*
> @@ -556,6 +558,7 @@ schedclock(struct proc *p)
>   SCHED_LOCK(s);
>   p->p_estcpu = ESTCPULIM(p->p_estcpu + 1);
>   resetpriority(p);
> + resched_proc(p, p->p_usrpri);
>   if (p->p_priority >= PUSER)
>   p->p_priority = p->p_usrpri;
>   SCHED_UNLOCK(s);
> Index: kern/kern_resource.c
> ===
> RCS file: /cvs/src/sys/kern/kern_resource.c,v
> retrieving revision 1.55
> diff -u -p -r1.55 kern_resource.c
> --- kern/kern_resource.c  5 Dec 2015 10:11:53 -   1.55
> +++ kern/kern_resource.c  24 Mar 2016 11:30:32 -
> @@ -194,8 +194,10 @@ donice(struct proc *curp, struct process
>   return (EACCES);
>   chgpr->ps_nice = n;
>   SCHED_LOCK(s);
> - TAILQ_FOREACH(p, >ps_threads, p_thr_link)
> - (void)resetpriority(p);
> + TAILQ_FOREACH(p, >ps_threads, p_thr_link) {
> + resetpriority(p);
> + resched_proc(p, p->p_usrpri);
> + }
>   SCHED_UNLOCK(s);
>   return (0);
>  }
> Index: sys/sched.h
> ===
> RCS file: /cvs/src/sys/sys/sched.h,v
> retrieving revision 1.41
> diff -u -p -r1.41 sched.h
> --- sys/sched.h   17 Mar 2016 13:18:47 -  1.41
> +++ sys/sched.h   24 Mar 2016 11:35:38 -
> @@ -166,6 +166,7 @@ void sched_stop_secondary_cpus(void);
>  #define cpu_is_idle(ci)  ((ci)->ci_schedstate.spc_whichqs == 0)
>  
>  void sched_init_runqueues(void);
> +void resched_proc(struct proc *p, u_char);
>  void setrunqueue(struct proc *);
>  void remrunqueue(struct proc *);
>  
> 
>

Re: Scheduler hack for multi-threaded processes

2016-03-27 Thread Mark Kettenis

> From: attila 
> Date: Sat, 26 Mar 2016 17:47:38 -0600
> 
> Jyri Hovila [Turvamies.fi]  writes:
> 
> > I can report significant usability improvement on a single core
> > ThinkPad T42 and a dual core ThinkPad X60.
> 
> I hate to crap on this wonderful parade, but on my T60 (i386, dmesg at
> bottom) running 25 march snap the heat has bumped a full 10DegC from
> what was "normal" before.  I'm sorry for the lack of science here and
> I have no hard numbers w/wo patch yet but in the past my steady state
> on this machine w/o firefox was something like 70DegC, w/just some
> xterms and emacs (aka life).  Starting firefox generally added 10DegC
> before I did anything at all and I always had to watch the heat and
> kill firefox when we crossed 95DegC or Bad Things Happened; thus I
> live with w3m in one hand and treat firefox as some kind of
> luxury... tor-browser was, strangely, less hard on things but maybe
> that's just because I never have too many tabs there (also, maybe
> firefox-esr is a little lighter, not sure).
> 
> Now it will be a challenge to see if I can cvs up, back out the patch
> and build a kernel without ringing the bell (100DegC).  I freely admit
> this is an old, P.O.S. laptop and that there might be some HW issue
> (fan seems fine but I haven't taken it apart and really looked).  It
> does seem like the difference in the scheduler has a remarkable effect
> on heat in my case.

If you're not running any multi-threaded code the diff should have
zero impact.  And I expect the diff to actually decrease the CPU load
when running such code, and therefore lower the temperature.  This is
most likely a hardware issue, i.e. dust or a failing fan.

uvm: enable amap per-page refcounting unconditionally

2016-03-27 Thread Stefan Kempf

It seems per-page reference counting is used since forever. I think
there's no reason to ever turn it off (and track referenced pages
with less accuracy, causing leaks).

So remove those #ifdefs.

ok?

Index: uvm/uvm_amap.c
===
RCS file: /cvs/src/sys/uvm/uvm_amap.c,v
retrieving revision 1.63
diff -u -p -r1.63 uvm_amap.c
--- uvm/uvm_amap.c  27 Mar 2016 09:51:37 -  1.63
+++ uvm/uvm_amap.c  27 Mar 2016 12:09:16 -
@@ -81,11 +81,9 @@ amap_list_remove(struct vm_amap *amap)
LIST_REMOVE(amap, am_list);
 }
 
-#ifdef UVM_AMAP_PPREF
 /*
- * what is ppref?   ppref is an _optional_ amap feature which is used
- * to keep track of reference counts on a per-page basis.  it is enabled
- * when UVM_AMAP_PPREF is defined.
+ * what is ppref?   ppref is an amap feature which is used
+ * to keep track of reference counts on a per-page basis.
  *
  * when enabled, an array of ints is allocated for the pprefs.  this
  * array is allocated only when a partial reference is added to the
@@ -147,7 +145,6 @@ pp_setreflen(int *ppref, int offset, int
ppref[offset+1] = len;
}
 }
-#endif
 
 /*
  * amap_init: called at boot time to init global amap data structures
@@ -196,9 +193,7 @@ amap_alloc1(int slots, int padslots, int
 
amap->am_ref = 1;
amap->am_flags = 0;
-#ifdef UVM_AMAP_PPREF
amap->am_ppref = NULL;
-#endif
amap->am_maxslot = totalslots;
amap->am_nslot = slots;
amap->am_nused = 0;
@@ -270,10 +265,8 @@ amap_free(struct vm_amap *amap)
pool_put(_amap_slot_pools[amap->am_maxslot - 1],
amap->am_slots);
 
-#ifdef UVM_AMAP_PPREF
if (amap->am_ppref && amap->am_ppref != PPREF_NONE)
free(amap->am_ppref, M_UVMAMAP, 0);
-#endif
pool_put(_amap_pool, amap);
 
 }
@@ -422,12 +415,10 @@ amap_copy(struct vm_map *map, struct vm_
srcamap->am_ref--;
if (srcamap->am_ref == 1 && (srcamap->am_flags & AMAP_SHARED) != 0)
srcamap->am_flags &= ~AMAP_SHARED;   /* clear shared flag */
-#ifdef UVM_AMAP_PPREF
if (srcamap->am_ppref && srcamap->am_ppref != PPREF_NONE) {
amap_pp_adjref(srcamap, entry->aref.ar_pageoff, 
(entry->end - entry->start) >> PAGE_SHIFT, -1);
}
-#endif
 
/* install new amap. */
entry->aref.ar_pageoff = 0;
@@ -551,19 +542,15 @@ amap_splitref(struct vm_aref *origref, s
if (origref->ar_amap->am_nslot - origref->ar_pageoff - leftslots <= 0)
panic("amap_splitref: map size check failed");
 
-#ifdef UVM_AMAP_PPREF
 /* establish ppref before we add a duplicate reference to the amap */
if (origref->ar_amap->am_ppref == NULL)
amap_pp_establish(origref->ar_amap);
-#endif
 
splitref->ar_amap = origref->ar_amap;
splitref->ar_amap->am_ref++;/* not a share reference */
splitref->ar_pageoff = origref->ar_pageoff + leftslots;
 }
 
-#ifdef UVM_AMAP_PPREF
-
 /*
  * amap_pp_establish: add a ppref array to an amap, if possible
  */
@@ -719,8 +706,6 @@ amap_wiperange(struct vm_amap *amap, int
}
 }
 
-#endif
-
 /*
  * amap_swap_off: pagein anonymous pages in amaps and drop swap slots.
  *
@@ -911,7 +896,6 @@ amap_ref(struct vm_amap *amap, vaddr_t o
amap->am_ref++;
if (flags & AMAP_SHARED)
amap->am_flags |= AMAP_SHARED;
-#ifdef UVM_AMAP_PPREF
if (amap->am_ppref == NULL && (flags & AMAP_REFALL) == 0 &&
len != amap->am_nslot)
amap_pp_establish(amap);
@@ -921,7 +905,6 @@ amap_ref(struct vm_amap *amap, vaddr_t o
else
amap_pp_adjref(amap, offset, len, 1);
}
-#endif
 }
 
 /*
@@ -945,7 +928,6 @@ amap_unref(struct vm_amap *amap, vaddr_t
/* otherwise just drop the reference count(s) */
if (amap->am_ref == 1 && (amap->am_flags & AMAP_SHARED) != 0)
amap->am_flags &= ~AMAP_SHARED; /* clear shared flag */
-#ifdef UVM_AMAP_PPREF
if (amap->am_ppref == NULL && all == 0 && len != amap->am_nslot)
amap_pp_establish(amap);
if (amap->am_ppref && amap->am_ppref != PPREF_NONE) {
@@ -954,5 +936,4 @@ amap_unref(struct vm_amap *amap, vaddr_t
else
amap_pp_adjref(amap, offset, len, -1);
}
-#endif
 }
Index: uvm/uvm_amap.h
===
RCS file: /cvs/src/sys/uvm/uvm_amap.h,v
retrieving revision 1.22
diff -u -p -r1.22 uvm_amap.h
--- uvm/uvm_amap.h  27 Mar 2016 09:51:37 -  1.22
+++ uvm/uvm_amap.h  27 Mar 2016 12:09:16 -
@@ -114,13 +114,10 @@ boolean_t amap_swap_off(int, int);
 
 /*
  * we currently provide an array-based amap implementation.  in this
- * implementation we provide the option of tracking split references
- * so that we don't lose track of references during

Re: ART regression, multicast

2016-03-27 Thread Martin Pieuchot

On 26/03/16(Sat) 23:25, Stuart Henderson wrote:
> On 2016/03/26 23:21, Stuart Henderson wrote:
> >   Sorry I don't have a simple test method,
> 
> oh, there are some example programs in p5-IO-Socket-Multicast (in
> /usr/local/share/examples/p5-IO-Socket-Multicast), can't reboot
> again right now to test that they fail with ART, but they work ok
> without ART and it looks like they might be an easier way..just
> run server.pl on one box, client.pl on another.

Thanks for the report unfortunately I don't understand the problem.

p5-IO-Socket-Multicast server & client work just fine here with ART,
w/ and w/o default route for multicast addresses.

avahi-based services also work fine here (group is 224.0.0.251).

Double resched_proc() in setrunnable()

2016-03-27 Thread Martin Pieuchot

Diff below moves resetpriority() out of updatepri() and resched_proc()
out of resetpriority() in order to expose a double resched_proc() call
in setrunnable().

This happens when a thread has slept for more than 1 second.  Since
p_usrpri is equal or bigger than p_priority, if the first call
triggers a need_resched() then the second will also do so.

I'd like to commit this diff which does not introduce any behavior
change then remove the first resched_proc() in setrunnable().

ok?

Index: kern/sched_bsd.c
===
RCS file: /cvs/src/sys/kern/sched_bsd.c,v
retrieving revision 1.43
diff -u -p -r1.43 sched_bsd.c
--- kern/sched_bsd.c9 Mar 2016 13:38:50 -   1.43
+++ kern/sched_bsd.c24 Mar 2016 11:37:34 -
@@ -246,6 +246,7 @@ schedcpu(void *arg)
newcpu = (u_int) decay_cpu(loadfac, p->p_estcpu);
p->p_estcpu = newcpu;
resetpriority(p);
+   resched_proc(p, p->p_usrpri);
if (p->p_priority >= PUSER) {
if (p->p_stat == SRUN &&
(p->p_priority / SCHED_PPQ) !=
@@ -284,7 +285,6 @@ updatepri(struct proc *p)
newcpu = (int) decay_cpu(loadfac, newcpu);
p->p_estcpu = newcpu;
}
-   resetpriority(p);
 }
 
 /*
@@ -454,7 +454,7 @@ mi_switch(void)
 #endif
 }
 
-static __inline void
+void
 resched_proc(struct proc *p, u_char pri)
 {
struct cpu_info *ci;
@@ -509,8 +509,11 @@ setrunnable(struct proc *p)
p->p_stat = SRUN;
p->p_cpu = sched_choosecpu(p);
setrunqueue(p);
-   if (p->p_slptime > 1)
+   if (p->p_slptime > 1) {
updatepri(p);
+   resetpriority(p);
+   resched_proc(p, p->p_usrpri);
+   }
p->p_slptime = 0;
resched_proc(p, p->p_priority);
 }
@@ -531,7 +534,6 @@ resetpriority(struct proc *p)
NICE_WEIGHT * (p->p_p->ps_nice - NZERO);
newpriority = min(newpriority, MAXPRI);
p->p_usrpri = newpriority;
-   resched_proc(p, p->p_usrpri);
 }
 
 /*
@@ -556,6 +558,7 @@ schedclock(struct proc *p)
SCHED_LOCK(s);
p->p_estcpu = ESTCPULIM(p->p_estcpu + 1);
resetpriority(p);
+   resched_proc(p, p->p_usrpri);
if (p->p_priority >= PUSER)
p->p_priority = p->p_usrpri;
SCHED_UNLOCK(s);
Index: kern/kern_resource.c
===
RCS file: /cvs/src/sys/kern/kern_resource.c,v
retrieving revision 1.55
diff -u -p -r1.55 kern_resource.c
--- kern/kern_resource.c5 Dec 2015 10:11:53 -   1.55
+++ kern/kern_resource.c24 Mar 2016 11:30:32 -
@@ -194,8 +194,10 @@ donice(struct proc *curp, struct process
return (EACCES);
chgpr->ps_nice = n;
SCHED_LOCK(s);
-   TAILQ_FOREACH(p, >ps_threads, p_thr_link)
-   (void)resetpriority(p);
+   TAILQ_FOREACH(p, >ps_threads, p_thr_link) {
+   resetpriority(p);
+   resched_proc(p, p->p_usrpri);
+   }
SCHED_UNLOCK(s);
return (0);
 }
Index: sys/sched.h
===
RCS file: /cvs/src/sys/sys/sched.h,v
retrieving revision 1.41
diff -u -p -r1.41 sched.h
--- sys/sched.h 17 Mar 2016 13:18:47 -  1.41
+++ sys/sched.h 24 Mar 2016 11:35:38 -
@@ -166,6 +166,7 @@ void sched_stop_secondary_cpus(void);
 #define cpu_is_idle(ci)((ci)->ci_schedstate.spc_whichqs == 0)
 
 void sched_init_runqueues(void);
+void resched_proc(struct proc *p, u_char);
 void setrunqueue(struct proc *);
 void remrunqueue(struct proc *);

Re: Scheduler hack for multi-threaded processes

2016-03-27 Thread Vadim Zhukov

27 марта 2016 г. 11:05 пользователь "Stefan Sperling" 
написал:
>
> On Sat, Mar 26, 2016 at 05:47:38PM -0600, attila wrote:
> > Now it will be a challenge to see if I can cvs up, back out the patch
> > and build a kernel without ringing the bell (100DegC).  I freely admit
> > this is an old, P.O.S. laptop and that there might be some HW issue
>
> Did you check for dust in the fan vent?
>
> I've had to treat my x60 with a hoover more than once after it had fallen
> ill with a temperature...

That's dangerous: you at least need fan cables from motherboard, to avoid
it generating electricity when spinning. I know two cases of killed this
way motherboards (not ThinkPad, but still).

--
WBR,
  Vadim Zhukov

Re: Scheduler hack for multi-threaded processes

2016-03-27 Thread Matthieu Herrb

On Sat, Mar 26, 2016 at 05:47:38PM -0600, attila wrote:
> 
> Now it will be a challenge to see if I can cvs up, back out the patch
> and build a kernel without ringing the bell (100DegC).

boot obsd ?

-- 
Matthieu Herrb


signature.asc
Description: PGP signature

Re: Scheduler hack for multi-threaded processes

2016-03-27 Thread Stefan Sperling

On Sat, Mar 26, 2016 at 05:47:38PM -0600, attila wrote:
> Now it will be a challenge to see if I can cvs up, back out the patch
> and build a kernel without ringing the bell (100DegC).  I freely admit
> this is an old, P.O.S. laptop and that there might be some HW issue

Did you check for dust in the fan vent?

I've had to treat my x60 with a hoover more than once after it had fallen
ill with a temperature...

Re: uvm: remove unused(?) amap_extend

2016-03-27 Thread Stefan Kempf

Martin Pieuchot wrote:
> On 26/03/16(Sat) 19:19, Stefan Kempf wrote:
> > Stefan Kempf wrote:
> > > amap_extend is called when merging two adjacent areas of virtual address
> > > space. However, merging is done only for kernel
> > > virtual address space. It's not done for user space:
> > > 
> > > uvm/uvm_map.c:1359
> > >   /*
> > >* Try to merge entry.
> > >*
> > >* Userland allocations are kept separated most of the time.
> > >* Forego the effort of merging what most of the time can't be merged
> > >* and only try the merge if it concerns a kernel entry.
> > >*/
> > >   if ((flags & UVM_FLAG_NOMERGE) == 0 &&
> > >   (map->flags & VM_MAP_ISVMSPACE) == 0)
> > >   uvm_mapent_tryjoin(map, entry, );
> > > 
> > > 
> > > As far as I can tell, kernel vm_map_entries do not use amaps. So
> > > amap_extend should never be called. Can we remove it?
> > 
> > Any objections against committing this diff?
> > 
> > Merging vm map entries for userspace was turned off a long time
> > ago in r1.104 of uvm/uvm_map.c.
> > 
> > The kernel doesn't use amaps either. Removing this would make the amap
> > shrink diffs simpler.
> 
> If it should never happen, what about putting a KASSERT() rather than
> returning NULL?

Good idea, IMO.

Index: uvm/uvm_map.c
===
RCS file: /cvs/src/sys/uvm/uvm_map.c,v
retrieving revision 1.209
diff -u -p -r1.209 uvm_map.c
--- uvm/uvm_map.c   15 Mar 2016 20:50:23 -  1.209
+++ uvm/uvm_map.c   27 Mar 2016 06:56:32 -
@@ -1448,14 +1448,14 @@ uvm_mapent_merge(struct vm_map *map, str
struct uvm_addr_state *free;
 
/*
-* Amap of e1 must be extended to include e2.
+* Merging is not supported for map entries that
+* contain an amap in e1. This should never happen
+* anyway, because only kernel entries are merged.
+* These do not contain amaps.
 * e2 contains no real information in its amap,
 * so it can be erased immediately.
 */
-   if (e1->aref.ar_amap) {
-   if (amap_extend(e1, e2->end - e2->start))
-   return NULL;
-   }
+   KASSERT(e1->aref.ar_amap == NULL);
 
/*
 * Don't drop obj reference:
 
> > > Index: uvm/uvm_amap.c
> > > ===
> > > RCS file: /cvs/src/sys/uvm/uvm_amap.c,v
> > > retrieving revision 1.62
> > > diff -u -p -r1.62 uvm_amap.c
> > > --- uvm/uvm_amap.c16 Mar 2016 16:53:43 -  1.62
> > > +++ uvm/uvm_amap.c23 Mar 2016 17:03:53 -
> > > @@ -279,174 +279,6 @@ amap_free(struct vm_amap *amap)
> > >  }
> > >  
> > >  /*
> > > - * amap_extend: extend the size of an amap (if needed)
> > > - *
> > > - * => called from uvm_map when we want to extend an amap to cover
> > > - *a new mapping (rather than allocate a new one)
> > > - * => to safely extend an amap it should have a reference count of
> > > - *one (thus it can't be shared)
> > > - * => XXXCDC: support padding at this level?
> > > - */
> > > -int
> > > -amap_extend(struct vm_map_entry *entry, vsize_t addsize)
> > > -{
> > > - struct vm_amap *amap = entry->aref.ar_amap;
> > > - int slotoff = entry->aref.ar_pageoff;
> > > - int slotmapped, slotadd, slotneed, slotalloc;
> > > -#ifdef UVM_AMAP_PPREF
> > > - int *newppref, *oldppref;
> > > -#endif
> > > - u_int *newsl, *newbck, *oldsl, *oldbck;
> > > - struct vm_anon **newover, **oldover;
> > > - int slotadded;
> > > -
> > > - /*
> > > -  * first, determine how many slots we need in the amap.  don't
> > > -  * forget that ar_pageoff could be non-zero: this means that
> > > -  * there are some unused slots before us in the amap.
> > > -  */
> > > - AMAP_B2SLOT(slotmapped, entry->end - entry->start); /* slots mapped */
> > > - AMAP_B2SLOT(slotadd, addsize);  /* slots to add */
> > > - slotneed = slotoff + slotmapped + slotadd;
> > > -
> > > - /*
> > > -  * case 1: we already have enough slots in the map and thus
> > > -  * only need to bump the reference counts on the slots we are
> > > -  * adding.
> > > -  */
> > > - if (amap->am_nslot >= slotneed) {
> > > -#ifdef UVM_AMAP_PPREF
> > > - if (amap->am_ppref && amap->am_ppref != PPREF_NONE) {
> > > - amap_pp_adjref(amap, slotoff + slotmapped, slotadd, 1);
> > > - }
> > > -#endif
> > > - return (0);
> > > - }
> > > -
> > > - /*
> > > -  * case 2: we pre-allocated slots for use and we just need to
> > > -  * bump nslot up to take account for these slots.
> > > -  */
> > > - if (amap->am_maxslot >= slotneed) {
> > > -#ifdef UVM_AMAP_PPREF
> > > - if (amap->am_ppref && amap->am_ppref != PPREF_NONE) {
> > > - if ((slotoff + slotmapped) < amap->am_nslot)
> > > - amap_pp_adjref(amap, slotoff + slotmapped, 
> > > - (amap->am_nslot - (slotoff + slotmapped)),
> > > -

Re: acpi gpio support

Aq macro replacements

Re: wsdisplay_compat_usl/KDENABIO: no need to specisal case i386

gdb on landisk

Re: uvm: enable amap per-page refcounting unconditionally

Re: Scheduler hack for multi-threaded processes

wsdisplay_compat_usl/KDENABIO: no need to specisal case i386

Re: Possible kernel function with stack frame > 2048 bytes

Re: mpsafe aesni

Possible kernel function with stack frame > 2048 bytes

xhci wedges on Supermicro X11SSL-F (Intel C232)

acpi gpio support

Re: ffs_read() tweak

Re: multitouch support again

[Patch/bgpd] Remove unused argument from community_ext_*

Re: /etc/netstart: route delete 224.0.0.0/4

Re: /etc/netstart: route delete 224.0.0.0/4

/etc/netstart: route delete 224.0.0.0/4

Re: ART regression, multicast

Re: Scheduler hack for multi-threaded processes

ehci_device_clear_toggle

Re: uvm: remove unused(?) amap_extend

Re: Double resched_proc() in setrunnable()

Re: Double resched_proc() in setrunnable()

Re: Scheduler hack for multi-threaded processes

uvm: enable amap per-page refcounting unconditionally

Re: ART regression, multicast

Double resched_proc() in setrunnable()

Re: Scheduler hack for multi-threaded processes

Re: Scheduler hack for multi-threaded processes

Re: Scheduler hack for multi-threaded processes

Re: uvm: remove unused(?) amap_extend

32 matches

Site Navigation

Mail list logo

Footer information