From: Adam Belay <ambx1@neo.rr.com>
To: Andi Kleen <ak@colin2.muc.de>
Cc: Dave Jones <davej@redhat.com>, Linus Torvalds <torvalds@osdl.org>,
Mika Penttil? <mika.penttila@kolumbus.fi>, Andi Kleen <ak@muc.de>,
David Hinds <dhinds@sonic.net>,
linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>,
"Grover, Andrew" <andrew.grover@intel.com>
Subject: Re: PCI memory allocation bug with CONFIG_HIGHMEM
Date: Wed, 7 Jan 2004 02:43:09 +0000 [thread overview]
Message-ID: <20040107024308.GB3188@neo.rr.com> (raw)
In-Reply-To: <20040107065156.GA30773@colin2.muc.de>
On Wed, Jan 07, 2004 at 07:51:56AM +0100, Andi Kleen wrote:
> On Wed, Jan 07, 2004 at 05:55:57AM +0000, Dave Jones wrote:
> > On Wed, Jan 07, 2004 at 06:02:56AM +0100, Andi Kleen wrote:
> > > > > 5.) Look into other ways of finding out if the PnPBIOS might be buggy,
> > > > > currently we only have DMI.
> > > > > Any others?
> > > > We could use the exception mechanism, and try to fix up any BIOS errors.
> > > > That would require:
> > >
> > > [...] It would not work for x86-64 unfortunately where you cannot do
> > > any BIOS calls after the system is running (it would only be possible
> > > early in boot)
> >
> > Why on earth would you want to call PNPBIOS on AMD64 anyway ?
>
> See the preceding thread. We're currently missing a reliable way to find
> free IO space for PCI resources, which is needed for some cases. The
> PNPBIOS was discussed as one of the possible solutions.
>
> For AMD64 clearly something ACPI based is needed though.
>
> -Andi
Just as an example...
Here is how the PnPBIOS reserves io space for which it can't find an actual
device: (notice it isn't necessarily related to ISA)
09 PNP0c02 system peripheral: other
flags: [no disable] [no config] [static]
allocated resources:
io 0x04d0-0x04d1 [16-bit decode]
io 0x0cf8-0x0cff [16-bit decode]
io 0x0010-0x001f [16-bit decode]
io 0x0022-0x002d [16-bit decode]
io 0x0030-0x003f [16-bit decode]
io 0x0050-0x0052 [16-bit decode]
io 0x0072-0x0077 [16-bit decode]
io 0x0091-0x0093 [16-bit decode]
io 0x00a2-0x00be [16-bit decode]
io 0x0400-0x047f [16-bit decode]
io 0x0540-0x054f [16-bit decode]
io 0x0500-0x053f [16-bit decode]
io disabled [16-bit decode]
io disabled [16-bit decode]
io disabled [16-bit decode]
mem disabled [8/16 bit] [r/o] [cacheable] [shadow]
mem disabled [8/16 bit] [r/o] [cacheable] [shadow]
mem disabled [8/16 bit] [r/o] [cacheable] [shadow]
mem disabled [8/16 bit] [r/o] [cacheable] [shadow]
mem disabled [8/16 bit] [r/o] [cacheable] [shadow]
mem disabled [8/16 bit] [r/o] [cacheable] [shadow]
mem disabled [8/16 bit] [r/o] [cacheable] [shadow]
mem disabled [8/16 bit] [r/o] [cacheable] [shadow]
mem 0xffb00000-0xffbfffff [32 bit] [r/o]
And here is the output for ACPI on the same system:
00000970: Device SYSR (\_SB_.PCI0.SBRG.SYSR)
00000978: Name _HID (\_SB_.PCI0.SBRG.SYSR._HID)
0000097d: PNP0c02 (0x020cd041)
-->snip
00000995: Name _CRS (\_SB_.PCI0.SBRG.SYSR._CRS)
-->snip
0000099f: Interpreted as PnP Resource Descriptor:
0000099f: Fixed I/O Ports: 0x10 @ 0x10
0000099f: Fixed I/O Ports: 0x1e @ 0x22
0000099f: Fixed I/O Ports: 0x1c @ 0x44
0000099f: Fixed I/O Ports: 0x2 @ 0x62
0000099f: Fixed I/O Ports: 0xb @ 0x65
0000099f: Fixed I/O Ports: 0xe @ 0x72
0000099f: Fixed I/O Ports: 0x1 @ 0x80
0000099f: Fixed I/O Ports: 0x3 @ 0x84
0000099f: Fixed I/O Ports: 0x1 @ 0x88
0000099f: Fixed I/O Ports: 0x3 @ 0x8c
0000099f: Fixed I/O Ports: 0x10 @ 0x90
0000099f: Fixed I/O Ports: 0x1e @ 0xa2
0000099f: Fixed I/O Ports: 0x10 @ 0xe0
0000099f: I/O Ports: 16 bit address decoding,
0000099f: minbase 0x4d0, maxbase 0x4d0, align 0x0, count 0x2
0000099f: I/O Ports: 16 bit address decoding,
0000099f: minbase 0x400, maxbase 0x400, align 0x0, count 0x70
0000099f: I/O Ports: 16 bit address decoding,
0000099f: minbase 0x470, maxbase 0x470, align 0x0, count 0x10
0000099f: I/O Ports: 16 bit address decoding,
0000099f: minbase 0x500, maxbase 0x500, align 0x0, count 0x40
0000099f: I/O Ports: 16 bit address decoding,
0000099f: minbase 0x800, maxbase 0x800, align 0x0, count 0x80
0000099f: 32-bit rw Fixed memory range:
0000099f: base 0xfff00000, count 0x100000
0000099f: 32-bit rw Fixed memory range:
0000099f: base 0xffb00000, count 0x100000
0000099f: Bad checksum 0x6, should be 0 // hmm, interesting ;-)
So they seem to provide a potential solution for this sort of problem.
Thanks,
Adam
next prev parent reply other threads:[~2004-01-07 7:55 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1aJdi-7TH-25@gated-at.bofh.it>
2004-01-06 3:32 ` PCI memory allocation bug with CONFIG_HIGHMEM Andi Kleen
2004-01-06 3:40 ` Linus Torvalds
2004-01-06 4:05 ` Andi Kleen
2004-01-06 5:04 ` Linus Torvalds
2004-01-06 8:12 ` Andi Kleen
2004-01-06 9:11 ` Mika Penttilä
2004-01-06 9:44 ` Andi Kleen
2004-01-06 10:16 ` Mika Penttilä
2004-01-06 10:49 ` Andi Kleen
2004-01-06 15:27 ` Linus Torvalds
2004-01-06 15:37 ` Andi Kleen
2004-01-06 15:48 ` Linus Torvalds
2004-01-06 22:29 ` Adam Belay
2004-01-07 4:06 ` Linus Torvalds
2004-01-07 5:02 ` Andi Kleen
2004-01-07 5:55 ` Dave Jones
2004-01-07 6:06 ` Linus Torvalds
2004-01-07 6:08 ` Dave Jones
2004-01-07 6:45 ` Linus Torvalds
2004-01-07 6:51 ` Andi Kleen
2004-01-07 2:43 ` Adam Belay [this message]
2004-01-07 8:32 ` Helge Hafting
2004-01-06 22:45 ` Eric W. Biederman
2004-01-07 0:06 ` Linus Torvalds
2004-01-07 4:58 ` Eric W. Biederman
2004-01-07 5:32 ` Linus Torvalds
2004-01-07 15:53 ` Eric W. Biederman
2004-01-07 16:32 ` Linus Torvalds
2004-01-07 17:32 ` Eric W. Biederman
2004-01-08 19:34 ` Eric W. Biederman
2004-01-07 9:31 ` Russell King
2004-01-07 15:06 ` Eric W. Biederman
2004-01-07 20:29 ` Russell King
2004-01-06 22:56 ` Eric W. Biederman
2004-01-05 20:07 David Hinds
2004-01-05 23:00 ` Russell King
2004-01-05 23:45 ` David Hinds
2004-01-06 0:36 ` Linus Torvalds
2004-01-06 0:44 ` David Hinds
2004-01-06 1:11 ` Linus Torvalds
2004-01-06 1:41 ` Linus Torvalds
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=20040107024308.GB3188@neo.rr.com \
--to=ambx1@neo.rr.com \
--cc=ak@colin2.muc.de \
--cc=ak@muc.de \
--cc=akpm@osdl.org \
--cc=andrew.grover@intel.com \
--cc=davej@redhat.com \
--cc=dhinds@sonic.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mika.penttila@kolumbus.fi \
--cc=torvalds@osdl.org \
/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