Re: X Window issues
On 11.05.2019 04:54, Kamil Rytarowski wrote: > On 10.05.2019 08:29, matthew green wrote: >> this is probably the recently discussed intel driver issues. >> i've added a build option to use the older driver. >> >> can you try build with INTEL_DRIVER_DATE=2014. jmake sure you >> clean src/external/mit/xorg/server/drivers/xf86-video-intel or >> the build likely won't be right. don't forget to upate both >> src and xsrc.. >> >> others who have had recent failures could also try -- and if >> you're adventurous, testing working systems as well. we will >> probably decide the default (new or old KMS default) depending >> on feedback. >> >> thanks. >> >> >> .mrg. >> > > I've upgraded distribution to INTEL_DRIVER_DATE= 2014 in mk.conf(5). > > It works a little bit better, but glxgears and mpv in any output format > utilizing hw acceleration breaks. > I can try to debug it after my return from BSDCan. signature.asc Description: OpenPGP digital signature
Re: X Window issues
On 10.05.2019 08:29, matthew green wrote: > this is probably the recently discussed intel driver issues. > i've added a build option to use the older driver. > > can you try build with INTEL_DRIVER_DATE=2014. jmake sure you > clean src/external/mit/xorg/server/drivers/xf86-video-intel or > the build likely won't be right. don't forget to upate both > src and xsrc.. > > others who have had recent failures could also try -- and if > you're adventurous, testing working systems as well. we will > probably decide the default (new or old KMS default) depending > on feedback. > > thanks. > > > .mrg. > I've upgraded distribution to INTEL_DRIVER_DATE= 2014 in mk.conf(5). It works a little bit better, but glxgears and mpv in any output format utilizing hw acceleration breaks. signature.asc Description: OpenPGP digital signature
Re: VirtualBox-6.0.6 fails build under 8.99.39
Just 'kmk' would have been enough. I enter ' kmk KBUILD_VERBOSE=2 BUILD_TYPE=release'. All this was advised earlier by uwe@, I am sure you can find the threads in the archives. The result is: % ls out/netbsd.amd64/release/bin/additions VBoxClientvboxvideo_drv_110.so vboxvideo_drv_114.so vboxvideo_drv_118.so vboxvideo_drv_16.so vboxvideo_drv_70.so VBoxControl vboxvideo_drv_111.so vboxvideo_drv_115.so vboxvideo_drv_13.so vboxvideo_drv_17.so vboxvideo_drv_71.so VBoxService vboxvideo_drv_112.so vboxvideo_drv_116.so vboxvideo_drv_14.so vboxvideo_drv_18.so vboxguest.kmodvboxvideo_drv_113.so vboxvideo_drv_117.so vboxvideo_drv_15.so vboxvideo_drv_19.so I copy these to /usr/local/bin/additions, then copy the module to the corresponding place, as below, and modify /etc/rc.local: % ls -l /usr/X11R7/lib/modules/drivers/vbox* lrwxr-xr-x 1 root wheel 20 Jan 10 00:33 /usr/X11R7/lib/modules/drivers/vboxvideo_drv.so -> vboxvideo_drv_118.so ... lrwxr-xr-x 1 root wheel 45 Jan 10 00:19 /usr/X11R7/lib/modules/drivers/vboxvideo_drv_118.so -> /usr/local/bin/additions/vboxvideo_drv_118.so lrwxr-xr-x 1 root wheel 44 Jan 10 00:19 /usr/X11R7/lib/modules/drivers/vboxvideo_drv_13.so -> /usr/local/bin/additions/vboxvideo_drv_13.so ... lrwxr-xr-x 1 root wheel 44 Jan 10 00:19 /usr/X11R7/lib/modules/drivers/vboxvideo_drv_71.so -> /usr/local/bin/additions/vboxvideo_drv_71.so xci@n8:~/p/VirtualBox-6.0.6 % ls -l /stand/amd64/8.0/modules/vboxguest total 1408 -rwxr-xr-x 1 root wheel 333728 May 10 20:23 vboxguest.kmod My/etc/rc.local contains: if [ -x /stand/amd64/`uname -r`/modules/vboxguest/vboxguest.kmod ]; then /sbin/modload vboxguest fi if [ -x /usr/local/bin/additions/VBoxService ]; then /usr/local/bin/additions/VBoxService --pidfile /var/run/VBoxService.pid fi ... The video driver in /etc/X11/xorg.conf is vboxvideo. -current now has a version of this builtin and working OK, so it is not quite clear how useful the rest of the bits will be. For NetBSD 8, I think the above configuration is fine. On Fri, 10 May 2019 at 20:47, Mayuresh wrote: > > On Fri, May 10, 2019 at 08:25:45PM +0100, Chavdar Ivanov wrote: > > You are using very old VirtualBox version from pkgsrc/wip. This is > > something I haven't bothered ever to try. I download the source from > > VirtualBox and build it myself. All you need is kbuild and yasm and > > LocalConfig.kmk with the following contents: > > Sorry to trouble with more basic questions. I am not familiar with kmk or > yasm. Can you please share some sample commands after creating > LocalConfig.kmk? > > > We are talking about the guest additions drivers at the moment, not > > the virtualisation product itself. > > Sorry, I missed the point here. You mean the core virtualization product > builds and is usable or not. > > Mayuresh --
Re: "route_enqueue: queue full, dropped message" blast from a 8.99.32 amd64 domU
At Fri, 10 May 2019 13:05:04 +0100, Roy Marples wrote: Subject: Re: "route_enqueue: queue full, dropped message" blast from a 8.99.32 amd64 domU > > I would imagine that if an interface is interupting that much then > it's constantly sending messages to route(4) to say that it's up/down > and addresses are detached/tentative in a tight loop. The queueing > mechanism has a fixed length and while we go out of our way to notify > userland if there's an error sending these messages, we can't send > this one at all so we just log it. > > So it's an artifact of your interupt storm, but not the cause. Thanks Roy! I'm afraid I was too distracted with other things at the time to look to see if I could identify which device might have accounted for the extra interrupts. I kind of assumed they were all from the console driver, though I just did a test and now realize that even at full speed it can't account for nearly the magnitude of interrupts per second that I was seeing. During normal operation I see just over 8000/s (and with the console spewing there are only about 200/s more), and it all seems to add up since this is an 8-vcpu domU, and I have HZ=1000. Before I rebooted I was seeing numbers ranging up to 25000/s. So, what in the world could make either the single xennet0 interface, or the lo0 interface for that matter, bounce in such a fashion I wonder. As far as I can tell from old console log files this did not happen in the first few years of life of this system (from about 2015) when it (and its dom0) was running 7.99.various. -- Greg A. Woods +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgpsV8DWRsowi.pgp Description: OpenPGP Digital Signature
Re: VirtualBox-6.0.6 fails build under 8.99.39
On 10.05.2019 21:04, Mayuresh wrote: > On Sat, May 11, 2019 at 12:05:03AM +0530, Mayuresh wrote: >> pxe_call.c:(.text.pxe_api_call+0x12): undefined reference to >> `__stack_chk_guard' > > PKGSRC_USE_SSP=no makes it go away, but that gives rise to following > errors that weren't present when it was not set. > > > In file included from > /usr/pkgsrc/wip/virtualbox/work/VirtualBox-5.0.16/src/VBox/HostDrivers/Support/SUPR3HardenedMain.cpp:67:0: > /usr/pkgsrc/wip/virtualbox/work/VirtualBox-5.0.16/include/VBox/types.h:78:37: > error: expected unqualified-id before numeric constant > typedef struct VM *PVM; > ^ > /usr/pkgsrc/wip/virtualbox/work/VirtualBox-5.0.16/include/VBox/types.h:78:37: > error: expected initializer before numeric constant > kmk: *** > [/usr/pkgsrc/wip/virtualbox/work/VirtualBox-5.0.16/out/netbsd.amd64/release/obj/SUPR3HardenedStatic/SUPR3HardenedMain.o] > Error 1 > > > Mayuresh > If you want to install it on NetBSD as host, it won't work. The part is not finished. signature.asc Description: OpenPGP digital signature
Re: VirtualBox-6.0.6 fails build under 8.99.39
On Fri, May 10, 2019 at 08:25:45PM +0100, Chavdar Ivanov wrote: > You are using very old VirtualBox version from pkgsrc/wip. This is > something I haven't bothered ever to try. I download the source from > VirtualBox and build it myself. All you need is kbuild and yasm and > LocalConfig.kmk with the following contents: Sorry to trouble with more basic questions. I am not familiar with kmk or yasm. Can you please share some sample commands after creating LocalConfig.kmk? > We are talking about the guest additions drivers at the moment, not > the virtualisation product itself. Sorry, I missed the point here. You mean the core virtualization product builds and is usable or not. Mayuresh
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 2019.05.10.17.34.26. An extract from the build.sh output follows: # compile lib/conio.o /tmp/bracket/build/2019.05.10.17.34.26-i386/tools/bin/i486--netbsdelf-gcc -march=i386 -mtune=i386 -I/tmp/bracket/build/2019.05.10.17.34.26-i386/src/sys/arch/i386/stand/lib/../../../../lib/libsa --sysroot=/tmp/bracket/build/2019.05.10.17.34.26-i386/destdir -DBOOTXX -I /tmp/bracket/build/2019.05.10.17.34.26-i386/src/sys/arch/i386/stand/bootxx/bootxx_ffsv1/../../lib -I /tmp/bracket/build/2019.05.10.17.34.26-i386/obj/sys/arch/i386/stand/bootxx/bootxx_ffsv1 -DBOOTXX_SECTORS=15 -DPRIMARY_LOAD_ADDRESS=0x1000 -DSECONDARY_LOAD_ADDRESS=0x1 -DXXfs_open=ffsv1_open -DXXfs_close=ffsv1_close -DXXfs_read=ffsv1_read -DXXfs_stat=ffsv1_stat -DFS=ffsv1 -DNO_LBA_CHECK -DEPIA_HACK -nostdinc -D_STANDALONE -I/tmp/bracket/build/2019.05.10.17.34.26-i386/src/sys/arch/i386/stand/bootxx/bootxx_ffsv1/../../../../.. -DLIBSA_SINGLE_FILESYSTEM=xxfs -DLIBSA_NO_TWIDDLE -DLIBSA_NO_FD_CHECKING -DLIBSA_NO_RAW_ACCESS -DLIBSA_NO_FS_WRITE -DLIBSA_NO_FS_SEEK -DLIBSA_SINGLE_DEVICE=blkdev -DLIBKERN_OPTIMISE_SPACE -D"b lkdevioctl(x,y,z)=EINVAL" -D"blkdevclose(f)=0" -D"devopen(f,n,fl)=(*(fl)=(void *)n,0)" -DLIBSA_NO_DISKLABEL_MSGS -I/tmp/bracket/build/2019.05.10.17.34.26-i386/src/sys/arch/i386/stand/bootxx/bootxx_ffsv1/../../../../../lib/libkern/../../../common/lib/libc/quad -I/tmp/bracket/build/2019.05.10.17.34.26-i386/src/sys/arch/i386/stand/bootxx/bootxx_ffsv1/../../../../../lib/libkern/../../../common/lib/libc/string -I/tmp/bracket/build/2019.05.10.17.34.26-i386/src/sys/arch/i386/stand/bootxx/bootxx_ffsv1/../../../../../lib/libkern/../../../common/lib/libc/arch/i386/string -x assembler-with-cpp -c /tmp/bracket/build/2019.05.10.17.34.26-i386/src/sys/arch/i386/stand/lib/conio.S -o conio.o --- dependall-usr.sbin --- /tmp/bracket/build/2019.05.10.17.34.26-i386/tools/lib/gcc/i486--netbsdelf/7.4.0/../../../../i486--netbsdelf/bin/ld: i386.o: in function `.L482': i386.c:(.text+0x3923): undefined reference to `rdmsr' collect2: error: ld returned 1 exit status *** [cpuctl] Error code 1 nbmake[7]: stopped in /tmp/bracket/build/2019.05.10.17.34.26-i386/src/usr.sbin/cpuctl 1 error The following commits were made between the last successful build and the failed build: 2019.05.10.16.24.35 mgorny src/tests/lib/libc/sys/t_ptrace_amd64_wait.h,v 1.10 2019.05.10.16.24.35 mgorny src/tests/lib/libc/sys/t_ptrace_i386_wait.h,v 1.8 2019.05.10.16.27.03 mgorny src/sys/arch/i386/include/reg.h,v 1.21 2019.05.10.16.28.00 mgorny src/tests/lib/libc/sys/t_ptrace_x86_wait.h,v 1.11 2019.05.10.16.42.57 mlelstv src/usr.sbin/cpuctl/arch/cpuctl_i386.h,v 1.3 2019.05.10.16.42.57 mlelstv src/usr.sbin/cpuctl/arch/i386-asm.S,v 1.5 2019.05.10.16.42.57 mlelstv src/usr.sbin/cpuctl/arch/i386.c,v 1.96 2019.05.10.16.42.57 mlelstv src/usr.sbin/cpuctl/arch/x86_64-asm.S,v 1.6 2019.05.10.16.43.09 skrll src/sys/arch/arm/arm32/arm32_machdep.c,v 1.128 2019.05.10.17.34.26 mgorny src/tests/lib/libc/sys/t_ptrace_x86_wait.h,v 1.12 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2019.05.html#2019.05.10.17.34.26
Re: VirtualBox-6.0.6 fails build under 8.99.39
You are using very old VirtualBox version from pkgsrc/wip. This is something I haven't bothered ever to try. I download the source from VirtualBox and build it myself. All you need is kbuild and yasm and LocalConfig.kmk with the following contents: ... VBOX_WITHOUT_HARDENING := 1 VBOX_ONLY_ADDITIONS := 1 VBOX_WITH_ADDITION_DRIVERS := 1 VBOX_WITH_X11_ADDITIONS := 1 VBOX_ONLY_ADDITIONS_WITHOUT_RTISOMAKER := 1 ... At the moment I am trying to build v.6.0.6 under 8-STABLE from 5th of April on a machine with no pkgsrc, everything installed using pkgin. We are talking about the guest additions drivers at the moment, not the virtualisation product itself. The build process puts everything under the out subfolder, it has to be then placed in the relevant locations and configured. The build is fine: 19:23:54.449825 main VBoxService 6.0.6 r129722 (verbosity: 0) netbsd.amd64 (May 10 2019 20:20:57) release log 19:23:54.449841 main Log opened 2019-05-10T19:23:54.449784000Z 19:23:54.449914 main OS Product: NetBSD 19:23:54.449937 main OS Release: 8.0 19:23:54.449957 main OS Version: NetBSD 8.0 (GENERIC) #0: Tue Jul 17 14:59:51 UTC 2018 mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC 19:23:54.449972 main Executable: /usr/local/bin/additions/VBoxService 19:23:54.449979 main Process ID: 10201 19:23:54.449986 main Package type: BSD_64BITS_GENERIC 19:23:54.453211 main 6.0.6 r129722 started. Verbose level = 0 My initial query was what has changed in 8.99.39 compared to 8.99.37 - it builds on the later, fails on the former. On Fri, 10 May 2019 at 20:04, Mayuresh wrote: > > On Sat, May 11, 2019 at 12:05:03AM +0530, Mayuresh wrote: > > pxe_call.c:(.text.pxe_api_call+0x12): undefined reference to > > `__stack_chk_guard' > > PKGSRC_USE_SSP=no makes it go away, but that gives rise to following > errors that weren't present when it was not set. > > > In file included from > /usr/pkgsrc/wip/virtualbox/work/VirtualBox-5.0.16/src/VBox/HostDrivers/Support/SUPR3HardenedMain.cpp:67:0: > /usr/pkgsrc/wip/virtualbox/work/VirtualBox-5.0.16/include/VBox/types.h:78:37: > error: expected unqualified-id before numeric constant > typedef struct VM *PVM; > ^ > /usr/pkgsrc/wip/virtualbox/work/VirtualBox-5.0.16/include/VBox/types.h:78:37: > error: expected initializer before numeric constant > kmk: *** > [/usr/pkgsrc/wip/virtualbox/work/VirtualBox-5.0.16/out/netbsd.amd64/release/obj/SUPR3HardenedStatic/SUPR3HardenedMain.o] > Error 1 > > > Mayuresh --
Re: VirtualBox-6.0.6 fails build under 8.99.39
On Sat, May 11, 2019 at 12:05:03AM +0530, Mayuresh wrote: > pxe_call.c:(.text.pxe_api_call+0x12): undefined reference to > `__stack_chk_guard' PKGSRC_USE_SSP=no makes it go away, but that gives rise to following errors that weren't present when it was not set. In file included from /usr/pkgsrc/wip/virtualbox/work/VirtualBox-5.0.16/src/VBox/HostDrivers/Support/SUPR3HardenedMain.cpp:67:0: /usr/pkgsrc/wip/virtualbox/work/VirtualBox-5.0.16/include/VBox/types.h:78:37: error: expected unqualified-id before numeric constant typedef struct VM *PVM; ^ /usr/pkgsrc/wip/virtualbox/work/VirtualBox-5.0.16/include/VBox/types.h:78:37: error: expected initializer before numeric constant kmk: *** [/usr/pkgsrc/wip/virtualbox/work/VirtualBox-5.0.16/out/netbsd.amd64/release/obj/SUPR3HardenedStatic/SUPR3HardenedMain.o] Error 1 Mayuresh
Re: VirtualBox-6.0.6 fails build under 8.99.39
On Fri, May 10, 2019 at 09:30:06AM +0100, Chavdar Ivanov wrote: > Sure, although the last time I did this was months ago. Now, it needed python version to be set to 27. I have committed this change. Now there are linking errors for various sources but for these 3 symbols only. pxe_call.c:(.text.pxe_api_call+0x12): undefined reference to `__stack_chk_guard' pxe_call.c:(.text.pxe_api_call+0x96): undefined reference to `__stack_chk_guard' pxe_call.c:(.text.pxe_api_call+0x9d): undefined reference to `__stack_chk_fail' Any idea about these? Mayuresh
Re: audio panic booting -current under vbox 6.0.6
I had the same. Changed the emulated device to Intel audio, now it boots OK. On Fri, 10 May 2019 at 18:56, Christoph Badura wrote: > > Yesterday I tried booting an amd64 install iso from sources updated > around 16:00 UTC under virtualbox 6.0.6. The kernel paniced with > panic: audio_indexof_format: cannot find matched format > > The VM was configured with 1GB of RAM, 5GB of disk. ICH9 chipset and ICH > AC97 audio. Host is a macbook pro running up-to-date macOS. > > The kernel messages via serial console are attached. > > Anything I can do to help debug this? > --chris --
audio panic booting -current under vbox 6.0.6
Yesterday I tried booting an amd64 install iso from sources updated around 16:00 UTC under virtualbox 6.0.6. The kernel paniced with panic: audio_indexof_format: cannot find matched format The VM was configured with 1GB of RAM, 5GB of disk. ICH9 chipset and ICH AC97 audio. Host is a macbook pro running up-to-date macOS. The kernel messages via serial console are attached. Anything I can do to help debug this? --chris [ 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.39 (GENERIC) #0: Thu May 9 20:42:44 CEST 2019 [ 1.000] b...@total-internal-reflection.k.bsd.de:/Users/bad/work/rump-current/src-cvs/obj/obj.amd64/sys/arch/amd64/compile/GENERIC [ 1.000] total memory = 1023 MB [ 1.000] avail memory = 966 MB [ 1.000] WARNING: module error: module `cd9660' pushed by boot loader already exists [ 1.000] cpu_rng: RDRAND [ 1.000] running cgd selftest aes-xts-256 aes-xts-512 done [ 1.030] mainbus0 (root) [ 1.030] ACPI: RSDP 0x000E 24 (v02 VBOX ) [ 1.030] ACPI: XSDT 0x3FFF0040 4C (v01 VBOX VBOXXSDT 0001 ASL 0061) [ 1.030] ACPI: FACP 0x3FFF0110 F4 (v04 VBOX VBOXFACP 0001 ASL 0061) [ 1.030] ACPI: DSDT 0x3FFF0530 0022EA (v02 VBOX VBOXBIOS 0002 INTL 20100528) [ 1.030] ACPI: FACS 0x3FFF0240 40 [ 1.030] ACPI: APIC 0x3FFF0280 54 (v02 VBOX VBOXAPIC 0001 ASL 0061) [ 1.030] ACPI: HPET 0x3FFF02E0 38 (v01 VBOX VBOXHPET 0001 ASL 0061) [ 1.030] ACPI: MCFG 0x3FFF0320 3C (v01 VBOX VBOXMCFG 0001 ASL 0061) [ 1.030] ACPI: SSDT 0x3FFF0360 0001CC (v01 VBOX VBOXCPUT 0002 INTL 20100528) [ 1.030] ACPI: 2 ACPI AML tables successfully acquired and loaded [ 1.030] ioapic0 at mainbus0 apid 1 [ 1.030] cpu0 at mainbus0 apid 0 [ 1.030] cpu0: Intel(R) Core(TM) i7-4578U CPU @ 3.00GHz, id 0x40651 [ 1.030] cpu0: package 0, core 0, smt 0 [ 1.030] acpi0 at mainbus0: Intel ACPICA 20190405 [ 1.030] acpi0: fixed power button present [ 1.030] acpi0: fixed sleep button present [ 1.0061613] hpet0 at acpi0: high precision event timer (mem 0xfed0-0xfed00400) [ 1.0146367] pckbc1 at acpi0 (PS2K, PNP0303) (kbd port): io 0x60,0x64 irq 1 [ 1.0146367] pckbc2 at acpi0 (PS2M, PNP0F03) (aux port): irq 12 [ 1.0146367] attimer1 at acpi0 (TIMR, PNP0100): io 0x40-0x43,0x50-0x53 [ 1.0146367] PCIE (PNP0C02) at acpi0 not configured [ 1.0146367] SRL0 (PNP0501) at acpi0 not configured [ 1.0146367] acpivga0 at acpi0 (GFX0): ACPI Display Adapter [ 1.0146367] acpiout0 at acpivga0 (VGA, 0x0100): ACPI Display Output Device [ 1.0146367] acpibat0 at acpi0 (BAT0, PNP0C0A-0): ACPI Battery [ 1.0146367] acpiacad0 at acpi0 (AC, ACPI0003-0): ACPI AC Adapter [ 1.0146367] ACPI: Enabled 2 GPEs in block 00 to 07 [ 1.0146367] pckbd0 at pckbc1 (kbd slot) [ 1.0146367] pckbc1: using irq 1 for kbd slot [ 1.0146367] wskbd0 at pckbd0 mux 1 [ 1.0146367] pms0 at pckbc1 (aux slot) [ 1.0146367] pckbc1: using irq 12 for aux slot [ 1.0146367] wsmouse0 at pms0 mux 0 [ 1.0146367] pci0 at mainbus0 bus 0: configuration mode 1 [ 1.0146367] vga0 at pci0 dev 2 function 0: vendor 80ee product beef (rev. 0x00) [ 1.0146367] wsdisplay0 at vga0 kbdmux 1 [ 1.0146367] drm at vga0 not configured [ 1.0146367] wm0 at pci0 dev 3 function 0: Intel i82540EM 1000BASE-T Ethernet (rev. 0x02) [ 1.0146367] wm0: interrupting at ioapic0 pin 19 [ 1.0146367] wm0: Ethernet address 08:00:27:0f:98:42 [ 1.0146367] makphy0 at wm0 phy 1: Marvell 88E1011 Gigabit PHY, rev. 4 [ 1.0146367] makphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto [ 1.0146367] vendor 80ee product cafe (miscellaneous system) at pci0 dev 4 function 0 not configured [ 1.0146367] auich0 at pci0 dev 5 function 0: i82801AA (ICH) AC-97 Audio [ 1.0146367] auich0: interrupting at ioapic0 pin 21 [ 1.0146367] auich0: ac97: SigmaTel STAC9700 codec; no 3D stereo [ 1.0146367] auich0: ac97: ext id 0x800 [ 1.0146367] piixpm0 at pci0 dev 7 function 0: vendor 8086 product 7113 (rev. 0x08) [ 1.0146367] piixpm0: interrupting at ioapic0 pin 23 [ 1.0146367] iic0 at piixpm0: I2C bus [ 1.0146367] ichlpcib0 at pci0 dev 31 function 0: vendor 8086 product 27b9 (rev. 0x02) [ 1.0146367] ichlpcib0: 24-bit timer [ 1.0146367] tco0 at ichlpcib0: TCO (watchdog) timer configured. [ 1.0146367] ahcisata0 at pci0 dev 31 function 2: vendor 8086 product 2829 (rev. 0x02) [ 1.0146367] ahcisata0: AHCI revision
Re: Hints for Bananapi and -current
Am Mi., 8. Mai 2019 um 00:51 Uhr schrieb Jason Thorpe :
>
> > On May 7, 2019, at 2:37 PM, Jared McNeill wrote:
> >
> > On Tue, 7 May 2019, Markus Kilbinger wrote:
> >
> >> - I was not able to bootarm.efi this kernel from its local ffs2 (!)
> >> netbsd partition on the sdcrad. Is bootarm.efi limited to ffs1?
> >
> > It uses ffs support from libsa, so I would expect it to work (but can't say
> > that I have tried it on armv7).
>
> ...and it looks like ffsv2 is in the fs ops table in efiboot, so... *boggle*
boogled:
1. I had to disklabel(8) my sdcard (was just fdisk-ed before) to make
bootarm.efi successfully find the kernel on its ffsv2 partition.
W/should be gpt-ing it sufficient, too?
2. Played with bootarm.efi (stored on sdcard) on my cubietruck and a
connected gpt-ed sata disk: u-boot seems to detect it as scsi disk, I
had to "scsi scan" before it and its partitions would be correctly
detected for / by bootarm.efi.
I managed to make bootarm.efi boot from the recognised sata disk by
setting manually "dev hd0b" at its boot prompt (defaults to the sdcard
"hd1a").
After tons of
CACHE: Misaligned operation at range [bf4cdb70, bf4d1b70]
messages it finally loaded the kernel from the harddisks ffsv2
partition ("hd0b" aka "dk1") and booted successfully into NetBSD :-).
2.1 How to get rid of the "CACHE..." messages?
2.2 How to instruct bootarm.efi to boot automatically from a
non-standard / -default device / partition?
Regards, Markus.
Re: "route_enqueue: queue full, dropped message" blast from a 8.99.32 amd64 domU
On 10/05/2019 00:40, Greg A. Woods wrote: [Thu May 9 09:24:08 2019][ 6442662.0806318] route_enqueue: queue full, dropped message There were thousands of identical lines, all separated by a few microseconds. No doubt this spew was the real cause of the apparent interrupt storm and the resulting sluggishness. https://nxr.netbsd.org/xref/src/sys/net/rtsock_shared.c#1602 I would imagine that if an interface is interupting that much then it's constantly sending messages to route(4) to say that it's up/down and addresses are detached/tentative in a tight loop. The queueing mechanism has a fixed length and while we go out of our way to notify userland if there's an error sending these messages, we can't send this one at all so we just log it. So it's an artifact of your interupt storm, but not the cause. Roy
Re: VirtualBox-6.0.6 fails build under 8.99.39
Sure, although the last time I did this was months ago. On Fri, 10 May 2019 at 02:29, Mayuresh wrote: > On Thu, May 09, 2019 at 09:43:10PM +0100, Chavdar Ivanov wrote: > > While The said version compiles cleanly under 8.99.37 (I did it a few > > days ago), today under 8.99.39 it fails for me as follows: > > I am a late tuner to this development. Does it compile on 8.0? > > Mayuresh > --
re: X Window issues
this is probably the recently discussed intel driver issues. i've added a build option to use the older driver. can you try build with INTEL_DRIVER_DATE=2014. jmake sure you clean src/external/mit/xorg/server/drivers/xf86-video-intel or the build likely won't be right. don't forget to upate both src and xsrc.. others who have had recent failures could also try -- and if you're adventurous, testing working systems as well. we will probably decide the default (new or old KMS default) depending on feedback. thanks. .mrg.
Re: urndis0 works on amd64-8.0 but not on evbarm-current
On Fri, May 10, 2019 at 6:08 AM Mayuresh wrote: > > On Fri, May 10, 2019 at 06:05:34AM +, sc dying wrote: > > Attached files look bogus, I'll resend. > > Due to some other compulsions (a lot of pkgs that I need not building > under current, discussed on various threads) I reverted my environment to > 8.0. > > Is there any possibility to try things on 8.0? 8.0 looks like having same problems and I think the patches can be applied. > > Mayuresh > >
Re: urndis0 works on amd64-8.0 but not on evbarm-current
On Fri, May 10, 2019 at 06:05:34AM +, sc dying wrote: > Attached files look bogus, I'll resend. Due to some other compulsions (a lot of pkgs that I need not building under current, discussed on various threads) I reverted my environment to 8.0. Is there any possibility to try things on 8.0? Mayuresh
Re: urndis0 works on amd64-8.0 but not on evbarm-current
On Fri, May 10, 2019 at 5:56 AM sc dying wrote: > Either of attached patch might help you. Attached files look bogus, I'll resend. urndis.diff Description: Binary data dwc2.diff Description: Binary data
