6.0 Release - Pentium install panic and some questions
Paul Koch
paul.koch at statseeker.com
Mon Nov 21 05:20:40 GMT 2005
Hi, we are having a number of issues with 6.0-Release.
Our setup: We have ~40 machines in a development test environment,
ranging from P5/150Mhz/32M ram/IDE, PII Celerons, P3, P4, single and
dual processor setups.
Issue 1: Can't install on a Pentium P5 class machine:
The install panics when installing the base stuff. No useful messages
are displayed accept the "panic: page fault" and rebooting in 15
seconds. The machines are 10 year old DEC Pentiums, 32 to 64M ram, IDE
disks, etc. We have four of these in our test environment and appear to
install and run FreeBSD-5.4 fine.
Issue 2: phys_avail[] array too small in i386/machdep.c P5 boxes ??
We have something which we call a Remote Network Appliance (RNA), which
is basically a boot floppy with lots of stuff squeezed on it. The RNA
uses a cut down kernel config (ie. no kernel source modifications),
various other inhouse programs (eg. init/inetd/telnetd replacements),
built into a 1Mbyte MD root. We have no problems using everything up
until a 5.4-stable kernel but have various problems with 6.0-release.
When using 6.0, we get the following messages:
Overlapping or non-montonic memory region, ignoring second region
...
Too many holes in the physical address space, giving up
...
Fatel trap 12: page fault while in kernel mode
...
panic
Did a bit of searching and found that in Dragonfly phys_avail[] in
i386/machdep.c has been bumped up because it is too small. Looking at
6.0 machdep.c, looks like new dcons stuff has been added to it, and it
blocks out some physical memory to use. Not sure if that has anything
to do with it. From my understanding, phys_avail[10] gives you room
for four physical available address ranges (ie. 4 * start/end pair
entries and null terminated). I bumped the number up to 12 (ie. gives
me five address ranges) and we are off and going.
6.0 now boots on all our Pentium machines, but...
on 5.4-stable we got:
physical memory: 67108864
avail memory: 56156160
on 6.0 with phys_avail[12] we got:
physical memory: 67108864
avail memory: 63299584
more available memory for some reason ! Hmmm.
On most of our machines, when booting in verbose mode, the 5.4 kernel
reports three phys_avail segments, but the Pentium boxes report four.
On the patched 6.0, the Pentiums report five segments.
Unfortunately, the machine panics on Pentium machines when stress
testing it (ie. by making it run out of memory). On 5.4-stable it
would just kill user processes, under 6.0 it kills a few processes but
quickly panics with a page not present error. At least 6.0 now boots
and runs on a Pentium, whereas the standard install panics. I can't
get a dump of the RNA floppy panic because it has no swap or disk to
write to, and there isn't enough room on the floppy to build a kernel
with debugging stuff.
So, my question is... is it OK to bump phys_avail from 10 to 12 ?? or do
we just ditch the Pentium as a supported platform ?
Dragonfly have bumped it to 22, giving 10 segments.
The only other change we do is compile the kernel and world with -Os and
-funit-at-a-time to reduce the resulting binary sizes.
fyi, A copy of the floppy image is at:
http://www.statseeker.com/downloads/lanstat_fbsd60.bin
It also contains our realtime Statistical LAN Analyser. Instructions are
at http://www.statseeker.com/download1.html
The following is the RNA kernel config:
hints "./device.hints"
machine i386
cpu I586_CPU
cpu I686_CPU
ident RNA_KERNEL
options SCHED_ULE
options INET
options FFS
options MD_ROOT
options MD_ROOT_SIZE=1024
options COMPAT_FREEBSD4
options HZ=1000
options CLK_USE_I8254_CALIBRATION
options VM_KMEM_SIZE_SCALE
options NO_SWAPPING
options INIT_PATH="/rna-init"
device apm
device pci
device vga
device fdc
device md
device mem
nodevice io
device atkbdc
device atkbd
device pty
device sc
options MAXCONS=2
options SC_HISTORY_SIZE=500
options SC_NORM_ATTR="(FG_GREEN|BG_BLACK)"
options SC_NORM_REV_ATTR="(FG_YELLOW|BG_GREEN)"
options SC_KERNEL_CONS_ATTR="(FG_YELLOW|BG_BLACK)"
options SC_KERNEL_CONS_REV_ATTR="(FG_BLACK|BG_RED)"
options SC_NO_CUTPASTE
options SC_NO_FONT_LOADING
options SC_NO_SYSMOUSE
options DEVICE_POLLING
device de
device em
device ixgb
device txp
device miibus
device bfe
device bge
device dc
device fxp
device lge
device nge
device pcn
device re
device sf
device sis
device sk
device ste
device ti
device tl
device tx
device vge
device vr
device wb
device xl
device loop
device ether
device bpf
Issue 3: Actually a question about the kernel
Looking at a kernel before it is stripped, there appears to be a table
of text symbols right at the end (GLOBAL_OFFSET_TABLE), which are
removed when stripped. But the same table is in the kernel twice, once
~163k offset and the other at the end. Without having a good
understanding of how the kernel works, I am assuming the one at 163k
offset is part of some dynamic kernel library which isn't stripped ??
I'd like to strip this, or at least null it out so kgzip can reduce the
resulting kernel size more. I did this, and nothing appeared to break,
so far. Is this a bad thing to do ?
Thanks
Paul.
More information about the freebsd-stable
mailing list