PCMCIA: unable to map memory

Hi,

after a four day procedure of trial and error I am
hoping that you could perhaps help me.

Since nearly one year I run a Redhat 7.0 system on
a compaq contura aero laptop. (486SLC33, 20 MB RAM
10 GB hdd, one 16bit PCMCIA-Slot, kernel
2.2.19ext3) Thanks to the pcmcia-package it works
since then well as web/file/mailserver.

Now I got a identical machine and installed
successfully Redhat 9a on it. Runs nearly the same
speed (slow but OK for its purpose).

But I can't convince pcmcia to run with the kernel
2.4.20-20.9.

The problem:
All aeros have naturally a defect in their RAM if
this is upgraded to the max of 20MB (which I did,
as you can imagine). The source of this problem is
told to be a strange behaviour of the
pcmcia-controller. Because of this, there is a
32kb part of RAM that must be excluded for linux,
otherwise the system freezes some time after
start. For this purpose people use the BadRAM or
BadMEM-patch provided by the linux-community and
they append badram=0x010b0000,0xffff8000 at start
or in lilo.conf.

Further the pcmcia-cardmanager has to be told to
only use the ram-adresses 0xb0000-0xb7fff which is
done in /etc/pcmcia/config.opts (and all the other
include commands are outcommented).

As I told all this works rock-stable on the RedHat
7 machine since nearly one year.

With RedHat 9 and my 2.4 kernel this dosn't seem
to work any more.

If I start pcmcia, it says "unable to map memory"
and dmesg tells me:

-----
Linux PCMCIA Card Services 3.2.5
kernel build: 2.4.20-20.9-badram #1 Mon Nov 3
03:22:06 CET 2003
options: [pci] [apm]
Intel ISA/PCI/CardBus PCIC probe:
VLSI 82C146 rev 00 ISA-to-PCMCIA at port 0x3e0
ofs 0x00
host opts [0]: none
ISA irqs (scanned) = 3,4,5,7,9,10,11,12,15
status change on irq 15
cs: memory probe 0x0b0000-0x0b7fff: excluding
0xb0000-0xb7fff
cs: unable to map card memory!
cs: unable to map card memory!
cs: unable to map card memory!
cs: unable to map card memory!
cs: unable to map card memory!
cs: unable to map card memory!
cs: unable to map card memory!
cs: unable to map card memory!
memory_cs: RequestWindow: Resource in use
-----

If I use the other RAM-addresses in config.opts,
pcmcia starts and detects my 3Com574-NIC but the
system freezes after some time as expected.

Debugging
I use the newest pcmcia-cs 3.2.5 (I also tried out
3.2.3). Kernel pcmcia is disabled, modules and
network are enabled. I also recompiled the kernel
with enabled kernel-pcmcia and reinstalled
pcmcia-cs - same result.

I then copied the kernel 2.2.19ext3 over from my
other aero, copied a 2.2.19 kernel tree into
/usr/src (unfortunately I am not able to build a
new 2.2 kernel on the redhat 9 system, must have
something to do with the compilers). Then I
reinstalled pcmcia-cs.
The result: PCMCIA is working! on the RedHat 9
system (but only with that specific kernel :-( )

So it must have to do with the 2.4 kernel. As the
only main difference to the 2.4-kernel, the
2.2.19-kernel is compiled without pci-support. I
had no success in compiling the 2.4-kernel without
pci (compilation failed), don't know if this is
important. The aero has of course no pci, it was
manufactured 1994 - with ISA.

If I append all my configuration files this will
get too long. So please look at them: I copied
them to:
[url]http://ulihansen.kicks-ass.net/aero/pcmcia-problem[/url]

There you find:
config.opts /etc/pcmcia/config.opts
dmesg-2.2.19 dmesg after boot with kernel 2.2.19
dmesg-2.4.20-20.9 dmesg after boot with 2.4.20
kernel-config-2.2.19 .config of kernel 2.2.19
kernel-config-2.4.20-20.9 .config of 2.4.20
lilo.conf /etc/lilo.conf
rc.d-init.d-pcmcia /etc/rc.d/init.d/pcmcia
rc.d-rc.pcmcia /etc/rc.pcmcia
Same as /etc/rc.pcmcia.N
sysconfig-pcmcia /etc/sysconfig/pcmcia

Thank you very much for reading. I hope you have
an idea.

Thanks
Uli

Ulrich Hansen <uhansen@mainz-online.de> wrote:
[color=blue]
> All aeros have naturally a defect in their RAM if
> this is upgraded to the max of 20MB (which I did,
> as you can imagine). The source of this problem is
> told to be a strange behaviour of the
> pcmcia-controller. Because of this, there is a
> 32kb part of RAM that must be excluded for linux,
> otherwise the system freezes some time after
> start. For this purpose people use the BadRAM or
> BadMEM-patch provided by the linux-community and
> they append badram=0x010b0000,0xffff8000 at start
> or in lilo.conf.[/color]
[color=blue]
> With RedHat 9 and my 2.4 kernel this dosn't seem
> to work any more.[/color]

My guess would be that there is something different about how the
badmem stuff is handled in 2.4, which is making this memory range off
limits for the PCMCIA drivers.

What does /proc/iomem say when you boot up the 2.4 kernel?

-- Dave

Hi Dave,
Thank you very much for answering.
[color=blue]
> What does /proc/iomem say when you boot up the 2.4 kernel?[/color]

cat /proc/iomem says:

00000000-0009efff : System RAM
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000f0000-000fffff : System ROM
00100000-013fffff : System RAM
00100000-00240c09 : Kernel code
00240c0a-00283d5f : Kernel data

Unfortunately I am no expert in ram-addresses -
but I am beginning to work on it ;-)

