Re: CVS commit: src/sys/dev/tprof

[Jared McNeill]

I think this is a bug in your device tree because the KASSERT was 
intentional:


 - In the ACPI case, we probe for CPU PMU support before calling
   armv8_pmu_init.
 - In the FDT case, the PMU attaches to a node described in the device
   tree.

So if you hit this KASSERT, AFAICT it means your device tree is describing 
a device that is not there. Unless I'm missing something here.


Take care,
Jared

On Wed, 9 Nov 2022, Ryo Shimizu wrote:


Module Name:src
Committed By:   ryo
Date:   Wed Nov  9 19:06:46 UTC 2022

Modified Files:
src/sys/dev/tprof: tprof_armv8.c

Log Message:
If the hardware does not support PMU, return an error instead of KASSERT.


To generate a diff of this commit:
cvs rdiff -u -r1.14 -r1.15 src/sys/dev/tprof/tprof_armv8.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/sbin/devpubd/hooks

[Jared McNeill]

The script no longer works:

Starting devpubd.
/libexec/devpubd-hooks/02-wedgenames: 164: Syntax error: end of file unexpected 
(expecting "done")

Take care,
Jared


On Thu, 5 Aug 2021, Robert Elz wrote:


Module Name:src
Committed By:   kre
Date:   Thu Aug  5 12:52:47 UTC 2021

Modified Files:
src/sbin/devpubd/hooks: 02-wedgenames

Log Message:
Obliterate bogus $@ usage.

While here, fix some quoting, change some style, and attempt
to properly handle wedge names with embedded newlines, and those
that end with a '/' character (not particularly happy with the
solution to that last one, but it is better than it was).

Is there a reason that characters that need encoding in wedge names
(white space, and more) are encoded as %%XX (XX is the hex value of
the char - but 2 % chars?  Why?).   That remains unchanged, but as
the script already relied upon sh's $'...' quoting, I think we can rely
upon printf as well, so replace the old (very elegant, but slow) encoding
function with a much simpler one (does the same thing).


To generate a diff of this commit:
cvs rdiff -u -r1.6 -r1.7 src/sbin/devpubd/hooks/02-wedgenames

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/sys

[Jared McNeill]

The H6 BSP provides some clues:
#if defined(CONFIG_ARCH_SUN8IW12) \
|| defined(CONFIG_ARCH_SUN8IW15) \
|| defined(CONFIG_ARCH_SUN50IW3) \
|| defined(CONFIG_ARCH_SUN50IW6)
#define SUNXI_UART_FIFO_SIZE256
#elif defined(CONFIG_ARCH_SUN3IW1)
#define SUNXI_UART_FIFO_SIZE32
#else
#define SUNXI_UART_FIFO_SIZE64
#endif
sun8iw12 = V5/V100
sun8iw15 = R311/A50
sun50iw3 = A63
sun50iw6 = H6
sun3iw1 = handful of ARM926EJ-S things we don’t support

Take care,
Jared

> On Jul 31, 2021, at 7:17 AM, Tobias Nygren  wrote:
> 
> On Fri, 30 Jul 2021 22:36:45 +0200
> Tobias Nygren  wrote:
> 
>> On Fri, 30 Jul 2021 17:25:46 -0300 (ADT)
>> Jared McNeill  wrote:
>> 
>>> Why only A20?
>> 
>> It is the hardware I have on hand. If you know specifically which
>> SoCs need this, the compat_data array can be extended.
>> I guess maybe these also?
>> allwinner,sun4i-a10
>> allwinner,sun6i-a31
> 
> Apparently it can be an issue on relatively speaking newer SoCs too.
> For example the H6 does not have DesignWare specific register,
> and comes with 256-byte FIFO instead of 64-byte.
> 
> It's not possible to deduce from the manual what DesignWare revision
> is used but I guess I can go over the data sheets of currently
> released SoCs and build a matrix of the proper values regardless
> of DesignWare revision.
> 

Re: CVS commit: src/sys

[Jared McNeill]

Why only A20?

On Fri, 30 Jul 2021, Tobias Nygren wrote:


Module Name:src
Committed By:   tnn
Date:   Fri Jul 30 12:46:46 UTC 2021

Modified Files:
src/sys/arch/arm/sunxi: sunxi_platform.c
src/sys/dev/ic: com.c

Log Message:
com(4): fix FIFO for DW_APB on Allwinner A20 (got broken by com.c 1.360)

Older DesignWare UARTs do not advertise their FIFO length so we must
provide it via device properties.


To generate a diff of this commit:
cvs rdiff -u -r1.43 -r1.44 src/sys/arch/arm/sunxi/sunxi_platform.c
cvs rdiff -u -r1.363 -r1.364 src/sys/dev/ic/com.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/lib/libc/regex

[Jared McNeill]

Building tools on macOS:

/Users/jmcneill/netbsd/git-src/tools/compat/../../lib/libc/regex/regcomp.c:1585:8: 
error: implicit declaration of function 'reallocarray' is invalid

  in C99 [-Werror,-Wimplicit-function-declaration]
ncs = reallocarray(p->g->sets, p->g->ncsets + 1, sizeof(*ncs));
  ^
/Users/jmcneill/netbsd/git-src/tools/compat/../../lib/libc/regex/regcomp.c:1585:8: 
note: did you mean 'reallocarr'?
/Users/jmcneill/netbsd/git-src/tools/compat/compat_defs.h:556:5: note: 
'reallocarr' declared here

int reallocarr(void *, size_t, size_t);
^


On Tue, 23 Feb 2021, Christos Zoulas wrote:


Module Name:src
Committed By:   christos
Date:   Tue Feb 23 22:14:59 UTC 2021

Modified Files:
src/lib/libc/regex: cname.h engine.c re_format.7 regcomp.c regerror.c
regex.3 regex2.h regexec.c regfree.c utils.h
Removed Files:
src/lib/libc/regex: cclass.h

Log Message:
sync with FreeBSD:
   - NLS support
   - GNU extensions
   - bug fixes


To generate a diff of this commit:
cvs rdiff -u -r1.7 -r0 src/lib/libc/regex/cclass.h
cvs rdiff -u -r1.7 -r1.8 src/lib/libc/regex/cname.h
cvs rdiff -u -r1.24 -r1.25 src/lib/libc/regex/engine.c
cvs rdiff -u -r1.12 -r1.13 src/lib/libc/regex/re_format.7
cvs rdiff -u -r1.38 -r1.39 src/lib/libc/regex/regcomp.c
cvs rdiff -u -r1.23 -r1.24 src/lib/libc/regex/regerror.c
cvs rdiff -u -r1.26 -r1.27 src/lib/libc/regex/regex.3
cvs rdiff -u -r1.13 -r1.14 src/lib/libc/regex/regex2.h
cvs rdiff -u -r1.22 -r1.23 src/lib/libc/regex/regexec.c
cvs rdiff -u -r1.15 -r1.16 src/lib/libc/regex/regfree.c
cvs rdiff -u -r1.6 -r1.7 src/lib/libc/regex/utils.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/sys/arch/aarch64/aarch64

[Jared McNeill]

On Mon, 22 Feb 2021, Ryo Shimizu wrote:


I think this condition is not necessary since cpu_idle() is just called from 
idle_loop(),
and ci_intr_depth is always zero at this time.


Ah yes, my mistake! Please feel free to revert this commit as part of 
your proposed change.

Re: CVS commit: src/sys

[Jared McNeill]

I noticed this on reboot since this change:

 [ 3636.2891122] turning off swap...stopping swap on /swap failed with error 16
 [ 3636.2991109] stopping swap on /swap2 failed with error 16

Can you have a look?

Thanks!
Jared


On Tue, 16 Feb 2021, Juergen Hannken-Illjes wrote:


Module Name:src
Committed By:   hannken
Date:   Tue Feb 16 09:56:32 UTC 2021

Modified Files:
src/sys/kern: vfs_mount.c
src/sys/uvm: uvm_swap.c

Log Message:
Reorganize uvm_swap_shutdown() a bit, make sure the vnode gets
locked and referenced across the call to swap_off() and finally
use it from vfs_unmountall1() to remove swap after unmounting
the last file system.

Adresses PR kern/54969 (Disk cache is no longer flushed on shutdown)


To generate a diff of this commit:
cvs rdiff -u -r1.85 -r1.86 src/sys/kern/vfs_mount.c
cvs rdiff -u -r1.200 -r1.201 src/sys/uvm/uvm_swap.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/sys/arch/evbarm/conf

[Jared McNeill]

I forgot that I added dma-ranges support back in Feb last year. All good, 
please ignore me :)



On Thu, 21 Jan 2021, Jared McNeill wrote:

This driver is not 64-bit safe and should not be enabled on aarch64 as-is. I 
think before turning it on we should restrict it to the lower 1GB of memory 
like the Pi3 models where we know it at least has a chance of working. You 
can do this easily by creating a restrictive tag using 
bus_dmatag_subregion(9).


Take care,
Jared

On Thu, 21 Jan 2021, Nia Alarie wrote:


Module Name:src
Committed By:   nia
Date:   Thu Jan 21 17:46:28 UTC 2021

Modified Files:
src/sys/arch/evbarm/conf: GENERIC64

Log Message:
add vcaudio (intentionally this time)

gives working audio output on rpi3 without needing to run a 32-bit image.


To generate a diff of this commit:
cvs rdiff -u -r1.173 -r1.174 src/sys/arch/evbarm/conf/GENERIC64

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/sys/arch/evbarm/conf

[Jared McNeill]

This driver is not 64-bit safe and should not be enabled on aarch64 as-is. 
I think before turning it on we should restrict it to the lower 1GB of 
memory like the Pi3 models where we know it at least has a chance of 
working. You can do this easily by creating a restrictive tag using 
bus_dmatag_subregion(9).


Take care,
Jared

On Thu, 21 Jan 2021, Nia Alarie wrote:


Module Name:src
Committed By:   nia
Date:   Thu Jan 21 17:46:28 UTC 2021

Modified Files:
src/sys/arch/evbarm/conf: GENERIC64

Log Message:
add vcaudio (intentionally this time)

gives working audio output on rpi3 without needing to run a 32-bit image.


To generate a diff of this commit:
cvs rdiff -u -r1.173 -r1.174 src/sys/arch/evbarm/conf/GENERIC64

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/sys/dev/wscons

[Jared McNeill]

The change isn't wrong, but I booted the wrong kernel and it does not fix 
the aarch64 issue I am seeing.


On Sun, 17 Jan 2021, Jared D. McNeill wrote:


Module Name:src
Committed By:   jmcneill
Date:   Sun Jan 17 15:13:15 UTC 2021

Modified Files:
src/sys/dev/wscons: wsdisplay_vconsvar.h

Log Message:
Add appropriate memory barriers around sc_busy accesses. Fixes an issue
where character cells are sometimes not erased properly on aarch64 at
boot.


To generate a diff of this commit:
cvs rdiff -u -r1.28 -r1.29 src/sys/dev/wscons/wsdisplay_vconsvar.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/usr.bin/xlint/lint1

[Jared McNeill]

Not sure if it is this exact change, but I am no longer able to build 
tools on Ubuntu 20.04.1:


--- lint1 ---
#  link  lint1/lint1
cc -O -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 
-I/home/jmcneill/netbsd/cvs-src/obj/tooldir.Linux-5.8.0-34-generic-x86_64/include/compat 
-I/home/jmcneill/netbsd/cvs-src/tools/compat -DHAVE_NBTOOL_CONFIG_H=1 
-D_FILE_OFFSET_BITS=64 
-I/home/jmcneill/netbsd/cvs-src/tools/lint1/../../usr.bin/xlint/lint1 -I. 
-DPASS=\"lint1.h\" 
-I/home/jmcneill/netbsd/cvs-src/tools/lint1/../../usr.bin/xlint/lint1/../arch/aarch64 
-I/home/jmcneill/netbsd/cvs-src/tools/lint1/../../usr.bin/xlint/lint1/../common 
-o lint1 cgram.lo decl.lo emit.lo emit1.lo err.lo func.lo init.lo 
inittyp.lo main1.lo mem.lo mem1.lo ops.lo print.lo scan.lo tree.lo 
tyname.lo 
-L/home/jmcneill/netbsd/cvs-src/obj/tooldir.Linux-5.8.0-34-generic-x86_64/lib 
-lnbcompat -lrt -lz -lm

/usr/bin/ld: ops.lo: in function `initmtab':
ops.c:(.text+0x63): undefined reference to `STRUCT_ASSIGN'
collect2: error: ld returned 1 exit status
*** [lint1] Error code 1

