Any kernel should do. The real time stuff may not exist in older kernels (1.2.13 and before), but just compile without it.
If you have new hardware, you may need a later kernel anyway.
Note that more and more drivers in newer kernels carry out their own PnP activity, so some ISA PnP cards may not even require isapnptools to configure, though isapnptools can still be useful for diagnosing things.
Version 2.4.x of the kernel will basically have the functionality of isapnptools built in.
You must be root to run isapnp and pnpdump because the program requires direct access to the IO ports.
If you compiled the program using gcc2.8.0 this is very likely due to a bug in the compiler's IO port handling.
Recompile using gcc2.7.2.
If you really must use gcc.2.8.x (like egcs) then you can try recompiling the KERNEL with the ioport.c from one of the later 2.1.xxx kernels, or 2.2.x kernels.
Another cause would appear to be using a binary from one linux distribution on another. In this case (and as I recommend everywhere), simply download the latest version and compile it yourself. It really isn't that difficult.
See also Making a static binary.
The output of
pnpdump should
give you the examples you need for your hardware. If you run it
with the -c (--config) flag, it should even show
how to configure your hardware in the output. The output of pnpdump
is supposed to be used as the input to
isapnp
after editing.
See also README.modules and INSTALL.
Use the -di options with
pnpdump.
The output dumps all the configuration registers for each device, you will have to interpret the results against the PnP spec, but it's mostly obvious.
If you do this before running isapnp you can see the BIOS/power up defaults.
Note that unused registers generally return all zeros. Unused DMA slots should return 4, though some devices erroneously return 0 (which is a valid used DMA channel).
This means no boards were found.
If you have just added a new card into an ISA bus slot, it may be
conflicting with the readport address in your
/etc/isapnp.conf file. You will need to check the resource
assignments in your configuration file to make sure they don't clash
with the new card.
Try re-running pnpdump to see if it comes up with a different readport address, then use the new readport address in you configuration file. If the new card is also PnP, you may also need to copy the configuration instructions across too.
Similarly, if you have changed your motherboard, it may have something clashing with your readport address.
See also Pnpdump reports "No boards found"
A popular READPORT address seems to be 0x273 or 0x277. You shouldn't need to explicitly specify one though as pnpdump can find one automatically.
Are you sure the missing board is configured as PnP ? Many PnP boards come with a DOS utility which allows them to be configured as non PnP, or has jumpers which can be used instead of PnP.
See also Pnpdump reports "No boards found"
Are you sure the board is ISA PnP ? If the board is PCI, it won't be found, neither will it be found if it is not PnP, which could well be the case for older boards. Note that for some cards with similar names, one could be ISA PnP, and one not.
See also Pnpdump doesn't find all the PnP boards in the system.
See also Pnpdump reports "No boards found"
There was a bug in pnpdump somewhere between isapnptools version 1.9 and 1.15 which resulted in incorrect handling of multiple boards (the logical device count for each board was not reset, so only the first board found was correct). I suggest you upgrade to the lastest version.
Use the -i (--ignorecsum) flag to
pnpdump. This flag was added
in version 1.18 of isapnptools.
See also Pnpdump reports "No boards found"
This means that you have no ISA PnP boards in your system. That's easy then, you don't need isapnptools...
If, in fact, you think you should have some ISA PnP boards, there are a few possibilities:
-i (--ignorecsum) flag to
pnpdump. This flag was added
in version 1.18 of isapnptools.
If you did this, and you used two arguments to prevent pnpdump from resetting some device's configuration, upgrade to Version 1.13 of isapnptools, which will do it's own isolation without resetting any device's configuration, even with less than two arguments.
Alternatively, if you are running the DOS version under windows 95, see the README.DOS file in the distribution.
If you don't care if the boards configuration is reset, just run pnpdump with fewer arguments.
If the board has been configured to a fixed setting, pnpdump won't find it. The thing to do is to find the (DOS based probably) configuration software and run it to check the board settings.
If the board is this type, there are two courses of action:
--reset option to
pnpdump.
I've got this too, and it appears that some sort of conflict is
occurring during the isolation sequence for the first (of two) boards,
causing the checksum to fail for every readport address tried. I've
added the -i (--ignorecsum) flag to
pnpdump in version 1.18 of isapnptools
to allow the isolation process to complete in the presence of this
fault.
The fault I've seen looks like there is some sort of bus contention going on, with lower priority devices not dropping out like they should during the isolation sequence: this results in a checksum error on every readport address tried, because the first byte read on the isolation sequence looks like the logical OR of each devices first byte.
cat /proc/pci, with AMI BIOS).
-D
--debug-isolate option to pnpdump. This allows you to see the
details of the isolation process in action. By studying the results,
and the ISA PnP spec, you may be able to figure out what is going
wrong. The code for this is in res-access.c.
See also I've got a ..., which runs fine under Win95, how can I find out the port settings and Examining Win95 resource settings.
and goes on .. "Assuming the card is broken".
What is supposed to happen, is that when reading the resource data, the first few bytes should be the same as the serial identifier (see section 4.5 of the PnP spec). (In the hardware they come from the same eeprom).
Some cards are broken, and don't reset the eeprom read pointer when reading after the sleep state, in this case (detected by the ident byte 0 differs from resource data), we assume the ident stuff has been skipped and we are into resource data proper.
This often comes after Pnpdump reports "Ident Byte x, (..) differs from resource data (..)".
This means that an invalid tag was encountered in the board's resource data. There is no mechanism for re-synchronising, so the resource data dump for that card has been aborted.
There's not much you can do about this. See also What does "End tag checksum 0xb8 (BAD)" mean (in the pnpdump output) ?.
If the word is a valid one, then it could just be that the braces are mismatched in your configuration file. The best solution is to strip out all the comments and examine what is left (the problem may then be obvious). You can do this easily:
cat isapnp.conf | grep -v '^#' | sed '/^$/d' | less
This means that attempting to read back the logical device number failed. The specification is rather unclear on whether this is guaranteed to work, and in any event, it doesn't appear to work with some devices.
There are two solutions:
(CONFIGURE CTL009c/481377 (LD 0
... LD 0 settings
(ACT Y))
(LD 1
... LD 1 settings
(ACT Y))
(LD 2
... LD 2 settings
(ACT Y))
(LD 3
... LD 3 settings
(ACT Y))
)
(CONFIGURE CTL009c/481377 (LD 0
... LD 0 settings
(ACT Y)
(REG 7 (POKE 1) (PEEK)) # Set logical device 1, but no check
... LD 1 settings
(ACT Y)
(REG 7 (POKE 2) (PEEK)) # Set logical device 2, but no check
... LD 2 settings
(ACT Y)
(REG 7 (POKE 3) (PEEK)) # Set logical device 3, but no check
... LD 3 settings
(ACT Y)
))
It means that the resource data read from the board was corrupt, which in turn means that the resource data dump may be wrong. If you know what the card resources really are, you can still configure it with isapnp.
The resource data is often stored in EEPROM, and can be written to via the appropriate accesses. It can be corrupted by a faulty windows 95 driver, or driver crash for example.
See also NT,WIN95,... works ok now, will running isapnp screw it up ?.
This means you have attempted to CHECK the device resource allocation for conflicts using the IO range feature, but the device has already been activated. Either remove the check, or put (ACT N) before the IO allocation.
Note that activated here means the board has been configured and is available for use, it does not mean it is in use. It may or may not have a driver installed in the kernel to use it, and there is no easy way to find out.
If you rerun isapnp, this is very likely to occur. You must first deactivate any drivers using the board. Then, when you rerun isapnp, make sure there is an (ACT N) at the beginning of the device configuration, configure and check the settings, then (ACT Y) and the end to reactivate it. You can then restart the drivers for the board.
This means you have attempted to CHECK the device resource allocation for conflicts using the IO range feature, but the check failed. Either: the device doesn't support IO range checks (which you can find out from the pnpdump output), in which case remove the check; or the device SIZE is too large, in which case correct it; or the test has failed due to a resource conflict, in which case change the IO BASE address.
In versions of isapnp in isapnptools-1.18 and earlier, there was a bug which caused this to occur anyway. A patch to fix it was produced in June 1999. Later versions should work properly.
The configuration file must end in WAITFORKEY.
pnpdump from isapnptools 1.9 neglected to put this at the end of the generated configuration script.
This message occurs if running kernels before the later 2.1.xxx
series. /proc/bus/pci/devices appears in later kernels to
allow the PCI device information to be read. If you have disabled the
proc filesystem, or are running an older kernel, then the isapnptools
programs cannot check resource allocations against those assigned to
PCI devices.
This is unlikely to be a problem, because the resources are likely to be shown used in /proc/interrupts and /proc/ioports etc if a driver is using them. If this isn't good enough, and you still get a problem with resource clashes, just add the PCI resources used to the /etc/isapnp.gone file.
Running a shell script generated by pnpdump -s gives lots of errors like:
./pnp.sh: dev_ids[0]=CTL0043: command not found
./pnp.sh: irq[0]=9: command not found
./pnp.sh: irq_flags[0]=0x0a: command not found
./pnp.sh: dma[0]=0: command not found
./pnp.sh: dma_flags[0]=0x08: command not found
./pnp.sh: io_start[0]=0x0240: command not found
./pnp.sh: io_len[0]=16: command not found
./pnp.sh: io_flags[0]=0x01: command not found
./pnp.sh: ${dev_ids[$i]}: bad substitution
This is due to the shell not understanding array variables. You need a newer shell, such as bash 2.0.x.
No. You won't normally need to reboot. Only if you do something silly like reset the PnP hardware while a driver is trying to use it.
The thing to do is to do all your experimenting with the programs and configuration files first. Only when you have the right settings, load the kernel drivers etc. If you want to experiment some more, unload the drivers first.