Uli

Ulrich Hansen <uhansen@mainz-online.de> wrote:[color=blue]
> Hi Dave,
> Thank you very much for answering.[/color]
[color=blue][color=green]
>> What does /proc/iomem say when you boot up the 2.4 kernel?[/color][/color]
[color=blue]
> cat /proc/iomem says:[/color]
[color=blue]
> 00000000-0009efff : System RAM
> 000a0000-000bffff : Video RAM area
> 000c0000-000c7fff : Video ROM
> 000f0000-000fffff : System ROM[/color]

So, 0xa0000-0xc7fff is being reserved for video memory.

Can you try moving your "bad RAM" area to, say, 0xd0000, and updating
config.opts to match that?

-- Dave

[color=blue]
> So, 0xa0000-0xc7fff is being reserved for video memory.
>
> Can you try moving your "bad RAM" area to, say, 0xd0000,
> and updating
> config.opts to match that?[/color]


Hi Dave,
thanks for the suggestion. Unfortunately I am no mathematician
and can only guess what you're telling me to do.

As I learned until now:

The BadRAM statement is made in lilo by appending
badram=0x010b0000,0xffff8000
which specifies a V1-pattern. The first number is
supposed to be the first RAM-address to exclude, the
second number is a so called mask. Seems OK, because
when parts of a ram-bank fail, the defunct area stretches over
a geometric extension rather than over a logical one.
But I don't understand what this means for my problem.

At least from dmesg (2.4.20) it seems like the badram-
statement defines these ranges:

010b0 =010b0/00000 BFR
010b1 =010b1/00000 BFR
010b2 =010b2/00000 BFR
010b3 =010b3/00000 BFR
010b4 =010b4/00000 BFR
010b5 =010b5/00000 BFR
010b6 =010b6/00000 BFR
010b7 =010b7/00000 BFR

The include statement in config.opts defines (as I
understand it) a memory area. So with the statement
include memory 0xb0000-0xb7fff I order the cardmanager
to use this address-range.

Now 0xa0000-0xc7ffff is according to /proc/iomem
reserved for video-memory. This address-range
includes the range 0xb0000-0xb7fff given in
config.opts, so this won't work.

The 0xd0000-0xd7fff seems to be free according to
/proc/iomem.

So as soon as I come home from my nightshift I will
try to start cardmanager with the option

include memory 0xd0000-0xd7fff

and maybe I could include another option for BadRAM like
badram=0x010b0000,0xffff8000 badram=0x010d0000,0xffff8000
But I am really not shure about that.

Is this correct?

Thanks for your help! I'll post the result as soon
as possible.

Uli


PS: I also see that the BIOS-provided RAM-Map given by dmesg
differ between kernel 2.2.19
000a0000 @ 00000000 (usable)
01300000 @ 00100000 (usable)

and kernel 2.4.20
0000000000000000 - 000000000009f000 (usable)
0000000000100000 - 0000000001400000 (usable)

