Re: arm: don't unnecessarily call pmap_extract()

2016-01-30 Thread Patrick Wildt
On Tue, Jan 26, 2016 at 07:32:40PM +1100, Jonathan Gray wrote:
> On Sun, Jan 24, 2016 at 01:02:49AM +0100, Patrick Wildt wrote:
> > Hi,
> > 
> > there are two code points in the v7 pmap where we need the physical
> > address (to flush secondary cache) and use pmap_extract() instead
> > of just reading it from the vm page.  This diff removes those.
> > 
> > Patrick
> 
> When running with this diff on a imx6 cubox two out of three times xenocara
> builds have failed with sh dumping core due to bus errors.  Once in
> Mesa, and once in libXmu.  I don't remember that happening before,
> but I'll try and so some more builds on it without the diff.

Did you encounter any more issues running that diff?  Have you tried
compiling xenocara without after seeing those issues?

So far I have only run into unrelated build issues, like a missing
define or a python script being started without it having executable
permissions.

> 
> > 
> > diff --git sys/arch/arm/arm/pmap7.c sys/arch/arm/arm/pmap7.c
> > index 5bcc67b..78969bd 100644
> > --- sys/arch/arm/arm/pmap7.c
> > +++ sys/arch/arm/arm/pmap7.c
> > @@ -1105,11 +1105,9 @@ pmap_clean_page(struct vm_page *pg, int isync)
> >  * now while we still have a valid mapping for it.
> >  */
> > if (!wb) {
> > -   paddr_t pa;
> > cpu_dcache_wb_range(pv->pv_va, PAGE_SIZE);
> > -   if (pmap_extract(pm, (vaddr_t)pv->pv_va, ))
> > -   cpu_sdcache_wb_range(pv->pv_va, pa,
> > -   PAGE_SIZE);
> > +   cpu_sdcache_wb_range(pv->pv_va,
> > +   VM_PAGE_TO_PHYS(pg), PAGE_SIZE);
> > wb = TRUE;
> > }
> > }
> > @@ -1126,10 +1124,8 @@ pmap_clean_page(struct vm_page *pg, int isync)
> > PTE_SYNC(cwb_pte);
> > cpu_tlb_flushD_SE(cwbp);
> > cpu_cpwait();
> > -   paddr_t pa;
> > cpu_dcache_wb_range(cwbp, PAGE_SIZE);
> > -   if (pmap_extract(pmap_kernel(), (vaddr_t)cwbp, ))
> > -   cpu_sdcache_wb_range(cwbp, pa, PAGE_SIZE);
> > +   cpu_sdcache_wb_range(cwbp, VM_PAGE_TO_PHYS(pg), PAGE_SIZE);
> > }
> >  }
> >  
> > 



Panic with the latest snapshot

2016-01-30 Thread Liviu Daia
APU1.C router running the latest snapshot, Atheros AR9281 configured
as an AP.  The kernel panics shortly after connecting a wifi client.

Regards,

Liviu Daia


panic: kernel diagnostic assertion "pd.m->m_pkthdr.pf.statekey ==
NULL" failed: file "../../../../net/pf.c", line 6569
Starting stack trace...
panic() at panic+0x10b
__assert() at __assert+0x25
pf_test() at pf_test+0xe26
ipv4_input() at ipv4_input+0x240
ipintr() at ipintr+0x1e
netintr() at netintr+0x64
softintr_dispatch() at softintr_dispatch+0x8b
Xsoftnet() at Xsoftnet+0x1f
--- interrupt ---
end trace frame: 0x0, count: 249
taskq_thread+0x6c:
End of stack trace.
syncing disks... 106 106 8 done
panic: sleep: softnet failed insomnia
Starting stack trace...
panic() at panic+0x10b
sleep_setup() at sleep_setup+0xff
sched_barrier() at sched_barrier+0x9a
re_stop() at re_stop+0xe1
re_ioctl() at re_ioctl+0x169
if_downall() at if_downall+0x8a
boot() at boot+0xe4
reboot() at reboot+0x26
panic() at panic+0x106
__assert() at __assert+0x25
pf_test() at pf_test+0xe26
ipv4_input() at ipv4_input+0x240
ipintr() at ipintr+0x1e
netintr() at netintr+0x64
softintr_dispatch() at softintr_dispatch+0x8b
Xsoftnet() at Xsoftnet+0x1f
--- interrupt ---
end trace frame: 0x0, count: 241
taskq_thread+0x6c:
End of stack trace.
panic: sleep: softnet failed insomnia
Starting stack trace...
panic() at panic+0x10b
sleep_setup() at sleep_setup+0xff
sched_barrier() at sched_barrier+0x9a
re_stop() at re_stop+0xe1
re_ioctl() at re_ioctl+0x169
if_downall() at if_downall+0x8a
boot() at boot+0xe4
reboot() at reboot+0x26
panic() at panic+0x106
sleep_setup() at sleep_setup+0xff
sched_barrier() at sched_barrier+0x9a
re_stop() at re_stop+0xe1
re_ioctl() at re_ioctl+0x169
if_downall() at if_downall+0x8a
boot() at boot+0xe4
reboot() at reboot+0x26
panic() at panic+0x106
__assert() at __assert+0x25
pf_test() at pf_test+0xe26
ipv4_input() at ipv4_input+0x240
ipintr() at ipintr+0x1e
netintr() at netintr+0x64
softintr_dispatch() at softintr_dispatch+0x8b
Xsoftnet() at Xsoftnet+0x1f
--- interrupt ---
end trace frame: 0x0, count: 233
taskq_thread+0x6c:
End of stack trace.


