> > The other day, I reported to linux-kernel a kernel oops in 2.0.33 that
> > was a protection fault at 0040 during boot. Upon further
> > investigation, it appears that the Debian boot disks do not suffer
> > from this problem.
> They probably don't have APM enabled in their kernel.
Correct. Which is probably not a good thing, since a lot of desktop
machines especially annoyingly ship with power management turned on,
and can do nasty things to Linux like turn off the CPU when there's no
keyboard activity for a certain amount of time. I've had
installations botched by this before, and have just turned off power
management in the desktop's BIOS.
Laptops are not quite so easy to deal with -- power management is
vital to a laptop and it must be supported by the OS, or the OS will
not be very useful on the laptop.
> > machines also don't have compliant BIOSes, and this driver will
> > cause those machines to panic during the boot phase (typically,
> > these machines are using a data segment of 0040, which is reserved
> > for the Linux kernel). If you get random kernel OOPSes that don't
> The message above is a little misleading, the real point is that
> the BIOS is using data segment 0x40 which is not a valid segment
> descriptor for Linux. It is a valid segment offset in real mode,
> but Linux is running in protected mode where access to this value
> as a segment descriptor is illegal. The BIOS is buggy!
OK, well I can't claim to know a lot about x86 protected mode
architecture (my only assembly experience has been DOS real mode).
But here's another interesting tidbit of information. After I finally
just couldn't make Linux go on there like I wanted (esp. hibernate
function, which is important to me for a laptop), I decided to try out
FreeBSD -- I need some sort of Unix, preferably Linux, but I figured
FreeBSD may work. I grabbed the FreeBSD+PAO boot/install disk (PAO is
FreeBSD's laptop support system). It worked perfectly -- detected
APM, PCMCIA, etc. And hibernate works.
I really prefer to work in Linux but I'm leaving FreeBSD on there for
the moment since I have no better option right now. Anyway, it seems
that FreeBSD is somehow getting around this problem. What I don't
know is HOW they are getting around it. I am not a kernel hacker so I
unfortunately won't be much use analyzing their code, but I can try and
find their APM code and mail it to anybody interested.
> OK, there is not much work going on with the APM driver for various
> reasons - the biggy being that APM is now defunct :-( There is a new
Hmm, weird. AFAIK, all current laptops still use APM.
> API for doing power management that I know nothing about (yet). Also
> there have not been any major revisions of teh APM BIOS specifiation anyway.
It seems, though, that some support for certain "buggy" BIOSes might be
warranted. (Like is present for CMS640, etc.) I much perfer
my Debian to FreeBSD :-)
> I think the only solution is to complain to IBM and get it fixed.
> There may already be an updated BIOS available (I don't know).
I have looked at their webpage and they apparently do have a BIOS
update. Looking at their changelog, they do not say that they have
dealt with an issue like this, but it is possible that they did and
just didn't mention it. I will flash the image this afternoon and let
everyone know how it works.
Even if it works, I would still say that it might be beneficial to
adopt whatever workaround FreeBSD is using for this bug. From my
limited understanding of it, it may prove useful for desktop machines
with APM support as well.
Thanks for the info.
-- John Goerzen Southwind Internet Access, Inc, Business e-mail: firstname.lastname@example.org
Personal e-mail: email@example.com Wichita State University e-mail: firstname.lastname@example.org Developer, Debian GNU/Linux <http://www.debian.org>