Date: Mon, 4 Dec 2017 18:46:32 +0100 From: Emmanuel Vadot <manu@bidouilliste.com> To: Jeff Roberson <jeff@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r326347 - in head/sys: kern sys vm Message-ID: <20171204184632.560fb4996235a9180a37be48@bidouilliste.com> In-Reply-To: <201711282340.vASNetfP044382@repo.freebsd.org> References: <201711282340.vASNetfP044382@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 28 Nov 2017 23:40:55 +0000 (UTC) Jeff Roberson <jeff@FreeBSD.org> wrote: > Author: jeff Hi Jeff, > Date: Tue Nov 28 23:40:54 2017 > New Revision: 326347 > URL: https://svnweb.freebsd.org/changeset/base/326347 > > Log: > Eliminate kmem_arena and kmem_object in preparation for further NUMA commits. > > The arena argument to kmem_*() is now only used in an assert. A follow-up > commit will remove the argument altogether before we freeze the API for the > next release. > > This replaces the hard limit on kmem size with a soft limit imposed by UMA. When > the soft limit is exceeded we periodically wakeup the UMA reclaim thread to > attempt to shrink KVA. On 32bit architectures this should behave much more > gracefully as we exhaust KVA. On 64bit the limits are likely never hit. > > Reviewed by: markj, kib (some objections) > Discussed with: alc > Tested by: pho > Sponsored by: Netflix / Dell EMC Isilon > Differential Revision: https://reviews.freebsd.org/D13187 > > Modified: > head/sys/kern/kern_malloc.c > head/sys/kern/subr_vmem.c > head/sys/sys/vmem.h > head/sys/vm/memguard.c > head/sys/vm/uma.h > head/sys/vm/uma_core.c > head/sys/vm/uma_int.h > head/sys/vm/vm_kern.c > head/sys/vm/vm_map.c > head/sys/vm/vm_object.c > head/sys/vm/vm_object.h This seems to break USB (EHCI and OHCI) on Pine64 (arm64) The board just hang when plugin usb device, setting hw.usb.ehci.debug=3 this is what I have when plugging an usb stick : ehci_root_intr: port 1 changed ehci_set_hw_power: ehci_roothub_exec: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 ehci_roothub_exec: type=0x23 request=0x01 wLen=0x0000 wValue=0x0010 wIndex=0x0001 ehci_roothub_exec: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 ehci_roothub_exec: type=0x23 request=0x01 wLen=0x0000 wValue=0x0014 wIndex=0x0001 ehci_roothub_exec: type=0x23 request=0x03 wLen=0x0000 wValue=0x0004 wIndex=0x0001 ehci_roothub_exec: ehci after reset, status=0x00001005 ehci_roothub_exec: ehci port 1 reset, status = 0x00001005 ehci_roothub_exec: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 ehci_roothub_exec: type=0x23 request=0x01 wLen=0x0000 wValue=0x0014 wIndex=0x0001 ehci_roothub_exec: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 ehci_ep_init: endpoint=0xfffffd00004f10f8, addr=0, endpt=0, mode=0 (1) If you have any idea on how to debug/resolve this, Cheers, -- Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171204184632.560fb4996235a9180a37be48>