solved (!)[color=blue]
> So as soon as I come home from my nightshift I will
> try to start cardmanager with the option
>
> include memory 0xd0000-0xd7fff
>
> and maybe I could include another option for BadRAM like
> badram=0x010b0000,0xffff8000 badram=0x010d0000,0xffff8000
> But I am really not shure about that.[/color]

Unbelievable (I myself didn't understand that
'logic') but it seems to work somehow:

append="badram=0x010b0000,0xffff8000,0x010d0000,0xffff8000"
in lilo.conf

and

include memory 0xd0000-0xd7fff
in config.opts

got pcmcia up and running although cardmanager
with the first start still complained:
------
(from dmesg)

Linux PCMCIA Card Services 3.2.5
kernel build: 2.4.20-20.9-badram #1 Mon Nov 3
03:22:06 CET 2003
options: [pci] [apm]
Intel ISA/PCI/CardBus PCIC probe:
VLSI 82C146 rev 00 ISA-to-PCMCIA at port 0x3e0
ofs 0x00
host opts [0]: none
ISA irqs (scanned) = 3,4,5,7,9,10,11,15
status change on irq 15
cs: unable to map card memory!
cs: unable to map card memory!
cs: unable to map card memory!
cs: unable to map card memory!
cs: unable to map card memory!
cs: unable to map card memory!
cs: IO port probe 0x0100-0x04ff: excluding 0x3c0-0x3e7
cs: IO port probe 0x0a00-0x0aff: clean.
cs: IO port probe 0x0c00-0x0cff: clean.
eth0: Me at io 0x300, irq 3, hw_addr
00:01:03:9C:08:33.
ASIC rev 1, 64K FIFO split 1:1 Rx:Tx,
autoselect MII interface.
eth0: found link beat
eth0: autonegotiation complete: 100baseT-FD selected


----

I rebooted again and since then dmesg shows always:

--------
Linux PCMCIA Card Services 3.2.5
kernel build: 2.4.20-20.9-badram #1 Mon Nov 3
03:22:06 CET 2003
options: [pci] [apm]
Intel ISA/PCI/CardBus PCIC probe:
VLSI 82C146 rev 00 ISA-to-PCMCIA at port 0x3e0
ofs 0x00
host opts [0]: none
ISA irqs (scanned) = 3,4,5,7,9,10,11,15
status change on irq 15
cs: memory probe 0x0d0000-0x0d7fff: clean.
cs: IO port probe 0x0100-0x04ff: excluding 0x3c0-0x3e7
cs: IO port probe 0x0a00-0x0aff: clean.
cs: IO port probe 0x0c00-0x0cff: clean.
eth0: Me at io 0x300, irq 3, hw_addr
00:01:03:9C:08:33.
ASIC rev 1, 64K FIFO split 1:1 Rx:Tx,
autoselect MII interface.
eth0: found link beat
eth0: autonegotiation complete: 100baseT-FD selected
--------



So everything seems to be OK. It cost me
additional 32kb of ram, but I am not worrying
about it.

Anyhow, I will now keep both eyes open if the
system runs stable. The first (and up to now very
reliable) test of doing a ls -l in /dev is passed
without problem, so there's much hope.

Thanks, Dave, again very much for that precious hint!
Uli

Ulrich Hansen <uhansen@mainz-online.de> wrote:
[color=blue]
> Unbelievable (I myself didn't understand that
> 'logic') but it seems to work somehow:[/color]
[color=blue]
> append="badram=0x010b0000,0xffff8000,0x010d0000,0xffff8000"
> in lilo.conf[/color]

Remove the first badram range and leave just the new one.

-- Dave

[color=blue]
> Remove the first badram range and leave just the new one.[/color]

Yes, I did so, and: it works great. I already
thought about it, because the BadRAM solution
worked OK with an excluded Ram area of 32kb
before, so it shouldn't need 64kb now.

Thanks for helping to work this out. I am really
happy to have solved this nasty problem after days
of confusion. :-)

It's the best to write the solution down while the
problem is still clear on mind. Therefore I add
now a summary, so everybody who wants to run a
recent linux on a compaq contura aero can profit
from this. I also will add the following text to
my website at [url]http://ulihansen.kicks-ass.net/aero[/url]

