your syntax is wrong. it should read:
append="mem=384M"
Robert Hyatt Computer and Information Sciences
[EMAIL PROTECTED] University of Alabama at Birmingham
(205) 934-2213 115A Campbell Hall, UAB Station
(205) 934-5473 FAX Birmingham, AL 35294-1170
On Sat, 11 Mar 2000, Andrew J. Pavlis wrote:
> I just upgraded my hard-drive and am getting that same
> problem..............64MB of ram rather than 384MB show up. The problem is,
> lilo.conf has the mem=384M and I get a syntax error when I run lilo "near" that
> line (aka Syntax error near line 12)
>
> Contents of line 12:
> mem=384M
>
> Can't seem to fix it either...............this sux!!!
> -Andy
> "Robert G. Brown" wrote:
>
> > This is just to report an interesting problem I encountered trying to
> > install RH 6.0 or 6.1 on a SuperMicro dual 300MHz PII with the older
> > 440LX chipset. Basically the install would go perfectly but when I
> > tried to boot the new system, the boot would absolutely hang at the
> > point where the aic7xxx driver was initializing. This was quite
> > maddening; given access to the system via a suitable boot floppy I tried
> > all sorts of things including the installation of a monolithic kernel
> > and so forth.
> >
> > Finally I noted that I could boot the system with the linux-up kernel
> > (uniprocessor) after a clean install. I discovered further that the
> > kernel was only identifying the system as having 64 MB of memory instead
> > of the 384 MB it actually has. No problem, I added the usual append
> > line to lilo.conf and voila! The system would boot EITHER UP or SMP. A
> > bit disappointing to learn a) that even a driver-free SMP 2.2 kernel +
> > aic7xxx driver won't boot in at least this system with only 64 MB to
> > boot in -- have no idea where the failure lives, but it is most annoying
> > and occurs consistently with 2.2.5 (RH 6.0) 2.2.10 (homemade), 2.2.12
> > (RH 6.1) and 2.2.13 (homemade); and b) that 2.2 kernels still don't
> > autodetect memory on at least some systems that aren't THAT old.
> >
> > However, now the tulip module won't load in the SMP kernel only. Or
> > rather, it loads, but simply doesn't function. Except sometimes when it
> > does. This system has a genuine tulip 21141 KNE-100 that has worked
> > perfectly under 2.0.x for years, except that it has on occasion been
> > smitten with the PCI/ioport bug (where the card module loads but
> > identifies the wrong ioport for the card except sometimes when it gets
> > it right). Historically, this bug was identifiable/fixable by
> > unloading/reloading the module -- the driver would nearly always get the
> > ioport "right" the second time -- or by using a patch for the tulip
> > driver that I posted some years ago that uses a routine given by Rubini
> > in "Writing Linux Device Drivers" (O'Reilly Bronco) for sequentially
> > testing PCI bus ioports returned during the PCI configuration cycle for
> > actual read/writability instead of assuming that the first one returned
> > is actually writeable.
> >
> > The tulip driver has changed quite a bit and I'm going to have to
> > actually rewrite the pci code instead of just patching it to test
> > whether or not this loop/test solves the problem. I >>can<< report that
> > just loading/unloading/reloading the module does NOT make the problem go
> > away (if this is the problem) any longer. The kernel doesn't seem to
> > find an interrupt for the card, which may indicate a newer and deeper
> > problem, but one that "appears" to possibly differentiate between SMP
> > and UP kernels (no way to be sure without rebooting twenty or thirty
> > times from powerup situations so that most of the cold-configuration
> > possibilities and timing situations are statistically explored.
> >
> > I'm not looking for help (yet) although if anybody wants to offer some
> > that is fine;-), but I thought it might be useful to get a report of
> > these problems into the relevant lists so that others might be able to
> > recognize them and try such solutions as I've developed in the event
> > that this is happening to others. I'm hoping to tackle the process of
> > getting an SMP kernel to work properly next week, so any suggestions I
> > get before then will be most welcome.
> >
> > rgb
> >
> > Robert G. Brown http://www.phy.duke.edu/~rgb/
> > Duke University Dept. of Physics, Box 90305
> > Durham, N.C. 27708-0305
> > Phone: 1-919-660-2567 Fax: 919-660-2525 email:[EMAIL PROTECTED]
> >
> > -
> > Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/dmentre/smp-howto/
> > To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
>
> -
> Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/dmentre/smp-howto/
> To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
>
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/dmentre/smp-howto/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
