GSoC ZFS root support
Hello, My name is Bruno Maximo e Melo, I'm a bachelor student in Information Systems from University of São Paulo (USP). I have almost 2 years professional experience on web development and devops. I have used FreeBSD for years, where I have built my first custom kernel. Now, I want to enter in low level programming because I like to know how things work and I want to make part of that Unix story. I'm advocating for the study of NetBSD at USP because of features like prekern, rump, etc... and more people are now interested in contributing to NetBSD in the next GSoC. Actually I'm running NetBSD aarch64 in Qemu because I'm learning ARM assembly language and I have not chosen a Linux distro because I wanted to interact and get used to NetBSD. I learned programming in C language, and already had theoretical class of operating systems. But I'm completely newbie in OS development and never had the interested to write an OS from scratch, but to develop an existant one and make part of its community. That's why I want to take this GSoC. I have a disorganized github at github.com/brunomaximom where I put work I did in the semester for grad school. I'm looking for a mentor to this GSoC. I know I need to take the code from FreeBSD here https://github.com/freebsd/freebsd/tree/master/stand/libsa/zfs and port it to work on NetBSD's libsa here https://github.com/NetBSD/src/tree/trunk/sys/lib/libsa. I hope to get a feedback soon :D. Thanks for read me. Link of the project: https://wiki.netbsd.org/projects/project/zfs_root/
Re: All (?) network tests failing
Unfortunately they still work for me after a clean build. I am going to try to download a standard build... christos > On Mar 30, 2020, at 3:35 PM, Christos Zoulas wrote: > > Signed PGP part > Ok, let me start a clean build. > > christos > >> On Mar 30, 2020, at 2:36 PM, Andreas Gustafsson wrote: >> >> Christos Zoulas wrote: >>> All the tests are failing for you the same way: >>> >>> rump.route: SO_RERROR: Socket operation on non-socket >>> >>> I doubt that my gif change affected that. This smells to me like the rump fd >>> hijack is not >>> working either because we have some new system call involved or something is >>> messing >>> up the file descriptors. What is your build host? >> >> The tests are failing on both the TNF testbed and my own. The >> respective OS versions are: >> >> NetBSD babylon5.netbsd.org 8.1_STABLE NetBSD 8.1_STABLE (BABYLON5) #1: Fri >> Jan 24 21:50:18 UTC 2020 >> s...@franklin.netbsd.org:/home/netbsd/8/amd64/obj/sys/arch/amd64/compile/BABYLON5 >> amd64 >> NetBSD guido.araneus.fi 9.0 NetBSD 9.0 (GENERIC) #0: Fri Feb 14 00:06:28 UTC >> 2020 mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC >> amd64 >> >> -- >> Andreas Gustafsson, g...@gson.org > > > signature.asc Description: Message signed with OpenPGP
Re: All (?) network tests failing
Ok, let me start a clean build. christos > On Mar 30, 2020, at 2:36 PM, Andreas Gustafsson wrote: > > Christos Zoulas wrote: >> All the tests are failing for you the same way: >> >> rump.route: SO_RERROR: Socket operation on non-socket >> >> I doubt that my gif change affected that. This smells to me like the rump fd >> hijack is not >> working either because we have some new system call involved or something is >> messing >> up the file descriptors. What is your build host? > > The tests are failing on both the TNF testbed and my own. The > respective OS versions are: > > NetBSD babylon5.netbsd.org 8.1_STABLE NetBSD 8.1_STABLE (BABYLON5) #1: Fri > Jan 24 21:50:18 UTC 2020 > s...@franklin.netbsd.org:/home/netbsd/8/amd64/obj/sys/arch/amd64/compile/BABYLON5 > amd64 > NetBSD guido.araneus.fi 9.0 NetBSD 9.0 (GENERIC) #0: Fri Feb 14 00:06:28 UTC > 2020 mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64 > > -- > Andreas Gustafsson, g...@gson.org signature.asc Description: Message signed with OpenPGP
Re: All (?) network tests failing
Christos Zoulas wrote: > All the tests are failing for you the same way: > > rump.route: SO_RERROR: Socket operation on non-socket > > I doubt that my gif change affected that. This smells to me like the rump fd > hijack is not > working either because we have some new system call involved or something is > messing > up the file descriptors. What is your build host? The tests are failing on both the TNF testbed and my own. The respective OS versions are: NetBSD babylon5.netbsd.org 8.1_STABLE NetBSD 8.1_STABLE (BABYLON5) #1: Fri Jan 24 21:50:18 UTC 2020 s...@franklin.netbsd.org:/home/netbsd/8/amd64/obj/sys/arch/amd64/compile/BABYLON5 amd64 NetBSD guido.araneus.fi 9.0 NetBSD 9.0 (GENERIC) #0: Fri Feb 14 00:06:28 UTC 2020 mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64 -- Andreas Gustafsson, g...@gson.org
Re: All (?) network tests failing
On Mon, Mar 30, 2020 at 08:28:10PM +0200, Martin Husemann wrote: > On Mon, Mar 30, 2020 at 02:25:01PM -0400, Christos Zoulas wrote: > > What is your build host? > > I am running the latest build I installed built from NetBSD/current to > > NetBSD/current. > > I see the same fallout on a NetBSD-current build on a NetBSD-current > (but it crept in delayed, probably because something did not get immediately > rebuild by build.sh -u). I also see the same with builds from releng.netbsd.org: http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/HEAD/amd64/202003270130Z_atf.html#failed-tcs-summary -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: All (?) network tests failing
On Mon, Mar 30, 2020 at 02:25:01PM -0400, Christos Zoulas wrote: > What is your build host? > I am running the latest build I installed built from NetBSD/current to > NetBSD/current. I see the same fallout on a NetBSD-current build on a NetBSD-current (but it crept in delayed, probably because something did not get immediately rebuild by build.sh -u). Martin
Re: All (?) network tests failing
> >> 2. The gif related tests are failing because of a recent change to record >> mac addresses >>I committed a fix for that. > > Your fix didn't work; the gif tests are still failing with > src/tests/net/net_common.sh 1.40: > > > http://www.gson.org/netbsd/bugs/build/amd64-baremetal/2020/2020.03.30.13.01.39/test.html#net_if_gif_t_gif_gif_basic_ipv4overipv4 > >> 3. The rest of the tests (I've sampled 5 of them) don't fail for me. > > If you do a full release build from scratch, install the release, and > run the tests in the installed release like the testbeds do, I bet > they will fail for you, too. All the tests are failing for you the same way: rump.route: SO_RERROR: Socket operation on non-socket <>I doubt that my gif change affected that. This smells to me like the rump fd hijack is not working either because we have some new system call involved or something is messing up the file descriptors. What is your build host? I am running the latest build I installed built from NetBSD/current to NetBSD/current. christos signature.asc Description: Message signed with OpenPGP
Re: All (?) network tests failing
Christos Zoulas wrote: > I've been looking into this: > 1. The libcrypto/bn test just needs more time That may be. That one never failed on real hardware for me (it just went from taking 3 seconds to 14), but 200+ other test cases did fail, and still do. > 2. The gif related tests are failing because of a recent change to record mac > addresses > I committed a fix for that. Your fix didn't work; the gif tests are still failing with src/tests/net/net_common.sh 1.40: http://www.gson.org/netbsd/bugs/build/amd64-baremetal/2020/2020.03.30.13.01.39/test.html#net_if_gif_t_gif_gif_basic_ipv4overipv4 > 3. The rest of the tests (I've sampled 5 of them) don't fail for me. If you do a full release build from scratch, install the release, and run the tests in the installed release like the testbeds do, I bet they will fail for you, too. -- Andreas Gustafsson, g...@gson.org
Re: All (?) network tests failing
I've been looking into this: 1. The libcrypto/bn test just needs more time 2. The gif related tests are failing because of a recent change to record mac addresses I committed a fix for that. 3. The rest of the tests (I've sampled 5 of them) don't fail for me. christos > On Mar 30, 2020, at 8:50 AM, Martin Husemann wrote: > > On Mon, Mar 30, 2020 at 03:44:49PM +0300, Andreas Gustafsson wrote: >> Martin Husemann wrote: >>> -current just had a serious regression in test results, it seems like >>> ~all networking tests are failing now: >> >> Many (most?) of these have been failing for more than a week now, as >> reported on current-users in >> >> http://mail-index.netbsd.org/current-users/2020/03/23/msg038127.html >> >> which identified both the commits and the developer responsible for >> the breakage. > > Well, they did not fail for me, and I can't see how the openssl upgrade > is related - there certainly is something strange ongoing (maybe a bug > in the build system not triggering all rebuilds for update builds). > > Martin signature.asc Description: Message signed with OpenPGP
Re: All (?) network tests failing
On Mon, Mar 30, 2020 at 03:44:49PM +0300, Andreas Gustafsson wrote: > Martin Husemann wrote: > > -current just had a serious regression in test results, it seems like > > ~all networking tests are failing now: > > Many (most?) of these have been failing for more than a week now, as > reported on current-users in > > http://mail-index.netbsd.org/current-users/2020/03/23/msg038127.html > > which identified both the commits and the developer responsible for > the breakage. Well, they did not fail for me, and I can't see how the openssl upgrade is related - there certainly is something strange ongoing (maybe a bug in the build system not triggering all rebuilds for update builds). Martin
Re: All (?) network tests failing
Martin Husemann wrote: > -current just had a serious regression in test results, it seems like > ~all networking tests are failing now: Many (most?) of these have been failing for more than a week now, as reported on current-users in http://mail-index.netbsd.org/current-users/2020/03/23/msg038127.html which identified both the commits and the developer responsible for the breakage. -- Andreas Gustafsson, g...@gson.org
Re: All (?) network tests failing
rump.route: SO_RERROR: Socket operation on non-socket Many of the ones not failing "silently" show that. Martin
All (?) network tests failing
-current just had a serious regression in test results, it seems like ~all networking tests are failing now: Failed test cases: dev/audio/t_audio:AUDIO_WSEEK, lib/libc/sys/t_ptrace_sigchld:traceme_raise1, lib/libc/sys/t_ptrace_wait:core_dump_procinfo, lib/libc/sys/t_ptrace_wait3:core_dump_procinfo, lib/libc/sys/t_ptrace_wait4:core_dump_procinfo, lib/libc/sys/t_ptrace_wait6:core_dump_procinfo, lib/libc/sys/t_ptrace_waitid:core_dump_procinfo, lib/libc/sys/t_ptrace_waitid:syscall_signal_on_sce, lib/libc/sys/t_ptrace_waitpid:core_dump_procinfo, lib/libcurses/t_curses:mvscanw, net/net/t_forwarding:ipforwarding_fragment_v4, net/net/t_ipv6address:linklocal, net/net/t_ping_opts:ping_opts_gateway, net/net/t_ping_opts:ping_opts_recordroute, net/net/t_ping_opts:ping_opts_sourceaddr, net/net/t_ping6_opts:ping6_opts_gateway, net/net/t_ping6_opts:ping6_opts_interface, net/net/t_ping6_opts:ping6_opts_sourceaddr, net/arp/t_arp:arp_garp, net/arp/t_arp:arp_garp_without_dad, net/arp/t_arp:arp_link_activation, net/arp/t_arp:arp_proxy_arp_pub, net/arp/t_arp:arp_proxy_arp_pubproxy, net/arp/t_dad:dad_basic, net/if_ipsec/t_ipsec_natt:ipsecif_natt_transport_null, net/if_ipsec/t_ipsec_natt:ipsecif_natt_transport_rijndaelcbc, net/if_pppoe/t_pppoe:pppoe6_pap, net/if_pppoe/t_pppoe:pppoe_chap, net/if_pppoe/t_pppoe:pppoe_pap, net/ipsec/t_ipsec_gif:ipsec_gif_ipv4_transport_ah_hmacsha512, net/ipsec/t_ipsec_gif:ipsec_gif_ipv4_transport_ah_null, net/ipsec/t_ipsec_gif:ipsec_gif_ipv4_transport_esp_null, net/ipsec/t_ipsec_gif:ipsec_gif_ipv4_transport_esp_rijndaelcbc, net/ipsec/t_ipsec_gif:ipsec_gif_ipv4_tunnel_ah_hmacsha512, net/ipsec/t_ipsec_gif:ipsec_gif_ipv4_tunnel_ah_null, net/ipsec/t_ipsec_gif:ipsec_gif_ipv4_tunnel_esp_null, net/ipsec/t_ipsec_gif:ipsec_gif_ipv4_tunnel_esp_rijndaelcbc, net/ipsec/t_ipsec_gif:ipsec_gif_ipv6_transport_ah_hmacsha512, net/ipsec/t_ipsec_gif:ipsec_gif_ipv6_transport_ah_null, net/ipsec/t_ipsec_gif:ipsec_gif_ipv6_transport_esp_null, net/ipsec/t_ipsec_gif:ipsec_gif_ipv6_transport_esp_rijndaelcbc, net/ipsec/t_ipsec_gif:ipsec_gif_ipv6_tunnel_ah_hmacsha512, net/ipsec/t_ipsec_gif:ipsec_gif_ipv6_tunnel_ah_null, net/ipsec/t_ipsec_gif:ipsec_gif_ipv6_tunnel_esp_null, net/ipsec/t_ipsec_gif:ipsec_gif_ipv6_tunnel_esp_rijndaelcbc, net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv4_transport_ah_hmacsha512, net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv4_transport_ah_null, net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv4_transport_esp_null, net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv4_transport_esp_rijndaelcbc, net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv4_tunnel_ah_hmacsha512, net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv4_tunnel_ah_null, net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv4_tunnel_esp_null, net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv4_tunnel_esp_rijndaelcbc, net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv6_transport_ah_hmacsha512, net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv6_transport_ah_null, net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv6_transport_esp_null, net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv6_transport_esp_rijndaelcbc, net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv6_tunnel_ah_hmacsha512, net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv6_tunnel_ah_null, net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv6_tunnel_esp_null, net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv6_tunnel_esp_rijndaelcbc, net/ipsec/t_ipsec_misc:ipsec_getspi_update_sa_ah_hmacsha512, net/ipsec/t_ipsec_misc:ipsec_getspi_update_sa_ah_null, net/ipsec/t_ipsec_misc:ipsec_getspi_update_sa_esp_null, net/ipsec/t_ipsec_misc:ipsec_getspi_update_sa_esp_rijndaelcbc, net/ipsec/t_ipsec_misc:ipsec_lifetime_ipv4_ah_hmacsha512, net/ipsec/t_ipsec_misc:ipsec_lifetime_ipv4_ah_null, net/ipsec/t_ipsec_misc:ipsec_lifetime_ipv4_esp_null, net/ipsec/t_ipsec_misc:ipsec_lifetime_ipv4_esp_rijndaelcbc, net/ipsec/t_ipsec_misc:ipsec_lifetime_ipv6_ah_hmacsha512, net/ipsec/t_ipsec_misc:ipsec_lifetime_ipv6_ah_null, net/ipsec/t_ipsec_misc:ipsec_lifetime_ipv6_esp_null, net/ipsec/t_ipsec_misc:ipsec_lifetime_ipv6_esp_rijndaelcbc, net/ipsec/t_ipsec_misc:ipsec_spi_ah_hmacsha512_preferred_new_delete, net/ipsec/t_ipsec_misc:ipsec_spi_ah_hmacsha512_preferred_new_timeout, net/ipsec/t_ipsec_misc:ipsec_spi_ah_hmacsha512_preferred_old_delete, net/ipsec/t_ipsec_misc:ipsec_spi_ah_hmacsha512_preferred_old_timeout, net/ipsec/t_ipsec_misc:ipsec_spi_ah_null_preferred_new_delete, net/ipsec/t_ipsec_misc:ipsec_spi_ah_null_preferred_new_timeout, net/ipsec/t_ipsec_misc:ipsec_spi_ah_null_preferred_old_delete, net/ipsec/t_ipsec_misc:ipsec_spi_ah_null_preferred_old_timeout, net/ipsec/t_ipsec_misc:ipsec_spi_esp_null_preferred_new_delete, net/ipsec/t_ipsec_misc:ipsec_spi_esp_null_preferred_new_timeout, net/ipsec/t_ipsec_misc:ipsec_spi_esp_null_preferred_old_delete, net/ipsec/t_ipsec_misc:ipsec_spi_esp_null_preferred_old_timeout, net/ipsec/t_ipsec_misc:ipsec_spi_esp_rijndaelcbc_preferred_new_delete, net/ipsec/t_ipsec_misc:ipsec_spi_esp_rijndaelcbc_preferred_new_timeout, net/ipsec/t_ipsec_misc:ipsec_spi_esp_rijndaelcbc_preferred_old_delete,
[PATCH] xhci: Reduce ring memory usage
Hello.
Most devices use a few endpoints but current xhci code allocates all of
31 endpoints in the slot when a device is connected.
This patch defers ring memory allocation to when usbd_open_pipe opens
the endpoint, and it allocates one ring for an endpoint.
For example, a ordinary network device uses 4 endpoints.
It requires 192296 bytes in old code on amd64, it requires
25096 bytes in new code.
Old:
sizeof xhci_slot 1832
ring dma buf 4096 (per endpoint) x 31
xr_cookie 2048 (per endpoint) x 31
1832 + (4096 + 2048) x 32 = 192296
New:
sizeof xhci_slot 296
sizeof xhci_ring 56 (per endpoint) x 4
ring dma buf 4096 (per endpoint) x 4
xr_cookie 2048 (per endpoint) x 4
296 + (56 + 4096 + 2048) x 4 = 25096
I've replaced xhci_endpoint in xhci_slot with xhci_ring *[], as there are
no other structures other than xhci_ring in xhci_endpoint.
--- src/sys/dev/usb/xhcivar.h.orig 2019-01-07 07:03:37.277230389 +
+++ src/sys/dev/usb/xhcivar.h 2020-03-14 07:08:44.887226324 +
@@ -32,6 +32,7 @@
#include
#define XHCI_XFER_NTRB 20
+#define XHCI_MAX_DCI 31
struct xhci_soft_trb {
uint64_t trb_0;
@@ -70,7 +71,7 @@ struct xhci_endpoint {
struct xhci_slot {
usb_dma_t xs_dc_dma;/* device context page */
usb_dma_t xs_ic_dma;/* input context page */
- struct xhci_endpoint xs_ep[32]; /* endpoints */
+ struct xhci_ring *xs_xr[XHCI_MAX_DCI+1];/* transfer ring */
u_int xs_idx; /* slot index */
};
@@ -114,8 +115,8 @@ struct xhci_softc {
struct xhci_slot * sc_slots;
- struct xhci_ring sc_cr; /* command ring */
- struct xhci_ring sc_er; /* event ring */
+ struct xhci_ring *sc_cr;/* command ring */
+ struct xhci_ring *sc_er;/* event ring */
usb_dma_t sc_eventst_dma;
usb_dma_t sc_dcbaa_dma;
--- src/sys/dev/usb/xhci.c.orig 2020-03-14 03:10:50.091960001 +
+++ src/sys/dev/usb/xhci.c 2020-03-16 04:36:02.901525857 +
@@ -164,7 +164,7 @@ static usbd_status xhci_do_command(struc
static usbd_status xhci_do_command_locked(struct xhci_softc * const,
struct xhci_soft_trb * const, int);
static usbd_status xhci_init_slot(struct usbd_device *, uint32_t);
-static void xhci_free_slot(struct xhci_softc *, struct xhci_slot *, int, int);
+static void xhci_free_slot(struct xhci_softc *, struct xhci_slot *);
static usbd_status xhci_set_address(struct usbd_device *, uint32_t, bool);
static usbd_status xhci_enable_slot(struct xhci_softc * const,
uint8_t * const);
@@ -175,8 +175,9 @@ static void xhci_set_dcba(struct xhci_so
static usbd_status xhci_update_ep0_mps(struct xhci_softc * const,
struct xhci_slot * const, u_int);
static usbd_status xhci_ring_init(struct xhci_softc * const,
-struct xhci_ring * const, size_t, size_t);
-static void xhci_ring_free(struct xhci_softc * const, struct xhci_ring *
const);
+struct xhci_ring **, size_t, size_t);
+static void xhci_ring_free(struct xhci_softc * const,
+struct xhci_ring ** const);
static void xhci_setup_ctx(struct usbd_pipe *);
static void xhci_setup_route(struct usbd_pipe *, uint32_t *);
@@ -1194,20 +1195,20 @@ xhci_init(struct xhci_softc *sc)
struct xhci_erste *erst;
erst = KERNADDR(>sc_eventst_dma, 0);
- erst[0].erste_0 = htole64(xhci_ring_trbp(>sc_er, 0));
- erst[0].erste_2 = htole32(sc->sc_er.xr_ntrb);
+ erst[0].erste_0 = htole64(xhci_ring_trbp(sc->sc_er, 0));
+ erst[0].erste_2 = htole32(sc->sc_er->xr_ntrb);
erst[0].erste_3 = htole32(0);
usb_syncmem(>sc_eventst_dma, 0,
XHCI_ERSTE_SIZE * XHCI_EVENT_RING_SEGMENTS, BUS_DMASYNC_PREWRITE);
xhci_rt_write_4(sc, XHCI_ERSTSZ(0), XHCI_EVENT_RING_SEGMENTS);
xhci_rt_write_8(sc, XHCI_ERSTBA(0), DMAADDR(>sc_eventst_dma, 0));
- xhci_rt_write_8(sc, XHCI_ERDP(0), xhci_ring_trbp(>sc_er, 0) |
+ xhci_rt_write_8(sc, XHCI_ERDP(0), xhci_ring_trbp(sc->sc_er, 0) |
XHCI_ERDP_LO_BUSY);
xhci_op_write_8(sc, XHCI_DCBAAP, DMAADDR(>sc_dcbaa_dma, 0));
- xhci_op_write_8(sc, XHCI_CRCR, xhci_ring_trbp(>sc_cr, 0) |
- sc->sc_cr.xr_cs);
+ xhci_op_write_8(sc, XHCI_CRCR, xhci_ring_trbp(sc->sc_cr, 0) |
+ sc->sc_cr->xr_cs);
xhci_op_barrier(sc, 0, 4, BUS_SPACE_BARRIER_WRITE);
@@ -1543,7 +1544,7 @@ xhci_set_dequeue_locked(struct usbd_pipe
struct xhci_softc * const sc = XHCI_PIPE2SC(pipe);
struct xhci_slot * const xs = pipe->up_dev->ud_hcpriv;
const u_int dci = xhci_ep_get_dci(pipe->up_endpoint->ue_edesc);
- struct xhci_ring * const xr = >xs_ep[dci].xe_tr;
+ struct xhci_ring * const xr = xs->xs_xr[dci];
struct xhci_soft_trb trb;
usbd_status err;
@@ -1551,6 +1552,7 @@ xhci_set_dequeue_locked(struct usbd_pipe
XHCIHIST_CALLARGS("slot %ju dci %ju", xs->xs_idx, dci, 0, 0);
KASSERT(mutex_owned(>sc_lock));
+
