Problems with Yenta and TI PCI4451 chipset

[David Hinds]

On Thu, Mar 18, 2004 at 07:16:55PM -0500, Pavel Roskin wrote:
> On Thu, 18 Mar 2004, David Hinds wrote:
> 
> > On Thu, Mar 18, 2004 at 05:11:55PM -0500, Jon Schindler wrote:
> > > Linux version 2.6.4 (root at wheeler3) (gcc version 3.3.1) #18 Thu Mar 18
> > > 16:18:22 CST 2004
> > > BIOS-provided physical RAM map:
> > > BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
> > > BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
> > > BIOS-e820: 0000000000100000 - 000000003ffe2800 (usable)
> > > BIOS-e820: 000000003ffe2800 - 0000000040000000 (reserved)
> > > BIOS-e820: 00000000feda0000 - 00000000fee00000 (reserved)
> > > BIOS-e820: 00000000ffb80000 - 0000000100000000 (reserved)
> > > user-defined physical RAM map:
> > > user: 0000000000000000 - 000000000009fc00 (usable)
> > > user: 000000000009fc00 - 00000000000a0000 (reserved)
> > > user: 0000000000100000 - 000000003ffe2800 (usable)
> >
> > This is a boot loader problem; it is a bug in grub which they seem to
> > refuse to acknowledge and hence won't fix even though it has existed for
> > ages.  The boot loader is passing a bogus "mem=" option to the kernel
> > that causes resources to be allocated for your CardBus bridge that
> > conflict with a reserved memory region.
> >
> > Add:
> >
> >     reserve=0x3ffe2800,0x1d800
> >
> > to your kernel boot parameters and you should be ok.
> 
> If the problem is in grub, just add "--no-mem-option" after "kernel" in
> menu.lst, and grub won't supply the "mem" option.

Ah, I wasn't aware of this option; I only was able to find some
discussion of a compile-time setting.

> However, I doesn't see any discrepancy between the BIOS map and the user
> map.  The region starting as 0x3ffe2800 is reserved in both maps.

The region starting at 0x3ffe2800 is not reserved in the user-defined
map.  I'm not sure where you see that but the entire user map is those
three lines I clipped, and it ends at 0x3ffe2800.

> The socket status is read from the memory window 0.  Checking the contents
> of /proc/iomem may be helpful.

The socket status is read from the bridge registers which are in a
separate 4K window of their own, not memory window 0.  In this case
they were mapped at 0x3ffe3000 and 0x3ffe4000 for the two sockets.

-- Dave