OpenBSD 5.9-beta (GENERIC.MP) #1866: Fri Jan 29 19:22:49 MST 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2098520064 (2001MB)
avail mem = 2030780416 (1936MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7e16d820 (7 entries)
bios0: vendor coreboot version "4.0" date 09/08/2014
bios0: PC Engines APU
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT
acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) 
PE20(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3) UOH2(S3) UOH3(S3) 
UOH4(S3) UOH5(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD G-T40E Processor, 1000.15 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
16-way L2 cache
cpu0: 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 200MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD G-T40E Processor, 1000.00 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
16-way L2 cache
cpu1: 8 4MB entries fully associative
cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins
acpiprt0 at acpi0: bus -1 (AGPB)
acpiprt1 at acpi0: bus -1 (HDMI)
acpiprt2 at acpi0: bus 1 (PBR4)
acpiprt3 at acpi0: bus 2 (PBR5)
acpiprt4 at acpi0: bus 3 (PBR6)
acpiprt5 at acpi0: bus -1 (PBR7)
acpiprt6 at acpi0: bus 5 (PE20)
acpiprt7 at acpi0: bus -1 (PE21)
acpiprt8 at acpi0: bus -1 (PE22)
acpiprt9 at acpi0: bus -1 (PE23)
acpiprt10 at acpi0: bus 0 (PCI0)
acpiprt11 at acpi0: bus 4 (PIBR)
acpicpu0 at acpi0: C2(0@100 io@0x841), C1(@1 halt!), PSS
acpicpu1 at acpi0: C2(0@100 io@0x841), C1(@1 halt!), PSS
acpibtn0 at acpi0: PWRB
cpu0: 1000 MHz: speeds: 1000 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "AMD AMD64 14h Host" rev 0x00
ppb0 at pci0 dev 4 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi
pci1 at ppb0 bus 1
re0 at 

Re: [diff] lpbl(4): driver for TI LP8550 backlight controller (found in e.g. MacBook Air 6,2)

2016-01-30 Thread Joerg Jung
On Wed, Jan 27, 2016 at 05:20:59AM +0200, Sviatoslav Chagaev wrote:
> On Sun, 10 Jan 2016 21:28:31 +0100 Joerg Jung wrote:
> > On Sun, Jan 10, 2016 at 04:59:22AM +0200, Sviatoslav Chagaev wrote: 
> > > So below is a driver for TI LP8550.
> ...
> > > If there's any chance for it to be commited, please tell me what I need to
> > > fix/improve to get it commited (so I don't have to reapply it every time I
> > > upgrade).
> > 
> > IMHO, instead of adding another driver to the mix, I would prefer this 
> > to be handled through the associated asmc(4) keys instead of accessing
> > the chip directly.  The SMC is supposed to be the central point for such
> > manipulations.  Unfortunately, the keys are not documented and need some
> > non-trivial effort to be figured out.
> > 
> > If this is not possible through asmc(4) and if your new driver improves
> > the situation then I'm fine with importing it, but for now it is just
> > worse.
> > 
> 
> Using knowledge acquired from [1]

[1] contains some "wrong" (obsolete?) information, e.g. the Errors list.

> and [2] made a diff, posted below for
> reference, which adds:
>  * ioctl interface to asmc(4) to allow reading/writing of ``keys'' from
>userspace;
>  * companion smcprobe(1) which reads/writes ``keys'' using the ioctl;

Wow..., much effort for simple key dumping.  Please, find below an
(older/may not apply) diff which just dumps the keys directly from
kernel into dmesg.

Are you aware that keys can be all kind of types, e.g. structs?  Have
you seen the ASMC_INFO (0x13) command which might be used to determine
the type?  The key flags (read/write/atomic...) are mostly documented
somewhere.

>  * smcdumpkeys(1): scans an SMC textual firmware file and dumps the ``key''
>table that it contains.

Are you aware of the ASMC_INDEX (0x12) command, which can easily be used
to just iterate ALL keys based on index?

> Downloaded SMC FW [3], unpacked it using Google Drive and used smcdumpkeys(1) 
> +
> smcprobe(1) to create the table of keys and their current values before 
> suspend
> [4] and after wake up [5]. Diffed them [6], 

The diff approach is interesting... :) From your diff output I would try
to play with IPBF, MSXk, SAPN, and DM0T.

> filtering out keys which change over
> time as they are probably sensors (some might have gotten through).

If they start with:

'A'... usually ambient light sensor related,
'F'... fan sensors,
'T'... temperature sensors,
'P'... power related,
'V'... voltage sensors.

> Tried modifying all keys whose names start with 'B': no effect.

'B'... is likely not "backlight" but "battery".

> Tried modifying keys which are different after wake up: no effect.

Please find a more exhaustive/descriptive list of keys here:
http://web.archive.org/web/20151103144947/http://www.parhelia.ch/blog/statics/k3_keys.html

Have you seen this: https://github.com/gcsgithub/smc_util it contains
more details for the various structs.

You may also want to have a look into the existing FreeBSD and Linux
drivers.

> [1] 
> https://reverse.put.as/wp-content/uploads/2015/12/D1_02_Alex_Ninjas_and_Harry_Potter.pdf
> [2] 
> https://dev.inversepath.com/download/public/embedded_systems_exploitation.pdf
> [3] https://support.apple.com/kb/DL1748?locale=en_US
> [4] https://gist.github.com/S010/26145f4446fcc0b8a0d6#file-before_suspend-txt
> [5] https://gist.github.com/S010/26145f4446fcc0b8a0d6#file-after_wakeup-txt
> [6] 
> https://gist.github.com/S010/26145f4446fcc0b8a0d6#file-suspend_wakeup_key-diff


Index: asmc.c
===
RCS file: /cvs/src/sys/dev/isa/asmc.c,v
retrieving revision 1.17
diff -u -p -r1.17 asmc.c
--- asmc.c  12 Dec 2015 12:34:05 -  1.17
+++ asmc.c  12 Dec 2015 13:30:12 -
@@ -32,6 +32,8 @@
 #include 
 #include 
 
+#define ASMC_DEBUG 1
+
 #define ASMC_BASE  0x300   /* SMC base address */
 #define ASMC_IOSIZE32  /* I/O region size 0x300-0x31f */
 
@@ -42,6 +44,7 @@
 
 #define ASMC_READ  0x10/* SMC read command */
 #define ASMC_WRITE 0x11/* SMC write command */
+#define ASMC_INDEX 0x12/* SMC index command */
 #define ASMC_INFO  0x13/* SMC info/type command */
 
 #define ASMC_RETRY 10
@@ -85,6 +88,9 @@ struct asmc_softc {
 };
 
 intasmc_try(struct asmc_softc *, int, const char *, uint8_t *, uint8_t);
+#ifdef ASMC_DEBUG
+void   asmc_dump(struct asmc_softc *, uint32_t);
+#endif
 
 void   asmc_init(void *);
 void   asmc_refresh(void *);
