daily CVS update output
Updating src tree: P src/common/include/rpc/types.h P src/common/lib/libc/rpc/xdr.c P src/common/lib/libc/rpc/xdr_array.c P src/common/lib/libc/rpc/xdr_mem.c P src/doc/CHANGES cvs update: `src/external/cddl/osnet/dist/uts/common/rpc/types.h' is no longer in the repository cvs update: `src/external/cddl/osnet/dist/uts/common/rpc/xdr.c' is no longer in the repository cvs update: `src/external/cddl/osnet/dist/uts/common/rpc/xdr.h' is no longer in the repository cvs update: `src/external/cddl/osnet/dist/uts/common/rpc/xdr_array.c' is no longer in the repository cvs update: `src/external/cddl/osnet/dist/uts/common/rpc/xdr_mem.c' is no longer in the repository P src/share/installboot/evbarm/boards.plist U src/sys/arch/arm/dts/sun8i-h2-plus-bananapi-p2-zero.dts P src/sys/arch/evbarm/conf/GENERIC P src/sys/arch/x86/x86/intr.c P src/sys/dev/ic/ssdfb.c P src/sys/dev/mii/rgephy.c P src/sys/modules/solaris/Makefile.solmod Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 43122983 Jun 6 03:04 ls-lRA.gz
Suspend/resume on a Thinkpad T420s (success!)
Just tried the latest amd64 8.99.42 on top of a NetBSD-8 install on a Thinkpad T420s and it survived multiple suspend/resume cycles, both from the console and X11. (When suspended from X11 it resumed to a blank screen with a cursor and needed a Ctrl+Alt+F1 / Ctrl+Alt+F5 to reset the display). Suspended via "sysctl -w hw.acpi.sleep.state=3" Everything seemed to pick up fine - wifi, disk, keyboard and (new) trackpoint/trackpad. The i915_drm_resume did report wedged on reset, and pms_input: unusual del1 done, but it all seemed to work. Many thanks to everyone who worked on everything to make this happen! Looking forward to NetBSD-9 :) David (I'm assuming the list will excuse a dmesg of the process :) [ 1.000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, [ 1.000] 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, [ 1.000] 2018, 2019 The NetBSD Foundation, Inc. All rights reserved. [ 1.000] Copyright (c) 1982, 1986, 1989, 1991, 1993 [ 1.000] The Regents of the University of California. All rights reserved. [ 1.000] NetBSD 8.99.42 (GENERIC) #0: Mon Jun 3 15:49:04 UTC 2019 [ 1.000] mkre...@mkrepro.netbsd.org: /usr/src/sys/arch/amd64/compile/GENERIC [ 1.000] total memory = 16266 MB [ 1.000] avail memory = 15769 MB [ 1.000] timecounter: Timecounters tick every 10.000 msec [ 1.000] Kernelized RAIDframe activated [ 1.000] running cgd selftest aes-xts-256 aes-xts-512 done [ 1.000] RTC BIOS diagnostic error 0x80 [ 1.000] timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100 [ 1.030] LENOVO 41732AG (ThinkPad T420s) [ 1.030] mainbus0 (root) [ 1.030] ACPI: RSDP 0x000F00E0 24 (v02 LENOVO) [ 1.030] ACPI: XSDT 0xDAFFE120 AC (v01 LENOVO TP-8C 1390 PTEC 0002) [ 1.030] ACPI: FACP 0xDAFE8000 F4 (v04 LENOVO TP-8C 1390 PTL 0002) [ 1.030] ACPI: DSDT 0xDAFEB000 00E55F (v01 LENOVO TP-8C 1390 INTL 20061109) [ 1.030] ACPI: FACS 0xDAF2D000 40 [ 1.030] ACPI: SLIC 0xDAFFD000 000176 (v01 LENOVO TP-8C 1390 PTEC 0001) [ 1.030] ACPI: SSDT 0xDAFFC000 000249 (v01 LENOVO TP-SSDT2 0200 INTL 20061109) [ 1.030] ACPI: SSDT 0xDAFFB000 33 (v01 LENOVO TP-SSDT1 0100 INTL 20061109) [ 1.030] ACPI: SSDT 0xDAFFA000 000797 (v01 LENOVO SataAhci 1000 INTL 20061109) [ 1.030] ACPI: HPET 0xDAFE7000 38 (v01 LENOVO TP-8C 1390 PTL 0002) [ 1.030] ACPI: APIC 0xDAFE6000 98 (v01 LENOVO TP-8C 1390 PTL 0002) [ 1.030] ACPI: MCFG 0xDAFE5000 3C (v01 LENOVO TP-8C 1390 PTL 0002) [ 1.030] ACPI: ECDT 0xDAFE4000 52 (v01 LENOVO TP-8C 1390 PTL 0002) [ 1.030] ACPI: ASF! 0xDAFEA000 A5 (v32 LENOVO TP-8C 1390 PTL 0002) [ 1.030] ACPI: TCPA 0xDAFE3000 32 (v02 PTLLENOVO 0604 LNVO 0001) [ 1.030] ACPI: SSDT 0xDAFE2000 000A35 (v01 PmRef Cpu0Ist 3000 INTL 20061109) [ 1.030] ACPI: SSDT 0xDAFE1000 000996 (v01 PmRef CpuPm 3000 INTL 20061109) [ 1.030] ACPI: DMAR 0xDAFE E8 (v01 INTEL SNB 0001 INTL 0001) [ 1.030] ACPI: UEFI 0xDAFDF000 3E (v01 LENOVO TP-8C 1390 PTL 0002) [ 1.030] ACPI: UEFI 0xDAFDE000 42 (v01 PTLCOMBUF 0001 PTL 0001) [ 1.030] ACPI: UEFI 0xDAFDD000 000292 (v01 LENOVO TP-8C 1390 PTL 0002) [ 1.030] ACPI: 6 ACPI AML tables successfully acquired and loaded [ 1.030] ioapic0 at mainbus0 apid 2: pa 0xfec0, version 0x20, 24 pins [ 1.030] x2APIC available but disabled for a suspected SandyBridge BIOS bug [ 1.030] cpu0 at mainbus0 apid 0 [ 1.030] cpu0: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, id 0x206a7 [ 1.030] cpu0: package 0, core 0, smt 0 [ 1.030] cpu1 at mainbus0 apid 1 [ 1.030] cpu1: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, id 0x206a7 [ 1.030] cpu1: package 0, core 0, smt 1 [ 1.030] cpu2 at mainbus0 apid 2 [ 1.030] cpu2: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, id 0x206a7 [ 1.030] cpu2: package 0, core 1, smt 0 [ 1.030] cpu3 at mainbus0 apid 3 [ 1.030] cpu3: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, id 0x206a7 [ 1.030] cpu3: package 0, core 1, smt 1 [ 1.030] acpi0 at mainbus0: Intel ACPICA 20190405 [ 1.030] acpi0: X/RSDT: OemId , AslId [ 1.030] acpiecdt0 at acpi0: ACPI Embedded Controller via ECDT [ 1.030] acpi0: MCFG: segment 0, bus 0-63, address 0xf800 [ 1.030] ACPI: Dynamic OEM Table Load: [ 1.030] ACPI: SSDT 0xB34B2E0BA010 0008C0 (v01 PmRef Cpu0Cst 3001 INTL 20061109) [ 1.030] ACPI: Dynamic OEM Table Load: [ 1.030] ACPI: SSDT 0xB3
build failure for dreamcast with MKCROSSGDB=yes?
After a bit of fallout with "create-version.sh" was fixed, building with "MKCROSSGDB=yes" succeeds for all ports I build except "dreamcast". It fails with: [...] CXXsh-nbsd-tdep.o /x/current/src/tools/gdb/../../external/gpl3/gdb/dist/gdb/sh-nbsd-tdep.c:35:24: fatal error: gdb_assert.h: No such file or directory compilation terminated. nbgmake[1]: *** [sh-nbsd-tdep.o] Error 1 nbgmake[1]: Leaving directory `/r0/build/current/obj/dreamcast/tools/gdb/build/gdb' [...] This is with sources updated as of about 201906051655Z. Anyone else seeing this? -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: What to do with base X11 for netbsd-9 ?
Same EFI issue here: EFI/GK208B [GeForce GT 710] gets stuck when attempting to configure the card. Booting via CSM or EFI and nouveau disabled gets the machine up and nouveau works fine with acceleration in the CSM case. Looking at the PCI configuration the main difference is that the CSM sets the BusMaster bits to enabled on the bridges while this is not the case for EFI. Also more IO/MEM/ROM bits are set. I think we still lack sufficient PCI setup when booting via EFI. (lspci dumps are available on request). Frank On 06/05/19 11:25, Patrick Welche wrote: On Tue, Jun 04, 2019 at 01:03:49PM +0100, Patrick Welche wrote: On another front, I cannot boot a computer with nouveau and a NVidia GeForce GTX 680 (GK104). At the point where the console normally changes resolution, the screen goes black and everything stops. (No panic AFAICT) This has changed! The above is still true with EFI, but with BIOS booting, nouveau attaches successfully, and I can run xdm+twm! The experience is exactly the opposite to the one with Sandy Bridge: images display fine, glmark2 runs. It's the fonts which are unreadable (not a question of size but of artifacts. This is in 3840x mode. Still, at least I no longer have to disable nouveau in order to boot! Cheers, Patrick
Re: What to do with base X11 for netbsd-9 ?
On Wed, May 29, 2019 at 09:12:42AM +0200, Martin Husemann wrote: > Hey folks, > > I would like to get your feedback about the current state of the base X11, > as there have been lots of threads about various issues and I have lost > the overview of what works in -current and what does not. > > We *really* need to branch netbsd-9 very soon now, and it is unclear (at > least to me) what should happen to the in-tree X11 version. > > - we have very obvious display bugs at first sight in xdm > - self hosting builds on 4 GB amd64 machines are not really possible >any more (due to LLVM runtime dependencies, which can not even be >disabled at build time right now) > - reports here (and on other lists) about display problems and success >stories have no clear winner (but probably due to me losing track) > > So what is you story/opinion: is base X11 usable in -current? If not, > what needs to be done or what hardware needs fixes? FWIW, on a recent Dell laptop: [ 1.03] cpu0 at mainbus0 apid 0 [ 1.03] cpu0: Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz, id 0x806e9 [ 1.014344] i915drmkms0 at pci0 dev 2 function 0: vendor 8086 product 5916 (rev. 0x02) With current I can now use stellarium and opencpn with hardware accelleration, which is a real improvement over netbsd-8 (stellarium now gives me 60fps, when without hardware accelleration it's a less than 1 - almost unusable). -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: What to do with base X11 for netbsd-9 ?
pr...@cam.ac.uk (Patrick Welche) writes: >This has changed! The above is still true with EFI, but with BIOS booting, >nouveau attaches successfully, and I can run xdm+twm! What happens in EFI mode when, before booting the kernel you configure a display mode with the 'gop' command ? -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: building base with clang
Martin Husemann transcribed 372 bytes: > On Wed, Jun 05, 2019 at 07:48:25AM +, n...@n0.is wrote: > > Hi, > > > > how good or bad is the base system with clang (ie, since > > gcc is the default is enough care taken to make the cvs > > build with clang without major breakages)? > > Depends on your architecture. You can see a few of those builds > at > > http://releng.netbsd.org/cgi-bin/builds.cgi > > under "HEAD-llvm". Thanks! > Martin
Re: building base with clang
On Wed, Jun 05, 2019 at 07:48:25AM +, n...@n0.is wrote: > Hi, > > how good or bad is the base system with clang (ie, since > gcc is the default is enough care taken to make the cvs > build with clang without major breakages)? Depends on your architecture. You can see a few of those builds at http://releng.netbsd.org/cgi-bin/builds.cgi under "HEAD-llvm". Martin
Re: What to do with base X11 for netbsd-9 ?
On Tue, Jun 04, 2019 at 01:03:49PM +0100, Patrick Welche wrote: > On another front, I cannot boot a computer with nouveau and a > NVidia GeForce GTX 680 (GK104). At the point where the console normally > changes resolution, the screen goes black and everything stops. > (No panic AFAICT) This has changed! The above is still true with EFI, but with BIOS booting, nouveau attaches successfully, and I can run xdm+twm! The experience is exactly the opposite to the one with Sandy Bridge: images display fine, glmark2 runs. It's the fonts which are unreadable (not a question of size but of artifacts. This is in 3840x mode. Still, at least I no longer have to disable nouveau in order to boot! Cheers, Patrick
building base with clang
Hi, how good or bad is the base system with clang (ie, since gcc is the default is enough care taken to make the cvs build with clang without major breakages)? According to what I've found, is this all there is to mk.conf, or do some new options exist in addition to these: # needed as building GCC alongside clang is not maintained? MKGCC=no # libraries MKLLVM=yes # libc++ MKLIBCXX=yes # clang HAVE_LLVM=yes # pkgsrc with clang PKGSRC_COMPILER=clang # pkgsrc clang location CLANGBASE=/usr Cheers, ng0
Re: What to do with base X11 for netbsd-9 ?
* matthew green : > Lars Reichardt writes: > > > > > matthew green hat am 4. Juni 2019 um 07:19 > > > geschrieben: > > > > > > > > > unfortunately, you need the as-yet non-functional amdgpu driver > > > i believe: > > > > > > [ 1594.209] (--) RADEON(0): Chipset: "OLAND" (ChipID = 0x6613) > > > > > > means a GCN v1. radeon supports this minimally, but the GL does > > > not. > > > > > > > > > .mrg. > > > > afaik those GCN v1 chips are supported by radeon and have experimental > > support via amdgpu. > > > > It fails with glamor xorg disabled llvmpipe, some quick search hint in > > the direction of mesa build options. > > > > The same hardware works under Linux with both drivers accelerated. > > > > The kernel driver loads the OLAND_mc2.bin firmware but fails to load > > TAHITI_vce.bin (I guess it's for video decoding) which is missing from > > the filesystem maybe that's causing some hickup. > > ah yes - i forget how the overlaps between radeon and amdgpu > are and this one should be (only) in radeon as 'radeonsi'. > > can you try installing TAHITI_vce.bin and seeing what happens? > it seems unlikely to be the problem. > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/radeon > > if this doesn't help, we'll have to see what is up in Mesa. > > > .mrg. unfortunately it fails now with: [ 4.695688] radeon0: autoconfiguration error: error: VCE init error (-22). but not complaining about the missing vce fw anymore I'll try the modular-xorg maybe that show a different behavior and some pointer. Lars -- You will continue to suffer if you have an emotional reaction to everything that is said to you. True power is sitting back and observing everything with logic. If words control you that means everyone else can control you. Breathe and allow things to pass. --- Bruce Lee