nbmake[3]: stopped in /home/jmcneill/netbsd/cvs-src/tools/lint1
1 error

nbmake[3]: stopped in /home/jmcneill/netbsd/cvs-src/tools/lint1

nbmake[2]: stopped in /home/jmcneill/netbsd/cvs-src/tools/lint1

*** Failed target:  dependall-lint1
*** Failed command: _makedirtarget() { dir="$1"; shift; target="$1"; 
shift; case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .) this=""; 
real="/home/jmcneill/netbsd/cvs-src/tools" ;; *) this="${dir}/"; 
real="/home/jmcneill/netbsd/cvs-src/tools/${dir}" ;; esac; 
show=${this:-.}; echo "${target} ===> ${show%/}${1:+ (with: $@)}"; cd 
"${real}" && 
/home/jmcneill/netbsd/cvs-src/obj/tooldir.Linux-5.8.0-34-generic-x86_64/bin/nbmake 
_THISDIR_="${this}" "$@" ${target}; }; _makedirtarget lint1 dependall

*** Error code 2

Stop.
nbmake[1]: stopped in /home/jmcneill/netbsd/cvs-src/tools
*** [build_install] Error code 1

nbmake: stopped in /home/jmcneill/netbsd/cvs-src/tools
1 error

nbmake: stopped in /home/jmcneill/netbsd/cvs-src/tools

ERROR: Failed to make build_install in "tools"
*** BUILD ABORTED ***


On Tue, 5 Jan 2021, Roland Illig wrote:


Module Name:src
Committed By:   rillig
Date:   Tue Jan  5 23:50:29 UTC 2021

Modified Files:
src/usr.bin/xlint/lint1: Makefile op.h ops.def
Added Files:
src/usr.bin/xlint/lint1: ops.c
Removed Files:
src/usr.bin/xlint/lint1: Makefile.ops-c Makefile.ops-h mkops

Log Message:
lint: clean up generation of the operator tables

Instead of running a shell program that runs an AWK program that
generates the two files ops.c and ops.h, just define the operator tables
once in ops.def and use these definitions flexibly in ops.c and op.h.


To generate a diff of this commit:
cvs rdiff -u -r1.55 -r1.56 src/usr.bin/xlint/lint1/Makefile
cvs rdiff -u -r1.3 -r0 src/usr.bin/xlint/lint1/Makefile.ops-c \
   src/usr.bin/xlint/lint1/Makefile.ops-h
cvs rdiff -u -r1.13 -r0 src/usr.bin/xlint/lint1/mkops
cvs rdiff -u -r1.9 -r1.10 src/usr.bin/xlint/lint1/op.h
cvs rdiff -u -r0 -r1.1 src/usr.bin/xlint/lint1/ops.c
cvs rdiff -u -r1.6 -r1.7 src/usr.bin/xlint/lint1/ops.def

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src

[Jared McNeill]

Hi!

sys/external/gpl2/dts/dist is meant for upstream dts files only. Do 
you mind  moving this to sys/arch/arm/dts with the other custom dts files?


Thanks!
Jared


On Fri, 1 Jan 2021, Ryo Shimizu wrote:


Module Name:src
Committed By:   ryo
Date:   Fri Jan  1 07:41:46 UTC 2021

Modified Files:
src/distrib/sets/lists/dtb: ad.aarch64 ad.aarch64eb
src/sys/external/gpl2/dts/dist/arch/arm64/boot/dts/amlogic: Makefile
Added Files:
src/sys/external/gpl2/dts/dist/arch/arm64/boot/dts/amlogic:
meson-g12b-odroid-n2-plus.dts

Log Message:
add dts for odroid-N2 plus.

meson-g12b-odroid-n2-plus.dts of linux is not optimized for the odroid-N2plus 
CPU clock.
and the dts for odroid-n2-plus in the hardkernel repository is  significantly 
changed,
so cannot be imported without modification. Therefore, a simple 
meson-g12b-odroid-n2-plus.dts
has been added based on "meson-g12b-odroid-n2.dts" with only the cpu_opp_table 
and
regulator table changed.


To generate a diff of this commit:
cvs rdiff -u -r1.3 -r1.4 src/distrib/sets/lists/dtb/ad.aarch64
cvs rdiff -u -r1.2 -r1.3 src/distrib/sets/lists/dtb/ad.aarch64eb
cvs rdiff -u -r1.1.1.7 -r1.2 \
   src/sys/external/gpl2/dts/dist/arch/arm64/boot/dts/amlogic/Makefile
cvs rdiff -u -r0 -r1.1 \
   
src/sys/external/gpl2/dts/dist/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2-plus.dts

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/sys/arch/arm/rockchip

[Jared McNeill]

Oops. The change was to make sure that a devicetree node with a 
"rockchip,grf" property on a device type that doesn't provide a config 
struct doesn't deref a NULL ptr.


On Fri, 1 Jan 2021, Jared D. McNeill wrote:


Module Name:src
Committed By:   jmcneill
Date:   Fri Jan  1 11:44:41 UTC 2021

Modified Files:
src/sys/arch/arm/rockchip: rk_i2s.c

Log Message:
rk_i2s.c


To generate a diff of this commit:
cvs rdiff -u -r1.5 -r1.6 src/sys/arch/arm/rockchip/rk_i2s.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/sys/dev/wsfb

[Jared McNeill]

I think WSFB_VRAM_IS_RAM is meant to be a hint for what kind of memory you 
get when you mmap the device. When shadow FB is used, that is generally 
only used for rasops and mmap bypasses the shadow and uses device memory 
directly. So I think this could cause performance regressions on such 
hardware where shadow FB is enabled and reading VRAM is slow.


What problem are you attempting to solve with this change?


On Sun, 18 Oct 2020, Rin Okuyama wrote:


Module Name:src
Committed By:   rin
Date:   Sun Oct 18 11:54:21 UTC 2020

Modified Files:
src/sys/dev/wsfb: genfb.c

Log Message:
For WSDISPLAYIO_GET_FBINFO ioctl, set WSFB_VRAM_IS_RAM to fbi_flags
when shadow FB is used.


To generate a diff of this commit:
cvs rdiff -u -r1.74 -r1.75 src/sys/dev/wsfb/genfb.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/libexec/httpd

[Jared McNeill]

On Sat, 12 Sep 2020, Olaf Seibert wrote:


bozohttpd: add .m4a and .m4v file extensions.


