Next Previous Contents

6. Upgrading

6.1 I've upgraded isapnptools from my favourite distribution and it has wiped out my isapnp.conf file.

This has been reported as a side effect of upgrading Slackware 3.4 to 3.5. I'm sorry, but it must be a bug in the distribution, as upgrading from the isapnptools source will not do this. Please notify your distribution supplier as they should not stomp on user generated files during a package update.

If you get the latest isapnptools, it should be possible to generate a good isapnp.conf file without editting, though you may need cleverer boot up scripts to discover the resource allocations.

6.2 What should I do to upgrade isapnptools.

If you are updating using a non source version of isapnptools, I suggest you make a copy of the /etc/isapnp.conf and /etc/isapnp.gone files if present, just in case they get overwritten.

You may want to regenerate the /etc/isapnp.conf file to take advantage of new keywords which may have been introduced. In this case run pnpdump -c and capture the output, then edit it in comparison to the previous /etc/isapnp.conf file to make the hardware configuration the same.

6.3 I've upgraded isapnptools, and now isapnp gives errors.

Since version 1.16 of isapnptools, resource checking has been added. If your isapnp.conf file contained resource errors, these would have been invisible until you upgraded isapnptools. Note that due to bugs in the resource checking in versions prior to 1.19, resource conflicts may be indicated erroneously.

Adding the line

(CONFLICT (IO WARNING)(IRQ WARNING)(DMA WARNING)(MEM WARNING))
near the beginning of the isapnp.conf file would allow you to restore the previous behaviour.

6.4 I've upgraded my motherboard, and now isapnp can't find my boards.

This could be due to you specifying a READPORT address which is no longer free.

See also Pnpdump reports "No boards found"

6.5 I've upgraded my kernel to 2.4.x, now isapnp can't initialise my Sondblaster AWE.

This has been reported with isapnp v1.18. It appears the default readport of 0x203 clashes somehow with the 2.4.1 kernel, even though it has been compiled without kernel PnP support. The solution was to change the readport address to 0x273 (which has been the default since version 1.19).


Next Previous Contents