Re: CVS commit: src/sys/arch/x86/x86
Le 01/07/2016 à 16:22, matthew green a écrit : We use only one L4 slot for the direct map, which means that we cannot map more than 512GB. Panic properly if this limit is reached. thanks for making the failure mode clear. it would be nice to remove this limitation, and support upto at least 16TB of ram. systems with well over 512GB are not entirely uncommon in 2016, and the future is coming ;) NetBSD cannot support up to 512GB. The page levels used for the direct map are stored below the IOM area in physical memory. If the machine has more than ~160GB, and the CPU does not support superpages, the page levels and the IOM area collide, and the last page levels basically get overwritten.
Re: CVS commit: src/sys/dev/usb
On 2016/07/01 21:16, Nick Hudson wrote: Module Name:src Committed By: skrll Date: Fri Jul 1 12:16:36 UTC 2016 Modified Files: src/sys/dev/usb: umass.c umass_quirks.c umass_scsipi.c umassvar.h Log Message: Convert umass(4) to usbhist. If defined(USB_DEBUG) && !defined(UMASS_DEBUG), umass_scsipi.c cannot build because umassdebug is not referred from umass_scsipi.c. -- t-hash
Re: CVS commit: src/sys/arch/x86/x86
Le 01/07/2016 à 16:24, matthew green a écrit : Log Message: Surprisingly enough, the kernel expects the CPU to support large pages when creating the direct map on amd64. Therefore, the amd64 CPUs that do not support large pages basically don't work on NetBSD. It looks like it has always been this way; add a KASSERT to panic properly in case we come across one of these CPUs. this seems kind of useless. it's part of the definition of amd64. Yes, I found it in AMD64 Vol.2 p.169 right after committing this change. It still remains useful, since it makes sure we first went through the largepages initialization stuff.