I don't think audio/mpeg is correct for .m4a. Since .m4a is MPEG audio in 
an MP4 container, I would follow RFC 4337 ("MIME Type Registration for 
MPEG-4") here which says you should use audio/mp4 instead.


Take care,
Jared

Re: CVS commit: src

[Jared McNeill]

This causes issues with the source tree on case insensitive file-systems :(


On Wed, 22 Jul 2020, Martin Husemann wrote:


Module Name:src
Committed By:   martin
Date:   Wed Jul 22 16:50:41 UTC 2020

Modified Files:
src/distrib/sets/lists/etc: mi
src/etc: rc
src/etc/rc.d: Makefile bootconf.sh dhcpcd ip6addrctl ipfilter ipsec
iscsid mdnsd mountcritlocal mountcritremote network npf npf_boot pf
pf_boot random_seed route6d smtoff wpa_supplicant
Added Files:
src/etc/rc.d: MOUNTCRITLOCAL clearcritlocal llvmlockdir

Log Message:
Split the local disk availability step into two phases to allow scripts
that pre-populate parts of the system (e.g. a tmpfs based /var) an
easy place to plug in like:

# REQUIRE: mountcritlocal
# BEFORE: MOUNTCRITLOCAL

This also cleans up the existing special handling a bit by separating it
into new scripts. All later scripts now depend on MOUNTCRITLOCAL.
Discussed on tech-userlevel some time ago.


To generate a diff of this commit:
cvs rdiff -u -r1.260 -r1.261 src/distrib/sets/lists/etc/mi
cvs rdiff -u -r1.173 -r1.174 src/etc/rc
cvs rdiff -u -r0 -r1.1 src/etc/rc.d/MOUNTCRITLOCAL \
   src/etc/rc.d/clearcritlocal src/etc/rc.d/llvmlockdir
cvs rdiff -u -r1.106 -r1.107 src/etc/rc.d/Makefile
cvs rdiff -u -r1.16 -r1.17 src/etc/rc.d/bootconf.sh src/etc/rc.d/ipsec
cvs rdiff -u -r1.9 -r1.10 src/etc/rc.d/dhcpcd src/etc/rc.d/mountcritremote \
   src/etc/rc.d/route6d
cvs rdiff -u -r1.5 -r1.6 src/etc/rc.d/ip6addrctl src/etc/rc.d/npf \
   src/etc/rc.d/pf_boot
cvs rdiff -u -r1.19 -r1.20 src/etc/rc.d/ipfilter
cvs rdiff -u -r1.1 -r1.2 src/etc/rc.d/iscsid
cvs rdiff -u -r1.4 -r1.5 src/etc/rc.d/mdnsd src/etc/rc.d/smtoff
cvs rdiff -u -r1.15 -r1.16 src/etc/rc.d/mountcritlocal
cvs rdiff -u -r1.80 -r1.81 src/etc/rc.d/network
cvs rdiff -u -r1.2 -r1.3 src/etc/rc.d/npf_boot
cvs rdiff -u -r1.12 -r1.13 src/etc/rc.d/pf
cvs rdiff -u -r1.13 -r1.14 src/etc/rc.d/random_seed
cvs rdiff -u -r1.7 -r1.8 src/etc/rc.d/wpa_supplicant

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/usr.bin/make

[Jared McNeill]

On Sun, 2 Aug 2020, Roland Illig wrote:


Module Name:src
Committed By:   rillig
Date:   Sun Aug  2 09:43:22 UTC 2020

Modified Files:
src/usr.bin/make: var.c

Log Message:
make(1): use shorter local variable names

The c in cp was redundant since the context makes it obvious that this
is a character pointer. In a tight loop where lots of characters are
compared, every letter counts.


I don't follow the rationale here. Can you expand on this?

Re: CVS commit: src/sys/arch/aarch64/aarch64

[Jared McNeill]

I think this will have issues on some big.LITTLE configurations 
like Rockchip RK3399.


In the RK3399 case cpu[0-3] is VIPT I$ and cpu[4-5] is PIPT I$. Boot 
order of secondaries is not guaranteed so it is possible to get different 
values of aarch64_cache_vindexsize from one boot to the next.


Jared


On Thu, 2 Jul 2020, Rin Okuyama wrote:


Module Name:src
Committed By:   rin
Date:   Thu Jul  2 12:59:31 UTC 2020

Modified Files:
src/sys/arch/aarch64/aarch64: pmap.c

Log Message:
Set uvmexp.ncolors appropriately, which is required for some CPU
models with VIPT icache.

Otherwise, alias in virtual address results in inconsistent results,
at least for applications that rewrite text of other process, e.g.,
GDB for arm32.

Also, this hopefully fixes other unexpected failures due to alias.

Confirmed that there's no observable regression in performance;
difference in ``time make -j8'' for GENERIC64 kernel on BCM2837
with and without setting uvmexp.ncolors is within 0.1%.

Thanks to ryo@ for discussion.


To generate a diff of this commit:
cvs rdiff -u -r1.80 -r1.81 src/sys/arch/aarch64/aarch64/pmap.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/distrib/common/bootimage

[Jared McNeill]

On Fri, 29 May 2020, Izumi Tsutsui wrote:


src/distrib/common/bootimage/Makefile.bootimage (included from
Makefile.installimage) already has "USE_MBR?= no" line.


Makefile.installimage refers to it before including Makefile.bootimage and 
this test was causing make to throw an error:


  
https://nxr.netbsd.org/xref/src/distrib/common/bootimage/Makefile.installimage#41

All other users (i386, amd64) of Makefile.installimage explicitly set 
USE_MBR=yes. That's why it wasn't an issue before now.


Cheers,
Jared

Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64

[Jared McNeill]

Unfortunately this breaks building on a 9.0 arm64 host because it is 
picking up /usr/include/aarch64/armreg.h and the one in 9.0 is missing a 
bunch of stuff. It works when using armreg.h from the source tree instead, 
eg:


-#include 
+#include "/path/to/src/sys/arch/aarch64/include/armreg.h"



On Tue, 28 Apr 2020, matthew green wrote:


Module Name:src
Committed By:   mrg
Date:   Tue Apr 28 03:00:23 UTC 2020

Modified Files:
src/external/gpl3/gcc/dist/gcc/config/aarch64: driver-aarch64.c

Log Message:
slightly reduce the scope of #ifdef __NetBSD__ version of the
-m{cpu,tune,arch}=native handling code, and hopefully reduce
future effort by aligning inputs

- share common variables and setup more
- build a linux/arm64 like /proc/cpuinfo Features line and
 use that to match the new 'list of features' per gcc feature,
 based upon our sysctl(2) published info.  complete this list
 for all supported extensions.

now this feature works again.


To generate a diff of this commit:
cvs rdiff -u -r1.6 -r1.7 \
   src/external/gpl3/gcc/dist/gcc/config/aarch64/driver-aarch64.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/sys/arch/arm/sociox

[Jared McNeill]

Great work! One small remark:

+static int
+ave_fdt_match(device_t parent, cfdata_t cf, void *aux)
+{
+   static const char * compatible[] = {
+#ifdef _LP64
+   "socionext,unifier-ld20-ave4",
+#else
+   "socionext,unifier-pro4-ave4",
+   "socionext,unifier-pxs2-ave4",
+   "socionext,unifier-ld11-ave4",
+   "socionext,unifier-pxs3-ave4",
+#endif
+   NULL
+   };

Please do not use #ifdef here. Compatible strings are meant to describe 
which hardware device the driver is compatible with, and can be shared 
across multiple SoCs. In the case of IP licensing, possibly not even in 
the same SoC family! Consider a hypothetical where Socionext could release 
a new 32-bit SoC with an ave(4) that is functionally identical to the one 
found in their previous 64-bit chip.

Re: CVS commit: src/sys/arch/arm/sociox

[Jared McNeill]

Hi --

Is there really a need for all of this fdt stuff for SCA2A11? I would 
expect that the board can be fully supported in ACPI mode.


Thanks,
Jared


On Wed, 18 Mar 2020, Tohru Nishimura wrote:


Module Name:src
Committed By:   nisimura
Date:   Wed Mar 18 08:49:51 UTC 2020

Modified Files:
src/sys/arch/arm/sociox: files.sociox

Log Message:
add SynQuacer EXIU external IRQ unit driver desciption


To generate a diff of this commit:
cvs rdiff -u -r1.6 -r1.7 src/sys/arch/arm/sociox/files.sociox

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/sys/arch/arm/broadcom

[Jared McNeill]

On Nov 27, 2019, at 9:08 PM, Jason R Thorpe wrote:
> 
> + firqh = kmem_alloc(sizeof(*firqh), KM_SLEEP);
> + firqh->ih_irq = firq;
> + firqh->ih_fn = func;
> + firqh->ih_arg = arg;
> + TAILQ_INSERT_TAIL(>intr_handlers, firqh, ih_next);
> +
> + return firqh;

I should have commented the code in gicv3 so that you would have realized it 
was “unnecessarily complicated” for a reason :)

The interrupt_distribute(9) API makes an assumption that the return value of 
anything_intr_establish can be used as input for the MD interrupt_distribute 
implementation. For arm pic, struct intrsource * made most sense. It is a bit 
of a hassle for fdtbus and really shows the need for an MI interrupt API.

So where this breaks things is if you have something in the kernel do:

  Ih = fdtbus_intr_establish(…)
  interrupt_distribute(ih, target, NULL)

Currently the only place where this can happen is arch/arm/fdt/pmu_fdt.c but 
IMHO the code is perfectly valid and could appear in other places in the future.

Re: CVS commit: src/sys/dev/rasops

[Jared McNeill]

On Fri, 26 Jul 2019, Rin Okuyama wrote:


Also, convert loop of byte-wise copy into memset.


I am a bit concerned about this change because IIRC there are platforms 
where memset etc. cannot be used on device memory.

Re: CVS commit: src

[Jared McNeill]

It is not using firmload(9) though, it is a userland implementation of a 
similar API that I wrote specifically for this purpose:


https://nxr.netbsd.org/xref/src/usr.sbin/btattach/firmload.c

Cheers,
Jared


On Tue, 23 Jul 2019, Thomas Klausner wrote:


Hi Jared!

Yes, I saw that. But it's using firmload() as well to load it.

I moved this firmware because it was the only one remaining in that
directory.

I can put it back, if people think that's preferable, or someone else
can revert, I don't mind.

Cheers,
Thomas

P.S.: The file is 44k, so I'm not convinced by the "/ is small"
argument. ;)

On Tue, Jul 23, 2019 at 12:25:16PM -0300, Jared McNeill wrote:

Hi Thomas --

The bcm43xx firmware is different from other firmware images because it is
not loaded by the kernel directly. The tool that loads this image lives in
/usr/sbin, so /usr/libdata/firmware seemed more appropriate. The path
already existed in the list of firmware search paths (sysctl
hw.firmware.path) long before these files were added.

Cheers,
Jared


On Mon, 22 Jul 2019, Thomas Klausner wrote:


Module Name:src
Committed By:   wiz
Date:   Mon Jul 22 14:47:51 UTC 2019

Modified Files:
src/distrib/sets/lists/base: mi
src/etc/mtree: NetBSD.dist.base
src/external/broadcom/bcm43xx: Makefile

Log Message:
Move bcm43xx to /libdata/firmware, where all the other firmwares live.

Deprecate /usr/libdata/firmware.


To generate a diff of this commit:
cvs rdiff -u -r1.1207 -r1.1208 src/distrib/sets/lists/base/mi
cvs rdiff -u -r1.198 -r1.199 src/etc/mtree/NetBSD.dist.base
cvs rdiff -u -r1.3 -r1.4 src/external/broadcom/bcm43xx/Makefile

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src

[Jared McNeill]

Hi Thomas --

The bcm43xx firmware is different from other firmware images because it is 
not loaded by the kernel directly. The tool that loads this image lives in 
/usr/sbin, so /usr/libdata/firmware seemed more appropriate. The path 
already existed in the list of firmware search paths (sysctl 
hw.firmware.path) long before these files were added.


Cheers,
Jared


On Mon, 22 Jul 2019, Thomas Klausner wrote:


Module Name:src
Committed By:   wiz
Date:   Mon Jul 22 14:47:51 UTC 2019

Modified Files:
src/distrib/sets/lists/base: mi
src/etc/mtree: NetBSD.dist.base
src/external/broadcom/bcm43xx: Makefile

Log Message:
Move bcm43xx to /libdata/firmware, where all the other firmwares live.

Deprecate /usr/libdata/firmware.


To generate a diff of this commit:
cvs rdiff -u -r1.1207 -r1.1208 src/distrib/sets/lists/base/mi
cvs rdiff -u -r1.198 -r1.199 src/etc/mtree/NetBSD.dist.base
cvs rdiff -u -r1.3 -r1.4 src/external/broadcom/bcm43xx/Makefile

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: audio2

[Jared McNeill]

You are correct, my mistake!

On Tue, 21 May 2019, Tetsuya Isaki wrote:


At Thu, 9 May 2019 10:28:19 -0300 (ADT),
Jared McNeill wrote:

With order of operations here, and track->volume being in range 0...256, I
don't think this will work anyway. volume of 255 of less will cause the
sample to be 0, and 256 the original value.


(A * B >> C) is equivalent to ((A * B) >> C).
(A * B / C)  is equivalent to ((A * B) / C).
And in fact it worked.

# I'm sorry if I misread your text.

Thanks,
---
Tetsuya Isaki 


5234:#if defined(AUDIO_USE_C_IMPLEMENTATION_DEFINED_BEHAVIOR) && 
defined(__GNUC__)
5235-   *d++ += ((aint2_t)*s++) * track->volume >> 8;
5236-#else
5237-   *d++ += ((aint2_t)*s++) * track->volume / 256;
5238-#endif

Re: audio2

[Jared McNeill]

With order of operations here, and track->volume being in range 0...256, I 
don't think this will work anyway. volume of 255 of less will cause the 
sample to be 0, and 256 the original value.


On Wed, 8 May 2019, m...@netbsd.org wrote:


Is there some scenario where this made a difference?
it sounds like an optimization that a compiler should already do

5234:#if defined(AUDIO_USE_C_IMPLEMENTATION_DEFINED_BEHAVIOR) && 
defined(__GNUC__)
5235-   *d++ += ((aint2_t)*s++) * track->volume >> 8;
5236-#else
5237-   *d++ += ((aint2_t)*s++) * track->volume / 256;
5238-#endif

Re: CVS commit: src/sys/arch/evbarm/conf

[Jared McNeill]

Because we are using image type "kernel_noload" instead of "kernel" for 
GENERIC. The header on "kernel" type images contains a load address, and 
U-Boot will uncompress the kernel there. For "kernel_noload" type images 
there is no load address specified, with the expectation that the kernel 
will be executed in place.


It's probably not very hard to fix U-Boot to handle this case..


On Thu, 14 Mar 2019, Manuel Bouyer wrote:


On Thu, Mar 14, 2019 at 10:22:43AM +, Jared D. McNeill wrote:

Module Name:src
Committed By:   jmcneill
Date:   Thu Mar 14 10:22:43 UTC 2019

Modified Files:
src/sys/arch/evbarm/conf: mk.generic

Log Message:
U-Boot fails to boot a compressed kernel_noload image, so stop emitting
them.


Any idea why it doesn't work any more ?

--
Manuel Bouyer 
NetBSD: 26 ans d'experience feront toujours la difference
--

Re: Amazon EC2 setup

[Jared McNeill]

On Sat, 1 Dec 2018, Martin Husemann wrote:


Would it be possible (grep in dmesg, check sysctl, whatever?) to verify
we are running on an EC2?

And if not, require some explicit rc.conf entry to force this (e.g. for
testing puroses), but in usual setups default this script to off?


Exactly what this commit does.. ec2_init is only set to YES if an ena(4) 
device is attached.

Re: Amazon EC2 setup

[Jared McNeill]

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html

On Sat, 1 Dec 2018, m...@netbsd.org wrote:


This feels all kinds of insecure, is that the official way to do it?


Index: src/distrib/utils/embedded/files/ec2_init
diff -u /dev/null src/distrib/utils/embedded/files/ec2_init:1.1
--- /dev/null   Fri Nov 30 20:53:02 2018
+++ src/distrib/utils/embedded/files/ec2_init   Fri Nov 30 20:53:02 2018
@@ -0,0 +1,52 @@
+#!/bin/sh
+#
+# $NetBSD: ec2_init,v 1.1 2018/11/30 20:53:02 jmcneill Exp $
+#
+# PROVIDE: ec2_init
+# REQUIRE: NETWORKING
+# BEFORE:  LOGIN
+
+$_rc_subr_loaded . /etc/rc.subr
+
+name="ec2_init"
+rcvar=${name}
+start_cmd="ec2_init"
+stop_cmd=":"
+
+METADATA_URL="http://169.254.169.254/latest/meta-data/;
+SSH_KEY_URL="public-keys/0/openssh-key"
+HOSTNAME_URL="hostname"
+
+SSH_KEY_FILE="/root/.ssh/authorized_keys"
+
+ec2_init()
+{
+   (
+   umask 022
+   # fetch the key pair from Amazon Web Services
+   EC2_SSH_KEY=$(ftp -o - "${METADATA_URL}${SSH_KEY_URL}")
+
+   if [ -n "$EC2_SSH_KEY" ]; then
+   # A key pair is associated with this instance, add it
+   # to root 'authorized_keys' file
+   mkdir -p $(dirname "$SSH_KEY_FILE")
+   touch "$SSH_KEY_FILE"
+   cd $(dirname "$SSH_KEY_FILE")
+
+   grep -q "$EC2_SSH_KEY" "$SSH_KEY_FILE"
+   if [ $? -ne 0 ]; then
+   echo "Setting EC2 SSH key pair: ${EC2_SSH_KEY##* }"
+   echo "$EC2_SSH_KEY" >> "$SSH_KEY_FILE"
+   fi
+   fi
+
+   # set hostname
+   HOSTNAME=$(ftp -o - "${METADATA_URL}${HOSTNAME_URL}")
+   echo "Setting EC2 hostname: ${HOSTNAME}"
+   echo "$HOSTNAME" > /etc/myname
+   hostname "$HOSTNAME"
+   )
+}
+
+load_rc_config $name
+run_rc_command "$1"

Re: CVS commit: src/distrib/utils/embedded

[Jared McNeill]

On Thu, 22 Nov 2018, Aymeric Vincent wrote:


src/distrib/utils/embedded/files: armv7_boot.cmd


You shouldn't set fdtfile in this script because U-Boot already sets it. 

From socfpga_de0_nano_soc_defconfig:


CONFIG_DEFAULT_FDT_FILE="socfpga_cyclone5_de0_nano_soc.dtb"

This way, if you match on the SoC type in this file, you can run on any 
board using this SoC as long as you have a dtb for it. We shouldn't have 
to update the boot script to add new boards.

Re: CVS commit: src/sys/arch/arm/broadcom

[Jared McNeill]

On Sat, 20 Oct 2018, Ryo Shimizu wrote:


I think the dts should be fixed rather than #ifdef __arm__


I agree that we need to change dts to eliminate 32bit enable method from
the dtb for 64bit. However, it is also strange that enable-method code
for 32bit ARM remains in the 64bit binary as well.


I don't think the dts should be changed. This lets use share a dtb between 
32- and 64-bit kernels. The brcm,bcm2836-smp enable-method is documented 
as being supported only in 32-bit mode:


https://www.kernel.org/doc/Documentation/devicetree/bindings/arm/cpus.txt

Re: CVS commit: src/sys/dev/acpi

[Jared McNeill]

Hi Jaromir --

This change breaks the build of the one kernel that includes this code 
(evbarm GENERIC64) as intr_establish_xname is not an MI API.


Cheers,
Jared


On Mon, 15 Oct 2018, Jaromir Dolecek wrote:


Module Name:src
Committed By:   jdolecek
Date:   Mon Oct 15 06:58:08 UTC 2018

Modified Files:
src/sys/dev/acpi: ahcisata_acpi.c

Log Message:
use intr_establish_xname()


To generate a diff of this commit:
cvs rdiff -u -r1.1 -r1.2 src/sys/dev/acpi/ahcisata_acpi.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/sys/arch

[Jared McNeill]

On Wed, 19 Sep 2018, Aymeric Vincent wrote:


Module Name:src
Committed By:   aymeric
Date:   Wed Sep 19 17:31:39 UTC 2018

Added Files:
src/sys/arch/arm/altera: cycv_clkmgr.c cycv_dwcmmc.c cycv_gmac.c
cycv_intr.h cycv_platform.c cycv_reg.h cycv_rstmgr.c cycv_var.h
files.altera
src/sys/arch/arm/dts: socfpga_cyclone5_de0_sockit.dts
src/sys/arch/evbarm/altera: altera_start.S genassym.cf platform.h
src/sys/arch/evbarm/conf: NANOSOC files.altera mk.altera std.altera

Log Message:
Add support for the DE0 NanoSoC board.


Very cool!

Any chance that you could use sys/dev/fdt/dwcmmc_fdt.c instead of the new 
cycv_dwcmmc.c? It should be fairly generic.


Cheers,
Jared

Re: CVS commit: src/sys/arch/evbarm/conf

[Jared McNeill]

On Sun, 19 Aug 2018, Rin Okuyama wrote:


On 2018/08/18 22:41, Jared McNeill wrote:
Not sure I understand this change. arm32 should be defined on 32-bit evbarm 
platforms via std.evbarm.


If arm32 is not defined, I wouldn't expect a kernel to link as there are 
dependencies on it in arch/arm/conf/files.arm as well.


No "arm32" is not defined.

arch/arm/conf/files.arm is included because of "machine evbarm arm" lines in
std.* files for 32bit machines. On the other hand, for 64bit machines,


Thanks, I understand the issue now.

Re: CVS commit: src/sys/arch/evbarm/conf

[Jared McNeill]

Not sure I understand this change. arm32 should be defined on 32-bit 
evbarm platforms via std.evbarm.


If arm32 is not defined, I wouldn't expect a kernel to link as there are 
dependencies on it in arch/arm/conf/files.arm as well.




On Sat, 18 Aug 2018, Rin Okuyama wrote:


Module Name:src
Committed By:   rin
Date:   Sat Aug 18 09:29:45 UTC 2018

Modified Files:
src/sys/arch/evbarm/conf: files.evbarm

Log Message:
Fix a bug introduced in the previous revision;
We don't define arm32 anywhere, and majors.aarch64 is used unconditionally.


To generate a diff of this commit:
cvs rdiff -u -r1.30 -r1.31 src/sys/arch/evbarm/conf/files.evbarm

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/sys/dev/fdt

[Jared McNeill]

> On Jun 20, 2018, at 4:25 PM, Jason Thorpe  wrote:
> 
>> On Jun 20, 2018, at 9:56 AM, Jared McNeill  wrote:
>> 
>> On Wed, 20 Jun 2018, Jason Thorpe wrote:
>> 
>>> ofctl(8) is pretty useless for this purpose because it doesn't show you 
>>> which driver instance has attached to a given device tree node.  As for 
>>> passing generic boot args, it's not obvious how one does that on the RPI 
>>> (and I don't even see the hook that processes the generic boot args 
>>> bcm283x_platform).
>> 
>> https://www.raspberrypi.org/documentation/configuration/cmdline-txt.md
> 
> Sure, but where is the code for the brcm2835 platform that *processes* it?  I 
> see stuff for parsing console / fb options, but not for standard boot flags.

Firmware puts the string in /chosen/bootargs and we pick it up here: 
https://nxr.netbsd.org/xref/src/sys/arch/evbarm/fdt/fdt_machdep.c#378 
<https://nxr.netbsd.org/xref/src/sys/arch/evbarm/fdt/fdt_machdep.c#378>

The standard args are then processed here: 
https://nxr.netbsd.org/xref/src/sys/arch/evbarm/fdt/fdt_machdep.c#491 
<https://nxr.netbsd.org/xref/src/sys/arch/evbarm/fdt/fdt_machdep.c#491>

Re: CVS commit: src/sys/dev/fdt

[Jared McNeill]

On Wed, 20 Jun 2018, Jason Thorpe wrote:


ofctl(8) is pretty useless for this purpose because it doesn't show you which 
driver instance has attached to a given device tree node.  As for passing 
generic boot args, it's not obvious how one does that on the RPI (and I don't 
even see the hook that processes the generic boot args bcm283x_platform).


