lkml.org 
[lkml]   [1998]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.0.31 legacy 386 compatibility?
	OK, after looking the original message over, and thinking
about some of my replies, I realize that I'm not being clear enough.

I'm having a problem right after lilo loads and uncompresses
the kernel, _during_ device initialization, where 2.0.31 freezes on a
functional 386 but boots just fine on a 486 with the exact same cards,
drives, and config. The kernel never makes it to launching init, and
the machine never gets beyond serial, parallel, SCSI support, or
RAMDISK initialization (if any of these are compiled in). This makes
using a boot floppy from RedHat (or debian/slackware) impossible (it
just hangs at RAMDISK for RedHat). BTW: I failed to mention that the
machine has a hardware FPU, and I've both compiled in and removed
software FPU emulation (with no effect). I installed using the 486
and have been compiling test kernels there, then moving the cards,
drive, etc over to the 386 to test each new kernel. They always
freeze on the 386, but when the same drive and hardware is moved to my
486 it boots just fine. Former kernels never have a problem, and the
machine still runs my previous 2.0,29 (modified Redhat 4.0) install
flawlessly.

Since isolating this to the 386 hardware (pretty common for
old stuff, actually) I wanted to check if others have been noticing
problems with old 386's... Also, Dave@imladris.demon.co.uk corrected
me over the libc issue (a 'libc' for the kernel is provided with the
source, so it's irrelevant if I compile a kernel with glibc or libc 5)

So, why does the same hardware configuration with 2.0.31
(cards et all) fly on a 486, but fail with a 386? And also, why has
this been seemingly 'creeping' in? For example, I had to remove
RAMDISK and parallel support in 2.0.18 and 2.0.29 before I could get
those to boot on the 386 (they always worked on the 486)... now with
2.0.31 I can't seem to find _any_ options which will let the box boot.

Any help greatly appreciated (Thank You),
J. Maynard Gelinas

[original message with more hardware info below]

> Date: Mon, 12 Jan 1998 12:12:30 -0500 (EST)
> From: "J. Maynard Gelinas" <jmg@iac.net>
> To: linux-kernel@vger.rutgers.edu
> Subject: 2.0.31 legacy 386 compatibility?
>
> Hello,
> I have a 386/DX25 Chips based motherboard (82c80x) with 8MB of
> chip RAM, and a BIOS dating at 1989, which cannot run linux
> 2.0.31+glibc (Redhat 5.0). It _can_ run 2.0.29 with the old libc
> (redhat 4.0 based with plenty of modifications - though I had to
> compile a few kernels to get it bootable), but the problems have been
> getting consistently worse since about 2.0.18. Basically, it freezes
> right after either the serial init, parallel init, SCSI driver init,
> or RAMdisk init without logging anything. If I move the drive
> containing the OS to a 486 (SIS chipset based) the machine boots just
> fine. Because of this I've not been able to install RedHat on the 386
> from floppy, and have been forced to install from the 486 then compile
> test kernels from there. And I've tried at least seven kernels with
> varying options removed:
>
> - Old IDE/MFM disk driver (not enhanced)
> - No RAMdisk support
> - No kernel modules - monolithic kernel only
> - No PCI support (using a mono ISA herc card for video)
> - No parallel support
> - No IDE/Floppy support (using Adaptec 1542 controller)
> - Only one NIC driver
>
> I've pulled out all extraneous boards to reduce the
> possibility of conflicts. I know the IO Base addresses of all the
> boards which are installed and know they are being initialized
> properly on the 486.... so, why can this machine boot a 2.0.29
> kernel, but not 2.0.31?
>
> I can't imagine building a smaller monolithic kernel. I
> simply did _not_ add in support for any device not in the machine. It
> still freezes.... This machine is kinda important to me since it's my
> IP_MASQ router/gateway to the world. I've been using 2.0.29 with the
> IP_MASQ Bumper patch, but if it turns out that support for these old
> machines is dead I may have to upgrade the router hardware (which I'd
> rather not do when this system is perfectly fast enough for that job).
> Can anyone else report a functional legacy 386 system here, or is
> this global to all 386's?
>
> Thanks!
> J. Maynard Gelinas
>
>
>

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.068 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site