Re: arm: don't unnecessarily call pmap_extract()
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
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)
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
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
>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
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
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
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
On 2016-01-30, Christian Weisgerberwrote: > 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()
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
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
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()
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
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