Problems with Yenta and TI PCI4451 chipset

[Pavel Roskin]

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.

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 socket status is read from the memory window 0.  Checking the contents
of /proc/iomem may be helpful.

-- 
Regards,
Pavel Roskin