Please everybody correct me if I mixed something
up or got something wrong.

Thanks again, Dave
Uli


-----summary of the problem and solution--------

Linux on the compaq contura aero may become
unstable on machines that have been upgraded to 20
MB RAM. This instability is caused by an invalid
access to specific memory addresses above 16 MB.
Linux conflicts here with the pcmcia-controller.

As workaround it is possible to run linux stable
if you limit the aeros RAM with "mem=16M" at boot
or by disabling PCMCIA. This is not satisfying. So
let's take a look at the problem.

The invalid memory addresses can not be described
as a fixed memory hole - it is more like a
_shadow_, thrown by the controllers actually used
memory adresses into an area above 16 MB.

One aero-user, Donald Gordon suspects, that this
behaviour is caused by "incomplete address
decoding. Some parts of the system, including the
PCMCIA controller, may ignore the top 8 address
bits, thus causing a false image of (for instance)
the memory-mapped area used by the PCMCIA
controller to appear at 16mb + expected location".

This 'false image' or shadow in the > 16 MB RAM
adresses, thrown by the real memory addresses used
by the pcmcia controller, was irrelevant with
compaqs stock memory extension modules: They added
only 4 or 8 MB to the aeros soldered in
4MB-RAM-chips and gave it a max of 12 MB RAM.

With the production of third party (Kingston)
16-MB-RAM-Extension-Modules for the aero in the
late 90's, which gave the machine a max of 20 MB
RAM, this shadow became visible -and a problem for
linux users.

A problem that can be solved. Two things are here
important:

- An user-defined setting of the memory that
should be used by the pcmcia-controller. This can
be done with the line "include memory" in the
configuration file "/etc/pcmcia/config.opts" of
the pcmcia-cs-package by David Hinds. The package
must be installed if you want to use pcmcia with
kernel 2.2 or 2.4 and can be downloaded here:
[url]http://pcmcia-cs.sourceforge.net/[/url]

- A patch for the kernel (2.2. or 2.4) called
BadRAM by Rick van Rein (and it's successor BadMEM
by Nico Schmoigl). It allows specifying the
appropriate RAM-Adresses in the 'shadowed area'
that should be avoided by linux.
The BadRAM -patch can be downloaded from here:
[url]http://rick.vanrein.org/linux/badram/[/url]
BadMEM is found here:
[url]http://badmem.sourceforge.net/[/url]
Applied patches for redhat stock-kernels (2.4) can
be found here:
[url]http://dynamicnetservices.com/~will/badram/[/url]


1. Specifying the memory for the pcmcia-controller

With kernel 2.2 I used with success the
ram-addresses "0xb0000-0xb7fff". So try to specify
the ports and the memory that the
pcmcia-controller shall use in
/etc/pcmcia/config.opts with the following values:

include port 0x100-0x4ff, port 0xc00-0xcff
include memory 0xb0000-0xb7fff

All other "include memory"-statements must be
outcommented.

Kernel 2.4 (including BadRAM-patch) seems to react
more sensitive to the ram-map provided by the
aero's bios and reserves pages for the Video-RAM
that formerly were available for kernel 2.2. That
meant with kernel 2.4 we need to search a new free
RAM-adress-range for the pcmcia-controller. This
can be detected from /proc/iomem. So boot linux
with pcmcia disabled and command in the shell:

cat /proc/iomem

For me this created the following output:

00000000-0009efff : System RAM
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000f0000-000fffff : System ROM
00100000-013fffff : System RAM
00100000-00240c09 : Kernel code
00240c0a-00283d5f : Kernel data

Kernel 2.2 used the memory range 0xb0000-0xb7fff.
Now, with Kernel 2.4 this range is reserved for
Video RAM and can not be used. Still free seem to
be the adress-range from Oxd0000 to 0xeffff. So
lets try out these addresses:

So set in /etc/pcmcia/config.opts

include port 0x100-0x4ff, port 0xc00-0xcff
include memory 0xd0000-0xd7fff

All other "include memory"-statements must be
outcommented. The above values work OK for me.


2. Configuring BadRAM

Now with specifying the memory-adresses for the
pcmcia-controller the work is NOT done. We must
keep in mind, that the memory range used by the
controller throws a shadow of unusable
ram-adresses into the > 16 MB range. These RAM
adresses have to be excluded, otherwise linux will
freeze if you enable pcmcia. This can be done with
the kernel-patches BadRAM or BadMEM.