@@ -292,7 +298,9 @@ asmc_attach(struct device *parent, struc
}
printf(", %u key%s\n", ntohl(*(uint32_t *)buf),
(ntohl(*(uint32_t *)buf) == 1) ? "" : "s");
-
+#ifdef ASMC_DEBUG
+   asmc_dump(sc, ntohl(*(uint32_t *)buf));
+#endif
/* keyboard backlight led is optional */
sc->sc_kbdled = buf[0] = 127, buf[1] = 0;
if ((r = asmc_try(sc, ASMC_WRITE, "LKSB", buf, 2))) {
@@ -479,25 +487,25 @@ asmc_command(struct asmc_softc *sc, int 
if 

Re: ascii.7: use standard name for ASCII LF and FF

2016-01-30 Thread Sebastian Benoit
Christian Weisgerber(na...@mips.inka.de) on 2016.01.30 17:45:14 +0100:
> From a similar FreeBSD commit:
>   Use standard name for ASCII LF and FF control codes.
> 
> Only overdue by a few decades.  OK?

ok
 
> Index: ascii.7
> ===
> RCS file: /cvs/src/share/man/man7/ascii.7,v
> retrieving revision 1.7
> diff -u -p -r1.7 ascii.7
> --- ascii.7   19 Jan 2014 10:39:00 -  1.7
> +++ ascii.7   30 Jan 2016 16:39:52 -
> @@ -42,7 +42,7 @@ The
>  set:
>  .Bd -literal -offset left
>  000 nul  001 soh  002 stx  003 etx  004 eot  005 enq  006 ack  007 bel
> -010 bs   011 ht   012 nl   013 vt   014 np   015 cr   016 so   017 si
> +010 bs   011 ht   012 lf   013 vt   014 ff   015 cr   016 so   017 si
>  020 dle  021 dc1  022 dc2  023 dc3  024 dc4  025 nak  026 syn  027 etb
>  030 can  031 em   032 sub  033 esc  034 fs   035 gs   036 rs   037 us
>  040 sp   041  !   042  "   043  #   044  $   045  %   046  &   047  '
> @@ -64,7 +64,7 @@ The
>  set:
>  .Bd -literal -offset left
>  00 nul   01 soh   02 stx   03 etx   04 eot   05 enq   06 ack   07 bel
> -08 bs09 ht0a nl0b vt0c np0d cr0e so0f si
> +08 bs09 ht0a lf0b vt0c ff0d cr0e so0f si
>  10 dle   11 dc1   12 dc2   13 dc3   14 dc4   15 nak   16 syn   17 etb
>  18 can   19 em1a sub   1b esc   1c fs1d gs1e rs1f us
>  20 sp21  !22  "23  #24  $25  %26  &27  '
> @@ -86,7 +86,7 @@ The
>  set:
>  .Bd -literal -offset left
>0 nul1 soh2 stx3 etx4 eot5 enq6 ack7 bel
> -  8 bs 9 ht10 nl11 vt12 np13 cr14 so15 si
> +  8 bs 9 ht10 lf11 vt12 ff13 cr14 so15 si
>   16 dle   17 dc1   18 dc2   19 dc3   20 dc4   21 nak   22 syn   23 etb
>   24 can   25 em26 sub   27 esc   28 fs29 gs30 rs31 us
>   32 sp33  !34  "35  #36  $37  %38  &39  '
> -- 
> Christian "naddy" Weisgerber  na...@mips.inka.de
> 

-- 



ascii.7: use standard name for ASCII LF and FF

2016-01-30 Thread Christian Weisgerber
>From a similar FreeBSD commit:
  Use standard name for ASCII LF and FF control codes.

Only overdue by a few decades.  OK?

Index: ascii.7
===
RCS file: /cvs/src/share/man/man7/ascii.7,v
retrieving revision 1.7
diff -u -p -r1.7 ascii.7
--- ascii.7 19 Jan 2014 10:39:00 -  1.7
+++ ascii.7 30 Jan 2016 16:39:52 -
@@ -42,7 +42,7 @@ The
 set:
 .Bd -literal -offset left
 000 nul  001 soh  002 stx  003 etx  004 eot  005 enq  006 ack  007 bel
-010 bs   011 ht   012 nl   013 vt   014 np   015 cr   016 so   017 si
+010 bs   011 ht   012 lf   013 vt   014 ff   015 cr   016 so   017 si
 020 dle  021 dc1  022 dc2  023 dc3  024 dc4  025 nak  026 syn  027 etb
 030 can  031 em   032 sub  033 esc  034 fs   035 gs   036 rs   037 us
 040 sp   041  !   042  "   043  #   044  $   045  %   046  &   047  '
@@ -64,7 +64,7 @@ The
 set:
 .Bd -literal -offset left
 00 nul   01 soh   02 stx   03 etx   04 eot   05 enq   06 ack   07 bel
-08 bs09 ht0a nl0b vt0c np0d cr0e so0f si
+08 bs09 ht0a lf0b vt0c ff0d cr0e so0f si
 10 dle   11 dc1   12 dc2   13 dc3   14 dc4   15 nak   16 syn   17 etb
 18 can   19 em1a sub   1b esc   1c fs1d gs1e rs1f us
 20 sp21  !22  "23  #24  $25  %26  &27  '
@@ -86,7 +86,7 @@ The
 set:
 .Bd -literal -offset left
   0 nul1 soh2 stx3 etx4 eot5 enq6 ack7 bel
-  8 bs 9 ht10 nl11 vt12 np13 cr14 so15 si
+  8 bs 9 ht10 lf11 vt12 ff13 cr14 so15 si
  16 dle   17 dc1   18 dc2   19 dc3   20 dc4   21 nak   22 syn   23 etb
  24 can   25 em26 sub   27 esc   28 fs29 gs30 rs31 us
  32 sp33  !34  "35  #36  $37  %38  &39  '
-- 
Christian "naddy" Weisgerber  na...@mips.inka.de



Re: Don't wrap the cursor in tmux in copy mode

2016-01-30 Thread Michal Mazurek
On 14:45:12, 27.01.16, Nicholas Marriott wrote:
> Hi
> 
> tmux copy mode is not meant to work like vi, it is meant to work like
> emacs, but emacs does do this so we can change it.
> 
> However, your diff is wrong. It prevents the cursor moving back when it
> is at 0,0 _on screen_.

Here is a fixed version:

Index: window-copy.c
===
RCS file: /cvs/src/usr.bin/tmux/window-copy.c,v
retrieving revision 1.144
diff -u -p -r1.144 window-copy.c
--- window-copy.c   19 Jan 2016 15:59:12 -  1.144
+++ window-copy.c   30 Jan 2016 13:00:40 -
@@ -1775,11 +1775,13 @@ void
 window_copy_cursor_left(struct window_pane *wp)
 {
struct window_copy_mode_data*data = wp->modedata;
+   u_intpy;
 
-   if (data->cx == 0) {
+   py = screen_hsize(data->backing) + data->cy - data->oy;
+   if (data->cx == 0 && py > 0) {
window_copy_cursor_up(wp, 0);
window_copy_cursor_end_of_line(wp);
-   } else {
+   } else if (data->cx > 0) {
window_copy_update_cursor(wp, data->cx - 1, data->cy);
if (window_copy_update_selection(wp, 1))
window_copy_redraw_lines(wp, data->cy, 1);
@@ -1790,19 +1792,20 @@ void
 window_copy_cursor_right(struct window_pane *wp)
 {
struct window_copy_mode_data*data = wp->modedata;
-   u_intpx, py;
+   u_intpx, py, yy;
 
+   py = screen_hsize(data->backing) + data->cy - data->oy;
+   yy = screen_hsize(data->backing) + screen_size_y(data->backing) - 1;
if (data->screen.sel.flag && data->rectflag)
px = screen_size_x(>screen);
else {
-   py = screen_hsize(data->backing) + data->cy - data->oy;
px = window_copy_find_length(wp, py);
}
 
-   if (data->cx >= px) {
+   if (data->cx >= px && py < yy) {
window_copy_cursor_start_of_line(wp);
window_copy_cursor_down(wp, 0);
-   } else {
+   } else if (data->cx < px) {
window_copy_update_cursor(wp, data->cx + 1, data->cy);
if (window_copy_update_selection(wp, 1))
window_copy_redraw_lines(wp, data->cy, 1);

-- 
Michal Mazurek



sunxi: don't use sxitimer on the sun7i/A20

2016-01-30 Thread Patrick Wildt
Hi,

one of the reasons Allwinner A20/sun7i-based boards, like the
Cubieboard 2 or Banana Pi, don't boot is that the sxitimer does
not work for us.  We are getting no hardclock ticks and so the
system can't work.

There's a simple fix for that.  We can just not use the sxitimer
and instead use the ARM architected timer (agtimer) that is
supposed to be a generic implementation for all new cores and
already attaches anyway.  The sxitimer attachment currently
overrides the agtimer.  Removing sxitimer thus allows agtimer
to actually do its work.

Currently sxirtc uncondtionally ties into sxitimer.  To make
this work, just make sxirtc map its own page instead of relying
on the existence of a mapping created by sxitimer.

The address/size used for the sxirtc is from a device tree
source.

Patrick

diff --git sys/arch/armv7/sunxi/sunxi.c sys/arch/armv7/sunxi/sunxi.c
index accd475..80cc08f 100644
--- sys/arch/armv7/sunxi/sunxi.c
+++ sys/arch/armv7/sunxi/sunxi.c
@@ -67,9 +67,6 @@ struct board_dev sun4i_devs[] = {
 struct board_dev sun7i_devs[] = {
{ "sxipio", 0 },
{ "sxiccmu",0 },
-   { "sxitimer",   0 },
-   { "sxitimer",   1 },
-   { "sxitimer",   2 },
{ "sxidog", 0 },
{ "sxirtc", 0 },
{ "sxiuart",0 },
diff --git sys/arch/armv7/sunxi/sunxireg.h sys/arch/armv7/sunxi/sunxireg.h
index e1d4f55..59eb0f2 100644
--- sys/arch/armv7/sunxi/sunxireg.h
+++ sys/arch/armv7/sunxi/sunxireg.h
@@ -69,8 +69,8 @@
 #defineWDOG_SIZE   0x08
 #defineWDOG_IRQ24
 
-#defineRTC_ADDR0x0104
-#defineRTC_SIZE0x08
+#defineRTC_ADDR0x01c20d00
+#defineRTC_SIZE0x20
 
 /* Clock Control Module/Unit */
 #defineCCMU_ADDR   0x01c2
diff --git sys/arch/armv7/sunxi/sxirtc.c sys/arch/armv7/sunxi/sxirtc.c
index b0e0653..3ecbf5e 100644
--- sys/arch/armv7/sunxi/sxirtc.c
+++ sys/arch/armv7/sunxi/sxirtc.c
@@ -31,8 +31,8 @@
 #include 
 #include 
 
-#defineSXIRTC_YYMMDD   0x00
-#defineSXIRTC_HHMMSS   0x04
+#defineSXIRTC_YYMMDD   0x04
+#defineSXIRTC_HHMMSS   0x08
 
 #define LEAPYEAR(y)\
 (((y) % 4 == 0 &&\
@@ -76,8 +76,8 @@ sxirtc_attach(struct device *parent, struct device *self, 
void *args)
panic("sxirtc_attach: couldn't allocate todr_handle");
 
sc->sc_iot = aa->aa_iot;
-   if (bus_space_subregion(sc->sc_iot, sxitimer_ioh,
-   aa->aa_dev->mem[0].addr, aa->aa_dev->mem[0].size, >sc_ioh))
+   if (bus_space_map(sc->sc_iot, aa->aa_dev->mem[0].addr,
+   aa->aa_dev->mem[0].size, 0, >sc_ioh))
panic("sxirtc_attach: bus_space_subregion failed!");
 
handle->cookie = self;



back out ASSERT(...pf.statekey == NULL) @ pf.c:6569

2016-01-30 Thread Alexandr Nedvedicky
Hello,

time has come to backout stuff, which has been baked just before Christmas
2015.  Although there was some progress over the last few days the things are
not improving that fast to become good enough for 5.9 release.

I took patch (~sthen/pf-statekey-backout.diff) prepared by sthen last week and
did some minor tweaks so it applies cleanly. Patch removes the offending
KASSERT() and related changes.

I'll try to post partial patches in next few days, so brave volunteers will be
able to continue testing. So it will be possible re-commit the stuff, I'd like
to back out now, in much better shape.

thanks and
regards
sasha
 
8<---8<---8<--8<

Index: kern/uipc_mbuf.c
===
RCS file: /cvs/src/sys/kern/uipc_mbuf.c,v
retrieving revision 1.217
diff -u -p -r1.217 uipc_mbuf.c
--- kern/uipc_mbuf.c7 Jan 2016 22:23:13 -   1.217
+++ kern/uipc_mbuf.c30 Jan 2016 22:23:31 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: uipc_mbuf.c,v 1.217 2016/01/07 22:23:13 sashan Exp $  */
+/* $OpenBSD: uipc_mbuf.c,v 1.216 2015/12/23 21:04:55 jasper Exp $  */
 /* $NetBSD: uipc_mbuf.c,v 1.15.4.1 1996/06/13 17:11:44 cgd Exp $   */
 
 /*
@@ -72,8 +72,6 @@
  * Research Laboratory (NRL).
  */
 
-#include "pf.h"
-
 #include 
 #include 
 #include 
@@ -87,9 +85,6 @@
 #include 
 #include 
 #include 
-#if NPF > 0
-#include 
-#endif /* NPF > 0 */
 
 
 #include 
@@ -266,10 +261,6 @@ m_resethdr(struct mbuf *m)
/* delete all mbuf tags to reset the state */
m_tag_delete_chain(m);
 
-#if NPF > 0
-   pf_pkt_unlink_state_key(m);
-#endif /* NPF > 0 */
-
/* like m_inithdr(), but keep any associated data and mbufs */
memset(>m_pkthdr, 0, sizeof(m->m_pkthdr));
m->m_pkthdr.pf.prio = IFQ_DEFPRIO;
@@ -359,12 +350,8 @@ m_free(struct mbuf *m)
if (n)
n->m_flags |= M_ZEROIZE;
}
-   if (m->m_flags & M_PKTHDR) {
+   if (m->m_flags & M_PKTHDR)
m_tag_delete_chain(m);
-#if NPF > 0
-   pf_pkt_unlink_state_key(m);
-#endif /* NPF > 0 */
-   }
if (m->m_flags & M_EXT)
m_extfree(m);
 
@@ -1214,10 +1201,6 @@ m_dup_pkthdr(struct mbuf *to, struct mbu
to->m_flags = (to->m_flags & (M_EXT | M_EXTWR));
to->m_flags |= (from->m_flags & M_COPYFLAGS);
to->m_pkthdr = from->m_pkthdr;
-
-#if NPF > 0
-   pf_pkt_state_key_ref(to);
-#endif /* NPF > 0 */
 
SLIST_INIT(>m_pkthdr.ph_tags);
 
Index: net/if_pfsync.c
===
RCS file: /cvs/src/sys/net/if_pfsync.c,v
retrieving revision 1.226
diff -u -p -r1.226 if_pfsync.c
--- net/if_pfsync.c 27 Jan 2016 04:35:56 -  1.226
+++ net/if_pfsync.c 30 Jan 2016 22:23:33 -
@@ -523,7 +523,6 @@ pfsync_state_import(struct pfsync_state 
skw->port[0] = sp->key[PF_SK_WIRE].port[0];
skw->port[1] = sp->key[PF_SK_WIRE].port[1];
skw->rdomain = ntohs(sp->key[PF_SK_WIRE].rdomain);
-   PF_REF_INIT(skw->refcnt);
skw->proto = sp->proto;
if (!(skw->af = sp->key[PF_SK_WIRE].af))
skw->af = sp->af;
@@ -533,7 +532,6 @@ pfsync_state_import(struct pfsync_state 
sks->port[0] = sp->key[PF_SK_STACK].port[0];
sks->port[1] = sp->key[PF_SK_STACK].port[1];
sks->rdomain = ntohs(sp->key[PF_SK_STACK].rdomain);
-   PF_REF_INIT(sks->refcnt);
if (!(sks->af = sp->key[PF_SK_STACK].af))
sks->af = sp->af;
if (sks->af != skw->af) {
Index: net/pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.964
diff -u -p -r1.964 pf.c
--- net/pf.c25 Jan 2016 18:49:57 -  1.964
+++ net/pf.c30 Jan 2016 22:23:41 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: pf.c,v 1.964 2016/01/25 18:49:57 sashan Exp $ */
+/* $OpenBSD: pf.c,v 1.962 2015/12/23 21:04:55 jasper Exp $ */
 
 /*
  * Copyright (c) 2001 Daniel Hartmeier
@@ -231,11 +231,6 @@ int pf_step_out_of_anchor(int *, 
stru
 voidpf_counters_inc(int, struct pf_pdesc *,
struct pf_state *, struct pf_rule *,
struct pf_rule *);
-voidpf_state_key_link(struct pf_state_key *,
-   struct pf_state_key *);
-voidpf_inpcb_unlink_state_key(struct inpcb *);
-voidpf_state_key_unlink_reverse(struct pf_state_key *);
-
 #if NPFLOG > 0
 voidpf_log_matches(struct pf_pdesc *, struct pf_rule *,
struct pf_rule *, struct pf_ruleset *,
@@ -699,9 +694,8 @@ pf_state_key_attach(struct pf_state_key 
}
pool_put(_state_key_pl, sk);
s->key[idx] = cur;
-

Re: ascii.7: use standard name for ASCII LF and FF

2016-01-30 Thread Christian Weisgerber
On 2016-01-30, Christian Weisgerber  wrote:

> From a similar FreeBSD commit:
>   Use standard name for ASCII LF and FF control codes.
>
> Only overdue by a few decades.  OK?

share/misc/ascii, too.

Index: share/man/man7/ascii.7
===
RCS file: /cvs/src/share/man/man7/ascii.7,v
retrieving revision 1.7
diff -u -p -r1.7 ascii.7
--- share/man/man7/ascii.7  19 Jan 2014 10:39:00 -  1.7
+++ share/man/man7/ascii.7  31 Jan 2016 00:21:31 -
@@ -42,7 +42,7 @@ The
 set:
 .Bd -literal -offset left
 000 nul  001 soh  002 stx  003 etx  004 eot  005 enq  006 ack  007 bel
-010 bs   011 ht   012 nl   013 vt   014 np   015 cr   016 so   017 si
+010 bs   011 ht   012 lf   013 vt   014 ff   015 cr   016 so   017 si
 020 dle  021 dc1  022 dc2  023 dc3  024 dc4  025 nak  026 syn  027 etb
 030 can  031 em   032 sub  033 esc  034 fs   035 gs   036 rs   037 us
 040 sp   041  !   042  "   043  #   044  $   045  %   046  &   047  '
@@ -64,7 +64,7 @@ The
 set:
 .Bd -literal -offset left
 00 nul   01 soh   02 stx   03 etx   04 eot   05 enq   06 ack   07 bel
-08 bs09 ht0a nl0b vt0c np0d cr0e so0f si
+08 bs09 ht0a lf0b vt0c ff0d cr0e so0f si
 10 dle   11 dc1   12 dc2   13 dc3   14 dc4   15 nak   16 syn   17 etb
 18 can   19 em1a sub   1b esc   1c fs1d gs1e rs1f us
 20 sp21  !22  "23  #24  $25  %26  &27  '
@@ -86,7 +86,7 @@ The
 set:
 .Bd -literal -offset left
   0 nul1 soh2 stx3 etx4 eot5 enq6 ack7 bel
-  8 bs 9 ht10 nl11 vt12 np13 cr14 so15 si
+  8 bs 9 ht10 lf11 vt12 ff13 cr14 so15 si
  16 dle   17 dc1   18 dc2   19 dc3   20 dc4   21 nak   22 syn   23 etb
  24 can   25 em26 sub   27 esc   28 fs29 gs30 rs31 us
  32 sp33  !34  "35  #36  $37  %38  &39  '
Index: share/misc/ascii
===
RCS file: /cvs/src/share/misc/ascii,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 ascii
--- share/misc/ascii18 Oct 1995 08:44:44 -  1.1.1.1
+++ share/misc/ascii31 Jan 2016 00:21:31 -
@@ -1,5 +1,5 @@
 |000 nul|001 soh|002 stx|003 etx|004 eot|005 enq|006 ack|007 bel|
-|010 bs |011 ht |012 nl |013 vt |014 np |015 cr |016 so |017 si |
+|010 bs |011 ht |012 lf |013 vt |014 ff |015 cr |016 so |017 si |
 |020 dle|021 dc1|022 dc2|023 dc3|024 dc4|025 nak|026 syn|027 etb|
 |030 can|031 em |032 sub|033 esc|034 fs |035 gs |036 rs |037 us |
 |040 sp |041  ! |042  " |043  # |044  $ |045  % |046  & |047  ' |
@@ -16,7 +16,7 @@
 |170  x |171  y |172  z |173  { |174  | |175  } |176  ~ |177 del|
 
 | 00 nul| 01 soh| 02 stx| 03 etx| 04 eot| 05 enq| 06 ack| 07 bel|
-| 08 bs | 09 ht | 0a nl | 0b vt | 0c np | 0d cr | 0e so | 0f si |
+| 08 bs | 09 ht | 0a lf | 0b vt | 0c ff | 0d cr | 0e so | 0f si |
 | 10 dle| 11 dc1| 12 dc2| 13 dc3| 14 dc4| 15 nak| 16 syn| 17 etb|
 | 18 can| 19 em | 1a sub| 1b esc| 1c fs | 1d gs | 1e rs | 1f us |
 | 20 sp | 21  ! | 22  " | 23  # | 24  $ | 25  % | 26  & | 27  ' |
@@ -33,7 +33,7 @@
 | 78  x | 79  y | 7a  z | 7b  { | 7c  | | 7d  } | 7e  ~ | 7f del|
 
 |  0 nul|  1 soh|  2 stx|  3 etx|  4 eot|  5 enq|  6 ack|  7 bel|
-|  8 bs |  9 ht | 10 nl | 11 vt | 12 np | 13 cr | 14 so | 15 si |
+|  8 bs |  9 ht | 10 lf | 11 vt | 12 ff | 13 cr | 14 so | 15 si |
 | 16 dle| 17 dc1| 18 dc2| 19 dc3| 20 dc4| 21 nak| 22 syn| 23 etb|
 | 24 can| 25 em | 26 sub| 27 esc| 28 fs | 29 gs | 30 rs | 31 us |
 | 32 sp | 33  ! | 34  " | 35  # | 36  $ | 37  % | 38  & | 39  ' |
-- 
Christian "naddy" Weisgerber  na...@mips.inka.de



Re: arm: don't unnecessarily call pmap_extract()

2016-01-30 Thread Patrick Wildt
On Sun, Jan 31, 2016 at 02:53:57PM +1100, Jonathan Gray wrote:
> On Sat, Jan 30, 2016 at 08:01:00PM +0100, Patrick Wildt wrote:
> > On Tue, Jan 26, 2016 at 07:32:40PM +1100, Jonathan Gray wrote:
> > > On Sun, Jan 24, 2016 at 01:02:49AM +0100, Patrick Wildt wrote:
> > > > Hi,
> > > > 
> > > > there are two code points in the v7 pmap where we need the physical
> > > > address (to flush secondary cache) and use pmap_extract() instead
> > > > of just reading it from the vm page.  This diff removes those.
> > > > 
> > > > Patrick
> > > 
> > > When running with this diff on a imx6 cubox two out of three times 
> > > xenocara
> > > builds have failed with sh dumping core due to bus errors.  Once in
> > > Mesa, and once in libXmu.  I don't remember that happening before,
> > > but I'll try and so some more builds on it without the diff.
> > 
> > Did you encounter any more issues running that diff?  Have you tried
> > compiling xenocara without after seeing those issues?
> > 
> > So far I have only run into unrelated build issues, like a missing
> > define or a python script being started without it having executable
> > permissions.
> 
> I wonder if the following solidrun u-boot commit is related
> https://github.com/SolidRun/u-boot-imx6/commit/408544d61f230060f18ffe2e06565deadbcf3451
> 
> commit 408544d61f230060f18ffe2e06565deadbcf3451
> Author: Jon Nettleton 
> Date:   Tue Oct 13 13:56:13 2015 +0200
> 
> mx6: solidrun: update the pl310 initialization settings
> 
> Besides enabling prefetch we also need to enable the shared
> attribute override bit in the pl310's aux control register.
> 
> Not having this bit set makes the platform non-compliant with the
> ARMv7 ARM specified behaviour of conflicting memory aliases.
> Without this bit set the L2 controller will turn userspace bufferable
> reads into "cachable, no allocate" which can lead to userspace hitting
> stale, non-evicted cache lines.
> 
> Reference kernel commit eeedcea69e927857d32aaf089725eddd2c79dd0a
> 
> Going to try some builds running on a system bootstraped with an
> updated u-boot.
> 

Ouch, that does not sound good.  Sounds like a good idea to apply
and test that fix.

I just remembered changes I did in a local tree nearly two years ago.
It enables prefetch on Cortex-A9 for L1 and L2.  L2 is then set up to
not prefetch instructions, only data.  Unfortunately I don't remember
if it fixed a specific issue I encountered or was more of a try to
speed the machine it up.

Also there's a little diff to enable the SMP bit for the Cortex-A9.
Without that bit ldrex/strex cannot be used.  Would be nice to have
an actual SMP-friendly mutex implementation using ldrex/strex.



Re: domainname(1) - make usage __dead

2016-01-30 Thread Todd C. Miller
On Fri, 29 Jan 2016 14:34:39 -0500, "Ted Unangst" wrote:

> do we have a preferred order for these words? i always use static void __dead
> because i like the real C keywords first, then the annotations to follow.
> starting the line with __ creates "glare". i don't know. not a big deal, just
> throwing it out there.

Most code in the tree uses "static __dead void" which is what I
prefer.

 - todd



Re: Replace less(1)'s stdbool clone with the real McCoy

2016-01-30 Thread Todd C. Miller
On Fri, 29 Jan 2016 12:21:44 -0500, "Ted Unangst" wrote:

> To throw in my vote, I happen to like bool/true/false, but if we don't
> use them consistently, then sticking with int/1/0 is probably best. And
> rototilling the whole src is a bad idea.

I like bool as well and since less was already using a home-grown
variant, switching to stdbool makes sense to me.  OK millert@

 - todd



Re: arm: don't unnecessarily call pmap_extract()

2016-01-30 Thread Jonathan Gray
On Sun, Jan 31, 2016 at 05:55:30AM +0100, Patrick Wildt wrote:
> On Sun, Jan 31, 2016 at 02:53:57PM +1100, Jonathan Gray wrote:
> > On Sat, Jan 30, 2016 at 08:01:00PM +0100, Patrick Wildt wrote:
> > > On Tue, Jan 26, 2016 at 07:32:40PM +1100, Jonathan Gray wrote:
> > > > On Sun, Jan 24, 2016 at 01:02:49AM +0100, Patrick Wildt wrote:
> > > > > Hi,
> > > > > 
> > > > > there are two code points in the v7 pmap where we need the physical
> > > > > address (to flush secondary cache) and use pmap_extract() instead
> > > > > of just reading it from the vm page.  This diff removes those.
> > > > > 
> > > > > Patrick
> > > > 
> > > > When running with this diff on a imx6 cubox two out of three times 
> > > > xenocara
> > > > builds have failed with sh dumping core due to bus errors.  Once in
> > > > Mesa, and once in libXmu.  I don't remember that happening before,
> > > > but I'll try and so some more builds on it without the diff.
> > > 
> > > Did you encounter any more issues running that diff?  Have you tried
> > > compiling xenocara without after seeing those issues?
> > > 
> > > So far I have only run into unrelated build issues, like a missing
> > > define or a python script being started without it having executable
> > > permissions.
> > 
> > I wonder if the following solidrun u-boot commit is related
> > https://github.com/SolidRun/u-boot-imx6/commit/408544d61f230060f18ffe2e06565deadbcf3451
> > 
> > commit 408544d61f230060f18ffe2e06565deadbcf3451
> > Author: Jon Nettleton 
> > Date:   Tue Oct 13 13:56:13 2015 +0200
> > 
> > mx6: solidrun: update the pl310 initialization settings
> > 
> > Besides enabling prefetch we also need to enable the shared
> > attribute override bit in the pl310's aux control register.
> > 
> > Not having this bit set makes the platform non-compliant with the
> > ARMv7 ARM specified behaviour of conflicting memory aliases.
> > Without this bit set the L2 controller will turn userspace bufferable
> > reads into "cachable, no allocate" which can lead to userspace hitting
> > stale, non-evicted cache lines.
> > 
> > Reference kernel commit eeedcea69e927857d32aaf089725eddd2c79dd0a
> > 
> > Going to try some builds running on a system bootstraped with an
> > updated u-boot.
> > 
> 
> Ouch, that does not sound good.  Sounds like a good idea to apply
> and test that fix.
> 
> I just remembered changes I did in a local tree nearly two years ago.
> It enables prefetch on Cortex-A9 for L1 and L2.  L2 is then set up to
> not prefetch instructions, only data.  Unfortunately I don't remember
> if it fixed a specific issue I encountered or was more of a try to
> speed the machine it up.
> 
> Also there's a little diff to enable the SMP bit for the Cortex-A9.
> Without that bit ldrex/strex cannot be used.  Would be nice to have
> an actual SMP-friendly mutex implementation using ldrex/strex.

Does anything change with regards to memory coherency and types of
barriers that are needed if the bit is set?

It isn't clear to me how much we'd have to care about local/global
monitor, snoop control, changes to shareability domain configuration etc
when just running SP.



fix armv7 long descriptor second level bits

2016-01-30 Thread Jonathan Gray
The AP bits are the same place as in the small descriptor second level
format.

Expanded version of a diff from Patrick.

Index: arm/pmap.c
===
RCS file: /cvs/src/sys/arch/arm/arm/pmap.c,v
retrieving revision 1.57
diff -u -p -r1.57 pmap.c
--- arm/pmap.c  31 Jan 2016 00:14:50 -  1.57
+++ arm/pmap.c  31 Jan 2016 07:08:56 -
@@ -4361,6 +4361,12 @@ pt_entry_t   pte_l1_s_prot_kr;
 pt_entry_t pte_l1_s_prot_kw;
 pt_entry_t pte_l1_s_prot_mask;
 
+pt_entry_t pte_l2_l_prot_ur;
+pt_entry_t pte_l2_l_prot_uw;
+pt_entry_t pte_l2_l_prot_kr;
+pt_entry_t pte_l2_l_prot_kw;
+pt_entry_t pte_l2_l_prot_mask;
+
 pt_entry_t pte_l2_s_prot_ur;
 pt_entry_t pte_l2_s_prot_uw;
 pt_entry_t pte_l2_s_prot_kr;
@@ -4413,6 +4419,12 @@ pmap_pte_init_generic(void)
pte_l1_s_prot_kw = L1_S_PROT_KW_generic;
pte_l1_s_prot_mask = L1_S_PROT_MASK_generic;
 
+   pte_l2_l_prot_ur = L2_L_PROT_UR_generic;
+   pte_l2_l_prot_uw = L2_L_PROT_UW_generic;
+   pte_l2_l_prot_kr = L2_L_PROT_KR_generic;
+   pte_l2_l_prot_kw = L2_L_PROT_KW_generic;
+   pte_l2_l_prot_mask = L2_L_PROT_MASK_generic;
+
pte_l2_s_prot_ur = L2_S_PROT_UR_generic;
pte_l2_s_prot_uw = L2_S_PROT_UW_generic;
pte_l2_s_prot_kr = L2_S_PROT_KR_generic;
@@ -4542,6 +4554,12 @@ pmap_pte_init_armv7(void)
pte_l1_s_prot_kw = L1_S_PROT_KW_v7;
pte_l1_s_prot_mask = L1_S_PROT_MASK_v7;
 
+   pte_l2_l_prot_ur = L2_L_PROT_UR_v7;
+   pte_l2_l_prot_uw = L2_L_PROT_UW_v7;
+   pte_l2_l_prot_kr = L2_L_PROT_KR_v7;
+   pte_l2_l_prot_kw = L2_L_PROT_KW_v7;
+   pte_l2_l_prot_mask = L2_L_PROT_MASK_v7;
+
pte_l2_s_prot_ur = L2_S_PROT_UR_v7;
pte_l2_s_prot_uw = L2_S_PROT_UW_v7;
pte_l2_s_prot_kr = L2_S_PROT_KR_v7;
@@ -4679,6 +4697,12 @@ pmap_pte_init_xscale(void)
pte_l1_s_prot_kr = L1_S_PROT_KR_xscale;
pte_l1_s_prot_kw = L1_S_PROT_KW_xscale;
pte_l1_s_prot_mask = L1_S_PROT_MASK_xscale;
+
+   pte_l2_l_prot_ur = L2_L_PROT_UR_xscale;
+   pte_l2_l_prot_uw = L2_L_PROT_UW_xscale;
+   pte_l2_l_prot_kr = L2_L_PROT_KR_xscale;
+   pte_l2_l_prot_kw = L2_L_PROT_KW_xscale;
+   pte_l2_l_prot_mask = L2_L_PROT_MASK_xscale;
 
pte_l2_s_prot_ur = L2_S_PROT_UR_xscale;
pte_l2_s_prot_uw = L2_S_PROT_UW_xscale;
Index: arm/pmap7.c
===
RCS file: /cvs/src/sys/arch/arm/arm/pmap7.c,v
retrieving revision 1.22
diff -u -p -r1.22 pmap7.c
--- arm/pmap7.c 31 Jan 2016 00:14:50 -  1.22
+++ arm/pmap7.c 31 Jan 2016 07:08:57 -
@@ -3337,6 +3337,12 @@ pt_entry_t   pte_l1_s_prot_kr;
 pt_entry_t pte_l1_s_prot_kw;
 pt_entry_t pte_l1_s_prot_mask;
 
+pt_entry_t pte_l2_l_prot_ur;
+pt_entry_t pte_l2_l_prot_uw;
+pt_entry_t pte_l2_l_prot_kr;
+pt_entry_t pte_l2_l_prot_kw;
+pt_entry_t pte_l2_l_prot_mask;
+
 pt_entry_t pte_l2_s_prot_ur;
 pt_entry_t pte_l2_s_prot_uw;
 pt_entry_t pte_l2_s_prot_kr;
@@ -3388,6 +3394,12 @@ pmap_pte_init_generic(void)
pte_l1_s_prot_kw = L1_S_PROT_KW_generic;
pte_l1_s_prot_mask = L1_S_PROT_MASK_generic;
 
+   pte_l2_l_prot_ur = L2_L_PROT_UR_generic;
+   pte_l2_l_prot_uw = L2_L_PROT_UW_generic;
+   pte_l2_l_prot_kr = L2_L_PROT_KR_generic;
+   pte_l2_l_prot_kw = L2_L_PROT_KW_generic;
+   pte_l2_l_prot_mask = L2_L_PROT_MASK_generic;
+
pte_l2_s_prot_ur = L2_S_PROT_UR_generic;
pte_l2_s_prot_uw = L2_S_PROT_UW_generic;
pte_l2_s_prot_kr = L2_S_PROT_KR_generic;
@@ -3436,6 +3448,12 @@ pmap_pte_init_armv7(void)
pte_l1_s_prot_kr = L1_S_PROT_KR_v7;
pte_l1_s_prot_kw = L1_S_PROT_KW_v7;
pte_l1_s_prot_mask = L1_S_PROT_MASK_v7;
+
+   pte_l2_l_prot_ur = L2_L_PROT_UR_v7;
+   pte_l2_l_prot_uw = L2_L_PROT_UW_v7;
+   pte_l2_l_prot_kr = L2_L_PROT_KR_v7;
+   pte_l2_l_prot_kw = L2_L_PROT_KW_v7;
+   pte_l2_l_prot_mask = L2_L_PROT_MASK_v7;
 
pte_l2_s_prot_ur = L2_S_PROT_UR_v7;
pte_l2_s_prot_uw = L2_S_PROT_UW_v7;
Index: include/pmap.h
===
RCS file: /cvs/src/sys/arch/arm/include/pmap.h,v
retrieving revision 1.34
diff -u -p -r1.34 pmap.h
--- include/pmap.h  15 Aug 2015 22:20:20 -  1.34
+++ include/pmap.h  31 Jan 2016 07:08:57 -
@@ -431,6 +431,12 @@ extern pt_entry_t  pte_l1_s_prot_kr;
 extern pt_entry_t  pte_l1_s_prot_kw;
 extern pt_entry_t  pte_l1_s_prot_mask;
 
+extern pt_entry_t  pte_l2_l_prot_ur;
+extern pt_entry_t  pte_l2_l_prot_uw;
+extern pt_entry_t  pte_l2_l_prot_kr;
+extern pt_entry_t  pte_l2_l_prot_kw;
+extern pt_entry_t  pte_l2_l_prot_mask;
+
 extern pt_entry_t  pte_l2_s_prot_ur;
 extern pt_entry_t  pte_l2_s_prot_uw;
 extern pt_entry_t