Re: crash in amd64 -current
In article , Paul Goyette wrote: >With sources updated a few hours ago (2021-01-21 at 17:17:48 UTC) I am >getting the following crash as soon as it tries to start syslogd: > > breakpoint() at breakpoint+0x5 > vpanic() at vpanic+0x156 > snprintf() at snprintf > kqueue_check() at kqueue_check+0x183 > kevent1() at kevent1+0x49f > sys___kevent50() at sys___kevent50+0x33 > syscall() at syscall+0x23e > --- syscall (number 435) --- > syscall+0x23e: > >Also, why the heck does savecore(8) complain when I use the -N option? > > # savecore -fN /netbsd.bad.gdb > savecore: dumpdev /dev/console is tty; override kernel Seems that the dump device it finds by reading the kernel namelist from /netbsd.bad.gdb ends up being /dev/console... Is the machine you are running gdb the same as the machine that produced the dump? because the dev_t it read from the kernel namelist matched the dev_t for the console on the local machine in /dev. christos
crash in amd64 -current
With sources updated a few hours ago (2021-01-21 at 17:17:48 UTC) I am getting the following crash as soon as it tries to start syslogd: breakpoint() at breakpoint+0x5 vpanic() at vpanic+0x156 snprintf() at snprintf kqueue_check() at kqueue_check+0x183 kevent1() at kevent1+0x49f sys___kevent50() at sys___kevent50+0x33 syscall() at syscall+0x23e --- syscall (number 435) --- syscall+0x23e: Also, why the heck does savecore(8) complain when I use the -N option? # savecore -fN /netbsd.bad.gdb savecore: dumpdev /dev/console is tty; override kernel ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
daily CVS update output
Updating src tree: P src/distrib/sets/lists/comp/mi P src/share/man/man9/Makefile U src/share/man/man9/strlist.9 P src/share/misc/acronyms.comp P src/sys/arch/amiga/conf/DRACO P src/sys/arch/amiga/conf/GENERIC P src/sys/arch/amiga/conf/GENERIC.in P src/sys/arch/amigappc/conf/GENERIC P src/sys/arch/amigappc/conf/NULL P src/sys/arch/atari/conf/GENERIC.in P src/sys/arch/bebox/conf/GENERIC P src/sys/arch/evbarm/conf/GENERIC64 P src/sys/arch/evbarm/conf/POGO P src/sys/arch/evbmips/conf/CPMBR1400 P src/sys/arch/evbmips/conf/LINKITSMART7688 P src/sys/arch/evbmips/conf/MALTA P src/sys/arch/evbmips/conf/ZYXELKX P src/sys/arch/ews4800mips/conf/GENERIC P src/sys/arch/hp300/conf/GENERIC P src/sys/arch/hppa/conf/GENERIC P src/sys/arch/i386/conf/GENERIC_TINY P src/sys/arch/i386/conf/INSTALL_FLOPPY P src/sys/arch/i386/conf/INSTALL_TINY P src/sys/arch/i386/conf/NET4501 P src/sys/arch/mac68k/conf/GENERIC P src/sys/arch/macppc/conf/GENERIC P src/sys/arch/macppc/conf/GENERIC_601 P src/sys/arch/mvme68k/conf/GENERIC P src/sys/arch/mvme68k/conf/VME147 P src/sys/arch/news68k/conf/GENERIC P src/sys/arch/news68k/conf/GENERIC_TINY P src/sys/arch/news68k/conf/LIBERO P src/sys/arch/news68k/conf/NEWS1200 P src/sys/arch/next68k/conf/GENERIC P src/sys/arch/next68k/conf/SLAB P src/sys/arch/ofppc/conf/GENERIC P src/sys/arch/prep/conf/GENERIC P src/sys/arch/rs6000/conf/GENERIC P src/sys/arch/sandpoint/conf/ENCPP1 P src/sys/arch/sandpoint/conf/GENERIC P src/sys/arch/sandpoint/conf/SANDPOINT P src/sys/arch/sgimips/conf/GENERIC32_IP12 P src/sys/arch/sgimips/conf/GENERIC64_IP2x P src/sys/arch/sgimips/conf/GENERIC64_IP3x P src/sys/arch/sun3/conf/DISKLESS P src/sys/arch/sun3/conf/DISKLESS3X P src/sys/arch/sun3/conf/GENERIC P src/sys/arch/sun3/conf/GENERIC3X P src/sys/arch/sun3/conf/INSTALL P src/sys/arch/sun3/conf/INSTALL3X P src/sys/arch/x68k/conf/GENERIC P src/sys/arch/x68k/conf/INSTALL P src/sys/arch/x86/include/bus_defs.h P src/sys/arch/zaurus/conf/INSTALL P src/sys/dev/pci/virtio_pci.c P src/sys/dev/wscons/wsdisplay_vcons.c P src/sys/dev/wscons/wsdisplay_vconsvar.h P src/sys/kern/kern_entropy.c P src/sys/kern/kern_event.c P src/sys/lib/libkern/libkern.h P src/sys/lib/libkern/pmatch.c U src/sys/lib/libkern/strlist.c U src/sys/lib/libkern/strlist.h P src/usr.bin/make/cond.c P src/usr.bin/make/make.h P src/usr.bin/make/parse.c P src/usr.bin/make/unit-tests/cond-cmp-numeric-eq.exp P src/usr.bin/make/unit-tests/cond-cmp-numeric.exp P src/usr.bin/make/unit-tests/cond-cmp-string.exp P src/usr.bin/make/unit-tests/cond-func-defined.exp P src/usr.bin/make/unit-tests/cond-func.exp P src/usr.bin/make/unit-tests/cond-token-plain.exp P src/usr.bin/make/unit-tests/cond-token-plain.mk P src/usr.bin/make/unit-tests/cond1.exp P src/usr.bin/make/unit-tests/directive-ifdef.exp P src/usr.bin/make/unit-tests/directive-ifdef.mk P src/usr.bin/make/unit-tests/include-main.mk Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 37682224 Jan 22 03:03 ls-lRA.gz
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: 2021.01.21.20.48.33 reinoud src/sys/dev/pci/virtio_pci.c,v 1.18 Logs can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2021.01.html#2021.01.21.20.48.33
Re: virtio scsi under VirtualBox
On Thu, Jan 21, 2021 at 11:45:25AM +, Chavdar Ivanov wrote: > On Sat, 21 Nov 2020 at 16:37, Chavdar Ivanov wrote: > I see there were a few recent commits around sys/dev/pci/virtio*. Just > to mention that the presence of a virtio scsi device in a -current > (from yesterday) vm under VirtualBox 6.1.16 now results in a Guru > Meditation Error: > .. > 00:00:16.505215 [ 1.0443388] virtio1: SCSI device (rev. 0x01) > 00:00:16.505234 [ 1.0443388] vioscsi0 at virtio1: features: 0x1 It doesn't report that the feature negotiation goes wrong before printing its features, so the host is accepting v1 but nothing else and that should be OK. > 00:00:16.505323 virtio-scsi#0: virtio-scsci > numTargets=1!! > 00:00:16.505391 emR3Debug: rc=VERR_INVALID_PARAMETER Clumsy error reporting of VirtualBox! What parameter, what call etc. Could you please test the code with vioscsi revision 0? i.e. with `legacy' setting? Or/and the setting 'Virtio SCSI Single' if applicable? Also please boot the kernel with `netbsd -vx'? Is there a way to get better error message? With regards, Reinoud
Re: Automated report: NetBSD-current/i386 build failure
On Thu, Jan 21, 2021 at 04:33:40PM +0100, Reinoud Zandijk wrote: > I'd like to fix this ASAP but what is the correct way of dealing with this? Is > this an i386 failure or should code just not use bus_space_read_8() or > bus_space_write_8() ? Unless the spec requires it, you should just avoid those calls. Martin
Re: Automated report: NetBSD-current/i386 build failure
I'd like to fix this ASAP but what is the correct way of dealing with this? Is this an i386 failure or should code just not use bus_space_read_8() or bus_space_write_8() ? In the VirtIO case, it doesn't have to be written atomically though. What I could do is define a bus_space_write_8() function that gets compiled for i386 only but that's a hack. Reinoud On Thu, Jan 21, 2021 at 07:59:03PM +0700, Robert Elz wrote: > Date:Wed, 20 Jan 2021 21:17:40 + (UTC) > From:NetBSD Test Fixture > Message-ID: <161117746032.12857.1128493575446...@babylon5.netbsd.org> > > | 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 2021.01.20.19.46.48. > > The problem that caused that particular failure is fixed (martin@ > fixed the immediate problem, then I fixed a much older bug (2019 vintage) > that made martin's (correct) fix fail. > > But these commits are still responsible for the build (still) failing > > | The following commits were made between the last successful build and > | the failed build: > | > | 2021.01.20.19.46.48 reinoud src/sys/dev/acpi/virtio_acpi.c,v 1.5 > | 2021.01.20.19.46.48 reinoud src/sys/dev/fdt/virtio_mmio_fdt.c,v 1.5 > | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/if_vioif.c,v 1.66 > | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/ld_virtio.c,v 1.29 > | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/vio9p.c,v 1.3 > | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/viomb.c,v 1.12 > | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/viornd.c,v 1.14 > | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/vioscsi.c,v 1.25 > | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/virtio.c,v 1.43 > | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/virtio_pci.c,v 1.15 > | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/virtio_pcireg.h,v 1.1 > | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/virtioreg.h,v 1.7 > | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/virtiovar.h,v 1.17 > | 2021.01.20.19.46.48 reinoud src/sys/dev/virtio/virtio_mmio.c,v 1.4 > > The most recent log is at: > > http://releng.netbsd.org/b5reports/i386/2021/2021.01.21.09.50.37/build.log.tail > > and contains the following error messages (all one underlying issue) > > /tmp/build/2021.01.21.09.50.37-i386/tools/bin/i486--netbsdelf-ld: > virtio_pci.o: in function `virtio_pci_setup_queue_10': > virtio_pci.c:(.text+0x1285): undefined reference to `bus_space_write_8' > /tmp/build/2021.01.21.09.50.37-i386/tools/bin/i486--netbsdelf-ld: > virtio_pci.c:(.text+0x12a9): undefined reference to `bus_space_write_8' > /tmp/build/2021.01.21.09.50.37-i386/tools/bin/i486--netbsdelf-ld: > virtio_pci.c:(.text+0x12cd): undefined reference to `bus_space_write_8' > /tmp/build/2021.01.21.09.50.37-i386/tools/bin/i486--netbsdelf-ld: > virtio_pci.c:(.text+0x132e): undefined reference to `bus_space_write_8' > /tmp/build/2021.01.21.09.50.37-i386/tools/bin/i486--netbsdelf-ld: > virtio_pci.c:(.text+0x1357): undefined reference to `bus_space_write_8' > /tmp/build/2021.01.21.09.50.37-i386/tools/bin/i486--netbsdelf-ld: > virtio_pci.o:virtio_pci.c:(.text+0x1380): more undefined references to > `bus_space_write_8' follow > > This is as far as I can go with this one, I don't know whether i386 is > supposed to have a bus_space_write_8() function or not (and if not, what > should be used instead) or whether it exists, but for some reason isn't > being found (the error is detected in the INSTALL kernel build), or > something else. > > kre
Re: Automated report: NetBSD-current/i386 build failure
Date:Wed, 20 Jan 2021 21:17:40 + (UTC) From:NetBSD Test Fixture Message-ID: <161117746032.12857.1128493575446...@babylon5.netbsd.org> | 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 2021.01.20.19.46.48. The problem that caused that particular failure is fixed (martin@ fixed the immediate problem, then I fixed a much older bug (2019 vintage) that made martin's (correct) fix fail. But these commits are still responsible for the build (still) failing | The following commits were made between the last successful build and | the failed build: | | 2021.01.20.19.46.48 reinoud src/sys/dev/acpi/virtio_acpi.c,v 1.5 | 2021.01.20.19.46.48 reinoud src/sys/dev/fdt/virtio_mmio_fdt.c,v 1.5 | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/if_vioif.c,v 1.66 | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/ld_virtio.c,v 1.29 | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/vio9p.c,v 1.3 | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/viomb.c,v 1.12 | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/viornd.c,v 1.14 | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/vioscsi.c,v 1.25 | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/virtio.c,v 1.43 | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/virtio_pci.c,v 1.15 | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/virtio_pcireg.h,v 1.1 | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/virtioreg.h,v 1.7 | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/virtiovar.h,v 1.17 | 2021.01.20.19.46.48 reinoud src/sys/dev/virtio/virtio_mmio.c,v 1.4 The most recent log is at: http://releng.netbsd.org/b5reports/i386/2021/2021.01.21.09.50.37/build.log.tail and contains the following error messages (all one underlying issue) /tmp/build/2021.01.21.09.50.37-i386/tools/bin/i486--netbsdelf-ld: virtio_pci.o: in function `virtio_pci_setup_queue_10': virtio_pci.c:(.text+0x1285): undefined reference to `bus_space_write_8' /tmp/build/2021.01.21.09.50.37-i386/tools/bin/i486--netbsdelf-ld: virtio_pci.c:(.text+0x12a9): undefined reference to `bus_space_write_8' /tmp/build/2021.01.21.09.50.37-i386/tools/bin/i486--netbsdelf-ld: virtio_pci.c:(.text+0x12cd): undefined reference to `bus_space_write_8' /tmp/build/2021.01.21.09.50.37-i386/tools/bin/i486--netbsdelf-ld: virtio_pci.c:(.text+0x132e): undefined reference to `bus_space_write_8' /tmp/build/2021.01.21.09.50.37-i386/tools/bin/i486--netbsdelf-ld: virtio_pci.c:(.text+0x1357): undefined reference to `bus_space_write_8' /tmp/build/2021.01.21.09.50.37-i386/tools/bin/i486--netbsdelf-ld: virtio_pci.o:virtio_pci.c:(.text+0x1380): more undefined references to `bus_space_write_8' follow This is as far as I can go with this one, I don't know whether i386 is supposed to have a bus_space_write_8() function or not (and if not, what should be used instead) or whether it exists, but for some reason isn't being found (the error is detected in the INSTALL kernel build), or something else. kre
Re: virtio scsi under VirtualBox
On Sat, 21 Nov 2020 at 16:37, Chavdar Ivanov wrote:
>
> Ok, thanks. That's what I thought, but knowing it is SCSI after all,
> thought it wouldn't take much to get them working...
>
> On Sat, 21 Nov 2020 at 15:49, Martin Husemann wrote:
> >
> > On Sat, Nov 21, 2020 at 02:44:35PM +, Chavdar Ivanov wrote:
> > > Hi,
> > >
> > > I noticed the other day that he missing QUMRANET/VIRTIO PCI devices
> > > have been added
> >
> > Only the PCI IDs, no support for them yet.
I see there were a few recent commits around sys/dev/pci/virtio*. Just
to mention that the presence of a virtio scsi device in a -current
(from yesterday) vm under VirtualBox 6.1.16 now results in a Guru
Meditation Error:
..
00:00:16.505215 [ 1.0443388] virtio1: SCSI device (rev. 0x01)
00:00:16.505234 [ 1.0443388] vioscsi0 at virtio1: features: 0x1
00:00:16.505254
00:00:16.505273
00:00:16.505289 !!
00:00:16.505290 !! {vionet}
00:00:16.505290 !!
00:00:16.505292 uGuestFeatures = 0x01070020
00:00:16.505293 uQueueSelector = 0x0002
00:00:16.505294 uStatus = 0x07
00:00:16.505294 uISR = 0x00
00:00:16.505296 RX queue:
00:00:16.505297 VRing.uSize = 256
00:00:16.505298 VRing.addrDescriptors = 000107ccb000
00:00:16.505299 VRing.addrAvail = 000107ccc000
00:00:16.505299 VRing.addrUsed = 000107ccd000
00:00:16.505300 uNextAvailIndex = 0
00:00:16.505301 uNextUsedIndex = 0
00:00:16.505301 uPageNumber = 107ccb
00:00:16.505305 TX queue:
00:00:16.505306 VRing.uSize = 256
00:00:16.505306 VRing.addrDescriptors = 000107cce000
00:00:16.505307 VRing.addrAvail = 000107ccf000
00:00:16.505308 VRing.addrUsed = 000107cd
00:00:16.505308 uNextAvailIndex = 0
00:00:16.505309 uNextUsedIndex = 0
00:00:16.505310 uPageNumber = 107cce
00:00:16.505313 CTL queue:
00:00:16.505314 VRing.uSize = 16
00:00:16.505314 VRing.addrDescriptors = 000107cd1000
00:00:16.505315 VRing.addrAvail = 000107cd1100
00:00:16.505316 VRing.addrUsed = 000107cd2000
00:00:16.505317 uNextAvailIndex = 0
00:00:16.505317 uNextUsedIndex = 0
00:00:16.505318 uPageNumber = 107cd1
00:00:16.505321 !!
00:00:16.505322 !! {virtio-scsi0}
00:00:16.505322 !!
00:00:16.505323 virtio-scsi#0: virtio-scsci
numTargets=1!!
00:00:16.505391 emR3Debug: rc=VERR_INVALID_PARAMETER
00:00:24.052374 GUI: User request to power VM off on Guru Meditation.
00:00:24.052449 GUI: Passing request to power VM off from
machine-logic to UI session.
00:00:24.052460 GUI: Powering VM down on UI session power off request...
00:00:24.057412 Console: Machine state changed to 'Stopping'
00:00:24.058275 Console::powerDown(): A request to power off the VM
has been issued (mMachineState=Stopping, InUninit=0)
00:00:24.184327 VRDP: TCP server closed.
00:00:24.184881 Changing the VM state from 'GURU_MEDITATION' to 'POWERING_OFF'
00:00:24.184911 ** Guest state at power off for VCpu 3
**
00:00:24.184916 Guest CPUM (VCPU 3) state:
00:00:24.184918 rax=0003 rbx=8e0067c7
rcx=8e0067c7df98 rdx=0005
00:00:24.184922 rsi= rdi=9a187090 r8
= r9 =
00:00:24.184924 r10=0003 r11=8e0067c7
r12=8e0067c70940 r13=
00:00:24.184926 r14= r15=
00:00:24.184926 rip=ebee4f06 rsp=8e0067c7dfb0
rbp=8e0067c7dfc0 iopl=0 nv up di pl zr na po nc
00:00:24.184929 cs={0008 base= limit= flags=a09b}
00:00:24.184930 ds={0010 base= limit= flags=c093}
00:00:24.184931 es={0010 base= limit= flags=c093}
00:00:24.184932 fs={0010 base= limit= flags=c093}
00:00:24.184933 gs={0010 base=8e0067c7 limit= flags=c093}
00:00:24.184934 ss={0010 base= limit= flags=c093}
00:00:24.184935 cr0=80050033 cr2=
cr3=04b77000 cr4=0630
00:00:24.184937 dr0= dr1=
dr2= dr3=
00:00:24.184938 dr4= dr5=
dr6=0ff0 dr7=0400
00:00:24.184939 gdtr=ff04d000: idtr=:
eflags=0006
00:00:24.184941 ldtr={ base= limit= flags=0082}
00:00:24.184942 tr ={ base= limit= flags=008b}
00:00:24.184943 SysEnter={cs= eip= esp=}
00:00:24.184944 xcr=0001 xcr1=
xss= (fXStateMask=)
00:00:24.184945 FCW=037f FSW= FTW= FOP= MXCSR=1f80
MXCSR_MASK=
00:00:24.184947 FPUIP= CS= Rsrvd1= FPUDP=
DS= Rsvrd2=
00:00:24.184948 ST(0)=FPR0={''} t0
+0.00 * 2 ^ -16383 (*)
00:00:24.184951 ST(1
