From: ebiederman@lnxi.com (Eric W. Biederman)
To: Ronald G Minnich <rminnich@lanl.gov>
Cc: <linux-kernel@vger.kernel.org>, <linuxbios@lanl.gov>
Subject: Re: LinuxBIOS + ASUS CUA + 2.4.5 works; with 2.4.6 locks up
Date: 18 Sep 2001 16:54:59 -0600 [thread overview]
Message-ID: <m3u1y0nm7w.fsf@DLT.linuxnetworx.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0109181612380.28482-100000@snaresland.acl.lanl.gov>
In-Reply-To: <Pine.LNX.4.33.0109181612380.28482-100000@snaresland.acl.lanl.gov>
Ronald G Minnich <rminnich@lanl.gov> writes:
> Here is the scenario. We have LinuxBIOS working fine with 2.4.5 on an ASUS
> CUA mainboard (Acer M1631 TNT2 northbridge, m1535d southbridge). It boots
> to multiuser and works fine. All versions of linux from 2.4.0 to 2.4.5
> also work.
>
> If we upgrade to 2.4.6 we see the 'Posix compliance by Unifix' (or
> whatever) message and then ... that's it. The machine appears to lock up.
> Testing with the ICE shows that it is repeatedly going to address
> 0xfefe0c0, or similar (it varies). Note that is 7 digits of hex, not 8:
> it's not going after high PCI or BIOS memory, we think.
>
> It does appear to get through creating the kernel_thread for init, and we
> think it might be dying when it goes idle, but we're not sure.
That could happen though it sounds unlikely on a PIII.
> We sometimes get into the kernel thread for init and can single step it
> into pci setup. At some point however the machine will again lock up. The
> last POST code is 97.
>
> THe 0xfefec00 address is suspicious. Is there any APIC (NOT ACPI, I mean
> IO-APIC) change that came into 2.4.6?
Yes, according to the changlog. But apics are generally much higher.
> Is there any way the kernel could be
> trying to call the BIOS for some reason (we have APM etc. OFF). Does
> anyone have a hint at what we could look at? FWIW, we have run this kernel
> under linuxbios on other boxes. It only fails on the Acer, and only for
> 2.4.6 and later (we've tested up to 2.4.9).
It shouldn't be trying to call the BIOS.
Have you run memtest86? Seriously knowing that you don't have
bad memory or a bad memory setup would be rule out all kinds of problems.
Hmm. 0xfefe0c0 is just below 256 megs (I assume that is what you have in your
machine). The kernel allocates memory from the top down, at least it did last
time I looked. I can't think of a reason it would jump there, but I
can see it having a variable allocated up there.
On the other hand an address like: 0xc0e0ef0f (reverse endian) is
really wacky but completely inside of the kernel address space.
Eric
next prev parent reply other threads:[~2001-09-18 22:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-18 22:22 LinuxBIOS + ASUS CUA + 2.4.5 works; with 2.4.6 locks up Ronald G Minnich
2001-09-18 22:54 ` Eric W. Biederman [this message]
2001-09-18 22:56 ` Ronald G Minnich
2001-09-18 23:03 ` Eric W. Biederman
2001-09-18 23:35 ` Mark Hahn
2001-09-18 23:43 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3u1y0nm7w.fsf@DLT.linuxnetworx.com \
--to=ebiederman@lnxi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxbios@lanl.gov \
--cc=rminnich@lanl.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox