"Linux Gazette...making Linux just a little more fun!"

The Answer Guy

By James T. Dennis,
Starshine Technical Services, http://www.starshine.org/

Kernel crashes

From David W. MacDougall on 18 May 1998

Hello Answer Guy,

Since December, I have tried posting this problem to newsgroups and the responses I received were not helpful.

I am running Red Hat 5.0 on a Pentium 233 processor with 128mb of EDO RAM, Award BIOS, Award PnP BIOS, an Adaptec 2940 Host Adapter, and a Quantum SCSI 3.2gig hard drive. One of the boot up messages I get from the BIOS is "Checking DMI pool data."

I have tried running Slackware and Red Hat, both with kernel version 2.0.31 and 2.0.31. No matter what I do, it seems the kernel will "see" only about 14 mb of RAM (see meminfo file below). The first advice I got was to use an append command in LILO "mem=128mb" and several variations thereof. I tried entering that command every possible way, and though it did increase the amount of RAM available, the system would crash almost immediately, or as soon as I tried to access a disk drive. I would get a kernel panic message, then some messages about the SCSI hosts and then a complete freeze-up.

First that append directive should be:

append="mem=128M"

note that the quotes are required to assign this value to the append directive because of the "=" sign that is contained within the value. Also note that this value should be written with a capital letter "M" and not as "mb" (I'm hoping that your question has a typo that's not reflected in your actual lilo.conf file). You could also specify the size in hexadecimal (precede it with "0x") and I suspect that you could specify it as something like mem=134217728 (which is 128M in decimal). However I've never seen anyone do that.

Note also: You can pass a parameter such as mem=128M to your kernel by simply typing it it on the lilo command line during boot. In other words, when you pause your system at the 'lilo' prompt during the boot cycle you can manually "append" kernel parameters as you select which kernel/lilo image to load.

For example most of my lilo configuration have org "original," old, cur "current," and new stanza (images). So I could temporarily limit this machine (canopus) to use only 32 of its 64Mb of RAM by typing something like:

new mem=32M

... at the lilo boot prompt. A line like:

old root=/dev/sdb1 single mem=8M

... would run my "old" kernel, mounting the first partition on my second SCSI disk as the root filesystem, and limiting the kernel to only use eight megabytes of RAM (and I'd better hope that the rc scripts on /dev/sdb1 give me a bit of swap space or that first few minutes will be painful on with only eight MB). You can also pass these parameters to your kernel via LOADLIN.EXE.

You can learn all about the other boot prompt parameters in the BootPrompt-HOWTO at any LDP mirror:
http://www.linuxresources.com/LDP/HOWTO/BootPrompt-HOWTO.html

If your actual attempts have been in the correct syntax (and the error is just in your question) than it sounds suspiciously like a memory hole or a chunk of address space being used as a framebuffer (like a weird video card).

In the early 386 days (many years and three or four generations of processor ago) there were some systems that had 'top memory' or a 'memory hole' --- a chunk of address space used by the motherboard's chipset at about the 16Mb line (since nobody would have more than 16Mb of RAM ). Back in those days I was on the Quearterdeck tech support team (Linux didn't exist, yet) and we used to use the QEMM "notop" switch (if I remember it correctly) to work around the problems when this oddity wasn't automatically detected by QEMM.

However I don't think any Pentium or PII motherboard would have such a problem (it would definitely be considered a design flaw these days).

Are you saying that the kernel seems to be stable when you run it with only 14 or 15Mb of RAM --- but crashes soon after you force your kernel to use the rest? Have you tried setting the append line to 64Mb (or just manually passing a mem=64M parameter to your kernel)?

