Re: PCI memory allocation bug with CONFIG_HIGHMEM

[Adam Belay]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/