Messages in this thread | | | Date | Sat, 21 Feb 1998 15:07:17 +0100 (MET) | From | "Kurt Huwig jun." <> | Subject | Re: Laptops (APM) & 0040 crashes |
| |
I tested this patch and it works! Without this patch, I was unable to enable the APM support on my Acer-Notebook. The only solution was flashing the bios with a hacked version...
Dear Linus!
Please include this patch in 2.0.34 and the 2.1.x-series. It can be found at
http://www.linuxmama.com/20-bugfix.html#apm-0x40-fix
You just have to remove the 'init/patches'-directory.
Kurt
On 2 Feb 1998, John Goerzen wrote: > Thanks everyone for your replies on this issue. > Stephen.Rothwell@canb.auug.org.au writes: > > > > 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 >
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |