Searched hist:74283 (Results 1 - 6 of 6) sorted by relevance
| /freebsd-11-stable/sys/i386/i386/ | ||
| H A D | locore.s | diff 74283 Thu Mar 15 03:10:06 MST 2001 peter Kill the 4MB kernel limit dead. [I hope :-)]. For UP, we were using $tmp_stk as a stack from the data section. If the kernel text section grew beyond ~3MB, the data section would be pushed beyond the temporary 4MB P==V mapping. This would cause the trampoline up to high memory to fault. The hack workaround I did was to use all of the page table pages that we already have while preparing the initial P==V mapping, instead of just the first one. For SMP, the AP bootstrap process suffered the same sort of problem and got the same treatment. MFC candidate - this breaks on 4.x just the same.. Thanks to: Richard Todd <rmtodd@ichotolot.servalan.com> |
| H A D | mp_machdep.c | diff 74283 Thu Mar 15 03:10:06 MST 2001 peter Kill the 4MB kernel limit dead. [I hope :-)]. For UP, we were using $tmp_stk as a stack from the data section. If the kernel text section grew beyond ~3MB, the data section would be pushed beyond the temporary 4MB P==V mapping. This would cause the trampoline up to high memory to fault. The hack workaround I did was to use all of the page table pages that we already have while preparing the initial P==V mapping, instead of just the first one. For SMP, the AP bootstrap process suffered the same sort of problem and got the same treatment. MFC candidate - this breaks on 4.x just the same.. Thanks to: Richard Todd <rmtodd@ichotolot.servalan.com> |
| /freebsd-11-stable/sys/kern/ | ||
| H A D | subr_smp.c | diff 74283 Thu Mar 15 03:10:06 MST 2001 peter Kill the 4MB kernel limit dead. [I hope :-)]. For UP, we were using $tmp_stk as a stack from the data section. If the kernel text section grew beyond ~3MB, the data section would be pushed beyond the temporary 4MB P==V mapping. This would cause the trampoline up to high memory to fault. The hack workaround I did was to use all of the page table pages that we already have while preparing the initial P==V mapping, instead of just the first one. For SMP, the AP bootstrap process suffered the same sort of problem and got the same treatment. MFC candidate - this breaks on 4.x just the same.. Thanks to: Richard Todd <rmtodd@ichotolot.servalan.com> |
| /freebsd-11-stable/sys/x86/x86/ | ||
| H A D | mptable.c | diff 74283 Thu Mar 15 03:10:06 MST 2001 peter Kill the 4MB kernel limit dead. [I hope :-)]. For UP, we were using $tmp_stk as a stack from the data section. If the kernel text section grew beyond ~3MB, the data section would be pushed beyond the temporary 4MB P==V mapping. This would cause the trampoline up to high memory to fault. The hack workaround I did was to use all of the page table pages that we already have while preparing the initial P==V mapping, instead of just the first one. For SMP, the AP bootstrap process suffered the same sort of problem and got the same treatment. MFC candidate - this breaks on 4.x just the same.. Thanks to: Richard Todd <rmtodd@ichotolot.servalan.com> |
| H A D | mp_x86.c | diff 74283 Thu Mar 15 03:10:06 MST 2001 peter Kill the 4MB kernel limit dead. [I hope :-)]. For UP, we were using $tmp_stk as a stack from the data section. If the kernel text section grew beyond ~3MB, the data section would be pushed beyond the temporary 4MB P==V mapping. This would cause the trampoline up to high memory to fault. The hack workaround I did was to use all of the page table pages that we already have while preparing the initial P==V mapping, instead of just the first one. For SMP, the AP bootstrap process suffered the same sort of problem and got the same treatment. MFC candidate - this breaks on 4.x just the same.. Thanks to: Richard Todd <rmtodd@ichotolot.servalan.com> |
| /freebsd-11-stable/sys/amd64/amd64/ | ||
| H A D | mp_machdep.c | diff 74283 Thu Mar 15 03:10:06 MST 2001 peter Kill the 4MB kernel limit dead. [I hope :-)]. For UP, we were using $tmp_stk as a stack from the data section. If the kernel text section grew beyond ~3MB, the data section would be pushed beyond the temporary 4MB P==V mapping. This would cause the trampoline up to high memory to fault. The hack workaround I did was to use all of the page table pages that we already have while preparing the initial P==V mapping, instead of just the first one. For SMP, the AP bootstrap process suffered the same sort of problem and got the same treatment. MFC candidate - this breaks on 4.x just the same.. Thanks to: Richard Todd <rmtodd@ichotolot.servalan.com> |
Completed in 416 milliseconds