daily CVS update output
Updating src tree: P src/bin/sh/mkinit.sh P src/bin/sh/trap.c P src/doc/CHANGES P src/sbin/atactl/atactl.8 P src/sbin/atactl/atactl.c P src/share/man/man7/sysctl.7 P src/share/misc/acronyms.comp P src/sys/arch/aarch64/conf/files.aarch64 P src/sys/arch/amiga/amiga/machdep.c P src/sys/arch/arm/acpi/cpu_acpi.c P src/sys/arch/arm/conf/files.arm P src/sys/arch/arm/fdt/files.fdt P src/sys/dev/mm.c P src/sys/dev/pci/mpii.c P src/sys/dev/rasops/rasops4.c P src/sys/dev/wscons/wsemul_vt100_subr.c P src/sys/kern/init_sysctl.c P src/sys/kern/kern_proc.c P src/sys/miscfs/procfs/procfs_linux.c P src/sys/rump/librump/rumpkern/emul.c P src/sys/sys/param.h P src/sys/sys/proc.h P src/sys/sys/sysctl.h P src/usr.bin/vmstat/vmstat.1 Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 52439135 Dec 6 03:03 ls-lRA.gz
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
On 2018/12/06 0:22, David Brownlee wrote: On Sat, 1 Dec 2018 at 01:27, SAITOH Masanobu wrote: Committed. Hi - is this worth pulling up into netbsd-8? Of course yes! I ran a quick test and my T420s suspends/resumes fine with a netbsd-8 kernel and no X11 running. x11 looks to have issues which seem resolved in current, but it feels like a worthwhile fix to have in -8. It needed two other small changes pulled up (git hashes from https://github.com/NetBSD/src) # 5fca1fb34425590e514f0d745f936998fded9c18 PCIE_HAS_LINKREGS # 3fe2d92356e154aef689fc05111ac422c89c0785 PCIE_HAS_ROOTREGS The above two changes were pulled up two days ago. # 2e6fa7a8bbdd4df652e4cfb605385ff915176cbe suspend/resume I'll send the pullup request today. Sample kernel at http://ftp.netbsd.org/pub/NetBSD/misc/abs/netbsd-8-amd64-pci-resume/netbsd.gz if anyone wants to give it a quick go. (Many thanks again to msaitoh@ for all the work in analysing and You're welcome and thank you. If your didn't find the MSI's change, we couldn't fix this problem. fixing this - its really nice to have some fully functional suspend/resume use cases (eg :T420s with external mouse :) David -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Automated report: NetBSD-current/i386 build success
The NetBSD-current/i386 build is working again. The following commits were made between the last failed build and the successful build: 2018.12.05.19.56.49 christos src/sys/rump/librump/rumpkern/emul.c,v 1.189 2018.12.05.21.15.20 wiz src/share/man/man7/sysctl.7,v 1.137 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2018.12.html#2018.12.05.21.15.20
Re: issues with touchpad after update
On Tue, Dec 04, 2018 at 11:08:21PM +0100, Riccardo Mottola wrote: > > I just updated and rebuilt the kernel to current. > It is much better now. > That's good :) > > Indeed it "works" just not coveniently, so the feature is indeed > implemented. Non-multi-touch would jump badly with two fingers. > What are your synaptics settings? If scale_z is not 32 then you need to update again. I bumped up the default scaling for this variable, if it is still a bit jumpy then you can increase scale_z some more. You need the very latest synaptics driver to do this though. > Perhaps, as you write, it is sending to many scroll events or the scroll > amount is too big? > Yes, it was... > > It is something which worked only with the special synaptics driver, not > the standard windows one, the right area of the touchbar has a bar drawn > on and using that scrolled without the need of two fingers. I think Martin said he was going to look at this - again, I only have a clickpad on my laptop so it is hard to test. > I think it is just a software feature, maybe not even convenient - I am > not accustomed to it because e.g. ThinkPads do not have it. > It could be a software feature - if it is then we can do the same sort of thing I did for emulating 3 buttons on a clickpad (by default that only reports a left click which is why I started hacking on the driver in the first place...) -- Brett Lymn "We are were wolves", "You mean werewolves?", "No we were wolves, now we are something else entirely", "Oh"
Automated report: NetBSD-current/i386 build failure
This is an automatically generated notice of a NetBSD-current/i386 build failure. The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host, using sources from CVS date 2018.12.05.18.16.51. An extract from the build.sh output follows: rm -f librump.so.0.0 /tmp/bracket/build/2018.12.05.18.16.51-i386/tools/bin/i486--netbsdelf-gcc -shared -Wl,-soname,librump.so.0 -Wl,--warn-shared-textrel -Wl,-Map=librump.so.0.map --sysroot=/tmp/bracket/build/2018.12.05.18.16.51-i386/destdir -Wl,-T,/tmp/bracket/build/2018.12.05.18.16.51-i386/src/lib/librump/../../sys/rump/ldscript.rump -Wl,--warn-shared-textrel -Wl,-z,relro -o librump.so.0.0.tmp -Wl,-rpath-link,/tmp/bracket/build/2018.12.05.18.16.51-i386/destdir/lib -L=/lib -Wl,-x -Wl,--whole-archive librump_pic.a -Wl,--no-whole-archive -L/tmp/bracket/build/2018.12.05.18.16.51-i386/obj/lib/librumpuser -lrumpuser librump_pic.a(emul.pico): In function `rumpns_get_expose_address': emul.c:(.text+0x41c): multiple definition of `rumpns_get_expose_address' librump_pic.a(kern_proc.pico):kern_proc.c:(.text+0x3d8b): first defined here collect2: error: ld returned 1 exit status *** [librump.so.0.0] Error code 1 nbmake[7]: stopped in /tmp/bracket/build/2018.12.05.18.16.51-i386/src/lib/librump 1 error The following commits were made between the last successful build and the failed build: 2018.12.05.18.16.51 christos src/share/man/man7/sysctl.7,v 1.136 2018.12.05.18.16.51 christos src/sys/dev/mm.c,v 1.23 2018.12.05.18.16.51 christos src/sys/kern/init_sysctl.c,v 1.221 2018.12.05.18.16.51 christos src/sys/kern/kern_proc.c,v 1.222 2018.12.05.18.16.51 christos src/sys/miscfs/procfs/procfs_linux.c,v 1.74 2018.12.05.18.16.51 christos src/sys/sys/param.h,v 1.572 2018.12.05.18.16.51 christos src/sys/sys/proc.h,v 1.350 2018.12.05.18.16.51 christos src/sys/sys/sysctl.h,v 1.229 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2018.12.html#2018.12.05.18.16.51
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
On Sat, 1 Dec 2018 at 01:27, SAITOH Masanobu wrote: > > Committed. > Hi - is this worth pulling up into netbsd-8? I ran a quick test and my T420s suspends/resumes fine with a netbsd-8 kernel and no X11 running. x11 looks to have issues which seem resolved in current, but it feels like a worthwhile fix to have in -8. It needed two other small changes pulled up (git hashes from https://github.com/NetBSD/src) # 5fca1fb34425590e514f0d745f936998fded9c18 PCIE_HAS_LINKREGS # 3fe2d92356e154aef689fc05111ac422c89c0785 PCIE_HAS_ROOTREGS # 2e6fa7a8bbdd4df652e4cfb605385ff915176cbe suspend/resume Sample kernel at http://ftp.netbsd.org/pub/NetBSD/misc/abs/netbsd-8-amd64-pci-resume/netbsd.gz if anyone wants to give it a quick go. (Many thanks again to msaitoh@ for all the work in analysing and fixing this - its really nice to have some fully functional suspend/resume use cases (eg :T420s with external mouse :) David
Re: mfii0 kudos to bouyer@ Was Re: dmesg | grep -c "not configured" = 240...
On Tue, 4 Dec 2018, Martin Husemann wrote: On Tue, Dec 04, 2018 at 07:17:59PM +, Mike Pumford wrote: One thing that surprised me was that I was testing with the USB install image but instead of landing in sysinst I ended up at a a login prompt which was unexpected. Could this be because the USB disk that was my root device ended up as sd23 and there is a hard coded sd0 somewhere in the install code? No hardcoded sd0, but maybe the boot device matching did not properly work for this case (depends on geometry and stuff that the bootloader gets from bios USB emulation or something). Interesting, I noticed exactly the same when booting a -current image to test the original mfii changes. In my case, sd0 and sd1 are the HW RAID arrays and sd2 is the USB stick: [ 8.177453] sd2 at scsibus1 target 0 lun 0: disk removable [ 8.177453] sd2: 3958 MB, 522 cyl, 255 head, 63 sec, 512 bytes/sect x 8105984 sectors [ 8.287566] boot device: sd2 [ 8.287566] root on sd2a dumps on sd2b -- Stephen