Apply the appropriate BadRAM-patch for the kernel.
The patch "BadRAM-2.2.19.A1.patch" also works for
all above kernel 2.2-versions including 2.2.25.

For kernel 2.4 there are patches from different
contributers. I use the adapted version for the
newest redhat stock - kernel-source 2.4.20-20.9.
After patching the kernel you have a new
kernel-configuration-option under General setup
that is called
CONFIG_BADRAM=y
Please take care to enable that option.

Now specify the RAM-adresses you don't want to use:
either at boottime with the command
linux badram=value1,value2
or in lilo.conf with the line
append="badram=value1,value2"

The two values specify a so called V1-pattern.
value1 is supposed to be the first RAM-address to
exclude, value2 is a so called mask. So the second
value is NOT the last address to exclude but (as I
understand) a description of the geometrical form
of the RAM area that should be excluded. This is
OK for the original purpose of BadRAM: Using
defunct RAM-Modules. Defect areas of a RAM bank
don't stretch over a one coherent logical adress
range, they stretch over a geometrical area on the
physical ram-module.

A description (unfortunately in german) of these
patterns can be found in a report by Nico Schmoigl
for the Linux Magazin:

[url]http://www.linux-magazin.de/Artikel/ausgabe/2001/11/badmem/badmem.html?print=y[/url]

Now how to find out the correct values?

The value2 was provided by Donald Gordon in his
mail to the aero-usergroup. It is 0xffff8000.

value1 depends on the address-range, specified in
/etc/pcmcia/config.opts for the pcmcia-controller.
If you used
include memory 0xb0000-0xb7fff
the correct value1 for BadRAM would be
0x010b0000.

So these are settings for Badram corresponding to
the settings for the pcmcia-controller in
/etc/pcmcia/config.opts:

config.opts corresponding BadRAM-statement

0xb0000-0xb7fff 0x010b0000,0xffff8000
0xd0000-0xd7fff 0x010d0000,0xffff8000
0xe0000-0xe7fff 0x010e0000,0xffff8000
and so on.

For instance with kernel 2.4 I have in
/etc/pcmcia/config.opts the line:
include memory 0xd0000-0xd7fff
So in lilo.conf I must use the line
append="badram=0x010d0000,0xffff8000"

Now we paid respect to the 'shadow' the
pcmcia-controller throws into the >16MB RAM-range,
we exclude these areas with the help of BadRAM and
can now (after a lilo -v) safely reboot the aero
and use pcmcia.


Conclusion

Running Linux on laptops meant once again that
users have to work around errors that were made by
the manufactures, in this case compaq. On the
other hand I can not blame them: They never
thought that the contura aero would once run with
more than 12 MB RAM and never dreamed of Red Hat 9
installed on it instead of windows 3.1. ;-)

My thanks go to David Hinds who helped with
practical tips for finding the correct RAM-values.
And to the linux-community for providing all the
information, knowledge and software.

Linux means learning. Thanks for helping. Hope
this may help others.

Uli

"Bill Marcum" <bmarcum@iglou.com> schrieb im Newsbeitrag
news:<697081-ksl.ln1@don.localnet>...
[color=blue][color=green]
> > cs: memory probe 0x0b0000-0x0b7fff: excluding
> > 0xb0000-0xb7fff[/color]
>
> What do you have in /etc/pcmcia.opts? Is it include or exclude
> 0xb0000-0xb7fff? Try reversing it or commenting it out.[/color]

It was "include memory 0xb0000-0xb7fff".

I have in the meantime solved the problem with the precious help here. I
fully described the problem and its solution in my last mail. In short: the
RAM area defined by the include statement above was already occupied by the
video RAM - so it was automatically excluded by cs. Obviously Kernel 2.4
(with a newer BadRAM-patch) handles RAM areas different than 2.2, so I
couldn't keep the old RAM values. It was still a challenge to find working
values because the memory handling of the aero is quite tricky.

Thanks very much for answering. I have RedHat 9a up and running on a 486 SLC
33 with 20 MB RAM, made 1994! PCMCIA networking works great. I even was able
this evening to compile the pcmcia package new on it. So stability is no
problem any more. Next thing is samba and apache. Yep.

Thanks again
Uli