PCMCIA: unable to map memory - Portable

This is a discussion on PCMCIA: unable to map memory - Portable ; 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 ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: PCMCIA: unable to map memory

  1. 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:
    http://ulihansen.kicks-ass.net/aero/pcmcia-problem

    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









  2. Re: PCMCIA: unable to map memory

    Ulrich Hansen wrote:

    > 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.


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


    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

  3. Re: PCMCIA: unable to map memory

    Hi Dave,
    Thank you very much for answering.

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


    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


  4. Re: PCMCIA: unable to map memory

    Ulrich Hansen wrote:
    > Hi Dave,
    > Thank you very much for answering.


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


    > cat /proc/iomem says:


    > 00000000-0009efff : System RAM
    > 000a0000-000bffff : Video RAM area
    > 000c0000-000c7fff : Video ROM
    > 000f0000-000fffff : System ROM


    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

  5. Re: PCMCIA: unable to map memory


    > 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?



    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)







  6. Re: PCMCIA: unable to map memory

    solved (!)
    > 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.


    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


  7. Re: PCMCIA: unable to map memory

    Ulrich Hansen wrote:

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


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


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

    -- Dave

  8. Re: PCMCIA: unable to map memory


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


    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 http://ulihansen.kicks-ass.net/aero

    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:
    http://pcmcia-cs.sourceforge.net/

    - 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:
    http://rick.vanrein.org/linux/badram/
    BadMEM is found here:
    http://badmem.sourceforge.net/
    Applied patches for redhat stock-kernels (2.4) can
    be found here:
    http://dynamicnetservices.com/~will/badram/


    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:

    http://www.linux-magazin.de/Artikel/...m.html?print=y

    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


  9. Re: PCMCIA: unable to map memory

    "Bill Marcum" schrieb im Newsbeitrag
    news:<697081-ksl.ln1@don.localnet>...

    > > cs: memory probe 0x0b0000-0x0b7fff: excluding
    > > 0xb0000-0xb7fff

    >
    > What do you have in /etc/pcmcia.opts? Is it include or exclude
    > 0xb0000-0xb7fff? Try reversing it or commenting it out.


    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



+ Reply to Thread