Date: Mon, 21 Nov 2005 15:20:25 +1000 From: Paul Koch <paul.koch@statseeker.com> To: freebsd-stable@freebsd.org Subject: 6.0 Release - Pentium install panic and some questions Message-ID: <200511211520.25672.paul.koch@statseeker.com>
next in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200511211520.25672.paul.koch>