You basically want to narrow down exactly where the crash is occuring. Once you think you have it --- it's worth taking out your RAM DIMM's (SIMM's or whatever they are in your case) and swapping them (put all the DIMM's from one bank into the to slots and vice versa). If the crase "moves" with the chips than replace the RAM modules (the things might even work in another box --- since you can sometimes see some inexplicable "timing" glitches that amount to: "this board doesn't "like" those chips"

(Sounds scientific, doesn't it!).

Other than that you might consider removing all the cards in the system --- putting in the cheapest, plainest video card and IDE/multi-function card and drive you can find and testing it with that configuration. (Then you re-introduce your preferred adapters until the problems re-occur. In this way you isolated the problem to a specific hardware or software component).

My question is this: Where is my problem? Is there something inherent in the kernel that won't let it see any more than 14mb of RAM on this system without my having to add append statements to LILO? And why does the kernel panic once is does see more memory? I have tried adjusting the amount of memory stipulated in the command line to lower levels, tried entering it in HEX, and in bytes. The results are always the same.

There is definitely nothing that limits Linux to 14Mb of RAM. My oldest system ('antares' --- the old 33Mhz 386 that handles my uucp mail, INN netnews, fax, dial-in and dial-out modem, is the household web and POP server, and is the backup masquerading router when my ISDN goes out) has used 32Mb of RAM (auto-detected) for several years --- from Linux 0.99p10 through my current 2.0.33. That machine is about a decade old now. 'Betelgeuse' and 'Canopus' each have 64Mb. I've managed and configured systems with 128Mb and more (although most PC hardware tops out at 128 or 256 Mb).

Most systems will need the mem= parameter if they have more than 64Mb since there is no standard way to detect more than that. The 2.1/2.2 kernels may auto-detect large memory configurations on some systems, but I've heard that some of the methods for probing for this sort of RAM can lock up some other systems (something that prevents users from installing NT on some of those "unsupported" systems on the Microsoft "bad boy" list --- or so I've heard).

Or is my problem more with my Adaptec host adapter? Why will it work just fine with only 14mb of RAM but fall to pieces with more? (I also have an SCSI CD-ROM drive and a second 3.2 SCSI Quantum hard drive (which I use for Windows 95 in this dual-boot system.)

As I've said, I don't know. It could be any component of the system. However I've used Adaptec 2940's in 128Mb systems with Linux and FreeBSD. So that, by itself, is not likely to be the problem.

It's also almost inconceivable that the model of hard drive would affect this situation. Basically any SCSI hard drive will usually work on any supported SCSI controller without crashing the kernel. (A couple of SCSI devices can fight with one another and crash the SCSI bus --- particularly if you mix "differential" devices with others. However, you'd get kernel messages that would clearly indicate the subsystem involved --- and it would be independent of the memory layout (in every case I can think of).

I am reluctant to keep fiddling with the append parameters because every time the system crashes, it eats a hole or two in the filesystem. A Linux-knowledgeable friend suggested I might want to try upgrading to the development kernel (2.1.??) to see if that would cure the problem. He also suggested I write to Linux Torvalds, but I thought I should try you first.

I would definitely not bother Linus Torvalds directly with a problem of this sort. If I could isolate it to a specific module or block of code I might --- but I'd problem just post it to the Linux Kernel mailing list in any event. Linus is quite active on that list --- and it would simply be rude to request is personal attention to something that any kernel developer might be able to handle.

I feel sad sitting here with the world's greatest OS and all this RAM I can't use. Any guidance or direction you could give me would be greatly appreciated!

Again, double and triple check the syntax of your mem= parameter. Then try different values --- 64Mb, 96Mb, etc to isolate the specific limit. Read the BootPrompt-HOWTO. Try taking out that Matrox Mystique and using just a plain VGA card for testing. Disable all "Plug-n-Pray" features on your motherboard.

The first steps in all troubleshooting are to precisely describe and isolate the problem. In the worst case you might have a bad motherboard or some bad memory chips.

Thank you,
Dave

--------------
proc/meminfo
--------------

        total:    used:    free:  shared: buffers: 
cached:
Mem:  14004224 13795328   208896  8200192   180224 
4214784
Swap: 41119744 17133568 23986176
MemTotal:     13676 kB
MemFree:        204 kB
MemShared:     8008 kB
Buffers:        176 kB
Cached:        4116 kB
SwapTotal:    40156 kB
SwapFree:     23424 kB


--------------------
/proc/cpuinfo
--------------------

processor       : 0
cpu             : 586
model           : 4
vendor_id       : GenuineIntel
stepping        : 3
fdiv_bug        : no
hlt_bug         : no
fpu             : yes
fpu_exception   : yes
cpuid           : yes
wp              : yes
flags           : fpu vme de pse tsc msr mce cx8 mmx
bogomips        : 348.16


---------
/proc/scsi
----------

Attached devices: 
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: QUANTUM  Model: FIREBALL_TM3200S Rev: 300X
  Type:   Direct-Access                    ANSI SCSI
revision: 02
Host: scsi0 Channel: 00 Id: 01 Lun: 00
  Vendor: QUANTUM  Model: FIREBALL ST3.2S  Rev: 0F0C
  Type:   Direct-Access                    ANSI SCSI
revision: 02
Host: scsi0 Channel: 00 Id: 06 Lun: 00
  Vendor: MATSHITA Model: CD-ROM CR-508    Rev: XS03
  Type:   CD-ROM                           ANSI SCSI
revision: 02


---------------
/proc/pci
---------------

PCI devices found:
  Bus  0, device  19, function  0:
    VGA compatible controller: Matrox Mystique (rev 3).
      Medium devsel.  Fast back-to-back capable.  IRQ
10.  Master Capable.  Late
ncy=32.  
      Prefetchable 32 bit memory at 0xe0000000.
      Non-prefetchable 32 bit memory at 0xe1000000.
      Non-prefetchable 32 bit memory at 0xe0800000.
  Bus  0, device  18, function  0:
    SCSI storage controller: Adaptec AIC-7881U (rev 0).
      Medium devsel.  Fast back-to-back capable.  IRQ
11.  Master Capable.  Late
ncy=32.  Min Gnt=8.Max Lat=8.
      I/O at 0x6000.
      Non-prefetchable 32 bit memory at 0xe1004000.
  Bus  0, device   7, function  1:
    IDE interface: Intel 82371SB Natoma/Triton II PIIX3
(rev 0).
      Medium devsel.  Fast back-to-back capable. 
Master Capable.  Latency=32.  
      I/O at 0xf000.
  Bus  0, device   7, function  0:
    ISA bridge: Intel 82371SB Natoma/Triton II PIIX3
(rev 1).
      Medium devsel.  Fast back-to-back capable. 
Master Capable.  No bursts.  
  Bus  0, device   0, function  0:
    Host bridge: Intel 82437VX Triton II (rev 2).
      Medium devsel.  Master Capable.  Latency=32.  

Copyright © 1998, James T. Dennis
Published in Linux Gazette Issue 29 June 1998

	versions	lilo	virtdom	kernel	winmodem	basicmail	betterbak
	shadow	dell	dumbterm	whylinux	redhat	netcard	macrovir
	newlook	tacacs	sendmail	dialdppp	ppp233	msmail	procmail