Re: PCI memory allocation bug with CONFIG_HIGHMEM
From: Adam Belay (ambx1_at_neo.rr.com)
Date: 01/06/04
- Previous message: Rusty Russell: "Re: floppy driver and multiple floppies (was Re: 2.6.0 under vmware ?)"
- In reply to: Linus Torvalds: "Re: PCI memory allocation bug with CONFIG_HIGHMEM"
- Next in thread: Linus Torvalds: "Re: PCI memory allocation bug with CONFIG_HIGHMEM"
- Reply: Linus Torvalds: "Re: PCI memory allocation bug with CONFIG_HIGHMEM"
- Reply: Helge Hafting: "Re: PCI memory allocation bug with CONFIG_HIGHMEM"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 6 Jan 2004 22:29:59 +0000 To: Linus Torvalds <torvalds@osdl.org>
On Tue, Jan 06, 2004 at 07:48:37AM -0800, Linus Torvalds wrote:
>
>
> On Tue, 6 Jan 2004, Andi Kleen wrote:
> >
> > Anyways, I already implemented reservation for the aperture for the K8
> > driver some time ago. And it's in your tree. But it doesn't help for
> > finding IO holes because there could be other unmarked hardware lurking
> > there ... Or worse there is just no free space below 4GB.
>
> The "unmarked hardware" is why we have PCI quirks. Look at
> drivers/pci/quirks.c, and notice how many of the quirks are all about
> quirk_io_region(). Exactly because there isn't any way for the BIOS to
> tell us about these things on the IO side.
>
> (Actually, there is: PnP-BIOS calls are supposed to give us that
> information. However, not only are the BIOSes buggy and don't give a
> complete list _anyway_, anybody who uses the PnP-BIOS is much more likely
> to just get a kernel oops when the BIOS is buggy and assumes that only
> Windows will call it. So I strongly suggest you not _ever_ use pnp unless
> you absolutely have to).
For those with legacy systems, the isapnp protocol, a component of pnp, is
unaffected by this problem. Most systems that support ISA addin cards,
have correctly implemented PnPBIOSes.
>
> The same quirks could be done on the MMIO side for northbridges.
>
> Linus
For the past few weeks I've been doing research on the PnPBIOS general
protection faults, and I've come up with a few observations and a proposed
solution. Any comments would be appreciated.
1.) There probably isn't anything wrong with the way we're calling the PnPBIOS.
After searching through various mailing lists I discovered that several other
open source operating systems, although having many variations on the PnPBIOS
code, are having identical problems (including that the same type of calls
trigger the faults). A while back I added a change that was similar to some
of apm's buggy bios handling code. It appears to fix the problems with getting
dynamic resource information on many buggy systems. I later decided (see
pnp-fix-1 in -mm) to get static resource information (the resources set at boot
time) because the specifications suggest using that call when enumerating
devices for the first time. To my surprise, many have reported problems with
the PnPBIOS driver found in -mm. In addition, there are some, but
significantly fewer, BIOSes that are completely broken and don't work with
either call type.
The recent escd fix I have made corrects a thinko in the PnPBIOS code and it
turns out that faults from calling /proc/pnp/bus/escd were probably not caused
by BIOS bugs. I've attached this fix to the end of the email. This leaves
only the get node calls.
2.) Windows works with buggy BIOSes because of the way it calls them.
I looked into how Windows handles the PnPBIOS and may have discovered why it
works on buggy BIOS. It turns out that exclusively realmode calls are used.
See www.missl.cs.umd.edu/Projects/sebos/winint/index2.html#pnpbios. My
knowledge is limited in this area of the x86 architecture but it is my
impression that it would not be possible, or perhaps worth it, to implement
realmode calls for the Linux PnPBIOS driver because of the time it is
initialized.
3.) BIOS bugs appear to affect mostly laptops.
The Oops seems to generally occur when getting information about the mouse
controller. Because of touchpads and external mouses, the BIOS code may be
a little different from desktop systems. Nonetheless my laptop, as well as
all my other test systems, do not have any PnPBIOS problems.
4.) PnPBIOS support may not be fully implemented on a few rare systems with
ACPI.
The PnPBIOS standard has been obsoleted by ACPI. Only in systems made before
ACPI or systems with blacklisted ACPI support (there are many), is the PnPBIOS
necessary. Unfortunantly resource management in the Linux ACPI driver isn't
fully supported relative to resource management in the Linux PnPBIOS driver.
It is concievable that some PnPBIOSes only implement a minimal set of calls
properly.
A proposed solution...
For 2.6...
1.) only get dynamic resource information
2.) blacklist any BIOSes that fail on dynamic resource calls. We might get
lucky and there will be few enough that it is possible to create a blacklist.
Also look into them to see if they work with static instead.
3.) attach a warning, by printk and/or kconfig help, to the /proc/bus/pnp
interface as it is able to make any PnPBIOS call. (done in -mm)
4.) As a last resort disable PnPBIOS support if ACPI is successful. Although
the two can currently coexist, this would prevent the buggy BIOSes found in
more modern x86 systems from being used. Of course this would be useless if
the user decides to not include the ACPI driver.
5.) Look into other ways of finding out if the PnPBIOS might be buggy,
currently we only have DMI.
Any others?
For the next development kernel...
I am working on a new resource management infustructure, tied more closely to
the driver model and sysfs, and some ACPI patches. They should make it easier
for us to take advantage of ACPI resource management. Although one of my
biggest focuses is ACPI, I'd like to maintain compatibility with older
protocols such as PnPBIOS. Also it is a major goal to make it usable for all
architectures (like the existing resource management code), but perhaps even
for Open Firmware when it is further implemented.
From there we can phase out PnPBIOS support where ACPI provides an alternative.
It's worth noting that PnPBIOS support is useful on the majority of systems that
support it. In later kernels it can serve as an alternative when ACPI is buggy
or unsupported.
Thanks,
Adam
--- a/drivers/pnp/pnpbios/bioscalls.c 2003-11-26 20:44:47.000000000 +0000
+++ b/drivers/pnp/pnpbios/bioscalls.c 2003-12-02 21:17:42.000000000 +0000
@@ -493,7 +493,7 @@
if (!pnp_bios_present())
return ESCD_FUNCTION_NOT_SUPPORTED;
status = call_pnp_bios(PNP_READ_ESCD, 0, PNP_TS1, PNP_TS2, PNP_DS, 0, 0, 0,
- data, 65536, (void *)nvram_base, 65536);
+ data, 65536, __va((void *)nvram_base), 65536);
return status;
}
@@ -516,7 +516,7 @@
if (!pnp_bios_present())
return ESCD_FUNCTION_NOT_SUPPORTED;
status = call_pnp_bios(PNP_WRITE_ESCD, 0, PNP_TS1, PNP_TS2, PNP_DS, 0, 0, 0,
- data, 65536, nvram_base, 65536);
+ data, 65536, __va((void *)nvram_base), 65536);
return status;
}
#endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Rusty Russell: "Re: floppy driver and multiple floppies (was Re: 2.6.0 under vmware ?)"
- In reply to: Linus Torvalds: "Re: PCI memory allocation bug with CONFIG_HIGHMEM"
- Next in thread: Linus Torvalds: "Re: PCI memory allocation bug with CONFIG_HIGHMEM"
- Reply: Linus Torvalds: "Re: PCI memory allocation bug with CONFIG_HIGHMEM"
- Reply: Helge Hafting: "Re: PCI memory allocation bug with CONFIG_HIGHMEM"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
