The LTRP has been established to provide a central point for issues relating to using Token Ring under Linux.

The linux-tr mailing list exists for the discussion of problems or concerns about token ring support in linux.
To subscribe e-mail majordomo@linuxtr.net with the body of the message containing
subscribe linux-tr

There is a known problem with the mailing list at the moment. If you have a query you can contact me directly at mike_phillips@urscorp.com.

All input welcome, all hardware accepted :-)

Mike Phillips November 19, 2003

If you're really bored you can check out my diary

With the advent of 2.2.x, ibmtr.c was completely updated, which broke the pcmcia driver (ibmtr_cs.c). I updated the pcmcia driver to work with the new ibmtr driver and the 2.2.x kernels. This is where the first level of complication starts. As the pcmcia_cs package is stand alone, it has to support the various different kernels, so instead of being able to have different versions of drivers in different versions of the kernel source, the pcmcia_cs drivers must work with all kernel versions. This not only creates some ugliness in the driver itself but also causes confusion as to which version of pcmcia_cs works for the latest kernel.

At this point, everything was working fine, and then come along the 2.3.x develpment series of kernels. The 2.3.x kernels provided their own support for pcmcia and the ibmtr_cs driver was included in the kernel proper. So now there were two ways of getting pcmcia token ring support, either using the kernel drivers themselves or using the pcmcia_cs package, not too much of a problem because only developers were using the 2.3.x kernels. Of course this all changed when the 2.4 kernel was released and a lot more users started using the kernel.

During late 2000, early 2001, significant development work was done on both the standard ibmtr driver and the pcmcia driver. Original pcmcia updates including using high memory and hot-eject support. These initial updates were only for the 2.2.x kernels, and hence only included in the pcmcia_cs package. Later development saw great improvements in ibmtr and ibmtr_cs for the 2.4.x kernels. (These latest developments have made it into the -ac series of kernels but not into the main kernel tree yet.

So as of writing, 5/21/01, there are many different combinations of kernel version and driver floating around especially considering that different distributions have released different versions of the 2.4 kernels.

You will have to use the pcmcia_cs package and play with the /etc/pcmcia/config.opts, see the section below about config.opts fun. Just about any version of pcmcia_cs that's been released in the last 2/3 years will work fine.

If you really do need to get this up and running, then a recent pcmcia_cs is required and you should be able to grab the ibmtr.c and ibmtr.h from a 2.2.7 - 2.2.16 kernel and use them (note no greater than 2.2.16 !!)

You have to do the config.opts mangling, see the section on setting all this up.

Simply compile up pcmcia_cs and you're done. No need to play with config.opts, in fact if you've been running a previous version that did have the ibmtr_cs line in config.opts it would be a very good idea to remove or comment out the line. The new driver allocates the entire 64k for shared ram and it needs to be aligned on a 64k boundary, if you've got a previous srambase value not on a 64k boundary, the driver will barf and the kernel will panic.

If you want to use the latest and greatest version of the driver with the high memory and hot-swap support you can download the patch and patch up your kernel. Then the line in config.opts can be removed and everything will work fine.

The pcmcia_cs package will not work with the latest drivers, it may work with the 2.4.0-2.4.4 drivers.

I am currently in two minds about providing support with pcmcia_cs for the 2.4 kernels, you can ask me directly or check back every now and then so see if anything has changed.

Hey, I don't care, just give me something that works

OK, try this, it works in most situations, if it doesn't you have to read the rest of the section anyway.
modules "ibmtr_cs" opts "mmiobase=0xd2000 srambase=0xd4000"

The pcmcia driver need to allocate two areas of memory to operate properly. All areas of memory allocated must be aligned on the same boundary as the size of the area being aligned, i.e. a block 8K in size must be on an 8K boundary (0xc8000, 0xca000,0xcc000,0xce000,0xd0000,0xd2000) and for a 16K block must be on a 16K boundary (0xc8000,0xcc000,0xd0000, 0xd4000). All memory areas must be allocated within the ISA address space, 0xC0000-0xDFFFF). Theoretically you should be able to use anywhere within this area, although experience has shown that most machines hide stuff in the 0xc0000-0xc9fff area. Some machines have even been known to use the 0xd0000-0xd1fff area without telling anybody (some thinkpads !!). So you really want to stick with memory allocations in the 0xcc000 - 0xdffff range.
Of course, the two memory areas cannot overlap either ;)

The first area of memory is an 8K area for the memory mapped input/output (MMIO) and must be placed on an 8K boundary. This area of memory is not usually the cause of any problems and can be placed pretty much anywhere, recommended values are: 0xcc000, 0xd0000,0xd2000,0xd4000.
The second area of memory can be sized to fit your desires, this is the area of memory where the incoming and outgoing packets are stored and received. The driver defaults to a 16K memory size and must be placed on a 16K boundary. Good areas are: 0xd0000,0xd4000,0xd8000.

Once you've decided which areas of memory you are goin to try, you need to add the correct line to the /etc/pcmcia/config.opts file. Configuration lines in this file take the format of:
module "module_name" opts "option1=opt1_value option2=opt2_value ...."
In our case module_name is ibmtr_cs. There are three options that be set with the ibmtr_cs driver, mmiobase, srambase and sramsize. If they are not set they will revert to the defaults in the driver, which in 9 cases out of 10 won't work for you. sramsize rarely has to be set unless you are looking for that last little bit of performance from your adapter.
So, having decided upon your values, let's say 0xd2000 for the MMIO and 0xd4000 for the shared memory you would build a config.opts line like this: module "ibmtr_cs" opts "mmiobase=0xd2000 srambase=0xd4000"
The pcmcia_cs package must be restarted for these new options to take effect, i.e. /etc/init.d/pcmcia restart or /etc/rc.d/init.d/pcmcia restart depending upon which run level organization your distribution adheres to.
Then just plug it in and see if it works. If not you'll just have to go back and change the values for mmiobase and srambase until you find a combination that works.
Or, you can upgrade to a kernel/pcmcia_cs version that support high memory allocation, where all this config.opts nonsense is not required and you can just happily plug your adapter in and watch it run.