https://www.raspberrypi.org/documentation/configuration/cmdline-txt.md

Re: CVS commit: src/sys/dev/fdt

[Jared McNeill]

Not a fan of this, some of these paths can get fairly long (boot the 
VEXPRESS_A15 kernel to see for yourself) and the path is 
only really useful if you are debugging something.


If you want to see the debugging information we already have a way to 
do that with boot -x. You can also inspect the whole tree at runtime with 
ofctl(8).



On Wed, 20 Jun 2018, Jason R Thorpe wrote:


Module Name:src
Committed By:   thorpej
Date:   Wed Jun 20 05:59:18 UTC 2018

Modified Files:
src/sys/dev/fdt: fdtbus.c

Log Message:
In fdtbus_print(), aprint_normal the path to the device (rather than
aprint_debug).  This info is every bit as useful as, say, PCI device
locations.


To generate a diff of this commit:
cvs rdiff -u -r1.17 -r1.18 src/sys/dev/fdt/fdtbus.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/usr.sbin/ofctl

[Jared McNeill]

The -l flag dumps a partial tree starting with the node specified by 
'file'. The format of the output is the same as when you run ofctl with no 
arguments (this dumps the full tree, equivalent of 'ofctl -l /').


It looks like -r and -w will tell ofctl to read from or write to an 
externalized proplib file instead of using the openfirm ioctl interface.


On Sat, 26 May 2018, Thomas Klausner wrote:


Thank you!

Do you know what the -l, -r, and -w options do? Those are missing from the man 
page.

Cheers,
Thomas

On Sat, May 26, 2018 at 10:21:41AM +, Jared D. McNeill wrote:

Module Name:src
Committed By:   jmcneill
Date:   Sat May 26 10:21:41 UTC 2018

Modified Files:
src/usr.sbin/ofctl: ofctl.8 ofctl.c

Log Message:
Add -v flag which prints the full path of each device node when dumping
the full tree.


To generate a diff of this commit:
cvs rdiff -u -r1.4 -r1.5 src/usr.sbin/ofctl/ofctl.8
cvs rdiff -u -r1.12 -r1.13 src/usr.sbin/ofctl/ofctl.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.




Modified files:

Index: src/usr.sbin/ofctl/ofctl.8
diff -u src/usr.sbin/ofctl/ofctl.8:1.4 src/usr.sbin/ofctl/ofctl.8:1.5
--- src/usr.sbin/ofctl/ofctl.8:1.4  Thu Sep 25 22:44:51 2008
+++ src/usr.sbin/ofctl/ofctl.8  Sat May 26 10:21:41 2018
@@ -1,4 +1,4 @@
-.\"   $NetBSD: ofctl.8,v 1.4 2008/09/25 22:44:51 reed Exp $
+.\"   $NetBSD: ofctl.8,v 1.5 2018/05/26 10:21:41 jmcneill Exp $
 .\"
 .\" Copyright (c) 2006 The NetBSD Foundation, Inc.
 .\" All rights reserved.
@@ -27,7 +27,7 @@
 .\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 .\" POSSIBILITY OF SUCH DAMAGE.
 .\"
-.Dd September 29, 2006
+.Dd May 26, 2018
 .Dt OFCTL 8
 .Os
 .Sh NAME
@@ -36,6 +36,7 @@
 .Sh SYNOPSIS
 .Nm
 .Op Fl p
+.Op Fl v
 .Op Fl f Ar file
 .Op Ar node
 .Sh DESCRIPTION
@@ -66,6 +67,8 @@ instead of the default
 .Pa /dev/openfirm .
 .It Fl p
 Display each node's properties.
+.It Fl v
+Display the full path name for each node.
 .El
 .Sh FILES
 .Bl -tag -width "/dev/openprom "

Index: src/usr.sbin/ofctl/ofctl.c
diff -u src/usr.sbin/ofctl/ofctl.c:1.12 src/usr.sbin/ofctl/ofctl.c:1.13
--- src/usr.sbin/ofctl/ofctl.c:1.12 Wed Dec 23 13:42:24 2015
+++ src/usr.sbin/ofctl/ofctl.c  Sat May 26 10:21:41 2018
@@ -1,4 +1,4 @@
-/* $NetBSD: ofctl.c,v 1.12 2015/12/23 13:42:24 jmcneill Exp $  */
+/* $NetBSD: ofctl.c,v 1.13 2018/05/26 10:21:41 jmcneill Exp $  */

 /*-
  * Copyright (c) 2006, 2007 The NetBSD Foundation, Inc.
@@ -34,7 +34,7 @@
 #ifndef lint
 __COPYRIGHT("@(#) Copyright (c) 2006, 2007\
  The NetBSD Foundation, Inc.  All rights reserved.");
-__RCSID("$NetBSD: ofctl.c,v 1.12 2015/12/23 13:42:24 jmcneill Exp $");
+__RCSID("$NetBSD: ofctl.c,v 1.13 2018/05/26 10:21:41 jmcneill Exp $");
 #endif /* not lint */

 #include 
