Re: CVS commit: src/sys/dev/pci
In article <27744.1611294...@splode.eterna.com.au>, matthew green wrote: >> +#ifndef _LP64 > >_LP64 is a terrible way to make this choice. > >heaps of our 32 bit platforms implement the _8 variants. Let's add a _HAVE_ variable then? christos
re: CVS commit: src/sys/dev/pci
> +#ifndef _LP64 _LP64 is a terrible way to make this choice. heaps of our 32 bit platforms implement the _8 variants. .mrg.
Re: CVS commit: src/sys/dev/pci
In article <20210121204833.9ebcff...@cvs.netbsd.org>,
Reinoud Zandijk wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: reinoud
>Date: Thu Jan 21 20:48:33 UTC 2021
>
>Modified Files:
> src/sys/dev/pci: virtio_pci.c
>
>Log Message:
>Remove dependency on bus_space_write_8() for i386 and instead implement it as
>two bus_space_write_4()'s as allowed in the spec.
Isn't it better to do it this way so it always works (not just for little
endian)? We could even provide this in the MI bus.h if others need it
and don't care about the non-atomic transactions. I have not even compile
tested it.
christos
Index: virtio_pci.c
===
RCS file: /cvsroot/src/sys/dev/pci/virtio_pci.c,v
retrieving revision 1.18
diff -u -p -u -r1.18 virtio_pci.c
--- virtio_pci.c21 Jan 2021 20:48:33 - 1.18
+++ virtio_pci.c22 Jan 2021 04:46:24 -
@@ -34,6 +34,7 @@ __KERNEL_RCSID(0, "$NetBSD: virtio_pci.c
#include
#include
#include
+#include
#include
#include
@@ -731,9 +732,20 @@ virtio_pci_read_queue_size_10(struct vir
* By definition little endian only in v1.0 and 8 byters are allowed to be
* written as two 4 byters
*/
-#define bus_space_write_le_8(iot, ioh, reg, val) \
- bus_space_write_4(iot, ioh, reg, ((uint64_t) (val)) & 0x); \
- bus_space_write_4(iot, ioh, reg + 4, ((uint64_t) (val)) >> 32);
+#ifndef _LP64
+static __inline void
+bus_space_write_8(bus_space_tag_t iot, bus_space_handle_t ioh,
+ bus_size_t offset, uint64_t value)
+{
+#if _QUAD_HIGHWORD
+ bus_space_write_4(iot, ioh, offset, (uint32_t)(value & 0x));
+ bus_space_write_4(iot, ioh, offset + 4, (uint32_t)(value >> 32));
+#else
+ bus_space_write_4(iot, ioh, offset, (uint32_t)(value >> 32));
+ bus_space_write_4(iot, ioh, offset + 4, (uint32_t)(value & 0x));
+#endif
+}
+#endif /* !_LP64 */
static void
virtio_pci_setup_queue_10(struct virtio_softc *sc, uint16_t idx, uint64_t addr)
@@ -747,15 +759,15 @@ virtio_pci_setup_queue_10(struct virtio_
bus_space_write_2(iot, ioh, VIRTIO_CONFIG1_QUEUE_SELECT, vq->vq_index);
if (addr == 0) {
bus_space_write_2(iot, ioh, VIRTIO_CONFIG1_QUEUE_ENABLE, 0);
- bus_space_write_le_8(iot, ioh, VIRTIO_CONFIG1_QUEUE_DESC, 0);
- bus_space_write_le_8(iot, ioh, VIRTIO_CONFIG1_QUEUE_AVAIL, 0);
- bus_space_write_le_8(iot, ioh, VIRTIO_CONFIG1_QUEUE_USED, 0);
+ bus_space_write_8(iot, ioh, VIRTIO_CONFIG1_QUEUE_DESC, 0);
+ bus_space_write_8(iot, ioh, VIRTIO_CONFIG1_QUEUE_AVAIL, 0);
+ bus_space_write_8(iot, ioh, VIRTIO_CONFIG1_QUEUE_USED, 0);
} else {
- bus_space_write_le_8(iot, ioh,
+ bus_space_write_8(iot, ioh,
VIRTIO_CONFIG1_QUEUE_DESC, addr);
- bus_space_write_le_8(iot, ioh,
+ bus_space_write_8(iot, ioh,
VIRTIO_CONFIG1_QUEUE_AVAIL, addr + vq->vq_availoffset);
- bus_space_write_le_8(iot, ioh,
+ bus_space_write_8(iot, ioh,
VIRTIO_CONFIG1_QUEUE_USED, addr + vq->vq_usedoffset);
bus_space_write_2(iot, ioh,
VIRTIO_CONFIG1_QUEUE_ENABLE, 1);
@@ -771,7 +783,6 @@ virtio_pci_setup_queue_10(struct virtio_
VIRTIO_CONFIG1_QUEUE_MSIX_VECTOR, vec);
}
}
-#undef bus_space_write_le_8
static void
virtio_pci_set_status_10(struct virtio_softc *sc, int status)
Re: CVS commit: src/sys/kern (kern_event.c)
Ooopppsss ignore me - looks like this was already fixed and my update missed it. I'll retry. On Thu, 21 Jan 2021, Paul Goyette wrote: This change seems to break everything! As soon as I try to start syslogd I hit the panic() that you added [ 28.0253983] panic: kqueue_scan,1491: kq=0xdc13890bc4c0 kq->kq_count(1) != count(0), nmarker=1 [ 28.0253983] cpu0: Begin traceback... [ 28.0253983] vpanic() at netbsd:vpanic+0x156 [ 28.0253983] snprintf() at netbsd:snprintf [ 28.0253983] kqueue_check() at netbsd:kqueue_check+0x183 [ 28.0253983] kevent1() at netbsd:kevent1+0x49f [ 28.0253983] sys___kevent50() at netbsd:sys___kevent50+0x33 [ 28.0253983] syscall() at netbsd:syscall+0x23e [ 28.0253983] --- syscall (number 435) --- [ 28.0253983] netbsd:syscall+0x23e: [ 28.0253983] cpu0: End traceback... [ 28.0253983] fatal breakpoint trap in supervisor mode [ 28.0253983] trap type 1 code 0 rip 0x8021f415 cs 0x8 rflags 0x202 cr2 0x78742459e000 ilevel 0x8 rsp 0xa809281ebb50 [ 28.0253983] curlwp 0xdc138aa46540 pid 1352.1352 lowest kstack 0xa809281e72c0 Stopped in pid 1352.1352 (syslogd) at netbsd:breakpoint+0x5: leave I have a full crash dump if you need any further info. Module Name:src Committed By: jdolecek Date: Thu Jan 21 18:09:23 UTC 2021 Modified Files: src/sys/kern: kern_event.c Log Message: adjust kq_check() (enabled with DEBUG) to new reality - it's now perfectly normal to have kq_count bigger than number of the linked entries on the kqueue PR kern/50094, problem pointed out by Chuck Silvers To generate a diff of this commit: cvs rdiff -u -r1.111 -r1.112 src/sys/kern/kern_event.c 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 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+ ++--+---+ | 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 | ++--+---+
Re: CVS commit: src/sys/kern (kern_event.c)
This change seems to break everything! As soon as I try to start syslogd I hit the panic() that you added [ 28.0253983] panic: kqueue_scan,1491: kq=0xdc13890bc4c0 kq->kq_count(1) != count(0), nmarker=1 [ 28.0253983] cpu0: Begin traceback... [ 28.0253983] vpanic() at netbsd:vpanic+0x156 [ 28.0253983] snprintf() at netbsd:snprintf [ 28.0253983] kqueue_check() at netbsd:kqueue_check+0x183 [ 28.0253983] kevent1() at netbsd:kevent1+0x49f [ 28.0253983] sys___kevent50() at netbsd:sys___kevent50+0x33 [ 28.0253983] syscall() at netbsd:syscall+0x23e [ 28.0253983] --- syscall (number 435) --- [ 28.0253983] netbsd:syscall+0x23e: [ 28.0253983] cpu0: End traceback... [ 28.0253983] fatal breakpoint trap in supervisor mode [ 28.0253983] trap type 1 code 0 rip 0x8021f415 cs 0x8 rflags 0x202 cr2 0x78742459e000 ilevel 0x8 rsp 0xa809281ebb50 [ 28.0253983] curlwp 0xdc138aa46540 pid 1352.1352 lowest kstack 0xa809281e72c0 Stopped in pid 1352.1352 (syslogd) at netbsd:breakpoint+0x5: leave I have a full crash dump if you need any further info. Module Name:src Committed By: jdolecek Date: Thu Jan 21 18:09:23 UTC 2021 Modified Files: src/sys/kern: kern_event.c Log Message: adjust kq_check() (enabled with DEBUG) to new reality - it's now perfectly normal to have kq_count bigger than number of the linked entries on the kqueue PR kern/50094, problem pointed out by Chuck Silvers To generate a diff of this commit: cvs rdiff -u -r1.111 -r1.112 src/sys/kern/kern_event.c 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 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: CVS commit: src/sys/arch/evbarm/conf
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/kern
I believe it's this change that's made my vbox image panic at the drop of
a hat; while it occasionally panics before it even hits single user, it
also consistently panics when starting syslogd (even from single-user):
panic: kqueue_scan,1491: kq=0xc779aeff6dc0 kq->kq_count(1) != count(0),
nmarker=1
and the call chain is syscall -> sys___kevent50 -> kevent1 -> kqueue_check
it also causes a panic while trying to dump more than half the time,
but I have managed to get an image or two. ("panic: atastart: channel 0
busy, xfer not possible", if you're curious.)
On Wed, Jan 20, 2021 at 09:39:09PM +, Jaromir Dolecek wrote:
> Module Name: src
> Committed By: jdolecek
> Date: Wed Jan 20 21:39:09 UTC 2021
>
> Modified Files:
> src/sys/kern: kern_event.c
>
> Log Message:
> fix a race in kqueue_scan() - when multiple threads check the same
> kqueue, it could happen other thread seen empty kqueue while kevent
> was being checked for re-firing and re-queued
>
> make sure to keep retrying if there are outstanding kevents even
> if no kevent is found on first pass through the queue, and only
> drop the KN_QUEUED flag and kq_count when actually completely done
> with the kevent
>
> change is inspired by the FreeBSD in-flux handling, but without
> introducing the reference counting
>
> PR kern/50094 by Christof Meerwald
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.110 -r1.111 src/sys/kern/kern_event.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
> On Jan 21, 2021, at 12:00 AM, Martin Husemann > wrote: > > On Wed, Jan 20, 2021 at 07:46:48PM +, Reinoud Zandijk wrote: >> Module Name: src >> Committed By:reinoud >> Date:Wed Jan 20 19:46:48 UTC 2021 >> > [..] >> Log Message: >> Add VirtIO PCI v1.0 attachments and fix the drivers affected. >> >> * virtio on sparc64 attaches but is it not functioning though not a >> regression. > > While not a regression by this commit, it *did* work in netbsd-8, > so overall a bad regression that we should fix. This could be a bug in Qemu … it does not work on Alpha, either, and Jonathan Kollasch tracked down to Qemu 5’s Virtio subsystem not considering the DMA window on the Alpha platform. -- thorpej
Re: CVS commit: src/sys/dev
On Wed, Jan 20, 2021 at 07:46:48PM +, Reinoud Zandijk wrote: > Module Name: src > Committed By: reinoud > Date: Wed Jan 20 19:46:48 UTC 2021 > [..] > Log Message: > Add VirtIO PCI v1.0 attachments and fix the drivers affected. > > * virtio on sparc64 attaches but is it not functioning though not a > regression. While not a regression by this commit, it *did* work in netbsd-8, so overall a bad regression that we should fix. Martin
