Re: PAE broken on 7-STABLE
On Tue, Dec 6, 2011 at 12:33 AM, Arnaud Lacombe wrote: > this might be a silly question to ask, but why FreeBSD's VM (or at > least seems to) performs so badly compared to Linux' VM ? Because no one has done the work. :( As much as I hate to say it, we are a volunteer project. That is an excuse, not a reason, but one that has to be addressed nonetheless. -- Eitan Adler ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: PAE broken on 7-STABLE
Hi, On Mon, Dec 5, 2011 at 10:02 PM, Alan Cox wrote: > On Mon, Dec 5, 2011 at 4:15 PM, Arnaud Lacombe wrote: >> >> Hi, >> >> A FreeBSD 7-STABLE miserably crashes on the following: >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; apic id = 00 >> fault virtual address = 0xbfef >> fault code = supervisor read, page not present >> instruction pointer = 0x20:0xc05fd1c2 >> stack pointer = 0x28:0xc0af6c7c >> frame pointer = 0x28:0xc0af6cc0 >> code segment = base 0x0, limit 0xf, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 0 () >> trap number = 12 >> panic: page fault >> cpuid = 0 >> KDB: stack >> backtrace: >> db_trace_self_wrapper(c0662728,0,c062b78b,c0af6b28,0,...) at >> db_trace_self_wrapper+0x26panic(c062b78b,c06639cc,c06c1de4,1,1,...) at >> panic+0x106trap_fatal(c0c74388,c065b897,c064d922,10,c0c74000,...) at >> trap_fatal+0x270 >> trap_pfault(c06d4e40,c0c74380,c0af6c40,3,c06c1bc0,...) at >> trap_pfault+0x2aa >> trap(c0af6c3c) at trap+0x36ecalltrap() at calltrap+0x6 >> --- trap 0xc, eip = 0xc05fd1c2, esp = 0xc0af6c7c, ebp = 0xc0af6cc0 --- >> pmap_map(c0af6d68,3f6ba000,6,3fef8000,6,...) at pmap_map+0x72 >> vm_page_startup(c0d3e000,a,c0af6d88,c03f8f26,0,...) at >> vm_page_startup+0x35a >> vm_mem_init(0,af,af0020,af,0,...) at vm_mem_init+0x18 >> mi_startup() at mi_startup+0x56begin() at begin+0x2c >> >> on a machine with 24GB of RAM, while PAE is meant to support up to 64GB. >> >> - Arnaud >> >> ps: this is just a report, I'm not really expecting anything, any >> longer, from the FreebSD "community". >> > > At this early stage in the boot process, the page table pages for the kernel > address space must be statically allocated. When PAE was still actively > used, it was unusual to find machines that had more than about 16GB of RAM. > So, the static allocation of page table pages was set accordingly. For > larger machines, it is necessary to increase NKPT. The following comment > appears in i386/include/pmap.h: > > /* Initial number of kernel page tables. */ > #ifndef NKPT > #ifdef PAE > /* 152 page tables needed to map 16G (76B "struct vm_page", 2M page tables). > */ > #define NKPT 240 > #else > /* 18 page tables needed to map 4G (72B "struct vm_page", 4M page tables). > */ > #define NKPT 30 > #endif > #endif > > That said, a machine with 24GB of RAM is likely not going to be usable for > many workloads unless you also increase the size of the kernel virtual > address space (and thereby reduce the size of the user virtual address > space). > btw, thanks for the precise explanation! - Arnaud ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: PAE broken on 7-STABLE
Hi, On Mon, Dec 5, 2011 at 10:02 PM, Alan Cox wrote: > On Mon, Dec 5, 2011 at 4:15 PM, Arnaud Lacombe wrote: >> >> Hi, >> >> A FreeBSD 7-STABLE miserably crashes on the following: >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; apic id = 00 >> fault virtual address = 0xbfef >> fault code = supervisor read, page not present >> instruction pointer = 0x20:0xc05fd1c2 >> stack pointer = 0x28:0xc0af6c7c >> frame pointer = 0x28:0xc0af6cc0 >> code segment = base 0x0, limit 0xf, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 0 () >> trap number = 12 >> panic: page fault >> cpuid = 0 >> KDB: stack >> backtrace: >> db_trace_self_wrapper(c0662728,0,c062b78b,c0af6b28,0,...) at >> db_trace_self_wrapper+0x26panic(c062b78b,c06639cc,c06c1de4,1,1,...) at >> panic+0x106trap_fatal(c0c74388,c065b897,c064d922,10,c0c74000,...) at >> trap_fatal+0x270 >> trap_pfault(c06d4e40,c0c74380,c0af6c40,3,c06c1bc0,...) at >> trap_pfault+0x2aa >> trap(c0af6c3c) at trap+0x36ecalltrap() at calltrap+0x6 >> --- trap 0xc, eip = 0xc05fd1c2, esp = 0xc0af6c7c, ebp = 0xc0af6cc0 --- >> pmap_map(c0af6d68,3f6ba000,6,3fef8000,6,...) at pmap_map+0x72 >> vm_page_startup(c0d3e000,a,c0af6d88,c03f8f26,0,...) at >> vm_page_startup+0x35a >> vm_mem_init(0,af,af0020,af,0,...) at vm_mem_init+0x18 >> mi_startup() at mi_startup+0x56begin() at begin+0x2c >> >> on a machine with 24GB of RAM, while PAE is meant to support up to 64GB. >> >> - Arnaud >> >> ps: this is just a report, I'm not really expecting anything, any >> longer, from the FreebSD "community". >> > > At this early stage in the boot process, the page table pages for the kernel > address space must be statically allocated. When PAE was still actively > used, it was unusual to find machines that had more than about 16GB of RAM. > So, the static allocation of page table pages was set accordingly. For > larger machines, it is necessary to increase NKPT. The following comment > appears in i386/include/pmap.h: > > /* Initial number of kernel page tables. */ > #ifndef NKPT > #ifdef PAE > /* 152 page tables needed to map 16G (76B "struct vm_page", 2M page tables). > */ > #define NKPT 240 > #else > /* 18 page tables needed to map 4G (72B "struct vm_page", 4M page tables). > */ > #define NKPT 30 > #endif > #endif > > That said, a machine with 24GB of RAM is likely not going to be usable for > many workloads unless you also increase the size of the kernel virtual > address space (and thereby reduce the size of the user virtual address > space). > this might be a silly question to ask, but why FreeBSD's VM (or at least seems to) performs so badly compared to Linux' VM ? Thanks, - Arnaud ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: PAE broken on 7-STABLE
On Mon, Dec 5, 2011 at 4:15 PM, Arnaud Lacombe wrote: > Hi, > > A FreeBSD 7-STABLE miserably crashes on the following: > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0xbfef > fault code= supervisor read, page not present > instruction pointer = 0x20:0xc05fd1c2 > stack pointer = 0x28:0xc0af6c7c > frame pointer = 0x28:0xc0af6cc0 > code segment = base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 () > trap number = 12 > panic: page fault > cpuid = 0 > KDB: stack > backtrace: > db_trace_self_wrapper(c0662728,0,c062b78b,c0af6b28,0,...) at > db_trace_self_wrapper+0x26panic(c062b78b,c06639cc,c06c1de4,1,1,...) at > panic+0x106trap_fatal(c0c74388,c065b897,c064d922,10,c0c74000,...) at > trap_fatal+0x270 > trap_pfault(c06d4e40,c0c74380,c0af6c40,3,c06c1bc0,...) at trap_pfault+0x2aa > trap(c0af6c3c) at trap+0x36ecalltrap() at calltrap+0x6 > --- trap 0xc, eip = 0xc05fd1c2, esp = 0xc0af6c7c, ebp = 0xc0af6cc0 --- > pmap_map(c0af6d68,3f6ba000,6,3fef8000,6,...) at pmap_map+0x72 > vm_page_startup(c0d3e000,a,c0af6d88,c03f8f26,0,...) at > vm_page_startup+0x35a > vm_mem_init(0,af,af0020,af,0,...) at vm_mem_init+0x18 > mi_startup() at mi_startup+0x56begin() at begin+0x2c > > on a machine with 24GB of RAM, while PAE is meant to support up to 64GB. > > - Arnaud > > ps: this is just a report, I'm not really expecting anything, any > longer, from the FreebSD "community". > > At this early stage in the boot process, the page table pages for the kernel address space must be statically allocated. When PAE was still actively used, it was unusual to find machines that had more than about 16GB of RAM. So, the static allocation of page table pages was set accordingly. For larger machines, it is necessary to increase NKPT. The following comment appears in i386/include/pmap.h: /* Initial number of kernel page tables. */ #ifndef NKPT #ifdef PAE /* 152 page tables needed to map 16G (76B "struct vm_page", 2M page tables). */ #define NKPT240 #else /* 18 page tables needed to map 4G (72B "struct vm_page", 4M page tables). */ #define NKPT30 #endif #endif That said, a machine with 24GB of RAM is likely not going to be usable for many workloads unless you also increase the size of the kernel virtual address space (and thereby reduce the size of the user virtual address space). Regards, Alan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Sporadic 9.0-RC2 boot-time panic
On 12/1/2011 6:03 PM, Mike Andrews wrote: On 11/28/11 5:48 PM, Ronald Klop wrote: On Mon, 28 Nov 2011 23:37:27 +0100, Mike Andrews wrote: *Sometimes* when booting 9.0-RC2 on *some* of my machines, I'll get one of the following two panics during multiuser startup, usually while running the /usr/local/etc/rc.d scripts. (The instruction pointer is always exactly one of these two, and they look fairly related.) If after two or three reboots it manages to not panic, the system will run perfectly stable. FYI this is still happening on 9.0-RC3 -- r228247 to be precise. It only seems to be happening on one particular model of motherboard (Supermicro X8STi-F) but it is happening on several identical machines with them -- running on several other (mostly Supermicro) boards is just fine, including at least one with the exact same 82574L NICs. Whoever's wanting to work on this, contact me off-list to get some more up to date console logs and the kernel config. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: PAE broken on 7-STABLE
On Mon, Dec 5, 2011 at 5:15 PM, Arnaud Lacombe wrote: > Hi, > > A FreeBSD 7-STABLE miserably crashes on the following: Is this also true on 8 and 9 or is the problem unique to 7-STABLE? -- Eitan Adler ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
PAE broken on 7-STABLE
Hi, A FreeBSD 7-STABLE miserably crashes on the following: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xbfef fault code= supervisor read, page not present instruction pointer = 0x20:0xc05fd1c2 stack pointer = 0x28:0xc0af6c7c frame pointer = 0x28:0xc0af6cc0 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 () trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c0662728,0,c062b78b,c0af6b28,0,...) at db_trace_self_wrapper+0x26panic(c062b78b,c06639cc,c06c1de4,1,1,...) at panic+0x106trap_fatal(c0c74388,c065b897,c064d922,10,c0c74000,...) at trap_fatal+0x270 trap_pfault(c06d4e40,c0c74380,c0af6c40,3,c06c1bc0,...) at trap_pfault+0x2aa trap(c0af6c3c) at trap+0x36ecalltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc05fd1c2, esp = 0xc0af6c7c, ebp = 0xc0af6cc0 --- pmap_map(c0af6d68,3f6ba000,6,3fef8000,6,...) at pmap_map+0x72 vm_page_startup(c0d3e000,a,c0af6d88,c03f8f26,0,...) at vm_page_startup+0x35a vm_mem_init(0,af,af0020,af,0,...) at vm_mem_init+0x18 mi_startup() at mi_startup+0x56begin() at begin+0x2c on a machine with 24GB of RAM, while PAE is meant to support up to 64GB. - Arnaud ps: this is just a report, I'm not really expecting anything, any longer, from the FreebSD "community". ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: r228152: anyone got the None cipher working with base OpenSSH?
On Fri, Dec 2, 2011 at 3:32 PM, Jeremy Chadwick wrote:
> On Fri, Dec 02, 2011 at 02:57:48PM -0800, Freddie Cash wrote:
> > Looking through the commit messages for stable/8 and stable/9 I noticed
> > that the HPN patches were applied to OpenSSH in the base install. And
> > reading through the commit messages I see that one has to manually enable
> > the None cipher. However, I cannot, for the life of me, figure out how
> to
> > do that.
> >
> > The commit message for r228152 says to put "NONE_CIPHER_ENABLED=yes" into
> > /etc/make.conf. But doing so still gives the following error when world
> is
> > rebuilt/reinstalled:
> > command-line: line 0: Bad configuration option: NoneEnabled
> >
> > Putting NONE_CIPHER_ENABLED=yes into /etc/src.conf and rebuilding world
> > gives the same error.
> >
> > And, running "make -DNONE_CIPHER_ENABLED all install" under
> > /usr/src/secure/usr.bin/ssh/ also gives the same error.
> >
> > What am I missing? What's the magic incantation to add the None cipher
> to
> > base ssh?
>
> I have been discussing this with bz@ and brooks@ privately. I would
> rather not go into the details of what was discussed for reasons that I
> ALSO would rather not go into. Just know that the ambiguity is
> intentional.
>
> Here is what will work for you when added to /etc/make.conf:
>
> .if ${.CURDIR:M/usr/src/secure/*}
> CFLAGS+=-DNONE_CIPHER_ENABLED
> .endif
>
For the archives, the above snippet in /etc/make.conf and a buildworld
cycle enabled the NONE cipher in /usr/bin/ssh.
I'll be sure to read commit messages more carefully in the future. :)
Here's hoping that eventually/someday this gets converted into a src.conf
knob like WITH_IDEA or similar.
Thanks for all the help everyone.
--
Freddie Cash
fjwc...@gmail.com
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