@@ -62,6 +62,7 @@ static int isstrprint(const char *, size

 static int lflag;
 static int pflag;
+static int vflag;

 struct of_node {
TAILQ_ENTRY(of_node) of_sibling;
@@ -500,10 +501,11 @@ main(int argc, char **argv)
const char *propfilein = NULL;
const char *propfileout = NULL;

-   while ((c = getopt(argc, argv, "f:lpr:w:")) != EOF) {
+   while ((c = getopt(argc, argv, "f:lpr:vw:")) != EOF) {
switch (c) {
case 'l': lflag++; break;
case 'p': pflag++; break;
+   case 'v': vflag++; break;
case 'f': file = optarg; break;
case 'r': propfilein = optarg; break;
case 'w': propfileout = optarg; break;
@@ -511,7 +513,7 @@ main(int argc, char **argv)
}
}
if (errflag)
-   errx(1, "usage: ofctl [-pl] [-f file] [-r propfile] [-w propfile] 
[node...]");
+   errx(1, "usage: ofctl [-plv] [-f file] [-r propfile] [-w propfile] 
[node...]");

if (propfilein != NULL) {
of_proplib = prop_dictionary_internalize_from_file(propfilein);
@@ -694,7 +696,7 @@ oflist(int node, const char *parent_devi
int len;
while (node != 0) {
int child;
-   if (pflag == 0) {
+   if (pflag == 0 && vflag == 0) {
len = ofname(node, of_buf, of_buflen-1);
printf("%08x: %*s%s", node, depth * 2, "",
(char *) of_buf);

Re: CVS commit: src

[Jared McNeill]

Where did you get the compat strings used in tsllux_compats? Linux uses 
"amstaos" as vendor prefix, and always exact chip IDs (never anything like 
tsl256x).



On Sun, 27 May 2018, Jason R Thorpe wrote:


Module Name:src
Committed By:   thorpej
Date:   Sun May 27 05:31:20 UTC 2018

Modified Files:
src/distrib/sets/lists/man: mi
src/share/man/man4: Makefile
src/sys/dev/i2c: files.i2c
Added Files:
src/share/man/man4: tsllux.4
src/sys/dev/i2c: tsl256x.c tsl256xreg.h

Log Message:
Add a driver for the Taos TSL256x light sensors.


To generate a diff of this commit:
cvs rdiff -u -r1.1589 -r1.1590 src/distrib/sets/lists/man/mi
cvs rdiff -u -r1.654 -r1.655 src/share/man/man4/Makefile
cvs rdiff -u -r0 -r1.1 src/share/man/man4/tsllux.4
cvs rdiff -u -r1.91 -r1.92 src/sys/dev/i2c/files.i2c
cvs rdiff -u -r0 -r1.1 src/sys/dev/i2c/tsl256x.c src/sys/dev/i2c/tsl256xreg.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/external

[Jared McNeill]

On Sun, 8 Apr 2018, m...@netbsd.org wrote:


Can we talk to someone with legal expertise before importing code under
this license?


Thank you for your concern. This change was discussed with and approved by 
board.

Re: CVS commit: src/sys/arch/arm/sunxi

[Jared McNeill]

Hi Manuel --

On Tue, 3 Apr 2018, Manuel Bouyer wrote:


Log Message:
external interrupt functions are named "eint" in the sunxi_gpio_pins[]
arrays, while sunxi_gpio_establish() looks for "eint".
Rename eint to eint in sunxi_gpio_pins[]. Tested with an external interrupt
on PH0 on an A20.


I checked the Linux driver this morning as this was never (afaik) clearly 
defined in the binding docs. Linux uses the name "irq" for these pins -- 
we should do the same to be compatible with upstream dts files.


Cheers,
Jared

Re: CVS commit: [matt-nb8-mediatek] src/sys/arch/evbarm/mediatek

[Jared McNeill]

On Wed, 13 Dec 2017, Matt Thomas wrote:

+* Set up a preliminary mapping in the MMU to allow us to run
+* at KERNEL_BASE with caches on.


For FDT you need to add an extra entry for the DTB as the blob passed 
down from U-Boot is not guaranteed to live within the region covered by 
INIT_MEMSIZE.

Re: CVS commit: src/sbin/mount_qemufwcfg

[Jared McNeill]

The addition of a default case to the getopt loop means refuse will not 
have a chance to process built-in options.



On Sat, 25 Nov 2017, Christos Zoulas wrote:


Module Name:src
Committed By:   christos
Date:   Sun Nov 26 03:06:24 UTC 2017

Modified Files:
src/sbin/mount_qemufwcfg: Makefile fwcfg.c virtdir.c virtdir.h
Removed Files:
src/sbin/mount_qemufwcfg: defs.h

Log Message:
cleanup, knf, remove debugging printf, homebrew alloc macros, types.


To generate a diff of this commit:
cvs rdiff -u -r1.1 -r1.2 src/sbin/mount_qemufwcfg/Makefile \
   src/sbin/mount_qemufwcfg/fwcfg.c src/sbin/mount_qemufwcfg/virtdir.c \
   src/sbin/mount_qemufwcfg/virtdir.h
cvs rdiff -u -r1.1 -r0 src/sbin/mount_qemufwcfg/defs.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/sys/dev/sdmmc

[Jared McNeill]

On Wed, 8 Nov 2017, Pierre Pronchery wrote:


Sorry, I could not guess that, and I currently do not have reliable
Internet at home so I often have to work on this offline. I got this
part to build, thought this was a net positive and decided to commit it
so it can benefit others too.

You are much better and faster than me at working on this, I am
interested in this area but feel free to go ahead and commit what you
have if you can improve it or get it to work.


Your patch was more or less the same as mine :) I was waiting for the 
author of the original author to get it working on OpenBSD -- there's a 
non-trivial amount of work that needs to be done. The current bwfm sdio 
code doesn't do much more than read a device ID and then print a TODO 
message. It was enough for me to work out some kinks in our sdmmc stack, 
but it's quite a ways away from being ready to use.

Re: CVS commit: src/sys/dev/sdmmc

[Jared McNeill]

Could have saved yourself a lot of time if you had emailed me first, I've 
been sitting on this code since I ported bwfm but didn't commit it as the 
original code doesn't actually work. Do you plan on finishing it?



On Tue, 7 Nov 2017, Pierre Pronchery wrote:


Module Name:src
Committed By:   khorben
Date:   Tue Nov  7 16:30:32 UTC 2017

Modified Files:
src/sys/dev/sdmmc: files.sdmmc
Added Files:
src/sys/dev/sdmmc: if_bwfm_sdio.c

Log Message:
Add driver for Broadcom 802.11a/b/g/n/ac SDIO wireless devices, based on
the OpenBSD bwfm(4) driver.

I could not test this on any hardware yet, as it does not attach as-is on
my Raspberry PI 3.


To generate a diff of this commit:
cvs rdiff -u -r1.4 -r1.5 src/sys/dev/sdmmc/files.sdmmc
cvs rdiff -u -r0 -r1.1 src/sys/dev/sdmmc/if_bwfm_sdio.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/sys

[Jared McNeill]

On Fri, 27 Oct 2017, Utkarsh Anand wrote:


Module Name:src
Committed By:   utkarsh009
Date:   Fri Oct 27 09:59:17 UTC 2017

Modified Files:
src/sys/arch/x86/x86: intr.c
src/sys/ddb: db_interface.h db_panic.c
src/sys/kern: init_main.c subr_autoconf.c subr_disk.c subr_prf.c
vfs_subr.c vfs_wapbl.c
src/sys/sys: systm.h
src/sys/ufs/ufs: ufs_lookup.c

Log Message:
[syzkaller] Attempted fix for https://github.com/google/syzkaller/issues/399

syzkaller was failing to extract constants because of the above mentioned issue 
so I had to redeclare printf in sys/sys/systm.h
For more information on syzkaller, visit: https://github.com/google/syzkaller


Don't forget to update the printf(9) man page!

Re: CVS commit: src/etc/mtree

[Jared McNeill]

On Sat, 21 Oct 2017, Robert Elz wrote:


Log Message:
Create directory for new bwfm firmware to be installed into.


Thank you!

Re: CVS commit: src/sys/arch/amd64/conf

[Jared McNeill]

On Fri, 20 Oct 2017, Manuel Bouyer wrote:


Any reason to not add it to other arches (especially i386) too ?


I wasn't sure it would work everywhere because there are structures used 
to talk to the firmware that are defined (by both the bwfm driver and the 
firmware) w/o __packed.


Are you able to test i386?

Re: CVS commit: src/sys/dev/i2c

[Jared McNeill]

On Tue, 29 Aug 2017, Manuel Bouyer wrote:


But it depends on the order in which the devices are probed/attached,
isn't it ?


The MD FDT code hooks up the powerdown handler very early, in initarm:

https://nxr.netbsd.org/xref/src/sys/arch/evbarm/fdt/fdt_machdep.c#392

Re: CVS commit: src/sys/dev/i2c

[Jared McNeill]

On Tue, 29 Aug 2017, Manuel Bouyer wrote:


I'd like to have a way to disable this (a compile-time option would be OK
for me).

On evaluation boards (like cubieboard, or olimex lime2), you may have
a power button on the board itself but you don't have a way to add an external
power button (e.g. if you put the board in a case), so once powered off
you have to power-cycle it.


I'm not opposed to having a compile time option or sysctl -- but if we do 
I think we should try to make it MI. In theory an ACPI capable x86 board 
could have this problem as well..


For axp specifically I think the right place to put it would be as a 
properly for the PMIC node in the device tree to disable poweroff. This 
way we can set it on a per-board basis. I didn't see one in the current 
binding docs, so we'd want to coordinate with the linux-sunxi folks on that.



For a personnal project (for those curious, available at
https://github.com/mbouyer/marine_chartplotter) I embeeded a olimex lime2
in a case, along with a power/interface board. I did develop a driver for
the external power controller, and in such a case I don't want the
power hook of the axp20x to be called. I don't think this use case is
uncommon ...


Looking at your driver:

https://github.com/mbouyer/marine_chartplotter/blob/master/software/NetBSD/driver/picbmc.c#L137

By taking over cpu_powerdown_address this will bypass the FDT hooks, so 
you should be ok here.


Cheers,
Jared

Re: CVS commit: [netbsd-7] src

[Jared McNeill]

On Sun, 6 Aug 2017, sc dying wrote:


Does rpi_machdep.c forget to set property "disable"
in rpi_device_register?


Looks like I missed that one, thanks for spotting it. I'll prepare a patch 
for pullup.


Cheers,
Jared

Re: CVS commit: src/sys/dev/sdmmc

[Jared McNeill]

Thank you, I will see if I can make some progress in this area. One of my 
sunxi boards has DDR52-capable eMMC.


On Mon, 17 Jul 2017, Kimihiro Nonaka wrote:


I remember that it was not working yet.

2017-07-17 3:36 GMT+09:00 Jared McNeill <jmcne...@invisible.ca>:

Does the DDR52 code work? I don't see sdhc setting SMC_CAPS_MMC_DDR52
anywhere..



On Fri, 17 Feb 2017, NONAKA Kimihiro wrote:


Module Name:src
Committed By:   nonaka
Date:   Fri Feb 17 10:50:43 UTC 2017

Modified Files:
src/sys/dev/sdmmc: sdhc.c sdmmc_mem.c sdmmcchip.h

Log Message:
sdhc(4), sdmmc(4): Added MMC HS DDR52 support.


To generate a diff of this commit:
cvs rdiff -u -r1.97 -r1.98 src/sys/dev/sdmmc/sdhc.c
cvs rdiff -u -r1.53 -r1.54 src/sys/dev/sdmmc/sdmmc_mem.c
cvs rdiff -u -r1.7 -r1.8 src/sys/dev/sdmmc/sdmmcchip.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/sys/dev/sdmmc

[Jared McNeill]

Does the DDR52 code work? I don't see sdhc setting SMC_CAPS_MMC_DDR52 
anywhere..




On Fri, 17 Feb 2017, NONAKA Kimihiro wrote:


Module Name:src
Committed By:   nonaka
Date:   Fri Feb 17 10:50:43 UTC 2017

Modified Files:
src/sys/dev/sdmmc: sdhc.c sdmmc_mem.c sdmmcchip.h

Log Message:
sdhc(4), sdmmc(4): Added MMC HS DDR52 support.


To generate a diff of this commit:
cvs rdiff -u -r1.97 -r1.98 src/sys/dev/sdmmc/sdhc.c
cvs rdiff -u -r1.53 -r1.54 src/sys/dev/sdmmc/sdmmc_mem.c
cvs rdiff -u -r1.7 -r1.8 src/sys/dev/sdmmc/sdmmcchip.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/sys/arch/arm/include/arm32

[Jared McNeill]

This breaks kernel builds:

/home/jmcneill/netbsd/cvs-src/sys/uvm/pmap/pmap_tlb.c: In function 
'pmap_tlb_update_addr':
/home/jmcneill/netbsd/cvs-src/sys/uvm/pmap/pmap_tlb.c:739:13: error: implicit 
declaration of function 'pte_valid_p' [-Werror=implicit-function-declaration]
  KASSERTMSG(pte_valid_p(pte), "va %#"PRIxVADDR" %#"PRIxPTE,


On Thu, 25 May 2017, Nick Hudson wrote:


Module Name:src
Committed By:   skrll
Date:   Thu May 25 20:42:41 UTC 2017

Modified Files:
src/sys/arch/arm/include/arm32: pmap.h

Log Message:
Use the define name PMAP_HWPAGEWALKER and not PMAP_TLB_HWPAGEWALKER


To generate a diff of this commit:
cvs rdiff -u -r1.146 -r1.147 src/sys/arch/arm/include/arm32/pmap.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/sys/arch

[Jared McNeill]

Typo in awin_reg.h?

-#define AWIN_DEBE_MODCTL_OUT_SEL_LCD   0
+#define AWIN_DEBE_MODCTL_OUT_SEL_LCD0  0
+#define AWIN_DEBE_MODCTL_OUT_SEL_LCD1  0



On Tue, 3 Nov 2015, Manuel Bouyer wrote:


Module Name:src
Committed By:   bouyer
Date:   Tue Nov  3 18:38:03 UTC 2015

Modified Files:
src/sys/arch/arm/allwinner: awin_debe.c awin_reg.h awin_tcon.c
src/sys/arch/evbarm/awin: awin_machdep.c

Log Message:
A debe can't feed both tcon at the same time.
AWIN_DEBE_MODCTL_OUT_SEL will select which tcon instance will get data
(0 for tcon0, 1 for tcon1).
In tcon, AWIN_TCON_CTL_SRC_SEL_DE0 selects the default debe for this
tcon instance: debe0 for tcon0, debe1 for tcon1.
So always connect tcon0 to debe0 and tcon1 to debe1.
now display modes 0, 1 and 2 works; display modes 3 and 4 needs more work.


To generate a diff of this commit:
cvs rdiff -u -r1.17 -r1.18 src/sys/arch/arm/allwinner/awin_debe.c
cvs rdiff -u -r1.81 -r1.82 src/sys/arch/arm/allwinner/awin_reg.h
cvs rdiff -u -r1.6 -r1.7 src/sys/arch/arm/allwinner/awin_tcon.c
cvs rdiff -u -r1.45 -r1.46 src/sys/arch/evbarm/awin/awin_machdep.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/sys/arch

[Jared McNeill]

A31 and A80 use different PMUs. I checked in a fix -- the axp20x specific 
code in awin_machdep.c is now protected by #if NAXP20X > 0.



On Tue, 20 Oct 2015, Jeff Rizzo wrote:


On 10/17/15 8:30 AM, Manuel Bouyer wrote:

Module Name:src
Committed By:   bouyer
Date:   Sat Oct 17 15:30:14 UTC 2015

Modified Files:
src/sys/arch/arm/allwinner: awin_board.c awin_reg.h awin_var.h
src/sys/arch/evbarm/awin: awin_machdep.c
src/sys/arch/evbarm/conf: BPI CUBIEBOARD

Log Message:
Implement CPU frequency switching for A20.
This requires adjusting the CPU voltage, so enable the axp20x driver for
A20 boards.
In evbarm/awin/awin_machdep.c, the DCDC powering up the CPU cores needs to
be defined for each board. The board machine-dependant code (at this time,
only awin_machdep.c) has to provide a awin_set_mpu_volt() function
which calls the right PMU driver to change the CPU core voltage.

The CPU frequency/voltage table in awin_board.c comes from various
sources: linux kernel, device tree and fex scripts, and experiments on
olimex lime2 and cubieboard 2.
The following sysctls are provided (compatible with estd):
machdep.frequency.min,machdep.frequency.max: writable lower and upper
bounds of the useable frequencies. Affects machdep.frequency.available.
Lower bound defaults to 700Mhz, as does linux.
Upper bound defaults to 960Mhz, which is the boot frequency
on the boards I tested. There is a 1008Mhz entry available,
but requires an out of spec CPU voltage (more than 1.4V) so it's
not available by default.
machdep.frequency.available: list of available frequencies. This is
the CPU frequency/voltage table, bound by machdep.frequency.{min,max}.
machdep.frequency.current: current CPU speed. Write a new value to change
   the CPU speed, only values from machdep.frequency.available are
   accepted.





You broke kernel compiles for some of the other allwinner kernels with this 
commit; ALLWINNER_A80, for example:


awin_machdep.o: In function `awin_set_mpu_volt':
awin_machdep.c:(.text+0x870): undefined reference to `axp20x_set_dcdc'

It's not clear to me whether the A80 has the axp20x device, but not having it 
in the kernel config has meant no arm builds for a few days...


Can you fix this, please?

Thanks,
+j

Re: CVS commit: src/sys/dev/gpio

[Jared McNeill]

I should have been more clear in the commit message -- I added the 
dependency on gpiobutton(4), not gpio(4).


On Fri, 16 Oct 2015, Paul Goyette wrote:


Date: Fri, 16 Oct 2015 15:47:43 +0800 (PHT)
From: Paul Goyette 
Reply-To: p...@whooppee.com
To: source-changes-d@NetBSD.org
Cc: Jared D. McNeill 
Subject: Re: CVS commit: src/sys/dev/gpio

Shouldn't we also add a dependency from the gpio module to require the
sysmon_taskq module?


On Thu, 15 Oct 2015, Jared D. McNeill wrote:


Module Name:src
Committed By:   jmcneill
Date:   Thu Oct 15 09:07:49 UTC 2015

Modified Files:
src/sys/dev/gpio: files.gpio

Log Message:
pull in sysmon_taskq


To generate a diff of this commit:
cvs rdiff -u -r1.13 -r1.14 src/sys/dev/gpio/files.gpio

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.




+--+--+-+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:   |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org  |
+--+--+-+

Re: CVS commit: src/sys/arch/arm/allwinner

[Jared McNeill]

Unless you plan on implementing a better fix, I'm going to commit 
something like this (not compile tested) to restore HDMI audio 
functionality for A20 and A31.



Index: awin_debe.c
===
RCS file: /cvsroot/src/sys/arch/arm/allwinner/awin_debe.c,v
retrieving revision 1.15
diff -u -p -r1.15 awin_debe.c
--- awin_debe.c 5 Oct 2015 14:42:19 -   1.15
+++ awin_debe.c 8 Oct 2015 22:16:59 -
@@ -75,6 +75,8 @@ struct awin_debe_softc {
int sc_hot_x, sc_hot_y;
uint8_t sc_cursor_bitmap[8 * AWIN_DEBE_CURMAX];
uint8_t sc_cursor_mask[8 * AWIN_DEBE_CURMAX];
+
+   bool sc_audio_supp;
 };

 #define DEBE_READ(sc, reg) \
@@ -249,7 +251,7 @@ awin_debe_attach(device_t parent, device
 #endif

 #ifdef AWIN_DEBE_FWINIT
-   awin_debe_set_videomode();
+   awin_debe_set_videomode(, false);
awin_debe_enable(true);
 #endif
 }
@@ -472,7 +474,7 @@ awin_debe_enable(bool enable)
 }

 void
-awin_debe_set_videomode(const struct videomode *mode)
+awin_debe_set_videomode(const struct videomode *mode, bool audio_supp)
 {
struct awin_debe_softc *sc;
device_t dev;
@@ -485,6 +487,8 @@ awin_debe_set_videomode(const struct vid
}
sc = device_private(dev);

+   sc->sc_audio_supp = audio_supp;
+
if (mode) {
const u_int interlace_p = !!(mode->flags & VID_INTERLACE);
const u_int width = mode->hdisplay;
@@ -582,7 +586,9 @@ awin_debe_ioctl(device_t self, u_long cm
val &= ~AWIN_DEBE_MODCTL_HWC_EN;
}
DEBE_WRITE(sc, AWIN_DEBE_MODCTL_REG, val);
-   awin_tcon_enable(enable);
+   if (sc->sc_audio_supp == false) {
+   awin_tcon_enable(enable);
+   }
return 0;
case WSDISPLAYIO_GVIDEO:
val = DEBE_READ(sc, AWIN_DEBE_MODCTL_REG);
Index: awin_hdmi.c
===
RCS file: /cvsroot/src/sys/arch/arm/allwinner/awin_hdmi.c,v
retrieving revision 1.16
diff -u -p -r1.16 awin_hdmi.c
--- awin_hdmi.c 25 Jul 2015 15:19:54 -  1.16
+++ awin_hdmi.c 8 Oct 2015 22:16:59 -
@@ -565,7 +565,8 @@ awin_hdmi_read_edid(struct awin_hdmi_sof
awin_tcon_enable(false);
delay(2);

-   awin_debe_set_videomode(mode);
+   awin_debe_set_videomode(mode,
+   display_mode == DISPLAY_MODE_HDMI);
awin_tcon_set_videomode(mode);
awin_hdmi_set_videomode(sc, mode, display_mode);
awin_hdmi_set_audiomode(sc, mode, display_mode);
Index: awin_var.h
===
RCS file: /cvsroot/src/sys/arch/arm/allwinner/awin_var.h,v
retrieving revision 1.35
diff -u -p -r1.35 awin_var.h
--- awin_var.h  20 Apr 2015 01:33:22 -  1.35
+++ awin_var.h  8 Oct 2015 22:16:59 -
@@ -140,7 +140,7 @@ unsigned int awin_tcon_get_clk_div(void)
 bool   awin_tcon_get_clk_dbl(void);
 void   awin_tcon_set_videomode(const struct videomode *);
 void   awin_tcon_enable(bool);
-void   awin_debe_set_videomode(const struct videomode *);
+void   awin_debe_set_videomode(const struct videomode *, bool);
 void   awin_debe_enable(bool);
 intawin_debe_ioctl(device_t, u_long, void *);
 intawin_mp_ioctl(device_t, u_long, void *);

Re: CVS commit: src/sys/arch/arm/allwinner

[Jared McNeill]

On Tue, 6 Oct 2015, Manuel Bouyer wrote:


On Tue, Oct 06, 2015 at 10:06:31AM +1100, matthew green wrote:

And is this really a problem ? turning off video is configurable in the
X server, so if you want audio without video you can turn off the
screensaver ...


it's a problem if you want the screensaver to work when you're not
using the video or audio.  your idea means it is *always* on.


But it is already always on. The scren gets dark, but as the screen is
still getting valid HDMI signals it doens't go to sleep.


There is still value in blanking the screen vs displaying a fixed pattern.

Re: CVS commit: src/sys/arch/arm/allwinner

[Jared McNeill]

On Mon, 5 Oct 2015, Manuel Bouyer wrote:


On Mon, Oct 05, 2015 at 02:13:51PM -0300, Jared McNeill wrote:

Can you see what happens to audio output when the display is turend off in
this way? I have a vague memory of trying something like this before..


Not easily, my display doens't deal with HDMI audio.
It's also possible that the display side stop audio processing when going
to sleep ...


It has been a while, but ISTR the audio clock is derived from the video 
clock. So if you shut off video, you lose audio as well.

Re: CVS commit: src/sys/arch/arm/allwinner

[Jared McNeill]

It's really a problem because of how the audio device behaves when you 
turn the clock off from under it. I don't think changing X server 
configuration is a good solution when we can clearly do better than that 
by adding a bit of logic in the display driver to handle it.



On Mon, 5 Oct 2015, Manuel Bouyer wrote:


On Mon, Oct 05, 2015 at 02:42:00PM -0300, Jared McNeill wrote:

On Mon, 5 Oct 2015, Manuel Bouyer wrote:


On Mon, Oct 05, 2015 at 02:13:51PM -0300, Jared McNeill wrote:

Can you see what happens to audio output when the display is turend off in
this way? I have a vague memory of trying something like this before..


Not easily, my display doens't deal with HDMI audio.
It's also possible that the display side stop audio processing when going
to sleep ...


It has been a while, but ISTR the audio clock is derived from the video
clock. So if you shut off video, you lose audio as well.


And is this really a problem ? turning off video is configurable in the
X server, so if you want audio without video you can turn off the
screensaver ...

--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--

Re: CVS commit: src/sys/arch/arm/allwinner

[Jared McNeill]

Device tree is definitely the way to go (IMHO) but we don't have that 
code today and that's not a small effort. I wrote the fex code at a time 
when there was no other option. So it's there if you want to use it.




On Mon, 5 Oct 2015, Manuel Bouyer wrote:


On Mon, Oct 05, 2015 at 01:28:08PM -0300, Jared McNeill wrote:

On Mon, 5 Oct 2015, Manuel Bouyer wrote:

BTW, I'm looking at this because I need to make the LVDS interface to work
(and turn the display on/off via GPIOs, to save power). Do you have ideas
on how this should work ?
We won't have EDID source in this case; for the omap controller I did
hardcode a video mode in sources, which is quite ugly.


If you pass a compiled version of the fex for your board
(https://github.com/linux-sunxi/sunxi-boards/blob/master/sys_config/a20/a20-olinuxino_lime2.fex),


Yes, I've seen this fex stuff.
But are we sure it's the way to go ?
From http://linux-sunxi.org/Fex_Guide the mainline linux kernel
uses device tree, and from https://linux-sunxi.org/Mainline_U-boot
I guess u-boot is going this way too.
So sunxi and board makers could well drop fex support in the near future ...

--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--

Re: CVS commit: src

[Jared McNeill]

I'm seeing this error on arm now with today's autobuild: 
http://nyftp.netbsd.org/pub/NetBSD-daily/HEAD/201507241030Z/evbarm-earmv7hf/


armv7# pkg_info
assertion pthread__tsd_destructors[key] != NULL failed: file 
/home/source/ab/HEAD/src/lib/libpthread/pthread_tsd.c, line 179, 
function pthread__add_specific

[1]   Abort trap (core dumped) pkg_info
armv7# gdb pkg_info pkg_info.core
assertion pthread__tsd_destructors[key] != NULL failed: file 
/home/source/ab/HEAD/src/lib/libpthread/pthread_tsd.c, line 179, 
function pthread__add_specific

[1]   Abort trap (core dumped) gdb pkg_info pkg_info.core


On Fri, 29 May 2015, J. Hannken-Illjes wrote:


On 29 May 2015, at 16:26, J. Hannken-Illjes hann...@eis.cs.tu-bs.de wrote:


On 29 May 2015, at 09:37, Emmanuel Dreyfus m...@netbsd.org wrote:


Module Name:src
Committed By:   manu
Date:   Fri May 29 07:37:32 UTC 2015

Modified Files:
src/include: limits.h
src/lib/libpthread: pthread.c pthread_int.h pthread_key_create.3
pthread_tsd.c
src/lib/libpthread_dbg: pthread_dbg.c

Log Message:
Make PTHREAD_KEYS_MAX dynamically adjustable

snip

With this change some programs fail with

assertion pthread__tsd_destructors[key] != NULL failed
file src/lib/libpthread/pthread_tsd.c, line 169,
function pthread__add_specific

Machine is amd64, 16 cores, KVM host.  Among others gunzip fails.
Reverting this commit removes the failure.


With christos fix dated Fri May 29 16:05:13 UTC 2015 it works for me.

Thanks,

--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)

Re: CVS commit: src/share/misc

[Jared McNeill]

I don't think wtf handles duplicate entries very well:

apsaras$ cat  test  EOF

TLAthree letter acronym
TLAtrue love always
EOF

apsaras$ wtf -f test TLA
TLA: three letter acronym
true love always


On Mon, 13 Apr 2015, Blue Rats wrote:


Module Name:src
Committed By:   rodent
Date:   Mon Apr 13 00:39:57 UTC 2015

Modified Files:
src/share/misc: acronyms acronyms.comp

Log Message:
Welcome to 2015, acronyms.


To generate a diff of this commit:
cvs rdiff -u -r1.224 -r1.225 src/share/misc/acronyms
cvs rdiff -u -r1.148 -r1.149 src/share/misc/acronyms.comp

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src

[Jared McNeill]

Thank you! Do you plan on requesting a pullup for netbsd-7?


On Sun, 22 Mar 2015, Adrian Steinmann wrote:


Module Name:src
Committed By:   ast
Date:   Sun Mar 22 09:57:42 UTC 2015

Modified Files:
src/distrib/sets/lists/base: mi
src/distrib/sets/lists/man: mi
src/usr.sbin: Makefile
Added Files:
src/usr.sbin/service: Makefile service service.8

Log Message:
Import a substantially modified service(8) command from FreeBSD to
manage rc.d scripts.  This command is well known on most other Unixes
and should help soften the learning curve for Unix admins coming
to NetBSD.


To generate a diff of this commit:
cvs rdiff -u -r1.1097 -r1.1098 src/distrib/sets/lists/base/mi
cvs rdiff -u -r1.1497 -r1.1498 src/distrib/sets/lists/man/mi
cvs rdiff -u -r1.269 -r1.270 src/usr.sbin/Makefile
cvs rdiff -u -r0 -r1.1 src/usr.sbin/service/Makefile \
   src/usr.sbin/service/service src/usr.sbin/service/service.8

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/distrib/utils/embedded/conf

[Jared McNeill]

Thank you for catching this mistake, it should have been appending to 
${mnt}/etc/rc.local. I have checked in a fix.


On Thu, 12 Feb 2015, Takahiro HAYASHI wrote:


On 2015/02/07 00:15, Jared D. McNeill wrote:

Module Name:src
Committed By:   jmcneill
Date:   Fri Feb  6 15:15:02 UTC 2015

Modified Files:
src/distrib/utils/embedded/conf: rpi.conf

Log Message:
By default, RPI firmware sets the max CPU frequency to 600MHz. This can be
overridden by setting arm_freq in config.txt, but the default freq at boot
is still 600MHz.

Add logic to rc.local to compare the current vs. max CPU frequency; if they
differ, set the target frequency to the maximum.



+   cat  /tmp/a  EOF


This overrides /tmp/a if it exists, and surprises original owner.
Is this change intended? AFAICS this file is not used.


regards,
--
t-hash

Re: CVS commit: src/sys/dev/usb

[Jared McNeill]

Fixed commit message:

Add Xbox One controller support. Report descriptor from 
https://github.com/lloeki/xbox_one_controller;


On Sun, 8 Feb 2015, Jared D. McNeill wrote:


Module Name:src
Committed By:   jmcneill
Date:   Sun Feb  8 19:22:45 UTC 2015

Modified Files:
src/sys/dev/usb: uhidev.c uhidev.h
Added Files:
src/sys/dev/usb: x1input_rdesc.h


To generate a diff of this commit:
cvs rdiff -u -r1.61 -r1.62 src/sys/dev/usb/uhidev.c
cvs rdiff -u -r1.15 -r1.16 src/sys/dev/usb/uhidev.h
cvs rdiff -u -r0 -r1.1 src/sys/dev/usb/x1input_rdesc.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

re: CVS commit: src/sys/dev/videomode

[Jared McNeill]

On Mon, 17 Nov 2014, matthew green wrote:


hmm, does this change the module ABI?  ie, kernel version bump time?


I don't think anything in sys/modules uses edidvar.h

Re: CVS commit: src/usr.bin/config

[Jared McNeill]

Are you able to build the arch/evbarm/conf/CUBIEBOARD kernel with these 
changes?


The kernel config has options CPU_CORTEXA7, which depends on 
CPU_CORTEX, which depends on CPU_ARMV7. Neither CPU_CORTEX nor CPU_ARMV7 
are defined in opt_cputypes.h


On Fri, 10 Oct 2014, Masao Uebayashi wrote:


Date: Fri, 10 Oct 2014 10:22:49 +
From: Masao Uebayashi uebayasi-s783fymb3ccdnm+yrof...@public.gmane.org
Reply-To: source-changes-d-qavaossjccednm+yrof...@public.gmane.org
To: source-changes-full-qavaossjccednm+yrof...@public.gmane.org
Newsgroups: gmane.os.netbsd.devel.cvs.full
Followup-To: gmane.os.netbsd.devel.cvs.discuss
Subject: CVS commit: src/usr.bin/config

Module Name:src
Committed By:   uebayasi
Date:   Fri Oct 10 10:22:49 UTC 2014

Modified Files:
src/usr.bin/config: main.c

Log Message:
If an option is selected, select the matching (lowercased) attribute.  Handle
dependencies too.


To generate a diff of this commit:
cvs rdiff -u -r1.60 -r1.61 src/usr.bin/config/main.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/distrib/utils/embedded

[Jared McNeill]

On Fri, 5 Apr 2013, Hisashi T Fujinaka wrote:


On Sat, 6 Apr 2013, Izumi Tsutsui wrote:


If the problem is overflow of the image, shouldn't the extra variable
in each config file be bumped instead of changing a unit?


Sorry for the messy commit. I just changed the -b line the way I did
because I'm not sure where extra comes from and version 1.37 broke every
img that I tried to build.


In such case, asking comitter (or filing PR) would be better.


I did, and heard no objections to my change.


As author of 1.37, just so it's clear that I didn't approve this commit, I 
don't recall being asked about it at all.

Re: CVS commit: src/games/phantasia

[Jared McNeill]

On Sun, 17 Feb 2013, Martin Husemann wrote:

For those happy to never been exposed to this acronym: he is talking about
the Windows User Annoyance Coolaid which campaigns with it's brother VUS
(Keep virtualy all Users Stupid) to make expert users (defined as those
users that grok the concept of a pathname) look like complete idiots.


Let me explain the issue to you, as this is not (directly) about user 
protection, but instead about compat. The UAC executable name check was 
added in Vista, since administrative users don't run every executable with 
admin privileges. In this case, the run as administrator UAC dialog is 
there to help legacy software installers. Under Cygwin (where I'm running 
build.sh), it doesn't guarantee that a GUI is available to present the 
UAC dialog, so legacy executables try to elevate privileges, and fail (no 
GUI!) so permission denied is returned. This behaviour can be overriden by 
supplying a prog.exe.manifest file that specifies the requested 
permissions. Christos fixed this in bsd.hostprog.mk but the two culprits 
in src/games don't use that mechanism (and should probably be fixed to do 
so).

Re: CVS commit: src/games/phantasia

[Jared McNeill]

I've updated the commit message for src/games/phantasia/Makefile r1.36 and 
src/games/adventure/Makefile r1.14 to clarify the issue:


Workaround a toolchain issue by renaming the 'setup' host tool to 'mkdata' 
to make UAC happy when building with Cygwin. As described here --  
http://msdn.microsoft.com/en-us/library/windows/desktop/bb756960.aspx --  
32-bit executables whose filenames include the strings 'install', 'setup', 
'update', 'patch', etc. by default will request admin privileges unless an 
application manifest is provided. 

Re: CVS commit: src

[Jared McNeill]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


It doesn't have to be ELF, I do it now on x86 for splash images. From 
/boot I load a .png, .jpg, or .bmp and add it to the module list but mark 
it as BI_MODULE_IMAGE (instead of BI_MODULE_ELF). I can then grab the blob 
from the kernel -- see arch/x86/x86/x86_machdep.c:module_init_md()


On Wed, 23 Nov 2011, Thor Lancelot Simon wrote:

Can't make one of those without an ELF toolchain, right?  The basic
idea's about right, but I actually need something less sophisticated in its
packaging -- a way to just give the kernel the address of blob-of-stuff
the bootloader's dropped into place for it, so the entropy pool code
can just take it and prime itself.

Thor



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (NetBSD)

iQEcBAEBAgAGBQJOzVH9AAoJEKdMfxFXhnemlIUIALcDsuwTXTJ9LVuPZM+f/i4K
6z25M26KEz42EaqGGWa4iNY4vjS0hBPQFmnJFi9Eud+4RCmh469ClXp4g6yB/fSW
FgFZb5vEGCDto2AmPEyBWkz/g+hbG/+EvWmL12oHCYYh8wVIxN6VRo80LOq5M6Xb
v9nOBjgdiJ7ZuOlw00SK3dHSAoJkWY5/KevAN1UGmTNHfWtiNsgAJDQ5VBoDqNWl
U2J3IhPC9aSIjhavLOp0h4Nn5xnHq2ZxF1yQXdga7cddE8f2ru2vP2mdRFNOR/b3
qibTeQ5BRDS062UiiiLrhUIlOiS0S9vOD+MxCdd5aajvWnQPZK/6j3cH1+9jaZI=
=v/9x
-END PGP SIGNATURE-

Re: CVS commit: src/etc/skel

[Jared McNeill]

Please restore EDITOR=vi, otherwise the following message is going to 
haunt me for the rest of time:


$ svn commit
svn: Commit failed (details follow):
svn: Could not use external editor to fetch log message; consider setting the 
$SVN_EDITOR environment variable or using the --message (-m) or --file (-F) 
options
svn: None of the environment variables SVN_EDITOR, VISUAL or EDITOR are set, 
and no 'editor-cmd' run-time configuration option was found

On Wed, 19 Oct 2011, Izumi Tsutsui wrote:


Module Name:src
Committed By:   tsutsui
Date:   Wed Oct 19 10:14:35 UTC 2011

Modified Files:
src/etc/skel: dot.cshrc dot.profile

Log Message:
Cleanup ancient entries derived from 4.4BSD Lite2 merge
for newer useradd(8) users:
- remove all aliases
- remove annoying EXINIT setting
- comment out other environment settings

Discussed on tech-userlevel@.


To generate a diff of this commit:
cvs rdiff -u -r1.4 -r1.5 src/etc/skel/dot.cshrc
cvs rdiff -u -r1.5 -r1.6 src/etc/skel/dot.profile

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/etc/skel

[Jared McNeill]

This can't please everybody, so please nobody reasoning is why NetBSD 
also ships with twm as default.


EDITOR=vi has been in /etc/skel for 11yrs now, lots of discussion about 
it here: http://gnats.netbsd.org/10985



On Wed, 19 Oct 2011, Greg Troxel wrote:



Jared McNeill jmcne...@invisible.ca writes:


Please restore EDITOR=vi, otherwise the following message is going to
haunt me for the rest of time:

$ svn commit
svn: Commit failed (details follow):
svn: Could not use external editor to fetch log message; consider
setting the $SVN_EDITOR environment variable or using the --message
(-m) or --file (-F) options
svn: None of the environment variables SVN_EDITOR, VISUAL or EDITOR
are set, and no 'editor-cmd' run-time configuration option was found



I thought the historical default was that EDITOR should be ex, and
VISUAL vi.  But again this is preference; others like emacs.  So you're
really asking that the default for all users be set the way you like it,
instead of making your own choices and setting them.  To me this is an
argument for not having these values set in global default files.

Re: CVS commit: src/sys/arch/x86/x86

[Jared McNeill]

I would argue that any manually loaded module shouldn't be autounloaded. 
What do you think about flagging modules as autoloaded and only 
autounloading the autoloaded ones?



On Tue, 18 Oct 2011, Jukka Ruohonen wrote:


On Tue, Oct 18, 2011 at 08:43:46AM +0200, Marc Balmer wrote:

Am 18.10.11 06:27, schrieb Jukka Ruohonen:

On Tue, Oct 18, 2011 at 12:07:45AM +, Jared D. McNeill wrote:

Module Name:src
Committed By:   jmcneill
Date:   Tue Oct 18 00:07:45 UTC 2011

Modified Files:
src/sys/arch/x86/x86: vmt.c

Log Message:
don't allow module autounload


I wonder should autounloading be prohibited for all driver-class modules?


Why?  When the parent goes away, why not autounload a driver?


I am not sure. But have we thought about all the consequences and corner-
cases? Unloading happens while modifying hardware state? Deferred calls
in the drivers? And so on? To me it also seems that if I manually load
a driver-module, I expect it to stay loaded until I unload it.

- Jukka.

Re: CVS commit: src/sys/arch/amd64/conf

[Jared McNeill]

The problem is that i2c.c can be built either because some other driver 
needs i2cbus or because an instance of the iic driver is requested. Only 
in the latter case does CFDRIVER_DECL get added to ioconf.c. I think I'll 
have to split out the driver specific stuff into a separate file to fix this 
properly.


-Original Message- 
From: Marc Balmer
Sent: Monday, October 03, 2011 3:28 AM Newsgroups: 
gmane.os.netbsd.devel.cvs.full

To: source-changes-full-qavaossjccednm+yrof...@public.gmane.org
Subject: CVS commit: src/sys/arch/amd64/conf

Module Name: src
Committed By: mbalmer
Date: Mon Oct  3 07:28:14 UTC 2011

Modified Files:
src/sys/arch/amd64/conf: XEN3_DOM0

Log Message:
Enable an iic(4) device to prevent a linker warning.


To generate a diff of this commit:
cvs rdiff -u -r1.71 -r1.72 src/sys/arch/amd64/conf/XEN3_DOM0

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.







Modified files:

Index: src/sys/arch/amd64/conf/XEN3_DOM0
diff -u src/sys/arch/amd64/conf/XEN3_DOM0:1.71 
src/sys/arch/amd64/conf/XEN3_DOM0:1.72

--- src/sys/arch/amd64/conf/XEN3_DOM0:1.71 Thu Aug 18 20:55:21 2011
+++ src/sys/arch/amd64/conf/XEN3_DOM0 Mon Oct  3 07:28:14 2011
@@ -1,4 +1,4 @@
-# $NetBSD: XEN3_DOM0,v 1.71 2011/08/18 20:55:21 jakllsch Exp $
+# $NetBSD: XEN3_DOM0,v 1.72 2011/10/03 07:28:14 mbalmer Exp $

include arch/amd64/conf/std.xen

@@ -297,7 +297,7 @@ amdtemp* at pchb? # AMD CPU Temperatur

# AMD 768 and 8111 power/ACPI controllers
amdpm* at pci? dev ? function ? # RNG and SMBus 1.0 interface
-#iic* at amdpm? # sensors below are on this bus
+iic* at amdpm? # sensors below are on this bus

# Thermal monitor and fan controller
#dbcool* at iic? addr 0x2C # Unknown other motherboard(s)

Re: CVS commit: src/sys/dev/i2c

[Jared McNeill]

You forgot to make the iic driver detachable, modunload iic will panic I 
think.


-Original Message- 
From: Marc Balmer
Sent: Sunday, October 02, 2011 7:38 AM Newsgroups: 
gmane.os.netbsd.devel.cvs.full

To: source-changes-full-qavaossjccednm+yrof...@public.gmane.org
Subject: CVS commit: src/sys/dev/i2c

Module Name: src
Committed By: mbalmer
Date: Sun Oct  2 11:38:48 UTC 2011

Modified Files:
src/sys/dev/i2c: i2c.c

Log Message:
ii2c can be built as module.


To generate a diff of this commit:
cvs rdiff -u -r1.27 -r1.28 src/sys/dev/i2c/i2c.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.







Modified files:

Index: src/sys/dev/i2c/i2c.c
diff -u src/sys/dev/i2c/i2c.c:1.27 src/sys/dev/i2c/i2c.c:1.28
--- src/sys/dev/i2c/i2c.c:1.27 Tue Aug  2 18:46:35 2011
+++ src/sys/dev/i2c/i2c.c Sun Oct  2 11:38:48 2011
@@ -1,4 +1,4 @@
-/* $NetBSD: i2c.c,v 1.27 2011/08/02 18:46:35 pgoyette Exp $ */
+/* $NetBSD: i2c.c,v 1.28 2011/10/02 11:38:48 mbalmer Exp $ */

/*
 * Copyright (c) 2003 Wasabi Systems, Inc.
@@ -36,7 +36,7 @@
 */

#include sys/cdefs.h
-__KERNEL_RCSID(0, $NetBSD: i2c.c,v 1.27 2011/08/02 18:46:35 pgoyette Exp 
$);
+__KERNEL_RCSID(0, $NetBSD: i2c.c,v 1.28 2011/10/02 11:38:48 mbalmer Exp 
$);


#include sys/param.h
#include sys/systm.h
@@ -47,6 +47,7 @@ __KERNEL_RCSID(0, $NetBSD: i2c.c,v 1.27
#include sys/kthread.h
#include sys/proc.h
#include sys/kernel.h
+#include sys/module.h

#include dev/i2c/i2cvar.h

@@ -116,7 +117,7 @@ iic_search(device_t parent, cfdata_t cf,
 ia.ia_compat = NULL;

 if (config_match(parent, cf, ia)  0) {
- if (ia.ia_addr == (i2c_addr_t)-1)
+ if (ia.ia_addr == (i2c_addr_t)-1)
 config_attach(parent, cf, ia, iic_print);
 else if (ia.ia_addr = I2C_MAX_ADDR 
!sc-sc_devices[ia.ia_addr])
@@ -341,7 +342,7 @@ iic_smbus_intr_establish(i2c_tag_t ic, i
 il = malloc(sizeof(struct ic_intr_list), M_DEVBUF, M_WAITOK);
 if (il == NULL)
 return NULL;
-
+
 il-il_intr = intr;
 il-il_intrarg = intrarg;

@@ -371,7 +372,7 @@ iic_smbus_intr_establish_proc(i2c_tag_t
 il = malloc(sizeof(struct ic_intr_list), M_DEVBUF, M_WAITOK);
 if (il == NULL)
 return NULL;
-
+
 il-il_intr = intr;
 il-il_intrarg = intrarg;

@@ -460,3 +461,37 @@ iic_compat_match(struct i2c_attach_args

CFATTACH_DECL2_NEW(iic, sizeof(struct iic_softc),
iic_match, iic_attach, NULL, NULL, iic_rescan, iic_child_detach);
+
+MODULE(MODULE_CLASS_DRIVER, iic, NULL);
+
+#ifdef _MODULE
+#include ioconf.c
+#endif
+
+static int
+iic_modcmd(modcmd_t cmd, void *opaque)
+{
+ int error;
+
+ error = 0;
+ switch (cmd) {
+ case MODULE_CMD_INIT:
+#ifdef _MODULE
+ error = config_init_component(cfdriver_ioconf_iic,
+ cfattach_ioconf_iic, cfdata_ioconf_iic);
+ if (error)
+ aprint_error(%s: unable to init component\n,
+ iic_cd.cd_name);
+#endif
+ break;
+ case MODULE_CMD_FINI:
+#ifdef _MODULE
+ config_fini_component(cfdriver_ioconf_iic,
+ cfattach_ioconf_iic, cfdata_ioconf_iic);
+#endif
+ break;
+ default:
+ error = ENOTTY;
+ }
+ return error;
+}

Re: CVS commit: src/share/man/man4

[Jared McNeill]

I have ~70 analog channels coming in along with my digital cable service. 
Canada's digital OTA transition deadline is tomorrow but there are still a 
few markets where analog broadcasting will continue, my hometown being one 
of those places. Somewhere in storage I have a VCR with an RF output. I also 
have a bunch of game consoles, cameras, DVD players, etc with baseband video 
outputs (composite and S-Video).


-Original Message- 
From: Simon Burge
Sent: Tuesday, August 30, 2011 7:06 PM Newsgroups: 
gmane.os.netbsd.devel.cvs.discuss

To: Martin Husemann
Cc: source-changes-d@NetBSD.org
Subject: Re: CVS commit: src/share/man/man4

Martin Husemann wrote:


Just curious: are there analog TV feeds out there, anywhere, still?


Some parts of Australia until the end of next year...

Cheers,
Simon. 

Re: CVS commit: src/sys/arch/x86/x86

[Jared McNeill]

On Mon, 8 Aug 2011, Jukka Ruohonen wrote:

We should not really trust ACPI/FADT here. See acpicpu(4) how this is


Why?


derived from the actual CPU information. Additionally, I suggested decreasing
the quality of tsc(9) based on this information a long time ago, but joerg@
had concerns about this.


TSC is considerably faster so definitely preferred, but if it doesn't 
work, it doesn't work.

Re: CVS commit: src/sys/arch/x86/x86

[Jared McNeill]

On Mon, 8 Aug 2011, Jukka Ruohonen wrote:

Why?


Because we (the operating system) know this better than the BIOS writer.
And because this flag is not reliable; numerous systems where tsc(9) is
broken miss this flag in my ACPI table collection, and vice versa.


This flag is new in ACPI v3.0. If the flag is missing, it does not change 
behaviour from what the tsc driver did before. If the flag is present, the 
tsc driver will take the safe approach and prefer the HPET or PM-Timer as 
per ACPI spec. If you're really really really sure you know more about 
the platform than the platform code, you can re-enable TSC timecounter at 
runtime.

Re: CVS commit: src/sys/arch/x86/x86

[Jared McNeill]

On Mon, 8 Aug 2011, Jukka Ruohonen wrote:

Yes, but when possible, we should always prefer actual, reliable, CPU
information instead of the BIOS. Note also that at least with Intel CPUs,
the TSC should be entirely safe with the current stock-NetBSD (i.e. no
automatic CPU power management), but now you've marked it unreliable for
many systems (cf. also [1]).


It's not just Cx states but also MP synchronization (remember TSC is 
per-CPU). There are reports of 'WARNING: negative runtime; monotonic clock 
has gone backwards' messages using TSC on MP systems, which this will fix 
if the flag is set. Newer systems with invariant TSC shouldn't set the 
USE_PLATFORM_CLOCK flag.

Re: CVS commit: src/sys/arch/x86/x86

[Jared McNeill]

On Mon, 8 Aug 2011, Jukka Ruohonen wrote:


On Mon, Aug 08, 2011 at 08:16:43AM -0400, Jared McNeill wrote:

Newer systems with invariant TSC shouldn't set the USE_PLATFORM_CLOCK
flag.


But the do, unfortunately. Again, I have several examples from the field.


I'd be willing to let CPUID.8007H:EDX[8] (invariant TSC flag) override 
the USE_PLATFORM_CLOCK flag, does that work for you?

Re: CVS commit: src/sys/arch/x86/x86

[Jared McNeill]

On Tue, 8 Mar 2011, Michael Lorenz wrote:

Modified Files:
src/sys/arch/x86/x86: x86_autoconf.c


lol

re: CVS commit: src/sys/arch/amd64/conf

[Jared McNeill]

On Mon, 21 Feb 2011, matthew green wrote:

well, i dunno about others but i've found that the old modules
lying around tends to fill up space pretty quickly, but ignoring
that problem and looking at recent i386 builds, i see that the
MONOLITHIC kernel set is only 440kb larger than GENERIC, yet the
modules set is 3500kb.

i didn't look into why, but there's some numbers to go from.


A bunch of those modules are also in GENERIC, what you're seeing is a lot 
of duplication.